Hello to the forum!
While working on a project I needed to preload a bunch of values to a stack at initialisation phase at run-time. I couldn't get my head around throwing dozens and dozens of "put ... to tvar commands" in the initial section of the stack. From very early days I could recall that in programming languages like BASIC there was a DATA construct available (not that I am fond of BASIC but this feature was rather cool in some instances). However, this was excactly what I needed but I couldn't find a similiar language construct in LC.
Of course you could argue that I could put the values in an external file in XML or JSON or even flat text form. But I didn't want to have that because I am fond of the notion of a self-contained application and I try to avoid this whenever possible.
Skimming through the different LC forum posts I finally could find a threat of someone who had exactly the same requirement. If you are interested you can find the thread under the subject: "Storing large amounts of data in a script only stack".
In that thread I became aware for the very first time that with LC it is possible to consumate the very own script and do some neat processing with it. While potentially a dangerous thing to do it offered a way for me to solve my requirement pumping a bunch of predefined "hard-coded" values into an array.
Based on that idea I developed a script that reads data lines in CSV notation where the data are encapsulated in the LC comments. But I didn't like three things about the proposed solution in the thread mentioned:
- The absolute reference of the data lines. What happens when I reorganise the code and "line -5 to -1 of the script of me" doesn't contain the data lines involved any longer?
- I have different kind of types of data that needed to be loaded into different arrays
- The way of storing the data lines in the array seemed too limited for my purpose. I wanted to create different array index scheme.
The suboptimal absolute referencing of data lines:
Instead of using an absolute adressing mechanism I defined that a data section needs to have a keyword (called DATASECTION) at the beginning of the data section block in the script and another one (with DATASECTION) at the end of the relevant data section block. Only data lines in between are becoming candidates acting as input for the array load.
Different kinds of different data types for different arrays:
I enhanced the DATASECTION block start and end line with an ID. Having a block start it begins one data section with:
Code: Select all
/* bla bla DATASECTION ID:DBCONFIG bla bla */
--DATA the data line 1 in the DB-config section
--DATA the data line 2 in the DB-config section
::
--DATA the last data line in the DB-config section
/* bla bla end of DATASECTION ID:DBCONFIG bla bla */
/* bla bla DATASECTION ID:NETWORKCONFIG bla bla */
--DATA the data line 1 in the network config section
--DATA the data line 2 in the network config section
::
--DATA the last data line in the network config section
/* bla bla end of DATASECTION ID: NETWORKCONFIG bla bla */
Implementing different ways of array and key structures
I had different requirements for array indexing.
- an array with 1D key dimension using item 1 as it's key and the rest of the data line being in ONE field
- an array with 2D key dimension using running numbers (starting with 1) as it's key for both dimensions
- an array with 2D key dimension using item 1 as it's 1st-order-key and a running number (starting with 1) as it's 2nd-order-key
- an array with 2D key dimension where item1 of each data line acts as 1st-order-key and the column / item acts as the 2nd-order-key (much like a spreadsheet addressing scheme (A1, or C7)
- STANDARD
- NUMERIC
- KEYVALUE
- MATRIXRC
Code: Select all
--DATAFORM (STANDARD|NUMERIC|KEYVALUE|MATRIXRC)
So, this is a well-formed data section entry:
Code: Select all
/* ------ DATASECTION ID:DBCONFIG ------- */
--DATAFORM KEYVALUE
--DATA item1,item2,....,itemN
--DATA item1,item2,....,itemN
::
--DATA item1,item2,....,itemN
/* ------ END of DATASECTION ID:DBCONFIG ------- */
Second, locate the stackname where you have your data section. The stackname needs to be placed as parameter 2 of the function call. This parameter is optional.
Third, call the function LoadData2Array with the DATAFORM name of the DATASECTION as parameter 1 and the stackname (where the data section is located) as the second parameter. When parameter 2 isn't provided LoadData2Array looks for the data section in it's own script.
The call of the function is as follows (example):
Code: Select all
put LoadData2Array("LD2ASTAND", "Load Data 2 Array Demo") into StandardArray.
I hope this script is of value for you.
Diobosco