Shikhar13 / codenameone

Automatically exported from code.google.com/p/codenameone
0 stars 0 forks source link

Dialog DisposeWhenPointerOutOfBounds triggered when pointerReleased out of dialog bounds #247

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. I .show() a Dialog in a longPointerPress(x,y) method (that i wrote myself)
2. when the pointerRelease(x,y) x and y coordinates are out of the dialog 
bounds, the dialog disposes

What is the expected output? What do you see instead?
I think its better to not dispose a dialog when a pointerRelease() event 
occurs, which is out of the dialog's bounds because this leads to the 
(unwanted) disposing of the dialog before the user can read the dialog.

What version of the product are you using? On what operating system?
latest cn1, w7

Please provide any additional information below.
I hope that this is considered to be unwanted behaviour!

Original issue reported on code.google.com by tron.cos...@gmail.com on 9 Jul 2012 at 5:41

GoogleCodeExporter commented 9 years ago
We never perform navigation on pointer or key pressed which is generally a very 
bad practice and source of numerous bugs. 

As a workaround you can set dispose when pointer outside of bounds to false and 
only activate it when you get the pointer released event. 

I'm assigning to Chen so he can evaluate integrating that fix into the dialog 
code so it will work for this use case.

Original comment by shai.almog on 10 Jul 2012 at 5:45

GoogleCodeExporter commented 9 years ago
I am unable to reproduce this.
can you add a snippet of code that describes your problem

Original comment by cf27...@gmail.com on 16 Jul 2012 at 1:17

GoogleCodeExporter commented 9 years ago
This is the use case i was talking about:

- make a small dialog "LongPointerPressDialog" which is disposed when pointer 
out of bounds and that doesn't occupy all space of the display of the device

- create a form with a map in the designer

- add this code in the before method of the mapform:
       f.addPointerPressedListener(new ActionListener() {

            public void actionPerformed(ActionEvent evt) {
                Timer longPointerPressTimer = new Timer();
                longPointerPressTimer.schedule(new LongPointerPressClass(), 800);
            }

- make following class:
    public class LongPointerPressClass extends TimerTask {

        public LongPointerPressClass() {
        }

        public void run() {
            System.out.println("should now invoke longpointerpess dialog");
            Dialog longPointerPressDialog = ((Dialog) createContainer(fetchResourceFile(), "LongPointerPressDialog"));
            longPointerPressDialog .show();
        }
    }

- go to the mapform and click somewhere at the border of the device's screen 
(out of the bounds of the dialog)

-> the dialog is disposed because the pointerReleased() event is out of the 
dialog's bounds

Original comment by tron.cos...@gmail.com on 16 Jul 2012 at 2:51

GoogleCodeExporter commented 9 years ago
and of cause this code is stripped, it's not a real longpointerpress method ;-)

Original comment by tron.cos...@gmail.com on 16 Jul 2012 at 2:53

GoogleCodeExporter commented 9 years ago
on the dialog properties you can select/unselect DisposeWhenPointerOutOfBounds, 
is this not working?

Original comment by cf27...@gmail.com on 16 Jul 2012 at 3:00

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
selecting/unselecting DisposeWhenPointerOutOfBounds is working. I want the 
Dialog to be disposed when the pointer is pressed out of the dialogs bounds, 
but not when the pointer is _released_ out of bounds..

Original comment by tron.cos...@gmail.com on 16 Jul 2012 at 3:11

GoogleCodeExporter commented 9 years ago
this also affects the menu. Like this the menu behaviour is unnatural (at least 
on android) because usually the menu is not disposed when the pointer is 
pressed within the menu and then _released_ out of the menu's bounds.
It really feels wrong... 

Original comment by tron.cos...@gmail.com on 24 Oct 2012 at 10:35