pathToContainer and "do"

[Simon]

Hello all,
I have a variable "pathToContainer" that has "of group id 1036 of card id 1002 of stack "C:/Users/Simon/etc." in it.
using

Code: Select all

do "put "&quote&"PARTY"&quote&" into fld "&quote&"Comment"&quote&""  && pathToContainer

does work but if I add another variable

Code: Select all

do "put "&quote&"PARTY"&quote&"" && it && "into fld "&quote&"Comment"&quote&"" && gOwn

it fails miserably.

The first step which I seem to not be able to get my head around is "How do I do this without the "do"?"
If I have to use a "do" how do I get the second variable into it?
scriptLimits- the 10 lines - Does that mean 10 lines at most per object or 10 lines per stack?

Thanks for your ideas,
Simon

[FourthWorld]

LiveCode object reference resolution rules are much smarter than most other xTalks. In the olden days we'd often have to resort to "do" to build a complete object reference, but in LC you can usually mix literals and variables as long as the variable resolves to an object.

In your case, I believe you should be able to do something like this:

Code: Select all

put the long id of grp ID 1036 into tContainer
put "Party" into fld "Comment" of tContainer

[Simon]

Wow thanks!

I must have tried that?
I guess it's Friday.

Simon

[SparkOut]

Sometimes it's worth putting the variable name in parentheses to ensure the engine resolves that before trying to access an object. Especially if you are doing something like

Code: Select all

put "text" into field ("myField" & tVal)

[[-hh]]

..........

[SparkOut]

I don't know of a clear rule at all but I would suggest that is a scenario where putting the obj1 variable in parentheses may be worth trying.

[[-hh]]

..........

[SparkOut]

Yes that is exactly my impression - whether it's a rule, I can't guarantee, but it's certainly one of those things I believe gives the engine that bit of extra direction that helps.

[FourthWorld]

Hi all,
one more question in the same direction.

Often I use (try to use) constructs like

• put "field (" & quote & "myField" & quote && "tVal)" into obj1

(yes, with variable name in there) and then

• put "text" into obj1
• set lockText of obj1 to not the lockText of obj1

and so on.

With some controls this works, with other's not.

The text we put into fields, buttons, etc. is a property of those objects, and when we use property-setting syntax you should always get what you want provided the variable resolves to a valid object reference, e.g.:

Code: Select all

put the long id of fld 1 into tFld
set the text of tFld to "Some Text"

LiveCode also graciously allows us to use container syntax in addition to property syntax in some circumstances, so we can do things like this:

Code: Select all

put fld 1 + fld 2 into fld 3

Where things get challenging is when we use container syntax ("put") on object references stored in variables. In that case we have things like one of your examples above:

Code: Select all

put the long id of fld 1 into tObj
put "Some Text" into tObj

...in which the engine sees:

Code: Select all

put something into the variable tObj
put something else into the variable tObj

When in doubt about using object references in variables, using property syntax ("set") rather than container syntax ("put") should provide reliable results.

[Simon]

When in doubt about using object references in variables, using property syntax ("set") rather than container syntax ("put") should provide reliable results.

Now I see where my thinking was wrong!
put "Play" into pathToContainer was where my thinking got stuck.
set pathToContainer to "Play"

Always learning.
LiveCode ROCKS!

Simon