OK, what I was getting at was that this is illegal in Java as well:

@edvin uploaded a file: Uninitialized values can't be accessed

@edvin this compiles for me but throws the expected NPE

public class InitTest { Integer myValue; Integer thisWontCompile = 42 + myValue; public static void main(String[] args) { System.out.println("thisWont=" + new InitTest().thisWontCompile); } }

I suppose that makes sense, but I guess my thought was that since the value had been set in a previous function, it would recognize the next (but as discussed before, I would have to manually define callback functions for the the value to stay on track)

@carlw Fancy, that's actually different if you stick it in a method as local variables 🙂 I didn't know that was handled differently by the compiler!

however, wouldn't it follow that a value in onMouseDragged would know what a value in onMousePressed is? Not sure how it works, but I would assume that you would have to press a mouse down in order to drag

@amanda.hinchman-dominguez What you're talking about is a consequence of how these functions are called in a certain context, but the compiler cannot know that the value has been set before hand 🙂 That's why it refused to compile the code. As Carl pointed out, the typical solution is to assign a negative value, or since you're using JavaFX, you could use IntegerProperty instead, which can contain null, so you can actually check if it was called before hand if needed.

@amanda.hinchman-dominguez you might find this blog post useful. unfortunately, it's straightup javafx + fxml http://bekwam.blogspot.com/2016/02/moving-game-piece-on-javafx-checkerboard.html

@edvin sneaky compiler behavior! Now that makes sense, I just had wishful thinking. First thing I learned about coding is that computers are malicious and stupid 😬

@carlw sounds great! Perhaps it would be better for me to go ahead and have this written in javafx first before trying to write drag-and-drop in kotlin. I'm truly thankful that tornadofx allows the ability for multi-language support

@amanda.hinchman-dominguez One trick of the trade that's worth mentioning is userData and properties. I've built a few flowchart builder tools for clients and usually pass around a business / model object in these fields which are available in any Node So, that makes casting or working with any given shape not needed. You can just case the source to a Node and pluck off the userData or properties fields.

@amanda.hinchman-dominguez Haha, I thought it was us users that were malicious and stupid 😁

computers are only as good as we make them, right 😄

alright, cast to a node, use userData or properties fields. I'll give it a go. I read through the user properties and didn't really get it the first time, but the only way to really learn is by doing

you can see another use of properties in tornadofx. edvin uses them as an alternative to custom class or delegates. for example, you can flag a Rectangle object with a user property of "myapp.currentSourceConnection"

i prefer the properties to userData since it's more general. you can put any object on userData, but only a single object. properties can handle any number of name value pairs

@amanda.hinchman-dominguez what you want to avoid when dealing with graphical apps like this -- simple forms aside -- is to try to keep the model and business logic in sync at all times with what the user sees on the screen. There is of course a relationship (ex rectangle a + line 1 + rectangle b == voltage source a + wire + voltage source b). But you don't want to start putting a lot of the drag and drop operation into the model. What this means in practical terms is that you may support intermediate states for the UI -- ex dragging -- and execute a final model update onlyu when the UI operation concludes (drop). I've seen attempts to modify model elements along the way that end up in bad states and bugs.

Thanks for the helpful tip - I've only had extremely minimal experience with dealing with states in ruby on rails and elm; would you say that your blog on event processes handles intermediate states and updating a final model?

my post is pretty limited. in that repo, you'll see the start of a multi-player online checkers game built with JavaFX and WildFly (Web Sockets). i never got to integrate the game play which would be the final model update that applies the game rules

you can see what i'm talking about in the tornadofx forms where you commit. This separates the Screen State (values in a contact form) with the Record State (values saved via a RESTful web service to a contact table).

forms where I commit? What are you referencing to?

The PersonModel example from the ViewModel Wiki

Binding keeps certain classes 100% in sync with the UI, but an explicit commit() will establish a point at which we want to attempt a model update

@edvin outside state? I assume you mean the tablecell instead of the underlying data. If so, that's what I wanted

@pike If it works for you, keep it. But let me know if you run into performance or memory issues, we can look at a cheaper way to achieve the same goal.

I'm missing something important about

ItemViewModel

. For example, at what point does the

item

become non-null? I'm at the end of a wizard that manipulates the model -- now I want the item so I can do something with it. Committing the model doesn't seem to do it.

@edvin we’ll try it out today and see 🙂 I only chose this approach because I was focused on coloring a row.

@kastork what kind of class are you working with for an ItemViewModel?