DataGrid - not drawing fully in standalone - RESOLVED

[Richard Gaskin]

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