Bug when button under OK button in messagebox

I seem to have stumbled across a bug - if you have a button on your window in the same location as the OK button on a messagebox, pressing OK on the messagebox also triggers a tap event on the underlying button. Can anyone confirm?

James

Why do you have two buttons in the same location?

@ Architect; he doesn’t. He has 1 button in a location and then when he opens a dialog and the dialog’s button happens to occupy the same space as his button it glitches. Glide probably is going through the controls from 0 to Length - 1. In this case it should really go the other way around. Or have a window priority list.

Oh I see. Indeed sounds like a bug.

I am having the exact same problem.

Any touch on any part of the messagebox seems to be queued while the messagebox is open, and then “replayed” to whatever is underneath the messagebox once it is closed.

For example:

  1. I have a textbox with an ontap event that shows the keyboard.
  2. A messagebox opens, with an empty section of the messagebox covering that textbox completely.
  3. I touch that part of the messagebox 5 times while it is open… nothing seems to happen.
  4. I touch OK to close the messagebox.
  5. Once the messagebox has closed, the keyboard opens, and 4 presses of whatever key is now in the same spot as where I pressed 5 times previously appears in the textbox.

A similar thing happens even if I only make one VERY short and precise touch on the OK of the message box and the textbox is directly underneath the messagebox OK button, except that perhaps only 1 key press appears in the textbox. It’s almost like the OK button is “bouncing”, and those extra presses are also being transferred to whatever is underneath.

I have even tried removing the OnTap events for all the elements on the window before opening the messagebox, like this:

btnSave.TapEvent -= new OnTap(btnSave_TapEvent);

and then adding them back in again after a thread.sleep(1000), like this:

btnSave.TapEvent += new OnTap(btnSave_TapEvent);

and the behavior is exactly the same.

A debug showing the .TapEventIsNull shows true when I remove the events, but as soon as I add the OnTap event back onto the textbox they come flying back in again, like they were saved somewhere and get replayed again

I’m wondering if there is some kind of temporary workaround I can use until this bug is fixed?

I’m using a ChipworkX Dev System V1.5 with clrVersion 4.1.2821.0, Build 4.1.7.0

Many Thanks.

Welcome to the forum!

I haven’t used Glide much, but can you keep track if the event has been handled. Add TapEvent handlers for all controls in question. Set a boolean to true in the handler where you actually need the event and do nothing in other handlers if boolean is true.

A quick fix on the glide side would be to add “Handled” property to the event object. Setting it to “true” will prevent propagating it back.

We have some good news for glide. It is under final discussion and approval now.

Thanks for the welcome!

The (very poor and temporary) solution I came up with is something similar to your suggestion.

The problem is that the OnTap events seem to queue up against the event handler, even if it’s removed. As soon as you add it back in again the events all fire off in order. So in order to get rid of them you have to allow whatever is handling those touch events to fire off the event handling routine, even if it does nothing.

My solution is NOT to do this (as outline in the documentation)

btnSave.TapEvent += new OnTap(Glide.OpenKeyboard);

But do this instead:

btnSave.TapEvent += new OnTap(btnSave_TapEvent);

for whatever objects are underneath the messagebox when it opens.

Then in btnSave_TapEvent I check a boolean which indicates if I should ignore all tap events. I set the boolean to true just before I open the messagebox.

There is still a problem though if I set the boolean back to false as soon as the messagebox closes, because it seems like those ontap events can take a few hundred ms to come through. And if I do a thread.sleep then everything pauses, including the ontap events, and they come through again as soon as thread.sleep is finished.

So I had to do a little timer routine to automatically reset the boolean 1000ms after the messagebox is closed. This allowed the thread to continue and the events to fire off and be safely ignored before re enabling the touch events again.

Like I said, it’s very messy and cannot stay this way. I’m sure it could be made better, but I have only very basic, self-taught programming skills, and that’s the best I could do for now.

Thanks for your advice though Architect.

Srry for digging this up, but has this been solved in QFE2 RC2?

Glide is a separate library and unrelated to the SDK releases. You can find all source codes on codeplex. http://www.ghielectronics.com/glide

Oh Ok, didn’t know that, thought it went hand in hand with the SDK. Do you know if someone is working on a new version, since there hasn’t been a commit since July 30th?

EDIT: On the other hand it is actually clear since it has it’s own codeplex site and I had to download the source to compile the dll’s…Good Morning^^