Behavior question
I have a button named "myButton" with a behavior "myBehavior" whose script includes a handler named "loadData". >From anther control I execute: dispatch "loadData" to button "myButton" The loadData handler is not executed and the it variable contains "unhandled" after the dispatch command. That should work, shouldn't it? ___ 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
Re: Behavior question
I am not sure I understand. If "myButton" has a handler in its script called "loadData", then the dispatch command should work regardless of any behaviors. This is direct, message-bypassing, er, behavior. If the behavior of that other control, was set to the long id of "myButton", then simply invoking "loadData" from that control would cause the handler in "myButton" to fire. Is this what you are seeing? Or not seeing? Craig Newman -Original Message- From: Peter Haworth To: How to use LiveCode Sent: Tue, Jul 21, 2015 5:05 pm Subject: Behavior question I have a button named "myButton" with a behavior "myBehavior" whose script includes a handler named "loadData". >From anther control I execute: dispatch "loadData" to button "myButton" The loadData handler is not executed and the it variable contains "unhandled" after the dispatch command. That should work, shouldn't it? ___ 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
Re: Behavior question
On 7/21/2015 4:02 PM, Peter Haworth wrote: I have a button named "myButton" with a behavior "myBehavior" whose script includes a handler named "loadData". From anther control I execute: dispatch "loadData" to button "myButton" The loadData handler is not executed and the it variable contains "unhandled" after the dispatch command. That should work, shouldn't it? Onoe would think so. Does "send" work? It traverses the message hierarchy a little differently. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ 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
Re: Behavior question
Is loadData defined as a command or a function? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: Behavior question
Craig, The loadData command is in the behavior script, not the script of myButton. On Tue, Jul 21, 2015 at 3:24 PM wrote: > I am not sure I understand. > > > If "myButton" has a handler in its script called "loadData", then the > dispatch command should work regardless of any behaviors. This is direct, > message-bypassing, er, behavior. > > > If the behavior of that other control, was set to the long id of > "myButton", then simply invoking "loadData" from that control would cause > the handler in "myButton" to fire. > > > Is this what you are seeing? Or not seeing? > > > Craig Newman > > > > -Original Message- > From: Peter Haworth > To: How to use LiveCode > Sent: Tue, Jul 21, 2015 5:05 pm > Subject: Behavior question > > > I have a button named "myButton" with a behavior "myBehavior" whose > script > includes a handler named "loadData". > > From anther control I > execute: > > dispatch "loadData" to button "myButton" > > The loadData handler is > not executed and the it variable contains > "unhandled" after the dispatch > command. > > That should work, shouldn't > it? > ___ > 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 > ___ 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
Re: Behavior question
Thanks Jacque, that might have yielded a clue. When I use send, I get a runtime error "can't find handler". I've had issues in the past with behavior references not being resolved, to the extent that I wrote a handler to re-establish all object behavior references when my stack opens. Maybe this is another manifestation of that problem. Pete On Tue, Jul 21, 2015 at 3:31 PM J. Landman Gay wrote: > On 7/21/2015 4:02 PM, Peter Haworth wrote: > > I have a button named "myButton" with a behavior "myBehavior" whose > script > > includes a handler named "loadData". > > > >>From anther control I execute: > > > > dispatch "loadData" to button "myButton" > > > > The loadData handler is not executed and the it variable contains > > "unhandled" after the dispatch command. > > > > That should work, shouldn't it? > > Onoe would think so. Does "send" work? It traverses the message > hierarchy a little differently. > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > > ___ > 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
Re: Behavior question
It's a command. Even checked the spelling and also copy/pasted the handler name from it's declaration into the dispatch command. On Tue, Jul 21, 2015 at 3:33 PM Richard Gaskin wrote: > Is loadData defined as a command or a function? > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > 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
Re: Behavior question
Peter. A behavior is a property, not a handler in a script. That property is the long id of a button, which contains what one might call a "behavior" handler. The behavior handler is put into sort of its own separate "message path", accessed by other controls that have their behavior properties "point" to the behavior button and its behavior script. So many behaviors. Do this. On a new card, make two buttons. Name one "b1" and the other "b2". In the script of "b1", place this handler: on getRandom answer random(99) end getRandom. In the script of "b2" place this: on mouseUp getRandom end mouseUp. Now set the behavior of btn "b2" to the long id of btn "b1". And finally, click on "b2". Does this help? I think you are misusing the idea of behaviors. Craig -Original Message- From: Peter Haworth To: How to use LiveCode Sent: Tue, Jul 21, 2015 6:54 pm Subject: Re: Behavior question It's a command. Even checked the spelling and also copy/pasted the handler name from it's declaration into the dispatch command. On Tue, Jul 21, 2015 at 3:33 PM Richard Gaskin wrote: > Is loadData defined as a command or a function? > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > 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 ___ 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
Re: Behavior question
I just tried a very simple test in another stack and it worked so there must be something in the stack with the problem that is preventing the behavior from being resolved. On Tue, Jul 21, 2015 at 3:53 PM Peter Haworth wrote: > It's a command. Even checked the spelling and also copy/pasted the > handler name from it's declaration into the dispatch command. > > > On Tue, Jul 21, 2015 at 3:33 PM Richard Gaskin > wrote: > >> Is loadData defined as a command or a function? >> >> -- >> Richard Gaskin >> Fourth World Systems >> Software Design and Development for the Desktop, Mobile, and the Web >> >> ambassa...@fourthworld.comhttp://www.FourthWorld.com >> >> ___ >> 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
Re: Behavior question
On 07/21/2015 04:55 PM, Peter Haworth wrote: I just tried a very simple test in another stack and it worked so there must be something in the stack with the problem that is preventing the behavior from being resolved. Well, it *should* work. In most cases anyway. The only thing I can think of that would mess it up is if you have a loadData handler somewhere in a frontscript and it isn't passing the message on when it's done. I think of behavior scripts as private backscripts of the parent object. So it should be the next thing in the message path unless a frontscript grabs the message first and never lets go. I don't think that explains the "unhandled" status though, so there may be something else going on. -- Mark Wieder ahsoftw...@gmail.com ___ 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
Re: Behavior question
Yes, of course behavior is a property but the control referred to in the behavior has a script and the loadData handler is in that script. Hope that clarifies things On Tue, Jul 21, 2015 at 8:44 PM Mark Wieder wrote: > On 07/21/2015 04:55 PM, Peter Haworth wrote: > > > I just tried a very simple test in another stack and it worked so there > > must be something in the stack with the problem that is preventing the > > behavior from being resolved. > > Well, it *should* work. In most cases anyway. > > The only thing I can think of that would mess it up is if you have a > loadData handler somewhere in a frontscript and it isn't passing the > message on when it's done. > > I think of behavior scripts as private backscripts of the parent object. > So it should be the next thing in the message path unless a frontscript > grabs the message first and never lets go. > > I don't think that explains the "unhandled" status though, so there may > be something else going on. > > -- > Mark Wieder > ahsoftw...@gmail.com > > ___ > 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
Re: Behavior question
Right, the unhandled is what is throwing me, plus the fact that using send results in a runtime error. As I've found, what I'm doing works in a simplified environment so for some reason, this particular behavior isn't being resolved, just can't figure out why. On Tue, Jul 21, 2015 at 8:44 PM Mark Wieder wrote: > On 07/21/2015 04:55 PM, Peter Haworth wrote: > > > I just tried a very simple test in another stack and it worked so there > > must be something in the stack with the problem that is preventing the > > behavior from being resolved. > > Well, it *should* work. In most cases anyway. > > The only thing I can think of that would mess it up is if you have a > loadData handler somewhere in a frontscript and it isn't passing the > message on when it's done. > > I think of behavior scripts as private backscripts of the parent object. > So it should be the next thing in the message path unless a frontscript > grabs the message first and never lets go. > > I don't think that explains the "unhandled" status though, so there may > be something else going on. > > -- > Mark Wieder > ahsoftw...@gmail.com > > ___ > 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
Re: Behavior question
You double-checked the path to the behavior, right? If there are any other handlers in the behavior, do those work? On 7/22/2015 12:48 AM, Peter Haworth wrote: Right, the unhandled is what is throwing me, plus the fact that using send results in a runtime error. As I've found, what I'm doing works in a simplified environment so for some reason, this particular behavior isn't being resolved, just can't figure out why. On Tue, Jul 21, 2015 at 8:44 PM Mark Wieder wrote: On 07/21/2015 04:55 PM, Peter Haworth wrote: I just tried a very simple test in another stack and it worked so there must be something in the stack with the problem that is preventing the behavior from being resolved. Well, it *should* work. In most cases anyway. The only thing I can think of that would mess it up is if you have a loadData handler somewhere in a frontscript and it isn't passing the message on when it's done. I think of behavior scripts as private backscripts of the parent object. So it should be the next thing in the message path unless a frontscript grabs the message first and never lets go. I don't think that explains the "unhandled" status though, so there may be something else going on. -- Mark Wieder ahsoftw...@gmail.com ___ 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 -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ 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
Re: Behavior question
Yep, checked it over and over, plus the spelling of the command. My lcStackbrowser plugin has a feature where you click on an icon for an object's behavior and it automatically opens its script - that opens the correct script so pretty sure all is OK. I tried dispatching to a different handler - same result. I have got this to work however. I deleted the behavior reference and reset it. After that, all works well again. But after quitting LC and starting it again, the behavior is no longer resolved. For some reason, the behavior is not being resolved at runtime by LC and deleting and resetting it forces it to be resolved. On Wed, Jul 22, 2015 at 9:57 AM J. Landman Gay wrote: > You double-checked the path to the behavior, right? If there are any > other handlers in the behavior, do those work? > > On 7/22/2015 12:48 AM, Peter Haworth wrote: > > Right, the unhandled is what is throwing me, plus the fact that using > send > > results in a runtime error. > > > > As I've found, what I'm doing works in a simplified environment so for > some > > reason, this particular behavior isn't being resolved, just can't figure > > out why. > > > > On Tue, Jul 21, 2015 at 8:44 PM Mark Wieder > wrote: > > > >> On 07/21/2015 04:55 PM, Peter Haworth wrote: > >> > >>> I just tried a very simple test in another stack and it worked so there > >>> must be something in the stack with the problem that is preventing the > >>> behavior from being resolved. > >> > >> Well, it *should* work. In most cases anyway. > >> > >> The only thing I can think of that would mess it up is if you have a > >> loadData handler somewhere in a frontscript and it isn't passing the > >> message on when it's done. > >> > >> I think of behavior scripts as private backscripts of the parent object. > >> So it should be the next thing in the message path unless a frontscript > >> grabs the message first and never lets go. > >> > >> I don't think that explains the "unhandled" status though, so there may > >> be something else going on. > >> > >> -- > >>Mark Wieder > >>ahsoftw...@gmail.com > >> > >> ___ > >> 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 > > > > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > > ___ > 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
Re: Behavior question
Is this one of the behaviors that's dynamically assigned at startup or when a stack opens? I wonder if it's assigned too soon, before everything has finished loading. On 7/22/2015 1:03 PM, Peter Haworth wrote: Yep, checked it over and over, plus the spelling of the command. My lcStackbrowser plugin has a feature where you click on an icon for an object's behavior and it automatically opens its script - that opens the correct script so pretty sure all is OK. I tried dispatching to a different handler - same result. I have got this to work however. I deleted the behavior reference and reset it. After that, all works well again. But after quitting LC and starting it again, the behavior is no longer resolved. For some reason, the behavior is not being resolved at runtime by LC and deleting and resetting it forces it to be resolved. On Wed, Jul 22, 2015 at 9:57 AM J. Landman Gay wrote: You double-checked the path to the behavior, right? If there are any other handlers in the behavior, do those work? On 7/22/2015 12:48 AM, Peter Haworth wrote: Right, the unhandled is what is throwing me, plus the fact that using send results in a runtime error. As I've found, what I'm doing works in a simplified environment so for some reason, this particular behavior isn't being resolved, just can't figure out why. On Tue, Jul 21, 2015 at 8:44 PM Mark Wieder wrote: On 07/21/2015 04:55 PM, Peter Haworth wrote: I just tried a very simple test in another stack and it worked so there must be something in the stack with the problem that is preventing the behavior from being resolved. Well, it *should* work. In most cases anyway. The only thing I can think of that would mess it up is if you have a loadData handler somewhere in a frontscript and it isn't passing the message on when it's done. I think of behavior scripts as private backscripts of the parent object. So it should be the next thing in the message path unless a frontscript grabs the message first and never lets go. I don't think that explains the "unhandled" status though, so there may be something else going on. -- Mark Wieder ahsoftw...@gmail.com ___ 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 -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ 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 -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ 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
Re: Behavior question
This now ringing a bell with a problem I had a few months ago where many behaviors were not being resolved. In that thread, somebody recommended a repeat loop at startup to go through all objects in the stack, find the ones with behaviors and set the behavior to its existing property. That fixed the problem. But the current problem is happening in a stack which was excluded from the behavior reset. I just changed the reset behavior handler to include it and now all works fine. Still don;t know why all that should be necessary, maybe it's because the behavior objects are in a different stack than the objects that reference them (the stack is referenced in a start using command at startup) but it works so moving on. I do recall someone (Richard Gaskin) entering an enhancement request for a command to reestablish behaviors. My handler is very fast, not even noticeable at startup but it would be nice to have an official way to do it. On Wed, Jul 22, 2015 at 11:03 AM Peter Haworth wrote: > Yep, checked it over and over, plus the spelling of the command. My > lcStackbrowser plugin has a feature where you click on an icon for an > object's behavior and it automatically opens its script - that opens the > correct script so pretty sure all is OK. > > I tried dispatching to a different handler - same result. > > I have got this to work however. I deleted the behavior reference and > reset it. After that, all works well again. But after quitting LC and > starting it again, the behavior is no longer resolved. > > For some reason, the behavior is not being resolved at runtime by LC and > deleting and resetting it forces it to be resolved. > > On Wed, Jul 22, 2015 at 9:57 AM J. Landman Gay > wrote: > >> You double-checked the path to the behavior, right? If there are any >> other handlers in the behavior, do those work? >> >> On 7/22/2015 12:48 AM, Peter Haworth wrote: >> > Right, the unhandled is what is throwing me, plus the fact that using >> send >> > results in a runtime error. >> > >> > As I've found, what I'm doing works in a simplified environment so for >> some >> > reason, this particular behavior isn't being resolved, just can't figure >> > out why. >> > >> > On Tue, Jul 21, 2015 at 8:44 PM Mark Wieder >> wrote: >> > >> >> On 07/21/2015 04:55 PM, Peter Haworth wrote: >> >> >> >>> I just tried a very simple test in another stack and it worked so >> there >> >>> must be something in the stack with the problem that is preventing the >> >>> behavior from being resolved. >> >> >> >> Well, it *should* work. In most cases anyway. >> >> >> >> The only thing I can think of that would mess it up is if you have a >> >> loadData handler somewhere in a frontscript and it isn't passing the >> >> message on when it's done. >> >> >> >> I think of behavior scripts as private backscripts of the parent >> object. >> >> So it should be the next thing in the message path unless a frontscript >> >> grabs the message first and never lets go. >> >> >> >> I don't think that explains the "unhandled" status though, so there may >> >> be something else going on. >> >> >> >> -- >> >>Mark Wieder >> >>ahsoftw...@gmail.com >> >> >> >> ___ >> >> 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 >> > >> >> >> -- >> Jacqueline Landman Gay | jac...@hyperactivesw.com >> HyperActive Software | http://www.hyperactivesw.com >> >> ___ >> 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
Re: Behavior question
Peter Haworth wrote: > I do recall someone (Richard Gaskin) entering an enhancement request > for a command to reestablish behaviors. My handler is very fast, not > even noticeable at startup but it would be nice to have an official > way to do it. Mark Waddingham's comment #8 here suggests a good path forward, in which the engine takes care of this for us: http://quality.runrev.com/show_bug.cgi?id=8993 That was more than a year ago. I know they've had a lot on their plates, but it would be nice to have this one behind us. Behaviors are very useful, but only when they're not confusing. :) -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: Behavior question
Well now it's one of the ones that is assigned at startup - it wasn't when I started this thread. I'm pretty sure this all has to do with the engine's resolution of behavior references happening before all stacks are loaded. I have all my behaviors in a separate mainstack which is opened in a preOpenCard handler of the stack whose controls reference the behaviors. It appears even preOpenCard doesn't happen soon enough to allow the engine to resolve the behavior references. I wonder if putting a reference to the behaviors stack in the application stack's stackFiles property would fix this. I will try and post the result. On Wed, Jul 22, 2015 at 11:22 AM J. Landman Gay wrote: > Is this one of the behaviors that's dynamically assigned at startup or > when a stack opens? I wonder if it's assigned too soon, before > everything has finished loading. > > On 7/22/2015 1:03 PM, Peter Haworth wrote: > > Yep, checked it over and over, plus the spelling of the command. My > > lcStackbrowser plugin has a feature where you click on an icon for an > > object's behavior and it automatically opens its script - that opens the > > correct script so pretty sure all is OK. > > > > I tried dispatching to a different handler - same result. > > > > I have got this to work however. I deleted the behavior reference and > > reset it. After that, all works well again. But after quitting LC and > > starting it again, the behavior is no longer resolved. > > > > For some reason, the behavior is not being resolved at runtime by LC and > > deleting and resetting it forces it to be resolved. > > > > On Wed, Jul 22, 2015 at 9:57 AM J. Landman Gay > > > wrote: > > > >> You double-checked the path to the behavior, right? If there are any > >> other handlers in the behavior, do those work? > >> > >> On 7/22/2015 12:48 AM, Peter Haworth wrote: > >>> Right, the unhandled is what is throwing me, plus the fact that using > >> send > >>> results in a runtime error. > >>> > >>> As I've found, what I'm doing works in a simplified environment so for > >> some > >>> reason, this particular behavior isn't being resolved, just can't > figure > >>> out why. > >>> > >>> On Tue, Jul 21, 2015 at 8:44 PM Mark Wieder > >> wrote: > >>> > On 07/21/2015 04:55 PM, Peter Haworth wrote: > > > I just tried a very simple test in another stack and it worked so > there > > must be something in the stack with the problem that is preventing > the > > behavior from being resolved. > > Well, it *should* work. In most cases anyway. > > The only thing I can think of that would mess it up is if you have a > loadData handler somewhere in a frontscript and it isn't passing the > message on when it's done. > > I think of behavior scripts as private backscripts of the parent > object. > So it should be the next thing in the message path unless a > frontscript > grabs the message first and never lets go. > > I don't think that explains the "unhandled" status though, so there > may > be something else going on. > > -- > Mark Wieder > ahsoftw...@gmail.com > > ___ > 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 > >>> > >> > >> > >> -- > >> Jacqueline Landman Gay | jac...@hyperactivesw.com > >> HyperActive Software | http://www.hyperactivesw.com > >> > >> ___ > >> 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 > > > > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > > ___ > 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
Re: Behavior question
Thanks Richard. Read Mark's comment and I agree his solution sounds like the best way forward. On Wed, Jul 22, 2015 at 12:05 PM Richard Gaskin wrote: > Peter Haworth wrote: > > I do recall someone (Richard Gaskin) entering an enhancement request > > for a command to reestablish behaviors. My handler is very fast, not > > even noticeable at startup but it would be nice to have an official > > way to do it. > > Mark Waddingham's comment #8 here suggests a good path forward, in which > the engine takes care of this for us: > http://quality.runrev.com/show_bug.cgi?id=8993 > > That was more than a year ago. I know they've had a lot on their > plates, but it would be nice to have this one behind us. Behaviors are > very useful, but only when they're not confusing. :) > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > 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
Re: Behavior question
Put a reference to the behavior stack in the stackFiles property of my application stack and commented out the startup handler. It works! On Wed, Jul 22, 2015 at 12:39 PM Peter Haworth wrote: > Well now it's one of the ones that is assigned at startup - it wasn't when > I started this thread. I'm pretty sure this all has to do with the > engine's resolution of behavior references happening before all stacks are > loaded. > > I have all my behaviors in a separate mainstack which is opened in a > preOpenCard handler of the stack whose controls reference the behaviors. > It appears even preOpenCard doesn't happen soon enough to allow the engine > to resolve the behavior references. > > I wonder if putting a reference to the behaviors stack in the application > stack's stackFiles property would fix this. I will try and post the result. > > > On Wed, Jul 22, 2015 at 11:22 AM J. Landman Gay > wrote: > >> Is this one of the behaviors that's dynamically assigned at startup or >> when a stack opens? I wonder if it's assigned too soon, before >> everything has finished loading. >> >> On 7/22/2015 1:03 PM, Peter Haworth wrote: >> > Yep, checked it over and over, plus the spelling of the command. My >> > lcStackbrowser plugin has a feature where you click on an icon for an >> > object's behavior and it automatically opens its script - that opens the >> > correct script so pretty sure all is OK. >> > >> > I tried dispatching to a different handler - same result. >> > >> > I have got this to work however. I deleted the behavior reference and >> > reset it. After that, all works well again. But after quitting LC and >> > starting it again, the behavior is no longer resolved. >> > >> > For some reason, the behavior is not being resolved at runtime by LC and >> > deleting and resetting it forces it to be resolved. >> > >> > On Wed, Jul 22, 2015 at 9:57 AM J. Landman Gay < >> jac...@hyperactivesw.com> >> > wrote: >> > >> >> You double-checked the path to the behavior, right? If there are any >> >> other handlers in the behavior, do those work? >> >> >> >> On 7/22/2015 12:48 AM, Peter Haworth wrote: >> >>> Right, the unhandled is what is throwing me, plus the fact that using >> >> send >> >>> results in a runtime error. >> >>> >> >>> As I've found, what I'm doing works in a simplified environment so for >> >> some >> >>> reason, this particular behavior isn't being resolved, just can't >> figure >> >>> out why. >> >>> >> >>> On Tue, Jul 21, 2015 at 8:44 PM Mark Wieder >> >> wrote: >> >>> >> On 07/21/2015 04:55 PM, Peter Haworth wrote: >> >> > I just tried a very simple test in another stack and it worked so >> there >> > must be something in the stack with the problem that is preventing >> the >> > behavior from being resolved. >> >> Well, it *should* work. In most cases anyway. >> >> The only thing I can think of that would mess it up is if you have a >> loadData handler somewhere in a frontscript and it isn't passing the >> message on when it's done. >> >> I think of behavior scripts as private backscripts of the parent >> object. >> So it should be the next thing in the message path unless a >> frontscript >> grabs the message first and never lets go. >> >> I don't think that explains the "unhandled" status though, so there >> may >> be something else going on. >> >> -- >> Mark Wieder >> ahsoftw...@gmail.com >> >> ___ >> 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 >> >>> >> >> >> >> >> >> -- >> >> Jacqueline Landman Gay | jac...@hyperactivesw.com >> >> HyperActive Software | http://www.hyperactivesw.com >> >> >> >> ___ >> >> 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 >> > >> >> >> -- >> Jacqueline Landman Gay | jac...@hyperactivesw.com >> HyperActive Software | http://www.hyperactivesw.com >> >> __
Re: Behavior question
On 07/22/2015 12:39 PM, Peter Haworth wrote: Well now it's one of the ones that is assigned at startup - it wasn't when I started this thread. I'm pretty sure this all has to do with the engine's resolution of behavior references happening before all stacks are loaded. I have all my behaviors in a separate mainstack which is opened in a preOpenCard handler of the stack whose controls reference the behaviors. It appears even preOpenCard doesn't happen soon enough to allow the engine to resolve the behavior references. Yeah, I'd bet money that's exactly what's happening. Since the behaviors are in a stack that hasn't been loaded yet, the engine is *helpfully* nulling those out to keep you out of trouble. And all that happens before preOpenCard (and possibly preOpenStack) has a chance to come into play. -- Mark Wieder ahsoftw...@gmail.com ___ 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
Re: Behavior question
I never would have thought of that. What a handy tip. On 7/22/2015 5:32 PM, Peter Haworth wrote: Put a reference to the behavior stack in the stackFiles property of my application stack and commented out the startup handler. It works! On Wed, Jul 22, 2015 at 12:39 PM Peter Haworth wrote: Well now it's one of the ones that is assigned at startup - it wasn't when I started this thread. I'm pretty sure this all has to do with the engine's resolution of behavior references happening before all stacks are loaded. I have all my behaviors in a separate mainstack which is opened in a preOpenCard handler of the stack whose controls reference the behaviors. It appears even preOpenCard doesn't happen soon enough to allow the engine to resolve the behavior references. I wonder if putting a reference to the behaviors stack in the application stack's stackFiles property would fix this. I will try and post the result. On Wed, Jul 22, 2015 at 11:22 AM J. Landman Gay wrote: Is this one of the behaviors that's dynamically assigned at startup or when a stack opens? I wonder if it's assigned too soon, before everything has finished loading. On 7/22/2015 1:03 PM, Peter Haworth wrote: Yep, checked it over and over, plus the spelling of the command. My lcStackbrowser plugin has a feature where you click on an icon for an object's behavior and it automatically opens its script - that opens the correct script so pretty sure all is OK. I tried dispatching to a different handler - same result. I have got this to work however. I deleted the behavior reference and reset it. After that, all works well again. But after quitting LC and starting it again, the behavior is no longer resolved. For some reason, the behavior is not being resolved at runtime by LC and deleting and resetting it forces it to be resolved. On Wed, Jul 22, 2015 at 9:57 AM J. Landman Gay < jac...@hyperactivesw.com> wrote: You double-checked the path to the behavior, right? If there are any other handlers in the behavior, do those work? On 7/22/2015 12:48 AM, Peter Haworth wrote: Right, the unhandled is what is throwing me, plus the fact that using send results in a runtime error. As I've found, what I'm doing works in a simplified environment so for some reason, this particular behavior isn't being resolved, just can't figure out why. On Tue, Jul 21, 2015 at 8:44 PM Mark Wieder wrote: On 07/21/2015 04:55 PM, Peter Haworth wrote: I just tried a very simple test in another stack and it worked so there must be something in the stack with the problem that is preventing the behavior from being resolved. Well, it *should* work. In most cases anyway. The only thing I can think of that would mess it up is if you have a loadData handler somewhere in a frontscript and it isn't passing the message on when it's done. I think of behavior scripts as private backscripts of the parent object. So it should be the next thing in the message path unless a frontscript grabs the message first and never lets go. I don't think that explains the "unhandled" status though, so there may be something else going on. -- Mark Wieder ahsoftw...@gmail.com ___ 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 -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ 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 -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ 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 -- Jacqueline Landman Gay
