Re: Android tap location doesn't match visual location
Bug 23459 > On Nov 20, 2021, at 5:34 AM, Mark Waddingham via use-livecode > wrote: > > Hi Scott - the touch coords being wrong sounds like a bug to me - can you > file a report (with example stack if possible). > > Thanks! > > Mark. ___ 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: Android tap location doesn't match visual location
Will do. — Scott > On Nov 20, 2021, at 5:34 AM, Mark Waddingham via use-livecode > wrote: > > Hi Scott - the touch coords being wrong sounds like a bug to me - can you > file a report (with example stack if possible). > > Thanks! > > Mark. > > Sent from my iPhone > >> On 20 Nov 2021, at 12:04, scott--- via use-livecode >> wrote: >> >> Just answering my own question in case anyone searches this later. >> >> This was kind of a forehead slapper when I finally saw it. There was a >> native UIScroller over part of the screen. None of the other buttons on the >> screen were inside the rectangle of the scroller, so they weren’t effected. >> The scroller was being disabled while the fake dialog was on the screen and >> this worked fine for iOS but in my case at least, it is problematic for >> Android. My solution for now is to either leave the scroller active on >> Android (not a great UI but tolerable) or delete the scroller while the fake >> dialog is showing and rebuild the scroller after the fake dialog is >> dismissed… which is probably the better solution. I’m not sure why the >> disabled Android scroller is offsetting the touch when the iOS scroller is >> not. Maybe it is a bug and I’m the first person to put a disabled scroller >> over a button…more likely it is something that I’m doing wrong when I create >> the scroller. >> — Scott Morrow >> >>> On Nov 20, 2021, at 1:05 AM, scott--- via use-livecode >>> wrote: >>> >>> Jacque, that is pretty much what I’m doing (except that my semi-transparent >>> screen graphic is separate from the fake dialog group.) I agree that this >>> approach normally works well. I don’t have as much experience on Android so >>> I wondered if it had something to do with the platform. Apparently it is >>> something I’m doing. >>> >>> Brian, I will try your suggestion of isolating and breaking the process >>> down in order to determine where the issue lies. I was just feeling lazy >>> and hoping to save myself some work. :-) >>> >>> > On Nov 19, 2021, at 10:45 PM, J. Landman Gay via use-livecode > wrote: I've done several fake dialogs. The trick is to group the dialog with a a semi-transparent full screen graphic layered behind the dialog group. Greying the screen is normal behavior on Android and works on iOS too. The graphic has blocker mouse handlers so clicking it does nothing. That way you can script the dialog buttons to respond themselves. The user needs to click one of the buttons to make the dialog go away, at which point you hide the group. The buttons can put the response in the dialogData, which is a built in mechanism to transfer custom messages to a script, or else you can put the response in a global or a custom property. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com > On November 19, 2021 10:49:57 PM scott--- via use-livecode > wrote: > I’m having trouble with an app that up until now has just been for iOS. > Most of the changes have been pretty straight forward but I’ve > encountered a specific case where touching a button doesn’t pass the > touch message to the button being tapped… unless I touch significantly > below the button (I also had to switch from mouse messages to touch > messages in this particular case.) This is not a general issue. It only > happens when I show a group containing the buttons in question and while > this group is displayed there is repeat loop running that includes “wait > with messages” (I’m faking a modal dialog.) I encountered this once > before under the same circumstances (a fake modal dialog while moving an > iOS app to Android) and simply switched to using the built in dialog. > Unfortunately, that won’t work in this case. Any thoughts? > > -- > Scott Morrow > > Elementary Software > (Now with 20% less chalk dust!) > web https://elementarysoftware.com/ > email sc...@elementarysoftware.com > booth1-360-734-4701 > -- >>> >>> >>> ___ >>> 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
Re: Android tap location doesn't match visual location
Hi Scott - the touch coords being wrong sounds like a bug to me - can you file a report (with example stack if possible). Thanks! Mark. Sent from my iPhone > On 20 Nov 2021, at 12:04, scott--- via use-livecode > wrote: > > Just answering my own question in case anyone searches this later. > > This was kind of a forehead slapper when I finally saw it. There was a native > UIScroller over part of the screen. None of the other buttons on the screen > were inside the rectangle of the scroller, so they weren’t effected. The > scroller was being disabled while the fake dialog was on the screen and this > worked fine for iOS but in my case at least, it is problematic for Android. > My solution for now is to either leave the scroller active on Android (not a > great UI but tolerable) or delete the scroller while the fake dialog is > showing and rebuild the scroller after the fake dialog is dismissed… which is > probably the better solution. I’m not sure why the disabled Android scroller > is offsetting the touch when the iOS scroller is not. Maybe it is a bug and > I’m the first person to put a disabled scroller over a button…more likely it > is something that I’m doing wrong when I create the scroller. > — Scott Morrow > >> On Nov 20, 2021, at 1:05 AM, scott--- via use-livecode >> wrote: >> >> Jacque, that is pretty much what I’m doing (except that my semi-transparent >> screen graphic is separate from the fake dialog group.) I agree that this >> approach normally works well. I don’t have as much experience on Android so >> I wondered if it had something to do with the platform. Apparently it is >> something I’m doing. >> >> Brian, I will try your suggestion of isolating and breaking the process down >> in order to determine where the issue lies. I was just feeling lazy and >> hoping to save myself some work. :-) >> >> On Nov 19, 2021, at 10:45 PM, J. Landman Gay via use-livecode wrote: >>> >>> I've done several fake dialogs. The trick is to group the dialog with a a >>> semi-transparent full screen graphic layered behind the dialog group. >>> Greying the screen is normal behavior on Android and works on iOS too. The >>> graphic has blocker mouse handlers so clicking it does nothing. That way >>> you can script the dialog buttons to respond themselves. The user needs to >>> click one of the buttons to make the dialog go away, at which point you >>> hide the group. >>> >>> The buttons can put the response in the dialogData, which is a built in >>> mechanism to transfer custom messages to a script, or else you can put the >>> response in a global or a custom property. >>> >>> -- >>> Jacqueline Landman Gay | jac...@hyperactivesw.com >>> HyperActive Software | http://www.hyperactivesw.com On November 19, 2021 10:49:57 PM scott--- via use-livecode wrote: >>> I’m having trouble with an app that up until now has just been for iOS. Most of the changes have been pretty straight forward but I’ve encountered a specific case where touching a button doesn’t pass the touch message to the button being tapped… unless I touch significantly below the button (I also had to switch from mouse messages to touch messages in this particular case.) This is not a general issue. It only happens when I show a group containing the buttons in question and while this group is displayed there is repeat loop running that includes “wait with messages” (I’m faking a modal dialog.) I encountered this once before under the same circumstances (a fake modal dialog while moving an iOS app to Android) and simply switched to using the built in dialog. Unfortunately, that won’t work in this case. Any thoughts? -- Scott Morrow Elementary Software (Now with 20% less chalk dust!) web https://elementarysoftware.com/ email sc...@elementarysoftware.com booth1-360-734-4701 -- >> >> >> ___ >> 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: Android tap location doesn't match visual location
Just answering my own question in case anyone searches this later. This was kind of a forehead slapper when I finally saw it. There was a native UIScroller over part of the screen. None of the other buttons on the screen were inside the rectangle of the scroller, so they weren’t effected. The scroller was being disabled while the fake dialog was on the screen and this worked fine for iOS but in my case at least, it is problematic for Android. My solution for now is to either leave the scroller active on Android (not a great UI but tolerable) or delete the scroller while the fake dialog is showing and rebuild the scroller after the fake dialog is dismissed… which is probably the better solution. I’m not sure why the disabled Android scroller is offsetting the touch when the iOS scroller is not. Maybe it is a bug and I’m the first person to put a disabled scroller over a button…more likely it is something that I’m doing wrong when I create the scroller. — Scott Morrow > On Nov 20, 2021, at 1:05 AM, scott--- via use-livecode > wrote: > > Jacque, that is pretty much what I’m doing (except that my semi-transparent > screen graphic is separate from the fake dialog group.) I agree that this > approach normally works well. I don’t have as much experience on Android so I > wondered if it had something to do with the platform. Apparently it is > something I’m doing. > > Brian, I will try your suggestion of isolating and breaking the process down > in order to determine where the issue lies. I was just feeling lazy and > hoping to save myself some work. :-) > > >> On Nov 19, 2021, at 10:45 PM, J. Landman Gay via use-livecode >> wrote: >> >> I've done several fake dialogs. The trick is to group the dialog with a a >> semi-transparent full screen graphic layered behind the dialog group. >> Greying the screen is normal behavior on Android and works on iOS too. The >> graphic has blocker mouse handlers so clicking it does nothing. That way you >> can script the dialog buttons to respond themselves. The user needs to click >> one of the buttons to make the dialog go away, at which point you hide the >> group. >> >> The buttons can put the response in the dialogData, which is a built in >> mechanism to transfer custom messages to a script, or else you can put the >> response in a global or a custom property. >> >> -- >> Jacqueline Landman Gay | jac...@hyperactivesw.com >> HyperActive Software | http://www.hyperactivesw.com >> On November 19, 2021 10:49:57 PM scott--- via use-livecode >> wrote: >> >>> I’m having trouble with an app that up until now has just been for iOS. >>> Most of the changes have been pretty straight forward but I’ve encountered >>> a specific case where touching a button doesn’t pass the touch message to >>> the button being tapped… unless I touch significantly below the button (I >>> also had to switch from mouse messages to touch messages in this particular >>> case.) This is not a general issue. It only happens when I show a group >>> containing the buttons in question and while this group is displayed there >>> is repeat loop running that includes “wait with messages” (I’m faking a >>> modal dialog.) I encountered this once before under the same circumstances >>> (a fake modal dialog while moving an iOS app to Android) and simply >>> switched to using the built in dialog. Unfortunately, that won’t work in >>> this case. Any thoughts? >>> >>> -- >>> Scott Morrow >>> >>> Elementary Software >>> (Now with 20% less chalk dust!) >>> web https://elementarysoftware.com/ >>> email sc...@elementarysoftware.com >>> booth1-360-734-4701 >>> -- > > > ___ > 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: Android tap location doesn't match visual location
Jacque, that is pretty much what I’m doing (except that my semi-transparent screen graphic is separate from the fake dialog group.) I agree that this approach normally works well. I don’t have as much experience on Android so I wondered if it had something to do with the platform. Apparently it is something I’m doing. Brian, I will try your suggestion of isolating and breaking the process down in order to determine where the issue lies. I was just feeling lazy and hoping to save myself some work. :-) > On Nov 19, 2021, at 10:45 PM, J. Landman Gay via use-livecode > wrote: > > I've done several fake dialogs. The trick is to group the dialog with a a > semi-transparent full screen graphic layered behind the dialog group. Greying > the screen is normal behavior on Android and works on iOS too. The graphic > has blocker mouse handlers so clicking it does nothing. That way you can > script the dialog buttons to respond themselves. The user needs to click one > of the buttons to make the dialog go away, at which point you hide the group. > > The buttons can put the response in the dialogData, which is a built in > mechanism to transfer custom messages to a script, or else you can put the > response in a global or a custom property. > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > On November 19, 2021 10:49:57 PM scott--- via use-livecode > wrote: > >> I’m having trouble with an app that up until now has just been for iOS. Most >> of the changes have been pretty straight forward but I’ve encountered a >> specific case where touching a button doesn’t pass the touch message to the >> button being tapped… unless I touch significantly below the button (I also >> had to switch from mouse messages to touch messages in this particular >> case.) This is not a general issue. It only happens when I show a group >> containing the buttons in question and while this group is displayed there >> is repeat loop running that includes “wait with messages” (I’m faking a >> modal dialog.) I encountered this once before under the same circumstances >> (a fake modal dialog while moving an iOS app to Android) and simply switched >> to using the built in dialog. Unfortunately, that won’t work in this case. >> Any thoughts? >> >> -- >> Scott Morrow >> >> Elementary Software >> (Now with 20% less chalk dust!) >> web https://elementarysoftware.com/ >> email sc...@elementarysoftware.com >> booth1-360-734-4701 >> -- ___ 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
