This first attempt prompts the user for two integers, two longs, two floats, and two strings via a dialogbox. The values are written to the allocated memory block using the memwrite command, cleared, and then read back via the memread command. The primary downfall with this script is that you had to perform all the read and write operations manually in the script.
My second script added a procedure called access_mem that would read or write all variables associated with a memory block. This made it easier to store and retrieve the values as only one command was required in the main procedure. However, the syntax is a bit unwieldy since you have to specify all variables in the memory block when calling access_mem. To be able to store different data types with each call to access_mem would require a separate procedure to write and read each data type stored in the structure. One possible workaround to this would be to make all the member variables of the structure global variables and have access_mem directly store and read those values instead of requiring them to be specified in the procedure call.
For my third try, I modified the second script so that all values were stored as string values in the memory block by using ltoa, ftoa, and itoa to convert to string and atol, atof, and atoi to convert back. This works fine for integers and longs, as their maximum values can be held in 11 bytes when represented as a string, which is only a slight increase from the usual four bytes required for this data type. However, large or very precise float values cannot be represented in the 256-byte limit imposed on string variables. Due to this restriction, this attempt allocates 11 bytes of string storage for each string representation of a float value (mostly to make the math easier). The downside of this approach is that non-string data types must be converted to strings when stored in memory, and converted back to the original data type when retrieved. This also has to take place in the calling procedure rather than being tucked away in the procedure that performs the reading from and writing to memory.
This attempt takes the work done in struct2.was, makes the member variables globals, and stores or retrieves one member variable per procedure call. All of the work is done in the access_mem procedure with the user only needing to pass three pieces of information (the memory ID, the index of the variable in the structure, and whether to read from or write to memory). Additionally, if the structure index in the procedure call is -1, then all variables in the structure will be read from or written to memory.
This last script makes it easy to implement linked list structures in ASPECT. I hope to have a sample in the near future that illustrates some operations on a linked list where each entry is stored in memory blocks.
One thing to keep in mind when using the above examples is that I used 256 bytes for all string variables, as it is the maximum size of a string in ASPECT. However, you will want to use a smaller value more in line with the data expected in your script so you are not needlessly using memory. One step you will want to take is to check the length of any strings before they are written to memory to make sure they will not overwrite other values in your memory block or elsewhere. See lines 63-66 of struct3.was to see how to perform this check and truncate the string at a set value, if necessary.