Some guidance, please, on card layout.

[AtoZ]

I’m just at the start of a project and I’d like some input as to which way to go with it, before I get deep into the work and discover that I’ve gone wrong.

There is one card in the project onto which I must place 230 small text containers (for lack of a better word). The user will NOT input any information directly into the containers (that will be handled by pop-up dialogs). Usually, the user will not want to save the information (it’s useful only for the current session), but if the user wants to, the info will simply be saved as a long text string or two and then reloaded onto the card at a later time. Because of the arrangement of the text containers and various design considerations, it wouldn’t be practical to place them in a table or data grid.

So here’s my question: what would be the best remaining type of text container for this info? It could be fields, buttons, or even label fields. I would think of the three, that label fields would use the least memory.

I would appreciate any comments about the pros and cons of the available choices (and any other suggestions as well).

Also, I would welcome any suggestions about the best way of inserting and retrieving info from these many containers. At the moment, I’m thinking of naming them “R 1 C 1”, “R 1 C 2”, etc., and then, like a spreadsheet, accessing the correct field using chunks of their names. (I suppose I could also store the grid location of each container as a Customer Property of the container, but I haven’t worked with Custom Properties yet, so I’m not sure of their pros and cons for this purpose.)

[Mark]

Hi,

Fields and label fields are the same. The amount of memory they need depends on their content, not on whether they're a label field or a regular field. The only difference is that label fields have the transparent property set to true, the textAlign to right, the textStyle to bold and the lockText to true. You can change the looks of a field in (almost?) any way you like.

Perhaps, a simple way to store the values of the fields would be to use an array and save this array as a custom property or in a file (it is possible to decode an array to save it in a file).

You can make a list of all fields and use "repeat for each" or give each field that you want to save a special custom property (you can do that in the properties inspector).

For example

Code: Select all

on saveFields
  repeat with x = 1 to number of fields of this cd
    if the cUserValue of fld x is true then
      put fld x into myUserValuesArray[the id of fld x]
    end if
  end repeat
  put arrayEncode(myUserValuesArray) into url "binfile:~/desktop/uservalues.dat"
end saveFields

on readFields
  put url "binfile:~/desktop/uservalues.dat" into myUserValuesArray
  if the result is empty then
    put arrayDecode(myUserValuesArray) into myUserValuesArray
    repeat for each key myKey in myUserValuesArray
      put myUserValuesArray[myKey] into fld id myKey
    end repeat
  end if
end readFields

This is only an example. You need to adjust it to your own needs.

Kind regards,

Mark

[AtoZ]

Mark, thanks for your post.

I've added your script example to my sample script collection. I haven't yet gotten around trying saving to an external file, so your sample will be helpful. I can see easily enough (I think) how to adapt it to my own situation.

One concern I have about storing program info in external files (and the same applies to storing images in external files) is the possibility of users modifying or moving those files. Are there any strategies for preventing or minimizing this possibility?

It's good to know that only content affects the memory requirements for the different types of fields. While we're talking about this, do buttons take up any more or any less memory than fields?

[Mark]

Hi,

You might save files in th application support folder (Mac) or in the program data directory (Win). This is an option of you always need the same files and there is no need for users to copy the files to another computer. Normally, users don't look in those directories and if they do they'll probably understand that one should not mess with files located there.

Text is text. It doesn't matter whether it is in a field or in a button. Both buttons and fields are capable of tasks that require a lot of memory. It really depends on what you do with these controls. I wouldn't worry too much about it.

Kind regards,

Mark