LiveCode Forums.

This is surely a LiveCode-101 type question, but I’ve never before had reason to create a stack using a group of controls as a background for multiple cards.

One of the first Mac apps I purchased in 1989 was Panorama, which was great for creating flexible database files. But decades and several upgrades having passed, the only option – apart rebooting into macOS 10.6 in order to access those files – is to recreate these in LC.

After exporting one of these dBs as a tab-delimited text file – one line per record – I created a LC stack with the equivalent controls – set as a background group – and thought to populate the stack by creating a new card for each record via a script and setting each control accordingly.

Here’s the problem: Whereas a tab-delimited text item from a given record (line) of the text file is copied properly only into the corresponding LC text field of the current card, trying to set the hilite of a LC checkbox control on the current card actually changes the setting of that checkbox on *every* card.

(For example, if the tab-delimited item = 1 – representing a checked control – then the hilite for the corresponding LC checkbox button should be set to “true” for the current card only, and not for every card.)

I must be missing something really simple as regards managing how button items that belong to a background are set card-by-card via a script. Any insight will be much appreciated.

jeff k

See the shardHilite button property.

I'm curious, though: why is Panorama X not an option for your project?

jmk_phd wrote: ↑

Sun Oct 23, 2022 3:41 am

Here’s the problem: Whereas a tab-delimited text item from a given record (line) of the text file is copied properly only into the corresponding LC text field of the current card, trying to set the hilite of a LC checkbox control on the current card actually changes the setting of that checkbox on *every* card.

As Richard says - the sharedText property regulates this (the 'share text' tickbox in the property pane).

Just had a look at Panorama X - it really is interesting and certainly appears cost-effective and a reasonable DB solution for MacOS.
I have no use for it at present but is definitely one to keep in mind...

stam wrote: ↑

Sun Oct 23, 2022 7:08 pm

As Richard says - the sharedText property regulates this (the 'share text' tickbox in the property pane).

To clarify, sharedText is for field text, and sharedHilite is for button highlights. Parallel in how they're used, but for different control types.

Richard & Stam --

Of course the solution was something so simple. Thanks!

As regards Panorama, I can't say enough good about it: It's incredibly easy to master, very powerful, and (being RAM-based) incredibly fast. My reasons for not continuing to use it are simply mundane: There's no upgrade path from previous versions, and its new subscription model is cost-effective only if one either relies on it heavily (in which case it's worth every penny) or only so sporadically that if never used at all during a given month that credit does get carried over. (I fall somewhere in the middle.)

Plus, I do already have a LC subscription and no other new projects in the works. I figure that although the one record-per-card model will be a minor annoyance, this may prompt me to learn to use LC data grids (which might be able to emulate Paranorama in displaying records in a scrolling window rather than as separate cards).

One last question if possible: Panorama permits option/pulldown menus in a record. When populating a LC stack via script from a tab-delimited text file, both text fields and (thanks to your tip) checkboxes are no longer shared across cards. However, I've not figured out how to set the menuitem for a menu object via script that similarly does not get shared across cards. (No equivalent of sharedText/sharedHilite option in the property inspector for menu buttons.) Is there a trick for this?

For now, I've just replaced the menu buttons with text fields, so that upon importing the tab-delimited file what would be set as the chosen menuItem is displayed instead in a text field.

jeff k

Hi Jeff, is it not just a matter of setting the label of the (option/menu) button to the desired text?

Setting the text if such a button sets the list of options to select from. Setting its label sets its value to what you want it to show. (I may have misunderstood the question?)

stam wrote: ↑

Mon Oct 24, 2022 3:25 pm

is it not just a matter of setting the label of the (option/menu) button to the desired text?

That's what I had expected would happen as well. But instead the result is similar to what happens when the sharedHilite property of a background checkbox object (or sharedText property of a background field) is not deselected: Namely, the label to which the menu button is set on the last record/card created via script retroactively changes the label set for that object on all previous cards.

Either there is no "sharedLabel" property that can be deselected for menu buttons to prevent this, or its existence is documented somewhere that I've not yet been able to find.

I've already tried a number of strategies without success, using as a test case a simple menu btn "ColorMenu" to assign to each record a particular color. None of the following (among others) has worked:

(1) set the label of btn "ColorMenu" of this card to "Yellow"
(2) set the label of btn "ColorMenu" of this card to menuitem 7 of btn "ColorMenu" of this card -- menuitem 7 is "Yellow"
(3) set the backgroundColor of button "ColorMenu" of this card to "Yellow"

In each case, the value set for the last card changes the value set for every prior card.

I *must* be missing something, because even when I create a new card manually -- which displays the background objects for data entry -- the text fields and checkboxes can be changed for that card only, whereas choosing a different menuitem from the menu button on that card changes its value on all.

jmk_phd wrote: ↑

Mon Oct 24, 2022 8:44 pm

That's what I had expected would happen as well. But instead the result is similar to what happens when the sharedHilite property of a background checkbox object (or sharedText property of a background field) is not deselected: Namely, the label to which the menu button is set on the last record/card created via script retroactively changes the label set for that object on all previous cards.

Either there is no "sharedLabel" property that can be deselected for menu buttons to prevent this, or its existence is documented somewhere that I've not yet been able to find.

I think i've just been answering questions as i see them, rather than really giving these any deeper consideration.
So I just re-read your original post Jeff - looks like you want to treat the LC stack with it's card/stack paradigm as a database engine by creating a card for each record. For the problems above as well as many other utility and performance issues i personally would not recommend this - while the original HC may have done this, in modern LC i think there's more a tendency to think of the card as a window layout (i.e. 1 of each), and stacks either being a collection of these layouts and/or the app itself.

If this is really what you do then you can't safely use background groups because you will forever be risking cross-card data alteration. What you could do instead, is clone an existing card and update that with the relevant data if you want to stack to the 1-card-per-record paradigm (ie no background groups - but the layout is copied as is). While this creates exact copies, it also means that down the line when you want to change things you'd be in a world of pain if you decide you want to change the layout but also the data structure. It's going to be very difficult to maintain going forward.

Alternatively
You import the data as a tab delimited file and create a card per record - but why not just store the tab delimited text in a custom property of the stack (personally i would usually converts to an array so it's easier to modify particular fields) and then just write a handler than updates he one card with records as you search/browse... So instead of navigating cards, you're 'navigating' your data source and with a handler just automatically update the interface with the current record. If you have large amounts of data you'd probably benefit from storing this in an sqlite database instead of a text or array in a custom prop.

This would be a much commoner design pattern and for good reason. By separating the data from the interface you have much more design freedom and it becomes a trivial matter to adjust the layout of the 1 card that will be the viewer/editor for each record in your data set...

just my 2¢ anyway...

S.

Stam –

Thanks so much for your thoughtful analysis of the problem I’d outlined.

As a practical matter, I’ve found that by using only text fields and checkboxes in the background group, I can generate (via a script) a new card for each record and set each value independently from the corresponding line items of the CSV text file (which, for convenience, I did in fact save into a custom prop of the mainstack).

If LC menu buttons had a “sharedLabel” property – similar to sharedText and sharedHilite – that could be deactivated, then the label for each option/dropdown menu also could be set independently. (Presumably this was either not possible or not anticipated in the design of the LC IDE.)

Of course I could clone an existing card (sans background) and set the object values manually, but this defeats my original aim of generating a stack of approximately 300 cards/records automatically from the CSV file via script, into which new records could be inserted manually.

You may well be right that it’s not possible to emulate a Panorama database in LC. (And you're right to have guessed that I came to LC from having learned programming decades ago via HyperCard.).

So for now I will confine the stack design to text fields and checkboxes, and will save each menu item in a text field. It’s a bummer that, for example, I might have to type out “Yellow” into the text field of a new card, rather than choosing this from a menu – but I figure that I might be able to script such text fields to fill in the text based upon the first one or two characters entered.

Hi.

There have been several threads recently about this sort of thing. Each wrestles with two ideas, first, to create a separate card for each record, however that is constructed, and second, to create a single "master" card that is populated from a separate repository.

Back in HC days, the rolodex paradigm implied separate cards. Simple, and one could even modify them individually if there was good reason, a real advantage. But LC does not like thousands of cards, and I think it worthwhile to consider keeping the data in, say, a custom property, record delimited as desired, and loading as needed. This obviates the need to clone cards, to manage the shared whatevers, and is a much smaller stack.

"Navigation" would appear identical to a rolodex. All other functionality, such as editing, adding or deleting a particular record would also be indistinguishable, as would such things as the ordering of the several records.

Something to think about...

Craig

I agree that populating a single template card is the best approach in the long run. But if you want to stick to a multi-card stack you can just set the label of the menu button on preOpenCard.

jacque wrote: ↑

Tue Oct 25, 2022 5:09 pm

I agree that populating a single template card is the best approach in the long run. But if you want to stick to a multi-card stack you can just set the label of the menu button on preOpenCard.

The problem with that is that Jeff i think is storing his data in the controls themselves.

To me this is an issue is because he's doing this with backgrounded controls and expecting that each instance of the (same) background will hold and forever store independent data.

To do as you suggest, he would need some card or stack based (or external) storage of the data - in which case he'd might as well just use a template card... Or just go full hog and clone the card so that no background is used, no?

S.

Jeff.

You see that there are many ways forward, but some are better than others. At least in the opinions of those proposing them.

It may be comforting to visualize a simple one-card/one record construct, but when you start adding other gadgetry this may become complicated. Even with the template method, there may be changes required in the master card, based on the particular record being loaded. These changes must be codified and travel along with the data itself. They will be used to manage the loading process.

All doable, and very simply. But a good plan early on is really helpful. Are you comfortable with storing the data and loading it onto the master card? How about coding any particular style and layout changes?

Craig

I'm not familiar with Panorama, but to draw an analog with FileMaker Pro : An LC card is more or less equivalent to a FileMaker Pro 'layout'.
Not sure if that helps

stam wrote: ↑

Tue Oct 25, 2022 5:52 pm

To do as you suggest, he would need some card or stack based (or external) storage of the data - in which case he'd might as well just use a template card... Or just go full hog and clone the card so that no background is used, no?

Well, I'd use a template card myself but if he wants a multi-card rolodex stack then he can proceed as he is now. Set the shared property on those controls that support it, and use a scripted setting for only the controls that don't, like the menu button. When importing the data, a custom property could be set on each card that indicates the label of the menu button for that record.

Or, since the CSV text file is already being stored as a custom property, values could be retrieved from there.