Pivot
  1. Pivot
  2. PIVOT-675

Dialog does not become the Active Window

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 1.5.2
    • Fix Version/s: 2.0.1
    • Component/s: None
    • Labels:
      None

      Description

      EntryEditorPanel entryPanel = EntryEditorPanel.create();

      Dialog dialog = new Dialog(entryPanel, true);
      dialog.setTitle("New Entry");
      dialog.open(getWindow());

      dialog.requestActive();
      dialog.requestFocus();


      After the above code is executed the component in the dialog has the focus and behaves like the active window but it's windows titlebar is still grayed-out, it's not blue as you would expect. If you then click on the window it's titlebar becomes blue. This is a bit confusing and not the behavior you'd expect.

        Activity

        Hide
        Greg Brown added a comment -

        FWIW, I tried replacing the Prompt in the Context Menu tutorial with an Alert and I was not able to reproduce this problem. I'm curious to see the code that you are using that causes the issue to occur.

        Show
        Greg Brown added a comment - FWIW, I tried replacing the Prompt in the Context Menu tutorial with an Alert and I was not able to reproduce this problem. I'm curious to see the code that you are using that causes the issue to occur.
        Hide
        Greg Brown added a comment -

        Can you provide a code sample that demonstrates the issue by opening a dialog via a context menu?

        Show
        Greg Brown added a comment - Can you provide a code sample that demonstrates the issue by opening a dialog via a context menu?
        Hide
        ocean added a comment -

        Actually it looks like it doesn't really matter what Window value I pass in to the Dialog.open() method. Instead it seems possible that the context menu is still visible when I open the Dialog and this interferes with making the Dialog the true active window. I think I may need to find a way to delay the opening of the dialog until after the context menu is really gone.

        Show
        ocean added a comment - Actually it looks like it doesn't really matter what Window value I pass in to the Dialog.open() method. Instead it seems possible that the context menu is still visible when I open the Dialog and this interferes with making the Dialog the true active window. I think I may need to find a way to delay the opening of the dialog until after the context menu is really gone.
        Hide
        ocean added a comment -

        After digging around and playing with your example application I realized that this problem only happens when the action is triggered via a context menu. There are two ways to initiate the action that brings up the dialog: the user can double-click on a row in a TableView or they can right-click on the TableView and then click 'Edit Selected' from a popup menu. When the user double clicks the result is a dialog that behaves as expected, it has focus and it's window titlebar is blue. When the user brings up the dialog via the right-click popup menu the resulting dialog has focus but it's window titlebar is not blue.

        I don't see any reason in this code why this behavior should occur. The only thing I can guess is that possibly when a context menu is shown it interferes with calculations about what is the active window. For example, I just realized that getWindow is actually an ancestor-search and implemented in Component like:

        public Window getWindow()

        { return (Window)getAncestor(Window.class); }

        I will try passing in a concrete, known window instance and not rely on Component.getWindow that seems to behave strangely in the presence of context menus.

        Show
        ocean added a comment - After digging around and playing with your example application I realized that this problem only happens when the action is triggered via a context menu. There are two ways to initiate the action that brings up the dialog: the user can double-click on a row in a TableView or they can right-click on the TableView and then click 'Edit Selected' from a popup menu. When the user double clicks the result is a dialog that behaves as expected, it has focus and it's window titlebar is blue. When the user brings up the dialog via the right-click popup menu the resulting dialog has focus but it's window titlebar is not blue. I don't see any reason in this code why this behavior should occur. The only thing I can guess is that possibly when a context menu is shown it interferes with calculations about what is the active window. For example, I just realized that getWindow is actually an ancestor-search and implemented in Component like: public Window getWindow() { return (Window)getAncestor(Window.class); } I will try passing in a concrete, known window instance and not rely on Component.getWindow that seems to behave strangely in the presence of context menus.
        Hide
        Greg Brown added a comment - - edited

        By "self-contained", I mean that:

        a) It should be possible to execute the code as-is (i.e. it should not require any modification or additional work to get it to run).

        b) The code should not have any external dependencies. Neither of your above examples are self-contained, because they refer to classes, values, and methods that are not included in the example (EntryEditorPanel, xxx, deleteEntry(), and selectedE).

        Ideally, it should be the smallest amount of code required to reproduce the issue.

        I have attached a small app I created to try to reproduce the problem. I was not able to reproduce it, but maybe you can modify the example to get it to happen.

        Show
        Greg Brown added a comment - - edited By "self-contained", I mean that: a) It should be possible to execute the code as-is (i.e. it should not require any modification or additional work to get it to run). b) The code should not have any external dependencies. Neither of your above examples are self-contained, because they refer to classes, values, and methods that are not included in the example (EntryEditorPanel, xxx, deleteEntry(), and selectedE). Ideally, it should be the smallest amount of code required to reproduce the issue. I have attached a small app I created to try to reproduce the problem. I was not able to reproduce it, but maybe you can modify the example to get it to happen.
        Hide
        ocean added a comment -

        Hey Greg. Not sure what you mean by self-contained. Note that I've also discovered this problem with the Alert.alert methods. Eg the following code snippet also produces this problem:

        Alert.alert(
        MessageType.QUESTION,
        "Delete " + xxx + "?",
        getWindow(),
        new DialogCloseListener() {

        @Override
        public void dialogClosed(Dialog dialog, boolean modal) {
        if (dialog.getResult())

        { deleteEntry(selectedE); }

        else

        { return; }

        }
        });

        This seems to be the default behavior in pivot for all dialogs when running pivot applications as standalone java applications. Do you not see this behavior?

        Show
        ocean added a comment - Hey Greg. Not sure what you mean by self-contained. Note that I've also discovered this problem with the Alert.alert methods. Eg the following code snippet also produces this problem: Alert.alert( MessageType.QUESTION, "Delete " + xxx + "?", getWindow(), new DialogCloseListener() { @Override public void dialogClosed(Dialog dialog, boolean modal) { if (dialog.getResult()) { deleteEntry(selectedE); } else { return; } } }); This seems to be the default behavior in pivot for all dialogs when running pivot applications as standalone java applications. Do you not see this behavior?
        Hide
        Greg Brown added a comment -

        Could you provide a complete (self-contained) example that demonstrates the issue?

        Show
        Greg Brown added a comment - Could you provide a complete (self-contained) example that demonstrates the issue?

          People

          • Assignee:
            Unassigned
            Reporter:
            Bo
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development