@carlw @edvin my problem is as follows

Untitled.kt

If I load the width, height and divider position from config in onDock, divider is getting repositioned at the middle of the splitpane.

@anidotnet @edvin It seems like the problem is with the initial case. Once, the splitter is set, its position is remembered because the View is a Singleton. You're getting the same object when the Window is shown again. This example opts to set the initial position based on settings passed in through the global app.config object. Once this base case is handled, no other event related code is needed. I tried the app.config.double function but had some trouble with that so I have a null check. That's not essential to the task at hand which is getting the initial values established. (Looking more into it now.)

I also removed the code in BaseView as the newly-added onBeforeShow isn't needed (at least in this case).

@edvin this is printing 0.9 which is the default value rather than 0.1 which is the set value app.config.set("myvalue", 0.1) println( app.config.double("myvalue", 0.9) )

@carlw I was really looking for loading the states in one of the event listeners. The reason is for my app, I have created a different config repository backed by a db, and there each config element I can bind to any tfx property so when it changes the new value will be saved automatically and will be loaded and set next time after the window loads. Again, the problem with node's prefHeight/prefWidth is that when I change the width/height of the window, it does not reflect that change so it creates a binding problem for me. So I was looking into binding with stage's height/width instead, but we can see it is creating problem for splitpane divider. May be I am thinking it in wrong way, if you can give me some idea it will be great.

I let JavaFX layout the components as much as possible. It sounds like you might get into a probelmatic pattern where you're resetting the layout -- in accordance with saved preferences -- against what JavaFX is doing. This is even in the case of positions where my example demonstrates that the SplitPane position is "saved" when the window is re-shown. If there is a lot of this continual serialization of the current UI state, you might find a source of bugs coming from the gap between what you're recording and what JavaFX is doing by default.

So you are suggesting a direct binding with a property should be avoided. I should save the preference in unDock and load those during onDock or at layout time?

i would set up your base case based on the properties. for views, this will only be once because it's a singleton. subsequent settings should "stick around" because the same object is being displayed. then, you just have to worry about saving the values for next time the view is find() -ed. i'd have to look at the specific bindings. I've bound to width and height without an issue. my suggestion discourages adding more and more bound properties like "splitter division position" which are already set to what you want

But say, if the user change the splitter division position and want it to the same position next time when the stage is shown (find()-ed)

it's already in the same position as per my example, right?

you don't have to clear it out and then reset the value

Let me explain. Say currently position is it 0.2. User changes it to 0.3 and close the app. Now when the app opens, it should be at 0.3

so how do I do that without binding

an exit handler to save the current settings that have built up

yes, so ideally I should put the persistence part at onUnDock() and load it at layout time or onDock()?

are you doing a file-based operation with each splitter movement?

no, I am saving it in memory, during app exit I am saving it to a file

precisely saving it in a map and storing it in db during exit

did you consider the existing app.config map?

I considered it already, but in the same config repository I need to save other settings (apart from UI states) as a POJO directly

which app.config does not support

onUnDock is the best place to sync up to the config model IMO. It covers the shutdown case and will perform the occasional sync while the windows get moved around and hidden

then your exist handler persists the config model

ok..

what's the difference between app.config and your map?

the value takes Any?

and where do I load the value from config?

may map is like Map<String, ConfigElement<*>>