Hi.
Well, yes and no.
The "no" is that if you are in one stack, you need a fairly explicit pathname to an object in another stack. The "yes" is something like this:
Code: Select all
go stack "parameters"
get fld "user" & fld "IPAddress" & fld "password"
Another form of "yes", and much more robust if you are going to be doing this sort of thing a lot, is to place the contents of each field into a custom property. For example (pseudo):
Code: Select all
on closeField
put me into customPropertyNameBasedOnNameOfField
These properties might be updated every time a field is changed, using a "closeField" handler residing in the card script, and referencing each field via "the target" function. Anyway, you could then simply:
Code: Select all
get theUserField & theIPAddressField & thePasswordField
Where the location of the user is no longer an issue of any kind. Write back if none of this is clear.
Craig Newman
EDIT:
I was too quick. The custom properties would still have to reference the objects to which they are attached:
Code: Select all
get theUserField of field "users" of stack...
So there is little advantage. The other way to do this, using global variables, would require no such reference. They could be loaded as I mentioned before, in a card level closeField handler. But almost everyone shies away from these. You would have to declare them in the operative handler, so, again, another layer of annoyance. Maybe, after all, method 1 is cleanest.
)