Thank you Terry and Trevor for your feedback.
Trevor wrote:
> On Jan 15, 2010, at 7:38 PM, Richard Gaskin wrote:
>
>> I have a DataGrid which works fine in the IDE, but in a standalone
>> it draws only the appropriate number of alternating lines but no
>> contents in those rows.
>>
>> Because the problem is limited to the standalone it's difficult to
>> pin down; I hope to have more details as I continue to poke around.
>
> How is the revDataGridLibrary being included when you build the
> standalone? I ask because I've seen problems with behaviors not
> being resolved properly if the Data Grid library isn't in memory
> when the stack with the Data Grid group controls loads.
I found a suitable workaround by simply resetting the behavior of my DG
in the initialization script of the stack that it's in:
set the behavior of grp "dgResults" to \
the behavior of grp "dgResults"
But since this was just a workaround to let me get back to work, I still
wanted to figure out what was going on.
I finally resolved it this morning. Here's the bottom line, discovered
after quite a bit of experimentation:
It appears that if any behavior is unresolved at runtime, the engine
will fail to resolve any other behavior assignments it subsequently
encounters which reference the same behavior object, even ones occurring
after the behavior object has been safely loaded.
This may or may not be documented, depending on how you interpret this
note from the ParentScriptNotes.txt file:
Once resolution has failed for a parentScript reference, no attempt
will be made to resolve it again *unless* the parentScript of an
object is set to the same reference.
In my reading, "no attempt will be made to resolve it again" applies to
the instance rather than the referenced object, implying that any given
instance using a behavior will be attempted only once, but that each
instance will indeed be attempted.
If that were the case, then if a behavior is defined in a library
stackfile I would expect any object using that library to fail until
that library has been loaded (for behaviors I load using the suggested
"is a stack" test), but any object referencing the same behavior object
loaded after the behavior library has been loaded should succeed.
In my tests, this appears not to be the case. Instead, it seems that
once any object attempting to use a referenced behavior cannot be
resolved, any objects loaded later which reference the same behavior
object will not be resolved, even if the behavior object has been loaded
in the meantime.
In short, one mistake can make a lot of non-mistakes non-workable. :(
Perhaps by "*unless* the parentScript of an object is set to the same
reference" they mean "reset again in script" rather than simply having
been set in advance; with new stuff like this it's understandably easy
to write ambiguously.
It's a long story as to how I was able to pin this down, but more
relevant is this test I've put together to illustrate the issue in
isolation:
<http://fourthworldlabs.com/rev/behavior_test.zip>
The ReadMe file included in that archive describes the steps needed to
reproduce this issue, and explains what appears to be happening there.
If you or any of the other readers of this list feel like running that
test it would be useful to get your confirmation before I submit this to
the RQCC.
I'm also open to the idea that this may be merely a documentation issue
rather than an engine bug; if the current failure to resolve instance
references seems reasonable to you, perhaps simply clarifying the
ambiguity in the notes (and expanding the rather sparse Dictionary entry
for behavior to include that) would suffice.
There is a second consideration here as well:
Currently the engine attempts to resolve all behavior references
throughout a stack file, whether or not any of those substacks have been
directly accessed in any way.
This means that anyone wishing to use libraries which define behaviors
as external stack files must take care to make sure that any stacks that
use such libs are also external to the standalone stack file.
It would seem to offer more flexibility for the developer if behavior
references were resolved only when:
- the stack is opened
- the stack is brought into use with "start using"
- any of its objects are put into the frontScripts or backScripts
This may be a low priority for most folks, and is usually not an issue
for me since my own framework externalizes everything (even the Splash
screen, using only the slimmest possible stack in the executable itself).
But there may be times when it can be convenient to simply have UI
stacks as substacks in the executable, while still having the libraries
that drive them in separate stackfiles.
Your opinions on whether this is useful enough to pursue would be
appreciated.
I should also note that while the Rev v3.5 DP1 ParentScriptNotes.txt
describes a resolutionError message to be included in DP2, in v3.5,
v4.0, and v4.5 it does not appear this message is sent. It's not in the
Dictionary, and my resolutionError handler does not trigger when
unresolvable behavior references are encountered.
A silent failure in resolving behavior script lookups can eat up time in
diagnosis.
If the resolutionError message not slated to become part of v4.5 it
would be good if that could be confirmed by someone from RunRev Ltd. so
I can give some thought to implementing workarounds in my runtime
diagnostic tools.
Thanks again for your interest, and thanks in advance to anyone who
offers their feedback on the above.
--
Richard Gaskin
Fourth World
Rev training and consulting: http://www.fourthworld.com
Webzine for Rev developers: http://www.revjournal.com
revJournal blog: http://revjournal.com/blog.irv
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
