Oxygen Basic
Programming => Bugs & Feature Requests => Topic started by: Peter on February 18, 2013, 12:08:29 PM
-
Deleted
-
Yes that is strange...
I am not sure that :
Public Declare Function GetCommandLine Lib "kernel32.dll" Alias "GetCommandLineA" () As String
that this work as espected,because when i run this api function this function return
exe name path without command line recieved ...is this normal ???
Grrrr i must look into VB examples >:(
-
I know what type is returned and this is not a problem .
Problem is in what content is returned.
In case where there is no command line arguments given,
returned is full file path of exe from where is called GetCommandLine () function.
....so
when you or me send command line with ShellExecute()
recieved is not only sended filepath then first:
"C:\myfolder.myexe.exe" C:\myfolder2\myfile.txt
So there is a catch...
I have found that this recieved final string must be parsed (one VB and one EB example)
explain all .
In this examples is good because chr(34) " is used as marker for extracting needed string(filepath).
by the way i really don't get it what is wrong with latest oxygen.dll because i have constantly
problem with error that rect type is not defined !
But this is not true... >:(
So what i am do then remove latest oxygen.dll and use older which i found in some older examples.
And it is strange this not heapend one times them every time Charles release new release
old api things from includes simply don't work and constantly crush.,.. ::)
-
Hi Aurel,
Something mysterious going on here. I am checking awinh.inc (download 10 Feb)
I found that the RGB() function was missing but that is not the main cause of the problem.
Charles
-
I am working on a new Sdl library, everything without tricks ...
I was right! SW is a wrapper for SDL. I just started looking at sdlBasic source and how they integrated SDL into the language.
-
SDL is too much work for me when I have very little interest in this type of programming.
I'm looking forward to future releases of Simple Windows and hopefully it will work outside the O2 environment.
-
Hi Aurel,
Something mysterious going on here. I am checking awinh.inc (download 10 Feb)
I found that the RGB() function was missing but that is not the main cause of the problem.
Charles
Hi Charles...
Yes it is really something mysterious.
I see some weird problems with global strings when they used inside subs...just
crush app in the second.
-
DLL bstr arguments.
(http://us.123rf.com/400wm/400/400/brentmelissa/brentmelissa0711/brentmelissa071100002/2019633-skeleton-hung-by-a-noose-isolated-on-white.jpg)
-
No it's you ;D
-
Here is the latest awinh.inc
which work with older oxygen.dll for me.
Charles maybe you can compare them with new and see what is wrong.
X
-
And here is part of code inside exe who respond on GetCommandLine()
'in global scope...
string fileName=""
fileName = GetCommandLine()
print fileName
LoadFromFile()
'then subroutine...
SUB LoadFromFile
string source="",fPath=""
INT qpos,sf
qpos=instr(1,filename,chr(34))
qpos=instr(qpos+1,filename,chr(34))
fPath = Mid(filename,(qpos+1),255)
SendMessage edit1,WM_SETTEXT,0,strptr(fpath)
fPath=Trim(fPath)
IF fPath = ""
MsgBox fPath, "File NOT Found"
RETURN
END IF
source = GetFile fPath
SendMessage richedit1,WM_SETTEXT,0,strptr(source)
END SUB
And i found that string function Mid( in$,start,LEN(in$))
cose crush because LEN(in$) is somehow broken. ???
-
Hi Aurel,
Awinh is a mosaic of different coding styles, which is good for stress-testing oxygen :)
I found a sensitivity to variable names with _leading underscores, which I have now fixed.
Also the location of #lookahead needs to change. It should be located below equates and types. Preferably just before you functions and subs. I hope to make #lookahead more robust in future releases
#lookahead scans below, for subs and functions then generates declare statements, which may rely on type definitions defined previously.
See if this fixes the len() problem
Charles
X
-
Hi John,
I have now added Ascii/Wide String conversion to DLLC. You will also need the dreaded GUIDs for COM, and things like GDI+ image codecs, so I have added that as well.
Not quit sure how to handle COM calls yet. Without OOP infrastructure, they can be very nasty.
Charles.
PS: A diet of bstrings is not suitable for a skeleton. I recommend a large bowl of porridge for breakfast every day :)
-
WOW!
That really sounds awesome Charles.
Does DLLC stop the leaking with bstr's in SokoMouse? All that should be needed to test it is swap out the DYC calls in the SB version of sw.inc. The main program (SM.sbx) shouldn't have to be touched.
Not quit sure how to handle COM calls yet. Without OOP infrastructure, they can be very nasty.
Jose Roca has been doing COM/OLE Automation for years. (even before Zale changed his mind and stopped saying COM was bloatware) Can't we use Jose's direct calling method without the OOP style .dot. notation?
-
We can live without dot notation but the problem is how to reference all the calls available, without huge headers. Some COM interfaces have dozens of the blighters.
-
I found a sensitivity to variable names with _leading underscores
Hi Charles...
Yes i forget to tell you this and also problem sometimes is when variable name
begins with upper case not with lowercase i hope that you fix this to.
Yeah...awinh is a mosaic of different things and styles because is picked from many
source codes around( some of them are from XBLite)
and need cleaning.. ::)
-
Charles..
It looks that Len() now work fine but problem with RECT is still here >:(
Why work with old dll ...size 409kb but not work with this new 455kb ?
X
-
In attachment is oxygen.dll version which work with awinh.inc.
This same version of dll is used by Peter in his oxyMap Tutorial 1 with include sw.inc (18kb).
X
-
Hi Aurel, I had to reconfigure the early compiler passes in the recent Oxygen version.
Have you tried moving #lookahead down to the start of your subs and functions. Personally I prefer working without it as I find programs easier to debug when subs and functions are parsed in their natural order, with minimum need for declarations.
Charles
-
Personally I prefer working without it as I find programs easier to debug when subs and functions are parsed in their natural order, with minimum need for declarations.
SB works the same way. You must use a CALL for forward referenced functions.
-
We can live without dot notation but the problem is how to reference all the calls available, without huge headers.
I don't see users writing full blown COM applications with SB and DLLC. The concept is dynamically scripting only the functionality you need for your application from multiple API resources without the linking, headers and whatever else to get it all to play together. Jose's typelib browser generates direct call functions for PB which should be enough info to make the call with DLLC.
Notice the SBx wrapping functions that encapsulate a DYC or SB IUP extension module function and presents itself as a high level SB language function with all the relaxed syntax benefits (no DIMS, DECLARES, DEFINES and TYPELESS variables that know what they are when referenced) for a nature extension to the core language and named whatever the user so desires. (see SBx include for the SBx_buttons example)
Peter had mentioned before I started converting the SokoMouse game to SB that I may have issues getting Bass sound integrated with the game. I did a quick Google search for an API to play .wav files and MS MM had just what I needed with just one call. This is what I'm talking about with using dynamic scripting. You build your custom SBx DLLC based wrapper function once and included it from your custom library whenever you need that functionality again somewhere else.
-
Have you tried moving #lookahead down to the start of your subs and functions
No.
I think that is better to have #lookahead on top and i think that this is not problem in #lookahead.
But of course i can move #lookahead down and try ... ;)
-
Yes i move down #lookahead in awinh.inc and new dll finaly work.. :)
I think that you say me that i must move #lookahead in main program not in include file ::)
Thanks.. :)
Charles , I see that new dll need little bit more time to compile same program then old dll.
Is this connected with size of dll ?
-
Glad it worked, Aurel. I had the same Rect error. This is because rect is used in one or more of the lookaheads, and needs to be defined first.
Yes it takes slightly longer to compile. There are additional early passes. But when the code has very large headers with thousands of declarations, the compilation speed has improved by a factor of 10 or more. You can see it when you try Kent's VB Api: ProjectsB/WinApiVB6
Charles
-
Hi John,
Joses TLB browser only deals with Idispatch COM interfaces, which are particularly horrible. (I don't mean the browser).
The lower level access to COM is through the IUnknown based interfaces (or Punk interfaces if you will). I can cope with those quite easily.
They come from the winapi headers. Speech (SAPI) is the only one which interests me so far.
Charles
-
Direct Interfaces - Generates declarations for custom and dual interfaces. Dispatch only interfaces are skipped.
Direct interface is how it all began before PB embraced COM and started adding keywords to handle the low level stuff.
Have you tried generating PB direct COM interface code from Jose's browser yet?
' ########################################################################################
' Interface name = ISpeechGrammarRule
' IID = {AFE719CF-5DD1-44F2-999C-7A399F1CFCCC}
' ISpeechGrammarRule Interface
' Attributes = 4160 [&H00001040] [Dual] [Dispatchable]
' Inherited interface = IDispatch
' ########################################################################################
#IF NOT %DEF(%ISpeechGrammarRule_INTERFACE_DEFINED)
%ISpeechGrammarRule_INTERFACE_DEFINED = 1
INTERFACE ISpeechGrammarRule $IID_ISpeechGrammarRule
INHERIT IDispatch
' =====================================================================================
METHOD get_Attributes ( _ ' VTable offset = 28
) AS LONG ' [retval][out] *Attributes SpeechRuleAttributes <enum>
' =====================================================================================
METHOD get_InitialState ( _ ' VTable offset = 32
) AS ISpeechGrammarRuleState ' [retval][out] **State ISpeechGrammarRuleState <dispinterface>
' =====================================================================================
METHOD get_Name ( _ ' VTable offset = 36
) AS WSTRING ' [retval][out] *Name VT_BSTR
' =====================================================================================
METHOD get_Id ( _ ' VTable offset = 40
) AS LONG ' [retval][out] *Id VT_I4 <Long>
' =====================================================================================
METHOD Clear ( _ ' VTable offset = 44
) ' void
' =====================================================================================
METHOD AddResource ( _ ' VTable offset = 48
BYVAL ResourceName AS WSTRING _ ' [in] ResourceName VT_BSTR
, BYVAL ResourceValue AS WSTRING _ ' [in] ResourceValue VT_BSTR
) ' void
' =====================================================================================
METHOD AddState ( _ ' VTable offset = 52
) AS ISpeechGrammarRuleState ' [retval][out] **State ISpeechGrammarRuleState <dispinterface>
' =====================================================================================
END INTERFACE
-
Yes I had a look at speech
I did some work on Idispatch and also creating COM servers many years ago. So I could go back in time to review it. Idispatch was developed for vbscript and other scripting systems originally, but it is not pretty.
-
I'm not interested in creating a DLLC INCLUDE wrapper for COM interfaces. I just want to look at a typelib dump of a COM component and pick and choose what functions I need out of it for my script application. I will save the created snippet of code in my custom SBx (or whatever you want to call it) for use again without the chore of building the SB wrapper function for it again. DLLC should be a FFI tool with helper functions to satisfy requirements the API interface may require.
-
Only need to select the required GUIDs and also pass an index value to select the methods
But you may need a degree course to understand how to use some of these COM interfaces :)
-
But you may need a degree course to understand how to use some of these COM interfaces
All we need to do is show how a couple functions out of a COM interface works scripted, and I'm sure others will think it's a cool way to program and contribute their SB COM wrapper functions to the library pool. Maybe this would be a worthy project Jose Roca may enjoy as there really isn't anywhere to go with PB any longer.
-
Charles,
Are you going to handle Variant type variables internal to DLLC and pass SB a type it can handle?
John
-
I can deal with Iunknown, but I think the full Idispatch and all its side dishes will be a feast of development for somebody else to enjoy :)
Charles
-
I'm pretty sure all ActiveX controls use dual interfaces. That is good news if we want to use the IUP COM/ActiveX container. I'm sure I can find a OLE Automation (http://support.microsoft.com/kb/181473) library out there that will provide the basics in the form of an extension module.
DLLC is going to be a very cool extension module that is going to take scripting of APIs to a whole new level.
Once I see a working COM example with DLLC, I may take a shot at creating a parser that would convert Jose's TypeLib direct interface output to SB wrapped high level functions. Fun times ahead.
COM in plain C (http://www.codeproject.com/Articles/13601/COM-in-plain-C)
Intercepting Calls to COM Interfaces (http://www.codeproject.com/Articles/153096/Intercepting-Calls-to-COM-Interfaces)