Retain code functionality on cloned card

[dalkin]

Hi there. I have a project in mind that is based on word play and I have created a card in a Sub-stack that works well, and (because it's in a sub-stack) saves in a standalone, with simple code such as:

on mousedown
put the selectedText of me into field id 1011
end mousedown

and

on returnInField
put return before line 1 of field id 1011
put field id 1010 before field id 1011
put empty into field id 1010
end returnInField

I also want a user to be able to import a sound file that is specific to a single card and populate a scrolling list field (on another card). So far, the test build works fine when a single card is involved. The attached graphic gives some idea of the layout but I have 2 questionS I can't seem to move past.

1. If I clone a card, it creates a new card and all cloned objects (fields and buttons) have their own IDs, which is just great! but because the scripts now have to work with new IDs, the scripts don't work on the cloned card. Is there a way to dynamically update the IDs and put those values into the cloned script?

2. What is the best strategy for importing a sound file (any format that is supported in the Player) and storing it in the card?

Any and all suggestions will be most appreciated.

[dunbarx]

Hi.

Not sure exactly what you are up to, but consider this. Using explicit ID's as control references seems like a precise way to identify those controls, right? And your issue is that they are TOO precise, right? Too explicit.They cut across the entire stack.

Can you change your thinking a bit, and step back a little? Use the fact that the controls on the cloned card are owned by that new card. So if you have a handler that refers to a control by, say, number, that number will be unique to that card, and all would be well. On any random card:

Code: Select all

put random(999) into fld 3

That is, field 3 on the current card. Similarly, names are also local to the card they are on. So I am suggesting that you use a less unique identifier than ID's in the first place. Take advantage of the locality that LC's card structure offers and rethink the way you are thinking. If your handlers use these other methods of reference, that structure will automatically keep everything tidy.

Craig

[dalkin]

So grateful dunbarx! The answer is contained in the simple observation that "Similarly, names are also local to the card they are on." I would never have discovered that in a million years. It now works like a charm.

[Klaus]

...I have created a card in a Sub-stack that works well, and (because it's in a sub-stack) saves in a standalone, ...

If your application will be installed in the platform specific "Applications" folder, then only users with ADMIN permissions are allowed to write (= save something like a stack) here!

AND a substack is part of the application file and can NOT be saved anymore!

[bogs]

AND a substack is part of the application file and can NOT be saved anymore!

Unless, of course, the sub stack is part of a launcher stack solution.

[dunbarx]

Unless, of course, the sub stack is part of a launcher stack solution.

What Klaus means is that the substack of interest is not in the executable, or "splash" stack file, but rather must be part of any other stack file attached to that executable.

Craig

[dunbarx]

Dalkin.

Glad it now works. And glad that you see a little deeper into the workings of LC.

I rarely use ID's. Because they are "owned" by the stack, they do not care at all in which card they live. This can be very powerful, in that one can find them easily, and a pain, as you now know, because they are so haughtily independent.

Try always to use names or numbers. Names because they are descriptive and numbers when you may want to order controls under script control. But NEVER use numbers as names. LC will not know that "button 3" is the name of a button; it will assume you are speaking about the third button in layer order. Use something like "btn3" instead. Then you can extract the numerical portion of a name to process a suite of controls.

Craig