Behavior scripts not limited to buttons?

[mwieder]

Yeah, I think we're in the position of having to throw good money after bad... historically buttons somehow became the de facto containers for frontscripts and backscripts, so I guess behavior buttons seemed like the easy way out. I like the idea of promoting behaviors to faceless script objects, but I think it's too late to make that kind of architectural change.

[monte]

I've been thinking more on this faceless script container thing and I think we can use it as a back door to having a significant chunk of our code in plain text files... If you could insert a file into front/back... include file... start using file... set the behavior to file... there's probably 90% of the code in a well designed app...

[mwieder]

Hah! I just started a new topic on this.

[monte]

BTW the behavior script button in the project browser probably negates the need for the contextual menu somewhat... although not completely..

[LCMark]

It's also an argument for them being the correct object type isn't it?

Not from @malte's example - the point he was making that because behaviors are tied to a control (i.e a button) they do funky things in the editing environment because they still receive messages and such (such as mouseMove etc.). This would be true of any control - thus I see it as an argument very much for behaviors being expressed as their own object type and thus not receive any messages.

Yeah, I think we're in the position of having to throw good money after bad... historically buttons somehow became the de facto containers for frontscripts and backscripts, so I guess behavior buttons seemed like the easy way out. I like the idea of promoting behaviors to faceless script objects, but I think it's too late to make that kind of architectural change.

I don't see it as too late at all - when the engine architecture allows, we make behaviors what they should be and deprecate the old method.

It could be a faceless object like an audioClip... still... it will take a long time to deprecate and finally remove it being a button if we did that (we have a history of leaving things in for backwards compatibility) so we would end up with two abstract concepts rather than one...

Well, the 'leaving things in for backwards compatibility for a long time' is very much a consequence of two things (1) having a very diverse user-base many of whom have been using the product for many many years and maintain software that uses many older features and still need that software to keep running, and 2) having an engine architecture in which functionality is all or nothing - i.e. it isn't possible to factor out deprecated/legacy features into a separate module that is entirely optional.

In regards to the files thing... Best discussed on the new topic

[monte]

Not from @malte's example

The errors were thrown because it was the wrong object type (buttons don't have hScroll) so there's still two ways to resolve that particular problem...

[mwieder]

I'd like to revisit bug #7945, the fabled "resolutionError" message, when a behavior property exists for an object but the behavior can't be resolved. The comment on the bug report implies that the message was never implemented but that future updates to behaviors might take care of this. I think this message could be quite useful... Richard Gaskin states in 2009 that

I think the resolutionError message was to be sent either just before or just after preOpenCard, at the time when any behavior references would need to be resolved.

This would imply that it would happen only once whenever a given object is brought into the message path, and would not be sent in response to any other message (like mouseUp, etc.).

The benefit is that if you have objects that depend on having a set of behavior buttons in memory, this error notification at least lets you
know what the objects you expected to be available as behaviors can't be found.

[monte]

Perhaps whenever a message passes through an object with an unresolved behavior an attempt should be made to resolve it?

[mwieder]

The behavior resolution was apparently supposed to be done at preOpenCard time (and, of course, when a behavior property is set). So I think throwing the error at that point would suffice. Otherwise the message queue could get swamped with resolutionError messages.

I haven't looked at the behavior code enough yet to know whether behaviors are actually being resolved early or whether they only come into play if a message handler isn't in the current object and until then they're just another object property.

[monte]

They are resolved when the stack is loaded... search for resolveparentscript

[mwieder]

Hee. RunRevMarkFromTheFuture has visited the resolveparentscript method in object.cpp. I see he made some comments in 2015.

Anyway, resolveparentscript seems to be called from a number of places.

It also appears, if I'm reading this correctly, that the MCParentScript objects keep a linked list of the objects that reference them, so it should be possible to create a method in a MCParentScript object that returns a list of the objects that use a given button as a parentscript.

[LCMark]

Hee. RunRevMarkFromTheFuture has visited the resolveparentscript method in object.cpp. I see he made some comments in 2015.

As has MonteFromTheFuture (although I think I added those referencing comments) - in this case, it wasn't a future me, just one who got confused between month and year I think...

The idea of the resolutionError message was that it would be sent when a resolution failed, at which point the behavior becomes 'blocked' and an attempt isn't made to resolve it again. The message would allow either an error to be generated, or an attempt to load the relevant stack and force another resolution.

The reason for resolution only occurring once was to ensure that there wasn't a performance penalty associated with missing behaviors. Similar to script compilation - if a compile error occurs when the script is compiled (which occurs when it is first used), HH_DEAD_SCRIPT is set and compilation isn't attempted again until the script property is set again (scripts are compiled when they are first searched for a handler). In this context the 'resolutionError' message is an analogue of the 'scriptError' message.

One way to make the action of resolution a little more automatic would be to ditch the 'resolveparentscripts' logic and instead make it so that:

• a behavior is resolved when it is first used (i.e. searched for a handler)
• if it fails to resolve it is marked as blocked (unresolved) and resolutionError is sent (same logic as scriptError)
• whenever the environment changes, all currently blocked behaviors will be unblocked so a new attempt is made to resolve them

The key bit to get right here is detection of when the environment changes. From the point of view of behaviors, the environment changes when:

• a new stack is loaded (it could have the name of a blocked behavior)
• the name of a stack is changed (it could now have the name of a blocked behavior)
• a button id is changed on a stack that is the target of blocked behavior (it could have the id of a blocked behavior targetting that stack)

The naive approach of 'unblocking' all behaviors when one of these things occurs would be too slow as it would require a linear scan through all behaviors whenever one of those events occurs.

One viable approach might be to have a global 'generation' count for the environment. Blocked behaviors store the generation for when an attempt to resolve them was made, whenever one of the above events occur the generation count is incremented and when a blocked behavior is used, if the generation count has changed, it tries to resolve it again. The resolutionError message would only ever be sent once per behavior (rather than each time an attempt is made).

The only point of fragility I see with this approach is when the generation count wraps. Let's say behavior A fails to resolve at generation count N and is not touched again for a long time (i.e. isn't searched for a handler), but after the count wrapping at point N-1 a new stack is loaded and count becomes N again. At this point, for whatever reason, the behavior is searched again - it won't attempt to resolve as the generation count would be the same as it had stored even though it should resolve. Whilst this might seem like a very unlikely event - the law of large numbers says that it would probably happen at some point and cause a malfunction that would be impossible to track down (for that specific instance). That being said, I'm sure there's a way to resolve that point of fragility with a bit more thought...