05-17-2012 08:37 AM
Like you I find it difficult to believe that there is a problem with a straight Dialog. So can you create a simple, one screen example, with a Dialog in it, that shows the problem? Then we can look at it and test it ourselves.
05-17-2012 09:46 AM
the ButtonField isnt the issue, it's not there in the actual app, it was just a way to get the dialog box to show up in the same sort of context as my app.
On a slight different but related note, why do i need to tell the system that the button should consume the click? Thats insane, who wants a button that doesnt consume the click? What situation would that be normal? If your going to offer that as an option why is it a default, consuming the click should be the default and not consuming the click should be the option. Rant over!
05-17-2012 10:01 AM - edited 05-17-2012 10:02 AM
Just out of interest, does CONSUME_CLICK actually resolve the issue in your test case? If it does, that may well give us a hint to the real problem.
I do think you are hitting a Storm related issue rather than an OS 5.0 related issue. The Storm is different in its processing of events, to the extent I try not to support it if I can get away with it....
Try another OS 5.0 device to see if the problem is present there also.
I won't have time to test this code myself till much later.
05-17-2012 10:05 AM
if that solved ur problem, why not marked this as solved.
because I didnt realise that was the issue at the point. The button in test was just implemented to allow you to get the dialog to pop up in the same sort of way as my app does(i.e. after pressing something dialog pops up).
The "consume click" rant i went on was at the general absurdity of having to tell the system that the button must consume the click. Doesnt that sound stupid to you?
I just tested it and it does work. will mark your post as the solution