Closing an FXInternalWindow issue

[javalearner]

Hi again,
Noticed something a little odd, would like some clarification.

When using an FXDesktopPane, and I add say 3 FXInternalWindow's, then using the "X" close button one of the windows, next call the FXDesktopWindowManager's getWindows(), I would expect it to only return 2 windows, however it returns 3.

Also, if you add 5 windows, then click on the "X" to close them, and add another 5 windows, the "getWindows()" call returns 10 windows.

When you click the "X" close button, I would have throught that it would remove the Nodes from the Pane, and remove the window from the "SimpleListProperty<FXInternalWindow> windows array".

ie. looks like they get removed from the Pane, but no removed from the array.

Cheers.

[rzenz]

I can't reproduce this with the default test case (test.manual/com/sibvisions/rad/ui/javafx/ext/mdi/MDITestMain.java). They get correctly added and removed from the list. Can you test with that test class?

[javalearner]

Okay, I think I found how I am getting the weird behavior...

In the test program, you are calling the pane's add window function, however if you get the Window Manger to add the window the issue appears to happen.....

Should you always add windows directly into the Pane or the Window Manager? I would have thought you should make the Manager control the Pane... I might be mistaken... I thought the Pane would be like the View, and the Manager would be like the Controller/Model.
Why does the Pane and the Manager both keep separate Array's of windows?

To confirm, change the following:

Code: Select all

pane.getWindows().add(createWindow("Window #" + pane.getWindows().size()));

to

Code: Select all

pane.getWindowManager().addWindow(createWindow("Window #" + pane.getWindows().size()));

Add some windows and close them, and see what happens.......

Many thanks.

[rzenz]

Yes, the idea is that the user/client only interacts with the FXDesktopPane, the desktop pane acts as a facade over the window manager. Your MVC analogy is exactly reversed, consider the desktop pane the controller and the window manager the view. The idea is simple, through the desktop pane you control the windows which are being displayed, the window manager on the other hand is there to control how the windows are being displayed to the user.

With that in mind, the question as to how to fix this becomes complicated. Technically, the IFXWindowManager interface is only supposed to be used by FXDesktopPane, internally. I see how such a confusion like yours could easily happen. The best solution that I can think of right now is to revise and extend the Javadoc to make sure that it states this case clearly. As to whether this can be fixed, as the FXDesktopPane is propagating its changes to the IFXWindowManager, I'm not sure if it would be easy to also make the IFXWindowManager propagate its changes to the FXDesktopPane without causing a lot of unnecessary complexity. On second thought, the IFXWindowManager could be revised to only accept the FXDesktopPane and the properties and functions concerning the windows should be removed, so the interface would look like this:

Code: Select all

public interface IFXWindowManager
{
    public void attachTo(FXDesktopPane pDesktopPane);
    public void dispose();
    public void detach();
    public Pane getPane();
    public void restoreState(Object pState);
    public Object storeState();
}


With the attach/detach methods being new ones and the window functions removed. I believe that would actually solve this quite nicely, as the window manager can still register itself as listener on all the properties of the desktop pane.

[javalearner]

Ah, I see, I thought having the word "Pane" meant that it would act like a basic container (like the JavaFX Pane) and the window manger would do all the work.

I'll modify how I am interacting and focus on the Pane and leave the WM alone.

As such, thinking a little more on a Layout manager (for want of a better name), would this be best to work within the Window Manager, or attach it to the FXDesktopPane like you do with the Window Manager...?
And have it watch the Pane's Window list and if needed apply any resizing if called?

Many thanks.

[rzenz]

Ah, I see, I thought having the word "Pane" meant that it would act like a basic container (like the JavaFX Pane) and the window manger would do all the work.

Well, that is actually what is happening to a certain degree. The desktop pane manages the windows (and the active one, f.e.), but the window manager does decide how they are displayed to the user.

As such, thinking a little more on a Layout manager (for want of a better name), would this be best to work within the Window Manager, or attach it to the FXDesktopPane like you do with the Window Manager...?

And have it watch the Pane's Window list and if needed apply any resizing if called?

If you're talking about the stacking you've implemented, that would be best to have on the window managers. Having an additional window layout manager to the window manager seems rather confusing (not to mention that you can't really stack tabs, for example).