Android tap location doesn't match visual location

[scott at elementarysoftware.com]

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 <use-livecode at lists.runrev.com> 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 <use-livecode at lists.runrev.com> 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 | jacque at hyperactivesw.com
>> HyperActive Software | http://www.hyperactivesw.com
>> On November 19, 2021 10:49:57 PM scott--- via use-livecode <use-livecode at lists.runrev.com> 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     scott at elementarysoftware.com
>>> booth    1-360-734-4701
>>> ------------------------------------------------------
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode