Re: the defaultStack changes on resume

2017-08-10 Thread Mark Waddingham 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 > wrote: > > Well now wait just a doggone minute. What

Re: the defaultStack changes on resume

2017-08-10 Thread Bob Sneidar 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?

Re: the defaultStack changes on resume

2017-08-10 Thread Mark Waddingham 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

Re: the defaultStack changes on resume

2017-08-09 Thread Trevor DeVore via use-livecode
On Wed, Aug 9, 2017 at 11:08 AM, Paul Dupuis via use-livecode < use-livecode@lists.runrev.com> 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

Re: the defaultStack changes on resume

2017-08-09 Thread Bob Sneidar 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,

Re: the defaultStack changes on resume

2017-08-09 Thread Bob Sneidar 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

Re: the defaultStack changes on resume

2017-08-09 Thread Paul Dupuis 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

Re: the defaultStack changes on resume

2017-08-09 Thread Bob Sneidar 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

Re: the defaultStack changes on resume

2017-08-09 Thread Bob Sneidar 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