So that is something that could be fixed pretty easily. I’m thinking a script
local to store the value which will offset the additional work to figure it out
the first time.
Logic would be to check for some key object and if not found then move up the
behavior chain a level and look. Could either decide that only one could be
there or just keep going until there are no more. There is no error checking
now, so it could fail in the same manner.
A side effect would be that the call would be faster for every other use since
it would only be checking that the script local wasn’t empty and returning the
value.
Another option would be to just initialize the variable in _Initialize and use
it for the 10 places the function is currently used. That would be even faster
since it would eliminate the function call completely.
Thanks,
Brian
On Jul 23, 2018, 1:24 PM -0500, Niggemann, Bernd via use-livecode
<use-livecode@lists.runrev.com>, wrote:
> The problem Bob Sneidar ran into by changing the order of the behaviors of a
> dataGrid is due to the initialization process of the dataGrid at start-up.
>
> The behavior looks for a resourceStack by means of this handler.
>
> private function _ResourceStack
> local theStack, theCharNo
> put the behavior of me into theStack
> if theStack is not empty then
> put offset(" of stack", theStack) into theCharNo <-- looks only at first
> behavior which is in Bob's case the wrong stack
> delete char 1 to (theCharNo + 3) of theStack
> end if
>
> return theStack
> end _ResourceStack
>
>
> In Bob's case the function returns the stack the button his newly assembled
> behavior is placed on instead of stack "revdatagridlibrary.rev".
> Then the initialization trys to set again behaviors of specific elements of
> the datagrid to scripts of the "correct" _ResourceStack.
>
> This fails obviously and is the reason for Bob's approach to fail.
>
> Further details of this on request, I don't want to bother the list with them.
>
> Kind regards
>
> Bernd
>
>
>
>
>
>
> Richard Gaskin wrote:
>
> The more I've explored this the more subclassing by inserting a custom
> behavior in between a custom control and its original behavior should work.
> It's curious that it doesn't here.
>
> What exactly were the errors you encountered?
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
