Indexing UI-Objects - rule for callbacks

[ReneMiner]

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