Re: the defaultStack changes on resume
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 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 >> 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 > 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: the defaultStack changes on resume
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 > 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 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: the defaultStack changes on resume
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 ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ 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: the defaultStack changes on resume
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 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 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: the defaultStack changes on resume
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 > 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 > 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: the defaultStack changes on resume
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 > 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 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: the defaultStack changes on resume
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
>> 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
> 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: the defaultStack changes on resume
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
> 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
>> 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
> 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: the defaultStack changes on resume
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
> 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
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
the defaultStack changes on resume
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 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
