Field does not exist (but it does!)

[Paul D]

When I call a field inside a script and call a main stack script from a sub stack, the main stack script will error out unless I call the field by its name WITH the "on stack" extension?

Gives error
Stack name: Front (main stack)
on openproject
put field "test" into a
end openproject

Stack name: Open (sub stack)
on openstack
openproject
end openstack

Error: Field "test" does not exist

Works
Stack name: Front (main stack)
on openproject
put field "test" on stack "Front" into a
end openproject

Stack name: Open (sub stack)
on openstack
openproject
end openstack


Why do I have to tell the main stack to call a field on itself in a script that is contained on that stack?

[bn]

Paul,

if you put the command openproject into the stack script of your main stack this command is just in the message hierarchy. It does not matter where, you could put the same command into the stack script of a "stack in use" or a backscript, it would still work. But you have to tell it explicitly the stack name where your field "test" lives, except when field "test" is part of the calling stack.
You can test this if you put a field "test" into the substack and then it would work without the stack specification, but it would invoke the field "test" of the substack.
So it is actually a feature, not a bug. It gives you greater flexibility.

By the way, you name your main stack "Front" and your sub stack "open". I always avoid using reserved words for naming objects in Rev. In my experience this can be a source of hard to track bugs.

regards
Bernd

[Paul D]

well thats inconvenient. i didnt really name my stacks those names, i just used them in an example. thanks for the info Bernd.

[bn]

Paul,
it may be inconvenient but it is important why it is so. Especially if you are using substacks.
As soon as you open a substack its first card gets an openStack message. This message travel the message hierarchy. If the stack script of the substack does not have an openstack command then the message goes on to the stack script of the main stack. If the main stack does not have a on openstack handler the openstack message goes on and could be intercepted by an on openstack handler in a back script.
The point here is that when your mainstack opens the same thing happens:
The first card of the main stack gets the openstack message, if not handled by the card script it goes up to the stack script if not handled and so on.

Importantly if you have an "on openstack" handler in the main stack script this handler will be called twice: once when the main stack is opened and once when the substack is opened (assuming there is only one substack)

Because of this it is a good idea to place into the script of the substack an empty

Code: Select all

on openstack
end openstack

handler if they dont want to do anything with the openstack message in the sub stack. This way the mainstack does not get two openstack messages, because the empty on openstack handler in the substack blocks the message that the substack gets when opening.

Because of this some people put the openstack handler into the script of the first card of the main stack. That way the openstack message for the main stack gets handled in the card script and is not invoked by untrapped openstack messages from substacks.

The user guide has an illustration of the message path in the chapter on messages (5.3.2 of the 3.5 user guide)
Either way you have to be aware of this messaging or it can get pretty confusing. Even more confusing then my attempt at explaining this

regards
Bernd