ReneMiner
17-07-2023, 08:41
Since i repeatedly use sdk-functions from scripts (it's not meant that way - i know - thats why i always write this and ...
i just paste it here
' thinCore : watch out! Most of these functions work different when using them in SDK
' or via dll, i.e. MODULE. The variable list by App_listVariables does not
' allow to get variables of a certain stack level but just that were required
' to create UNIT/UDT-wide variable-scopes, means a script-unit declares itsself
' being a variable of type "xyscript.tBasicu" so it has subelements like an udt.
' in all procedures of that script-udt - "UNIT" - will the subelements be dimensioned
' as local virtual layover so these are accessible from the script without keyword ME.
' that creates the illusion of the between unit and end unit dimensioned subelements
' to be variables with a unit-wide scope. Of course in all these procedures can no
' variables be dimensioned nor be used as parameters if these have a name equal to
' one of the subelements. Static variables of the udt "UNIT" can be used to initialize
' the unit but these require ME.-prefix and are not useable for layovers nor byref-
' parameters. in any case some of them could be protected and provide a storage
' for times when the unit goes complete out of scope (none of its functions remains
' anywhere on functions-stack). the local variables inside the units procedures will
' be destroyed on exit function as usually - but the subelements will not loose theirs
' value as long as this instance of the unit is still "alive".
' But these units will not be made alive by creating a variable of it nor will there
' be _Create invoked by DIM somewhat. To allocate the space it requires an access-call
' by TBMain - which can make the unit become a private to tbMain bound Slave-scope that
' will persist for the lifetime of tbMain. If an "exclusive access" is requested by
' tbmain the unit will block all other request ( static variables inside the access-
' point-function will realize this) tbMain has also the power to allow the unit
' to be called from - by tbMain introduced functions or types.
' A Unit can also be completely free and serve anyone but only tbmain can create
' a persistant instance since all others will go when the functions that brought
' them to live will vanish from function stack. Calling a Units function will
' create a new instance - but not dimensioning it. Since this instance is created
' through a call - only the caller receives the pointer to access this instance.
' Any other callers may try and call: it will be another instance and the
' function-pointer (which is a variable local to the caller ) will be stored ...
' exactly... i told it already. the units subelements are where? See, you
' understood. So the unit and its subelements are private to the function that
' invokes the instance. An UDT that is not a unit but just a variable with procedures
' that actually do not hve a common scope can be improved the followng way:
' forget the keywords "PRIVATE" and "PUBLIC" and allow "COMMON" inside the
' declarations-section of an udt. Somewhere between type and end type where
' users define like
' X as Long
' Static Y as Long
' Common Z as Long
' now that's as the unit works in all subelements but for the udt it means to keep
' backward-compatibility and make Z as Long automatic a local variable to all
' procedures of this udt by creating
' Local Z as Long at Varptr(Me)+Udt_ElementOffset(Me.Z)
' and soon is common Z as Long a variable with type-scope-range.
thats from one of my unit-files (without these ideas) - still something else to do.
I made a guid become a UINT128 for the reason to create bitflags that allow to all functions of an udt to get set on an exclusion-list. If one is one the list and has the flag for function xy set then function xy will kick ... return him with no result where he came from. the above is in the air a long time already... maybe someone with insight and knowledge about many undocumented or with misleading names baptized sdk-functions.
pray for thunderstorms of wisdom and knowledge
yours
René
i just paste it here
' thinCore : watch out! Most of these functions work different when using them in SDK
' or via dll, i.e. MODULE. The variable list by App_listVariables does not
' allow to get variables of a certain stack level but just that were required
' to create UNIT/UDT-wide variable-scopes, means a script-unit declares itsself
' being a variable of type "xyscript.tBasicu" so it has subelements like an udt.
' in all procedures of that script-udt - "UNIT" - will the subelements be dimensioned
' as local virtual layover so these are accessible from the script without keyword ME.
' that creates the illusion of the between unit and end unit dimensioned subelements
' to be variables with a unit-wide scope. Of course in all these procedures can no
' variables be dimensioned nor be used as parameters if these have a name equal to
' one of the subelements. Static variables of the udt "UNIT" can be used to initialize
' the unit but these require ME.-prefix and are not useable for layovers nor byref-
' parameters. in any case some of them could be protected and provide a storage
' for times when the unit goes complete out of scope (none of its functions remains
' anywhere on functions-stack). the local variables inside the units procedures will
' be destroyed on exit function as usually - but the subelements will not loose theirs
' value as long as this instance of the unit is still "alive".
' But these units will not be made alive by creating a variable of it nor will there
' be _Create invoked by DIM somewhat. To allocate the space it requires an access-call
' by TBMain - which can make the unit become a private to tbMain bound Slave-scope that
' will persist for the lifetime of tbMain. If an "exclusive access" is requested by
' tbmain the unit will block all other request ( static variables inside the access-
' point-function will realize this) tbMain has also the power to allow the unit
' to be called from - by tbMain introduced functions or types.
' A Unit can also be completely free and serve anyone but only tbmain can create
' a persistant instance since all others will go when the functions that brought
' them to live will vanish from function stack. Calling a Units function will
' create a new instance - but not dimensioning it. Since this instance is created
' through a call - only the caller receives the pointer to access this instance.
' Any other callers may try and call: it will be another instance and the
' function-pointer (which is a variable local to the caller ) will be stored ...
' exactly... i told it already. the units subelements are where? See, you
' understood. So the unit and its subelements are private to the function that
' invokes the instance. An UDT that is not a unit but just a variable with procedures
' that actually do not hve a common scope can be improved the followng way:
' forget the keywords "PRIVATE" and "PUBLIC" and allow "COMMON" inside the
' declarations-section of an udt. Somewhere between type and end type where
' users define like
' X as Long
' Static Y as Long
' Common Z as Long
' now that's as the unit works in all subelements but for the udt it means to keep
' backward-compatibility and make Z as Long automatic a local variable to all
' procedures of this udt by creating
' Local Z as Long at Varptr(Me)+Udt_ElementOffset(Me.Z)
' and soon is common Z as Long a variable with type-scope-range.
thats from one of my unit-files (without these ideas) - still something else to do.
I made a guid become a UINT128 for the reason to create bitflags that allow to all functions of an udt to get set on an exclusion-list. If one is one the list and has the flag for function xy set then function xy will kick ... return him with no result where he came from. the above is in the air a long time already... maybe someone with insight and knowledge about many undocumented or with misleading names baptized sdk-functions.
pray for thunderstorms of wisdom and knowledge
yours
René