Dim varname as someUDT At pMem

[ReneMiner]

Problem as follows:

I create from pb-module a new UDT, like

Local myUDT, myData as String
 
myUDT="Type t_Test" & $CRLF & _
             "lNum_A as Long" & $CRLF & _
             "lNum_B as Long" & $CRLF & _
             "bX As Byte" & $CRLF & _
             "bY As Byte" & $CRLF & _
              "bZ As Byte" & $CRLF & _
             "End Type" & $CRLF

I have some data in memory, to simplify it in this example i use a string here

myData = MKL$(1000) & MKL$(2000) & " @`"  ' = 32, 64, 96

' then i create the udt in thinbasic through the module:

thinBasic_AddUDT(myUDT)

now i am stuck!
How can i dimension from pb-module an absolute tb-variable of t_Test at StrPtr(myData) ?

[ErosOlmi]

thinBasic_AddUDT Core API is used inside a compiled module to add new UDT types at script runtime.
It adds a new UDT inside current script execution allowing a module to injects into a script the UDT that the module expose.

Usually it is executed on Module loading inside LoadLocalSymbols function.
LoadLocalSymbols function is called by thinBasic Core at the very beginning of a script execution
From that point on the new UDT will exist in the script scope

Attached an example of thinBasic UI module source code LoadLocalSymbols function
In UI module many UDT are injected inside the script runtime so programmer does not need to define needed UDT inside the script
Such UDTs do not exist before script execution so you cannot use them before script execution

After thinBasic Core inject the new UDTs at script runtime, programmer can add into thinBasic script something like:

Uses "UI" '---Here thinBasic Core engine will call LoadLocalSymbols function and load all UDT loaded by the module
'---Here thinBasic Core knows about RECT udt, not before

'---Here programmer can use RECT udt to define new variables
Dim MyRect as RECT

'---Here you can use MyRect

without having an error because now thinBasic Core knows about it.

[ReneMiner]

Yes that step i already did. (guess unions will work same way...)

My problem is now to let the module create a variable of the new udt.
I want the udt to be present in the executed thinbasic-script by making use of the thinBasic_Hash-functions which provide memory-access on both sides:

My module shall calculate whatever belongs into the buckets and i want to place an udt-variable onto one of the hash-buckets. The SDK-functions allow to create a variable - but only as number or string -

 '----------------------------------------------------------------------------
  'thinBasic_AddVariable
  '----------------------------------------------------------------------------
  ' Add a new variable to current stack level
  '----------------------------------------------------------------------------
  DECLARE FUNCTION  thinBasic_AddVariable                         _
                          LIB "thinCore.DLL"                      _
                          ALIAS "thinBasic_AddVariable"           _
                          (                                       _
                            BYVAL vName       AS STRING,          _
                            BYVAL lValString  AS STRING,          _
                            BYVAL lValNumber  AS EXT   ,          _
                            BYVAL ForceType   AS LONG  ,          _
                   OPTIONAL BYVAL VarMemPtr   AS LONG  ,          _
                            BYVAL Reserved1   AS LONG  ,          _
                            BYVAL Reserved2   AS LONG  ,          _
                            BYVAL Reserved3   AS LONG  ,          _
                            BYVAL Reserved4   AS LONG             _
                          ) AS LONG

I suppose the optional VarMemPtr allows to place the thinbasic-variable upon a location that is accessible from the module. The reserved parameters are kind of unsolved puzzle, i suspect dimensions count and 3 dimensions but even if it were like this i can only dimension a number or a string - where i would place the value returned by VarPtr() performed on a pb-string - but here also - as with hash, a dynamic string is not the type of data that i want to work with - but my new UDT.

It comes with dynamic "Abilities" powered through a hash-wrapping-class but i want to avoid to force the user to call methods that filter the type of returned results already before a new ability is present, means i don't want to do it like

thinbasic_addMethod(cWrapper, "AddAbility_As_Byte",%thinbasic_ReturncodeByte, CodePtr(cWrap_newAbilityByte))
thinbasic_addMethod(cWrapper, "AddAbility_As_Integer",%thinbasic_ReturncodeInteger, CodePtr(cWrap_newAbilityInteger))
thinbasic_addMethod(cWrapper, "AddAbility_As_Long",%thinbasic_ReturncodeLong, CodePtr(cWrap_newAbilityLong))
'thinbasic_add...                         .... As Word, Dword, Quad, Single, Double, Ext, Currency, Guid, String

since this is limited to standard types only. Also using the class standard-function

thinBasic_Class_Add(cMyClass, codeptr(Exec_cMyClass))

(here Exec_cMyClass) does not allow to define anything that could return something. So there are obviously no circumstances that could make it possible to let user-defined - subelements - properties - methods - return a user-defined type of result - not to mention different kinds of them...



Did i overlook a function? How can i create an absolute variable of myUDT at pMem that is present in thinbasic (either global or local to the current function) where pMem is an arbitrary location in memory|string|hash|heap... and if necessary or helpful i will

Redim x(1 to 1) As myUDT At pMem

in powerbasic (module code)

maybe there is a way to transfer the structure - swap ptr? the idea is to use a fixed-len string-variable ergo byte-array in size of myUDT AS <dummy> to create a virtual variable from pb-module that is accessible in tb and then swap the internal ptrs and structure-information so the variable-type of myUDT is virtually available in a tb-script and its subelements (hash-keys) could pretend to be properties of different user-defined types