@edvin I have a custom scope but I want to register for app-wide events. Using DefaultScope on the declaration and fire() is easy enough object ShutdownEvent : FXEvent(scope=DefaultScope) fire(ShutdownEvent) however on the subscriber side, it looks like you're locked in to a framework scope setting I'm doing this as a workaround init { FX.eventbus.subscribe<ShutdownEvent>( DefaultScope, FXEventRegistration(ShutdownEvent::class, this, 1L) { root.scene.window!!.hide() } ) }

@sbyrne Here's a demo MDI app. It's requirements are to display text files through a command line argument or via the File > Open command. If you specify the command line argument (just a single value), the file will take the path and open a file, displaying the contents immediately in the main window. If you use the File > New Window option, you'll open an additional independent window which can display the text contents from a different file.

Simple_Text_Viewer_Source.kt

Initially, there's a single DefaultScope. That gives me the bootstrap to be able to load the program with an arg[0]. Subsequent windows use a new scope. Each Controller instance keeps track of the filename and the loaded contents. For app-wide shutdown, I use a modified DefaultScope event that broadcasts to all open instances.

MDI with 2 open windows

@edvin in the program posted above (listed under 11:30 PM my time), it looks like onDock() isn't called for every opened stage. When the app is opened, the View is displayed and the onDock is called. This is using the normal App(View::class) technique. In my File > New Window function, I use find<View>().openWindow(). In that case, the onDock isn't called. I think there's a problem in the state tracking and the app thinks additional instances of View are showing already. I haven't tested a Fragment, but I think this is supposed to work with Views that are scoped. I moved my binding code to onBeforeShow(). The version below works

Fixes a bug with the Stage title ; may be TornadoFX bug involving onDock()

@carlw Are you using the latest snapshot? We fixed a bug concerning this a little while ago

@sbyrne I'll post an example of how to open different views with different scopes depending on command line arguments 🙂

-.kt

If you start that application from the command line with

--initialView=view2

, it will show

View2

. If not, it will show

View1

. It also shows you how to create a scope and open the view in that scope. Use

newScope.set(someModel)

to put stuff into that scope. Does that help @sbyrne?

@edvin Testing out 1.7.18...I noticed another error on the label() builder in a different program when I switched

error_on_label_SimpleStringProperty_.m

My test case is label(SimpleStringProperty())

@edvin onDock() isn't being called with the 1.7.18-SNAPSHOT

Potential_Bug_in_onDock__.kt

My test case is the above code 1. Start the app 2. Verify that the onDock prints out a hashCode for the Stage 3. Select File > New Window 4. Verify that no message as in Step 2 is displayed

@carlw I tested your code, and it displays for both steps:

dock called for instance 216850238 dock called for instance 1681136234

As usual I couldn't bring myself to run the code sample before updating some of the code to newer syntax though.. hehe.. Can you try to run my code to see what happens? Don't suspect anything I did changed any semantics, but just to be sure. Also try against latest snapshot.

-.kt

@edvin - a couple of weeks ago you were going to post a new jpro sample app I believe - has that happened?

@gtnarg I submitted it to JPro and I think it was part of a talk at a conference in Germany, but the rewrite of the app was a much bigger task than I anticipated, so I didn't want to post an incomplete app. You see, I'm converting it from one backend to another, with vastly different database schemes.

@gtnarg I have a few views working, enough to demo it, but not all the code makes sense right now.. To get around some of the db weirdness I also had to do some trickery, so it won't all be best practices. However, I'm writing a more general version of the app where I have full control of the data store. This will be more interesting for other developers. It will instead export data to those other systems when needed.

@edvin are you using the 1.17.18-SNAPSHOT at sonatype?

@carlw No I'm just using the latest from github, but that should effectively be the same

I apologize for my rather dense question, but did I see somewhere that tornadofx is only currently support up to java 8??

that's what the github page says

but I see that https://openjfx.io/ is available for 11