Results 1 to 1 of 1

Thread: Indexing UI-Objects - rule for callbacks

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

    Indexing UI-Objects - rule for callbacks

    As currently for UI-objects (dialogs & controls) we have no way of indexing them, especially for callbacks.
    For the other functions and subs i use a suffix on the name since arrays will not invoke the create-functions of udts.

    When i create a
    Local MyDialog As tNewDialog(1)

    the name of myDialog is extended to

    "myDialog_0x0001" for the UI-dialog-class and it works that i can call different subs or functions of
    "myDialog_0x0001", "myDialog_0x0002", "myDialog_0x0003" etc. when i truncate the numeric part and call on the name-part only

    I pass the numeric part additional as parameter to the called function but i can use the same function for all that have the same namepart.



    -( the &H-notation will not work for names ) -

    for example i check
     if All(lenf(sname) > 7,
       Instr(-1, sName, "_0x") = Lenf(sName)- 6) ) then 
       sCallName = Leftf$(sName, Lenf(sName)-7)
       Call_IfExists "" & sCallName & "_someFunction" ( X, Y, Index )
    EndIf
    
    Index is already known and stored as Int16 - that allows negative indexing, useful for controls that will subtract something.
    The test if name has the index appended saves me to add another property just for the case the index = 0
    was assigned. Through being part of the name i also do not need to check if that index is available - a duplicate were already recognized when the variable is created

    this parameter:

    optional byval Index As Int16

    is always last parameter when i call subs or functions on dialogs and controls by name when i used multiple controls or dialogs with the same name-part.
    That allows mainly to have similar dialogs with the same controls names - in case i use it for controls like a grid of 3x5 labels or something
    i tend to use the indexes

    0x1101, 0x1201, 0x1301, 0x1401, 0x1501,
    0x2101, 0x2201, 0x2301, 0x2401, 0x2501,
    0x3101, 0x3201, 0x3301, 0x3401, 0x3501

    - else - the final 01 is on the first dialog, 0x1102 were myLabel(1,1) on the second dialog.

    Int16 serve for now and my needs, probably using Int64 allows 2 bytes for dialogs (-32768 to 32767) and
    6 bytes remaining for the controls in up to 3 dimensions.

    Now the question is, were that possible for callback-functions to truncate "_0x" and what follows
    and pass this truncated portion as parameter(s),
    provide it in a pseudo-variable of any

    Union uIndexes
    qIndex as Quad
    iIndex(4) As Int16 ' 1,2 and 3 as the control-Index in 3 dimensions, 4 as Dialog-Index
    End Union

    or dump it to any buffer the user has to provide?

    That was mainly the question.

    Truncate the numeric part of a name that we can use the same named callback or other function but have the truncated numeric part available ( either user-defined function must accept "byval qIdentity as Quad" or even the truncated part as String or user must provide a buffer where the truncated part is dumped before calling the function by name.

    Also thinkeable if "__" double-underscore contained in the name (not first, not last)
    String sPart()
    if Parse( sName, sPart, "__" ) > 1 Then
    if All( lenf(sPart(2)=18,
    Peek(Byte, strPtr(sPart(2)) )= 0x30 , '"0"
    Peek(Byte,Strptr(sPart(2))+1) Or 0x20 = 0x78 '"x"
    ' starts with 0x|0X 16 digits follow...
    a quad - hopefully
    else
    ' any kind of don't care - a string must swallow it
    ' put the second part to a buffer/ pseudo-variable/ or pass it as parameter
    SpecificIdentity = sPart(2)
    endif
    End if

    Call sPart(1) & "_onCallback" (sPart(2))



    type tNewDialog
       hWnd as Dword
       Index As Int16
        Function _Create() 
            ' the function finds the name of the local dimensioned variable that invoked this
           ' getting the previous functions name from stacklist and the local variables name from
          ' variables list, compares the varptr using thinbasic_variable_GetInfo with varptr( Me ) and knows
         ' the name that the user chooses for the dialog. The other settings the _create-function retrieves from
         ' inifile - where the inifilename contains also the name of the current user - so every user gets its own inifile.
         ' inifile-sections names are equal to dialogs names, so for dlgMain that is created in StartUp, the settings
        ' of Section [dlgMain] are to apply. 
        ' the restrictions of this approach (using _Create-functions to setup controls and dialogs ) are
    
      ' controls and dialogs must NOT be created as GLOBAL variables nor LOCAL variables in TBMain 
      ' since the udts are meant to be temporary only. Global variables are not temporary and local variables inside
      ' of the main function will persist until end of execution also.
    
    ' however 2 more secrets - after this function has created the new dialog it does :
    
      Dialog Set User hDlg, 1, Hash_New(200) 
    ' a hash-tables handle is attached to the dialog! this hash-table contains the "Properties" of this dialog, also controls that 
    ' will be created soon... 
    ' recommendation : HASH-KEYS are case-sensitive. Use $-Equates here for the properties and individual settings. 
    ' further the _Create-function (for dialogs that reside on desktop only - dialogs inside of something use a seperate udt)
    ' after creation of the dialog it will check ini-settings "Menubar" that holds a comma-seperated list of popup-names, add 
    ' these as property $Menubar to the dialogs hash and does the same for the popups that can be called as popupmenu 
    ' and obtains handles for all of those, then  
     Call_ifExists "" & dialogname & "_AddMenu"(hDlg) 
    ' where the menu-creation is wrapped by an udt that is dimensioned as local variable as NewMenu that takes hDlg as
    ' creation-parameter and checks for the name of the function to be _AddMenu" will obtain the hash-handle from dialogs
    ' user slot and switch the hash-tables $CurrentSituation to "MenuAdding" if ok. Not ok were the function that called were
    ' TBMain or global level previous on the stack.
    ' if menu is done it goes back to _create of NewDialog and attach things - if any - measure the dialogs client  and
    ' read in the controls from inifile. finally also
    Call_IfExists "" & dalogname$ & =_AddControls" (hDlg, clW, clH)  that works similar as the menu
    ' users can add controls during runtime - new controls will be saved to ini on exit
    End Function
    
    End Type 
    
    Function StartUp() As Dword
    ' startup-procedure necessary !
    'The following line in TBMain will generate a runtime error:
    
    Local dlgMain As tNewDialog()
    Function = dlgMain.hWnd
    
    End Function
    
    Last edited by ReneMiner; 17-07-2022 at 08:45.
    I think there are missing some Forum-sections as beta-testing and support

Similar Threads

  1. Replies: 2
    Last Post: 24-06-2020, 02:42
  2. Multidimensional indexing in unlimited dimensions
    By ReneMiner in forum General purpose scripts
    Replies: 1
    Last Post: 01-12-2015, 21:52
  3. The ten year rule - Does this apply to programming?
    By LanceGary in forum Shout Box Area
    Replies: 0
    Last Post: 10-12-2010, 11:35
  4. Callbacks
    By Pipes in forum UI (User Interface)
    Replies: 2
    Last Post: 29-05-2009, 16:18

Members who have read this thread: 0

There are no members to list at the moment.

Posting Permissions

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