Results 1 to 1 of 1

Thread: LookUp-Table-structure

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

    Question LookUp-Table-structure

    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...

    ...

    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?
    Last edited by ReneMiner; 24-03-2018 at 06:43.
    I think there are missing some Forum-sections as beta-testing and support

Similar Threads

  1. 12,000-year-old unexplained structure
    By Charles Pegge in forum Shout Box Area
    Replies: 0
    Last Post: 16-07-2012, 07:31
  2. online Interactive Periodic Table
    By zak in forum Science
    Replies: 0
    Last Post: 07-04-2012, 07:46
  3. Forum structure
    By ErosOlmi in forum Web and Forum
    Replies: 14
    Last Post: 15-08-2010, 06:32
  4. thinBasic language/Script structure/Execution directives/#DEFAULT
    By Petr Schreiber in forum Fixed or cleared errors in help material
    Replies: 2
    Last Post: 08-11-2007, 01:56
  5. thinBASIC language/Script structure/Functions
    By Petr Schreiber in forum Fixed or cleared errors in help material
    Replies: 1
    Last Post: 07-11-2007, 22:10

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
  •