Re: A question about openCard
Jacqueline is correct: if I’m not debugging, the execution contexts is not in the list of recentCards. But my palette still does not appear in the list of recentCards. Further testing reveals: although activating a palette triggers a resumeStack message, and leaving a palette triggers a resumeStack message in the stack activated, palettes do not get listed in “the recentCards”. So I think I will resort to a global. In my main stacks, a resumeStack handler should — compare the name of this stack with a global “gActiveStack” — if they are not the same, carry out init actions, and put the name of this stack into gActiveStack. David Epstein Jacqueline Gay wrote: I wouldn't expect the execution contexts to be in the list but it sounds like that's a result of the debugging process itself. Is it different if you just log it to the message box without the debugger? get the recentCards put it ... etc Does the palette not appear anywhere in the list at all? > On Jun 8, 2019, at 9:13 AM, David Epstein wrote: > > Several people gave helpful replies to my question, including pointing out > that this is a case of “resumeStack”, not “openCard”: > > Is there some simple way that an openCard handler can branch based on what > card it is coming from? > > When a user goes to a different card in a stack, or to a different stack, I > use an “openCard” handler to set things up. But I do not want those actions > taken if the user is merely “returning” to a card after using a palette tool, > or after a palette tool has been opened. > > Jacqueline Gay suggested using the “recentCards” to determine what card the > user is coming from. So I wrote this handler: > > function resumedTheSameCard > -- call this in a "resumeStack" handler. > -- returns true if palette "tTools" has just been active and the > resumeStack message was received by the same card that had been active when > that palette was activated. > -- returns false if we are coming from a different card, either directly or > with a palette activation in between. > get the recentCards > if the long id of stack "tTools" is not in line 2 of it then return false > -- nb should work even if palette "tTools" stack has several cards > return line 1 of it = line 3 of it > end resumedTheSameCard > > But this does not work. When I debug, I see that line 2 of the recentCards > does not refer to a card on my palette stack (“tTools”); it refers instead to > a card in the stack “Execution Contexts”. > > Why is that LiveCode system stack appearing in the recentCards, and why is my > palette not appearing there? > > Many thanks. > > David Epstein ___ 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: A question about openCard
I wouldn't expect the execution contexts to be in the list but it sounds like that's a result of the debugging process itself. Is it different if you just log it to the message box without the debugger? get the recentCards put it ... etc Does the palette not appear anywhere in the list at all? -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On June 8, 2019 8:15:14 AM David Epstein via use-livecode wrote: Several people gave helpful replies to my question, including pointing out that this is a case of “resumeStack”, not “openCard”: Is there some simple way that an openCard handler can branch based on what card it is coming from? When a user goes to a different card in a stack, or to a different stack, I use an “openCard” handler to set things up. But I do not want those actions taken if the user is merely “returning” to a card after using a palette tool, or after a palette tool has been opened. Jacqueline Gay suggested using the “recentCards” to determine what card the user is coming from. So I wrote this handler: function resumedTheSameCard -- call this in a "resumeStack" handler. -- returns true if palette "tTools" has just been active and the resumeStack message was received by the same card that had been active when that palette was activated. -- returns false if we are coming from a different card, either directly or with a palette activation in between. get the recentCards if the long id of stack "tTools" is not in line 2 of it then return false -- nb should work even if palette "tTools" stack has several cards return line 1 of it = line 3 of it end resumedTheSameCard But this does not work. When I debug, I see that line 2 of the recentCards does not refer to a card on my palette stack (“tTools”); it refers instead to a card in the stack “Execution Contexts”. Why is that LiveCode system stack appearing in the recentCards, and why is my palette not appearing there? Many thanks. David Epstein ___ 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: A question about openCard
Several people gave helpful replies to my question, including pointing out that this is a case of “resumeStack”, not “openCard”: Is there some simple way that an openCard handler can branch based on what card it is coming from? When a user goes to a different card in a stack, or to a different stack, I use an “openCard” handler to set things up. But I do not want those actions taken if the user is merely “returning” to a card after using a palette tool, or after a palette tool has been opened. Jacqueline Gay suggested using the “recentCards” to determine what card the user is coming from. So I wrote this handler: function resumedTheSameCard -- call this in a "resumeStack" handler. -- returns true if palette "tTools" has just been active and the resumeStack message was received by the same card that had been active when that palette was activated. -- returns false if we are coming from a different card, either directly or with a palette activation in between. get the recentCards if the long id of stack "tTools" is not in line 2 of it then return false -- nb should work even if palette "tTools" stack has several cards return line 1 of it = line 3 of it end resumedTheSameCard But this does not work. When I debug, I see that line 2 of the recentCards does not refer to a card on my palette stack (“tTools”); it refers instead to a card in the stack “Execution Contexts”. Why is that LiveCode system stack appearing in the recentCards, and why is my palette not appearing there? Many thanks. David Epstein ___ 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: A question about openCard
Simon Knight wrote: > "Is there some simple way that an openCard handler can branch based on > what card it is coming from?" > > My solution would be to give each card a customprop named say > “uCalledBy". Then when the app changes cards I set this prop e.g. > > Set the uCalledBy of Card 42 to “HitchHikers” > Go to Card 42 > > Then in Card 42 ’s opencard or anywhere else > > If the uCalledBy of me is “HitchHikers” then >answer “Where is your towel?” > end if Custom properties are an excellent option when both of these requirements are met: 1. The data is most meaningfully expressed when bound to a specific object. 2. The data benefits from persistence. In the scenario at hand, #1 is well met, but #2 may be problematic. For example, if you happen to save the stack while working on it (who doesn't?) then you'll have property values in place that may not be relevant to the next runtime session. This would require that you add a handler to clear those properties on startup, or some other useful entry point for execution, in addition to adding the code above. When you find yourself writing handlers to clean up after other handlers you've written, it may be time to reconsider the original premise. FWIW Jacque's solution seems the most with-the-grain one yet, using the function designed for this purpose: > Look at the recentCards. Line 2 is the card you came from. -- 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: A question about openCard
Look at the recentCards. Line 2 is the card you came from. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com Is there some simple way that an openCard handler can branch based on what card it is coming from? ___ 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: A question about openCard
ResumeStack can be tricky. For instance, if you are tracing a resumeStack handler to debug it, every time you click back on to the stack in question, it will trigger the debugger and suspend the stack again! Rinse and repeat until you realize you can't trace a resumeStack handler without some special handling. Bob S > On Jun 2, 2019, at 17:22 , Klaus major-k via use-livecode > wrote: > >> I’m not sure I understand the full range of events that “close” a card so >> that returning to it triggers “openCard.” Does this happen if I set an >> insertion point or select text in an unlocked field in a palette, or the >> user types there? Does it happen if I open a palette, or move a palette, or >> if the user clicks on the palette? > > See above, resumestack/suspendstack are the messages you could check, if > neccessary, in that case. > >> Many thanks. >> >> David Epstein > > Best > > Klaus > ___ 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: A question about openCard
> David E. wrote: > Is there some simple way that an openCard handler can branch based on > what card it is coming from? TMHO, the function that's made for that is the target (dictionary) Returns the object which received the message that started execution. Use the target function within a message handler to determine which object originally received the message. ___ 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: A question about openCard
"Is there some simple way that an openCard handler can branch based on what card it is coming from?" My solution would be to give each card a customprop named say “uCalledBy". Then when the app changes cards I set this prop e.g. Set the uCalledBy of Card 42 to “HitchHikers” Go to Card 42 Then in Card 42 ’s opencard or anywhere else If the uCalledBy of me is “HitchHikers” then answer “Where is your towel?” end if Simon ___ 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: A question about openCard
Hi David, > Am 03.06.2019 um 00:00 schrieb David Epstein via use-livecode > : > > Is there some simple way that an openCard handler can branch based on what > card it is coming from? checl "recentNames" in the dictionary, that may be what you are looking for. > When a user goes to a different card in a stack, or to a different stack, I > use an “openCard” handler to set things up. Yep. > But I do not want those actions taken if the user is merely “returning” to a > card after using a palette tool, or after a palette tool has been opened. Then the card will receive a "resumestack" (and "suspendstack"), but no "opencard" message. > I’m not sure I understand the full range of events that “close” a card so > that returning to it triggers “openCard.” Does this happen if I set an > insertion point or select text in an unlocked field in a palette, or the user > types there? Does it happen if I open a palette, or move a palette, or if > the user clicks on the palette? See above, resumestack/suspendstack are the messages you could check, if neccessary, in that case. > Many thanks. > > David Epstein Best Klaus -- Klaus Major http://www.major-k.de kl...@major-k.de ___ 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
