the defaultStack changes on resume

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

the defaultStack changes on resume

** Clarence P Martin ** via use-livecode
Has any one run into the following situation in LiveCode standalones?

In a multiple window application, the user has either a standard window
or a modal dialog open (the topWindow which is also the defaultStack).
They navigate to a 3rd party application and by some means back to the
LC standalone and click a control in the topWindow (again either a
standard window or dialog) and that window is NO LONGER the defaultStack
so an execution error occurs on the first control referenced that is not
fully qualified.

Obviously, I can fix this by fully qualifying all my object references
(i.e. instead of using fld "x", using fld "X" of stack "Y") but I am
curious is anyone else has seen anything like this?



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: the defaultStack changes on resume

** Clarence P Martin ** via use-livecode
BTW I worked around this by using my getParentStack() function. Here it is:

function getParentCard pObjectID
   put offset("card id", pObjectID) into tStartChar
   put char tStartChar to -1 of pObjectID into tCardID
   return tCardID
end getParentCard

function getParentStack pObjectID
    put wordOffset("stack", pObjectID) into tFirstWord
    put word tFirstWord to tFirstWord +1 of pObjectID into tParentStack
    return tParentStack
end getParentStack

NOTE: I only use single word stack names. This function will have to be reworked to account for multi-word stack names. Honestly though, if people would follow basic conventions about naming things, everything gets much simpler.

Bob S



> On Aug 9, 2017, at 09:08 , Paul Dupuis via use-livecode <[hidden email]> wrote:
>
> Has any one run into the following situation in LiveCode standalones?
>
> In a multiple window application, the user has either a standard window
> or a modal dialog open (the topWindow which is also the defaultStack).
> They navigate to a 3rd party application and by some means back to the
> LC standalone and click a control in the topWindow (again either a
> standard window or dialog) and that window is NO LONGER the defaultStack
> so an execution error occurs on the first control referenced that is not
> fully qualified.
>
> Obviously, I can fix this by fully qualifying all my object references
> (i.e. instead of using fld "x", using fld "X" of stack "Y") but I am
> curious is anyone else has seen anything like this?


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: the defaultStack changes on resume

** Clarence P Martin ** via use-livecode
Here is an updated version that should work with any stack name:

function getParentStack pObjectID
    put offset("stack ", pObjectID) into tStartChar
    put char tStartChar to -1 of pObjectID into tParentStack -- the long name of the parent stack
    return tParentStack
end getParentStack

Bob S


> On Aug 9, 2017, at 09:41 , Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> BTW I worked around this by using my getParentStack() function. Here it is:
>
> function getParentCard pObjectID
>   put offset("card id", pObjectID) into tStartChar
>   put char tStartChar to -1 of pObjectID into tCardID
>   return tCardID
> end getParentCard
>
> function getParentStack pObjectID
>    put wordOffset("stack", pObjectID) into tFirstWord
>    put word tFirstWord to tFirstWord +1 of pObjectID into tParentStack
>    return tParentStack
> end getParentStack
>
> NOTE: I only use single word stack names. This function will have to be reworked to account for multi-word stack names. Honestly though, if people would follow basic conventions about naming things, everything gets much simpler.
>
> Bob S
>
>
>
>> On Aug 9, 2017, at 09:08 , Paul Dupuis via use-livecode <[hidden email]> wrote:
>>
>> Has any one run into the following situation in LiveCode standalones?
>>
>> In a multiple window application, the user has either a standard window
>> or a modal dialog open (the topWindow which is also the defaultStack).
>> They navigate to a 3rd party application and by some means back to the
>> LC standalone and click a control in the topWindow (again either a
>> standard window or dialog) and that window is NO LONGER the defaultStack
>> so an execution error occurs on the first control referenced that is not
>> fully qualified.
>>
>> Obviously, I can fix this by fully qualifying all my object references
>> (i.e. instead of using fld "x", using fld "X" of stack "Y") but I am
>> curious is anyone else has seen anything like this?
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: the defaultStack changes on resume

** Clarence P Martin ** via use-livecode
In reply to this post by ** Clarence P Martin ** via use-livecode
I have handlers like these also. I have multiple work-arounds. You can
use suspend and resume to preserve the defaultStack and restore it. Lots
of way to work-around. I am curious if others have seen this and whether
anyone ever found a reproducible recipe.

So you have seen this behavior? In what versions of LC? Did you ever
find a consistent recipe to reproduce it?


On 8/9/2017 12:41 PM, Bob Sneidar via use-livecode wrote:

> BTW I worked around this by using my getParentStack() function. Here it is:
>
> function getParentCard pObjectID
>    put offset("card id", pObjectID) into tStartChar
>    put char tStartChar to -1 of pObjectID into tCardID
>    return tCardID
> end getParentCard
>
> function getParentStack pObjectID
>     put wordOffset("stack", pObjectID) into tFirstWord
>     put word tFirstWord to tFirstWord +1 of pObjectID into tParentStack
>     return tParentStack
> end getParentStack
>
> NOTE: I only use single word stack names. This function will have to be reworked to account for multi-word stack names. Honestly though, if people would follow basic conventions about naming things, everything gets much simpler.
>
> Bob S
>
>
>
>> On Aug 9, 2017, at 09:08 , Paul Dupuis via use-livecode <[hidden email]> wrote:
>>
>> Has any one run into the following situation in LiveCode standalones?
>>
>> In a multiple window application, the user has either a standard window
>> or a modal dialog open (the topWindow which is also the defaultStack).
>> They navigate to a 3rd party application and by some means back to the
>> LC standalone and click a control in the topWindow (again either a
>> standard window or dialog) and that window is NO LONGER the defaultStack
>> so an execution error occurs on the first control referenced that is not
>> fully qualified.
>>
>> Obviously, I can fix this by fully qualifying all my object references
>> (i.e. instead of using fld "x", using fld "X" of stack "Y") but I am
>> curious is anyone else has seen anything like this?
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: the defaultStack changes on resume

** Clarence P Martin ** via use-livecode
Yes I have had situations where what the built in functions were returning were not expected, and it screwed somethign up, which is why I do not rely on them. It seems a bit ambiguous to me that "this stack" might return different things depending on where the handler resides. By moving a script from a stack handler to a front or backscript, this can cause problems.

Therefore I never use those built in calls, having a drop dead accurate way to get what I want anyway.

Bob S


> On Aug 9, 2017, at 09:53 , Paul Dupuis via use-livecode <[hidden email]> wrote:
>
> I have handlers like these also. I have multiple work-arounds. You can
> use suspend and resume to preserve the defaultStack and restore it. Lots
> of way to work-around. I am curious if others have seen this and whether
> anyone ever found a reproducible recipe.
>
> So you have seen this behavior? In what versions of LC? Did you ever
> find a consistent recipe to reproduce it?


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: the defaultStack changes on resume

** Clarence P Martin ** via use-livecode
In reply to this post by ** Clarence P Martin ** via use-livecode
When I suspend a stack is save the current focused object and the current selection. Then on resume stack I restore it. That seems to work really well for me. The topStack should still be the topStack no matter what. Not sure why you need to reference the defaultStack.

Bob S


> On Aug 9, 2017, at 09:08 , Paul Dupuis via use-livecode <[hidden email]> wrote:
>
> Has any one run into the following situation in LiveCode standalones?
>
> In a multiple window application, the user has either a standard window
> or a modal dialog open (the topWindow which is also the defaultStack).
> They navigate to a 3rd party application and by some means back to the
> LC standalone and click a control in the topWindow (again either a
> standard window or dialog) and that window is NO LONGER the defaultStack
> so an execution error occurs on the first control referenced that is not
> fully qualified.
>
> Obviously, I can fix this by fully qualifying all my object references
> (i.e. instead of using fld "x", using fld "X" of stack "Y") but I am
> curious is anyone else has seen anything like this?
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: the defaultStack changes on resume

** Clarence P Martin ** via use-livecode
In reply to this post by ** Clarence P Martin ** via use-livecode
On Wed, Aug 9, 2017 at 11:08 AM, Paul Dupuis via use-livecode <
[hidden email]> wrote:

> Has any one run into the following situation in LiveCode standalones?
>
> In a multiple window application, the user has either a standard window
> or a modal dialog open (the topWindow which is also the defaultStack).
> They navigate to a 3rd party application and by some means back to the
> LC standalone and click a control in the topWindow (again either a
> standard window or dialog) and that window is NO LONGER the defaultStack
> so an execution error occurs on the first control referenced that is not
> fully qualified.
>
> Obviously, I can fix this by fully qualifying all my object references
> (i.e. instead of using fld "x", using fld "X" of stack "Y") but I am
> curious is anyone else has seen anything like this?
>

I think this bug report has a recipe for the issue you are seeing:

http://quality.livecode.com/show_bug.cgi?id=18030

This has been around for a long time. I don’t know of a workaround other
than fully qualifying all object references.

--
Trevor DeVore
ScreenSteps
www.screensteps.com
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: the defaultStack changes on resume

** Clarence P Martin ** via use-livecode
On 2017-08-09 20:48, Trevor DeVore via use-livecode wrote:
> I think this bug report has a recipe for the issue you are seeing:
>
> http://quality.livecode.com/show_bug.cgi?id=18030
>
> This has been around for a long time. I don’t know of a workaround
> other
> than fully qualifying all object references.

Unfortunately that is a separate issue.

The reason you get that error is because at present the popup button
command requires there to be a mouseStack. So if you cmd-tab away from
the app whilst your mouse is over some stack, and cmd-tab back in - it
will work; if you do not have your mouse over any stack, and do the same
you will get the error.

In fact, you get the same error if you press the shortcut combination
without the mouse over a stack.

I guess the 'popup' command was always intended to be run in response to
a mouse-click - both the ExecPopup function and the 'openmenu()'
function in MCButton have a guard against doing anything if the
mouseStack is empty.

The requirement for a mouseStack seems to be somewhat deeply tied into
the menu code so this could be a little tricky to untangle. (It
certainly seems to be part of the mouse tracking behavior menus need on
Windows and Linux).

So a simple explanation, but not a clear or easy solution.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: the defaultStack changes on resume

** Clarence P Martin ** via use-livecode
Well now wait just a doggone minute. What if I popup a button but the frontmost application is NOT LC, like when I drag drop onto an object I call a landing pad and popup a button to select what kind of data it is? This is Mac OS X. If LC isn't frontmost, how would that affect the mouseStack?

Bob S


> On Aug 10, 2017, at 10:32 , Mark Waddingham via use-livecode <[hidden email]> wrote:
>
> The reason you get that error is because at present the popup button command requires there to be a mouseStack. So if you cmd-tab away from the app whilst your mouse is over some stack, and cmd-tab back in - it will work; if you do not have your mouse over any stack, and do the same you will get the error.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: the defaultStack changes on resume

** Clarence P Martin ** via use-livecode
I'm pretty sure the mouseStack works even if the app is in the background - I could be wrong though...

Warmest Regards,

Mark.

Sent from my iPhone

> On 10 Aug 2017, at 19:11, Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> Well now wait just a doggone minute. What if I popup a button but the frontmost application is NOT LC, like when I drag drop onto an object I call a landing pad and popup a button to select what kind of data it is? This is Mac OS X. If LC isn't frontmost, how would that affect the mouseStack?
>
> Bob S
>
>
>> On Aug 10, 2017, at 10:32 , Mark Waddingham via use-livecode <[hidden email]> wrote:
>>
>> The reason you get that error is because at present the popup button command requires there to be a mouseStack. So if you cmd-tab away from the app whilst your mouse is over some stack, and cmd-tab back in - it will work; if you do not have your mouse over any stack, and do the same you will get the error.
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Loading...