Function Address

[peter]

Hi Eros,

How can I get the address from a Sub Routine or a Function ?
Do we have a command for for that ?
I need the address where my Function/ Sub lies.
As well as : addressOf(Function) under Visual Basic !
Peter

[ErosOlmi]

I'm sorry peter but this is impossible.
There is no addressof of a script function because thinBasic does not produce any intermediate or compiled code but just pure parsing.

I have to say that thare could be some trick for the future in order to be able to get back a real addressof to a compiled code but this is thinBasic vaporware for the moment so better not to talk.

Anyhow, if you can give some more info about what you are doing maybe there are different roads to follow but I'm quite sure you are doing some interfacing with external libraries that require a pointer to a function where to pass data to be handled and get back.

Sorry.
Eros

[peter]

Hi Eros,

i am trying to fill a structure.
Type WNDCLASS
style As Long
lpfnWndProc As Long
cbClsExtra As Long
cbWndExtra As Long
hInstance As Long
hIcon As Long
hCursor As Long
hbrBackground As Long
lpszMenuName As String
lpszClassName As String
End Type
"lpfnWndProc", needs the address !

[ErosOlmi]

No way, sorry.

WNDCLASS is used to create a window or a window control passing the structure to CreateWindow or CreateWindowEX.
It is the same as thinBasic DIALOG NEW ... or CONTROL ADD ... but all the complex matter is handled by thinBasic user interface module.

To be helpful I need to have detailed info about what you want to do otherwise quite complex to understand.

Ciao
Eros

[peter]

Okay, Eros

I will try another way.
Thank you.

[ISAWHIM]

peter, I was running into this same issue...

I am researching this also... AddresOf is specific to VB, and actually refers to an "EntryPoint", as if the file were a DLL. Windows has no idea that "%ButtonID" or "MyFunction()" exists, unless ThinBASIC explicitly reserves or assigns an internal entry-point value to it. The API-CALL will tell ThinBASIC... "I have a request to trigger "EntryPointAddress(123), with this data to pass (ReturnVal1, ReturnVal2, ReturnVal3)"

That would trigger a ghost CALL to that function or variable or sub, as if something inside your program called it.

AddressOf function
http://msdn.microsoft.com/en-us/library/y72ewk2b(VS.80).aspx
Delagates operation
http://msdn.microsoft.com/en-us/library/74wy9422(VS.80).aspx

The 1.7.0.0 "Beta" version, opens ThinBASIC to the world of CALLBACKS. Thus, my interest in this specific communication door.

To me... this translates into a (hWnd) or a (CBHNDL)... But, as a "Pointer". {Thus, address-of.} That function lies in "Windows Memory", and that "Pointer" is the location of that block in memory.

What isn't well known is that functions reside in memory as well, and therefore it is possible to store the address of a function in a pointer.http://bcbjournal.org/articles/vol4/0007/Understanding_function_pointers.htm

More citations...
(Passing Function Pointers to DLL Procedures and Type Libraries)
http://msdn.microsoft.com/en-us/library/aa263529(VS.60).aspx

Windows manages the callbacks, ThinBasic only responds to them. From what I understand, CBHNDL is a windows hWnd for that CALLBACK function, thus, is an "AddressOf a function"?
http://www.15seconds.com/issue/021002.htm

Once a callback is created, that "Function" is in memory. (It becomes used to handle all clone data, for devices which call that function. API calls that function by the pointer/CBHNDL, as does ThinBASIC.)

I am not sure of the relevance of this statement... But... Eros would know if it is of importance.

Note You can create your own call-back function prototypes in DLLs compiled with Visual C++ (or similar tools). To work with AddressOf, your prototype must use the __stdcall calling convention. The default calling convention (_cdecl) will not work with AddressOf.

This page sort-of makes sense... but I believe it only states what I have already suggested above. (Not sure, they assume the viewer already knows some things.)
http://home.hot.rr.com/graye/Articles/Delegates_AddressOf.htm

There is a small issue with "Filling" that TYPE...
Types here must have a fixed-length strings. (In case of string element, it is mandatory to specify a fixed size string.)
You have not defined a string size, so your string is "0" length, it will never fill with a value.

You would have to create a TYPE after you know the SIZE of each string, or remove the STRING elements from the TYPE, while you process those separate.

Type WNDCLASS_Head
style As Long
lpfnWndProc As Long
cbClsExtra As Long
cbWndExtra As Long
hInstance As Long
hIcon As Long
hCursor As Long
hbrBackground As Long
End Type
GLOBAL lpszMenuName As String
GLOBAL lpszClassName As String
GLOBAL MyHeadType AS WNDCLASS_Head

GLOBAL WNDCLASS AS String

When you want to "FILL" it...
WNDCLASS = MyHeadType & lpszMenuName & lpszClassName

To Read from it...
MyHeadType = MyReturnValueFromSomePlace
WNDCLASS = LTRIM$(MyReturnValueFromSomePlace, MyHeadType)

You have "lpszMenuName" and "lpszClassName", left inside "WNDCLASS". You can separate them by "Delimiter", or if you know the length of any one of those items.

lpfnWndProc would the CBHNDL of the window that has a CALLBACK assigned to it. (No callbacks, than you can not have a callback address. You need version 1.7.0.0+ to use that ability.)

[peter]

Hi ISAWHIM,

at first, thank you for the bunch of information.
I want to see what I can do therewith.
Everything is very interesting for me.
In this way, you cannot get enough stuff !
best wishes..

Peter

[ErosOlmi]

You can call in many different ways: AddressOf, CodePtr, FuncPtr, ...
Result is the same: you just get back an address in the code where the function resides in memory (code area). You can get an address of a function or of a label or other special statements

To keep it simple it is, more or less, like a GOTO statement. A position where the execution pointer jump and where the compiled code of the function reside. At that point there will be code to pop function parameters (if any) and the machine code of the function itself. The code will ends when a RETURN will be encountered.

It is like a VARPTR of a variable that return a pointer to a memory location where the variable data is stored.

When you executed a thinBasic script, it is parsed and executed on the fly. This permits great flexibility but pose some limitations like not having any machine code where to jump to or from which ask an AddressOf. There is just text source code.
In this behave thinBasic is quite unique because almost all interpreted programming languages create some sort of intermediate pre-parsed code usually called pCode. This is mainly done to increase execution speed.

Anyhow, there is nothing I can do at the moment to return something close to an AddressOf.
But I have some idea on how to "wrap" a functionality similar to AddressOf. But, again, this is future and not so close.

Ciao
Eros