LookUp-Table-structure

[ReneMiner]

The idea is simple. Let's say we have different objects as UI-controls that have some unique { ID | Pointer}, unique combinations of names and indexes and some other basic information like of what type they are and maybe some bit-flags etc.

Look at this:



*Table*

ControlID Name Index Type
...
1035 BtnSave 1 tButton
1036 BtnSave 2 tButton
1037 LblFilename 0 tLabel
...


Important is that we setup a structure that allows us to access the desired object fast and easy, clearly structured that helps us keep overview about large amounts of data.

We might create an UDT to store the information.

Usually we would do it like


Type tObject
ID as DWord
Name$ as String
Index as Long
Type$ as String
...
End Type
Dim objectList(123) as tObject

The ID should allow us to find out name and index and vice versa if we know name and index we can retrieve the ID (=dataPtr)
But to scan IDs or Name and Indexes this kind of UDT-ordering is suboptimal, the data in memory is stored alike
ID-Name$-Index-Type$-ID-Name$-Index-Type$...

If we had all IDs in one array, all names in a second array, another array for all indexes and one for the type$:
so ID(7) is corresponding to Name$(7), Index(7) and Type$(7) then we had 4 arrays...

alike the following:


Type tObjectList
ID() as DWord
Name$() as string
Index() as Long
Type$() as String
End Type
Dim objectList as tObjectList

That way we have ordered the information in memory like
all IDs-all Name$-all Indexes-all Type$
The information of objectList.ID(1) belongs together with .Name$(1), .Index(1) and .Type$(1) to the first of our objects.
Still this is not the optimal solution, we need to redim every subelement one by one if we add or remove something from the list. Also to scan the sub-arrays we have to place a layover before and it will be a problem to scan if the array gets sorted previously because the other arrays should always be in the same order as the array to scan...

Now look up to the first code again (where it says *Table*). BtnSave(1) might be the regular Save-button of an app that we create. BtnSave(2) could be "Save as..."
If we search the ControlID for BtnSave(2) we look in the name-column until we found "BtnSave" and then we check the index-column for the "2" until our eyes meet the line that holds both. Then we look at the same row left to find the ControlID...

Thinbasic has a few different kinds of tables like hash table or dictionary module. Those allow only one pair of key + data. But times when variables only had a name and content are long ago. We're heading towards variables that will become objects with even Names, Indexes, pointer to the stored data ( = unique ID ) and some basic information about variable-type (how to interpret data at the corresponding pointer), maybe even states as "Disabled", "Visible" etc. that tell us if the object has to be processed before we even touch its data.

Look up to the *Table* again...
:D
...

Tic-tic-tic...
(Brains working)

LookUp-Table!

Got it?

It needs something alike dictionary module but every stored data-element should be accessible using

- a numeric key (= DWord, Pointer, ID; always a positiv number > 0), unique on the table

- an alphabetical key (name) + optional index (any number in the range of type Long), unique combination on the table

It should be possible to retrieve the other key as well as the attached data, no matter what key is given.



Table tbl_myTable
Identify 1:
DataPtr As DWord
' or ControlID, any unique number...
Identify 2:
Name$ As String
Optional Index As Long
Header 1:
Type$ As String
Header 2:
Visible As Boolean
Header 3:
Enabled As Boolean
Header 4:
BitFlags As Long
End Table


Can there be some flexible data-structure that will allow to access a single element by giving either a numeric key or the name [+ index]?

Where it's up to the user how many additional columns he wants to have?