@carlw commented on @carlw’s file : Setting if viewing a singleton object's fields where the singleton is defined with the "object" keyboard

@edvin - the ItemViewModel documentation looks good. It might also be useful to see an example where the ViewModel would be used over the ItemViewModel

@gtnarg Ah, great thanks.. I will add some information about when to use ViewModel over ItemViewModel. The only real use case is if you have multiple sources of data, like if you use the ViewModel for navigation/ui state, and not to proxy for a certain domain object.

@gtnarg I pushed some info about ViewModel vs ItemViewModel to the guide now.

@carlw Nice! That's not on by default?

@edvin no. i was troubleshooting a singleton that used the object keyboard but wasn't able to examine the fields when i was debugging

@carlw I see. You could probably write it in the expression evaluator, but it wouldn't show up in the variable list?

@edvin i was chatting about this in the intellij channel. i'll send the code snippet over if you want to see what I'm writing about. You select an object in the debugger and rather than expanding, showing all the fields in the Kotlin class, it would say "No fields to display".

@carlw commented on @carlw’s file : From IntelliJ channel...resolved by debugger property to show static final fields

@User shared a file: and commented: Does anyone know if this is an IntelliJ problem or an incorrect interpretation of object? I'm trying to examine the data field in the function but get "no fields to display". If I convert this to a class and object pair, I can see the field.

I understand 🙂

@edvin - I think something went wrong with your commit - search on 'Typical Use Case' and you will find it twice

@gtnarg I see it, thanks. Wondering what happened there..

It seems like the whole thing was just duplicated somehow.. Need to figure out if there are any differences to the two copies. I'm on the laptop with an awfully small screen. Will try to sort it out after Alyssa is in bed.

There 🙂

I would expect

openModal()

to block by default similar to

openInternalWindow()

@edvin Is this a bug or am I doing something wrong?

@User uploaded a file: Untitled and commented: If I run the app, hit the button, and close, the JVM never shuts down (there are still a number of threads open).

@User uploaded a file: Untitled and commented: But this exits as expected

@Ruckus I'm just glancing over this, but I think this is works as designed. If you want the app to close and keep a thread running, try making it a daemon. The JVM will keep your program going as long as there are live threads. I don't have a reference handy. I've seen this in the context of Web Start JavaFX apps which won't close completely with Platform.exit() because the javaws process itself is still running, so you have to use a System.exit().

I don't want anything to stay running. How do I ensure the TornadoFX version exits when closed?

(The JavaFX version is the behavior I expect)

In both cases,

stopped: true

is printed, but only the JavaFX one exits. Not that if you don't submit anything to the pool both versions exit without a problem.

I usually use System.exit. If I have time later, I'll try to reproduce this and maybe see if ForkJoinPool gives you the semantics you're looking for.

Thanks. I'll mess around with it more too as I get time.

I don't know if a fork/join pool will be good for me since the submitted tasks won't be divide and conquer, just long running background tasks with a lot of calculations and file output.

(The calculations aren't recursive)

I don't use the join() for a fancy algorithm. Sometimes, I pull together a bunch of independent init sequences and the join() is a barrier to continuing. I'm thinking that maybe the join() will bring all the threads together whereas shutdown() was more of a hint to the threads.

Have you tried JavaFX Service? Maybe you don't really need a pool