Results 1 to 3 of 3

Thread: Dim varname as someUDT At pMem

  1. #1
    thinBasic MVPs
    Join Date
    Oct 2012
    Location
    Germany
    Age
    54
    Posts
    1,544
    Rep Power
    172

    Dim varname as someUDT At pMem

    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) ?
    I think there are missing some Forum-sections as beta-testing and support

  2. #2
    thinBasic author ErosOlmi's Avatar
    Join Date
    Sep 2004
    Location
    Milan - Italy
    Age
    57
    Posts
    8,793
    Rep Power
    10
    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.
    Attached Images Attached Images
    Last edited by ErosOlmi; 16-11-2023 at 07:20.
    www.thinbasic.com | www.thinbasic.com/community/ | help.thinbasic.com
    Windows 10 Pro for Workstations 64bit - 32 GB - Intel(R) Xeon(R) W-10855M CPU @ 2.80GHz - NVIDIA Quadro RTX 3000

  3. #3
    thinBasic MVPs
    Join Date
    Oct 2012
    Location
    Germany
    Age
    54
    Posts
    1,544
    Rep Power
    172
    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
    I think there are missing some Forum-sections as beta-testing and support

Members who have read this thread: 3

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •