LabVIEW
About How to develop Xnode
Solved!
wiebe@CARYA wrote:
We can compromise:
Agreed.
wiebe@CARYA wrote:
+ They tend to burn (my) time. So I'd only create one when I'm absolutely sure it's feasible, and very useful.
I hear this a lot when discussing XNodes and I agree that it can take some time to think of the use cases and either code for them, or code ways that the developer can't use it that way. That being said I make the XControl comparison. Every XControl I've developed has taken what seems like multiple weeks of off and on development. And the first time I go to use it I realize there are UI features missing or properties I'm expecting and not implemented. So I go back and hack them in and add XControl work around and spend seemingly another week or two with it. Then the next time I go to use it I find even more features missing or ways I want to use it. In the end I always end up with a huge mess of a XControl that just never feels good and took way more time to make than it should. XNodes in my opinion are better in that all that extra time I put into making it better actually does make it better. The ways in which a developer interacts with a node seems more constrained than the ways a developer will allow a user to interact with their UI.
@Hooovahh wrote:
wiebe@CARYA wrote:
We can compromise:
Agreed.
wiebe@CARYA wrote:
+ They tend to burn (my) time. So I'd only create one when I'm absolutely sure it's feasible, and very useful.
I hear this a lot when discussing XNodes and I agree that it can take some time to think of the use cases and either code for them, or code ways that the developer can't use it that way. That being said I make the XControl comparison. Every XControl I've developed has taken what seems like multiple weeks of off and on development. And the first time I go to use it I realize there are UI features missing or properties I'm expecting and not implemented. So I go back and hack them in and add XControl work around and spend seemingly another week or two with it. Then the next time I go to use it I find even more features missing or ways I want to use it. In the end I always end up with a huge mess of a XControl that just never feels good and took way more time to make than it should. XNodes in my opinion are better in that all that extra time I put into making it better actually does make it better. The ways in which a developer interacts with a node seems more constrained than the ways a developer will allow a user to interact with their UI.
I definitely prefer XNodes over XControls. No argument there.
First time I tried an XControl (back in LV 8.x) I found out that although the entire application would work in development, it would reproducible crash in the executable. Wasted a lot of time... Spoiled them for me, haven't tried if the bug was ever fixed (something about XControls on reentrant VIs in subpanels).
Search LabVIEW like a graph! 
@Hooovahh wrote:
wiebe@CARYA wrote:
We can compromise:
Agreed.
wiebe@CARYA wrote:
+ They tend to burn (my) time. So I'd only create one when I'm absolutely sure it's feasible, and very useful.
I hear this a lot when discussing XNodes and I agree that it can take some time to think of the use cases and either code for them, or code ways that the developer can't use it that way. That being said I make the XControl comparison. Every XControl I've developed has taken what seems like multiple weeks of off and on development. And the first time I go to use it I realize there are UI features missing or properties I'm expecting and not implemented. So I go back and hack them in and add XControl work around and spend seemingly another week or two with it. Then the next time I go to use it I find even more features missing or ways I want to use it. In the end I always end up with a huge mess of a XControl that just never feels good and took way more time to make than it should. XNodes in my opinion are better in that all that extra time I put into making it better actually does make it better. The ways in which a developer interacts with a node seems more constrained than the ways a developer will allow a user to interact with their UI.
The biggest headache I find with XControls is the need to support Properties and Methods (not needed for XNodes). Also, when creating XControls, in many places I often need the same code every time; so instead of starting with the 'empty' templates NI provides, I use my own 'full' templates and just cut away the parts I don't need. I've also created a couple of XNodes for use in XControls.
The biggest problem I've found with XNodes is handling data mutation. I find that UpdateState sometimes works, but often doesn't, meaning that old owning VIs get broken (and can be hard to fix). Try to avoid making any changes to the State.ctl after you've started using the XNode (it you really need a change, better to leave it alone and make a new XNode with a slightly different name).
@paul_cardinale wrote:
@Hooovahh wrote:
wiebe@CARYA wrote:
We can compromise:
Agreed.
wiebe@CARYA wrote:
+ They tend to burn (my) time. So I'd only create one when I'm absolutely sure it's feasible, and very useful.
I hear this a lot when discussing XNodes and I agree that it can take some time to think of the use cases and either code for them, or code ways that the developer can't use it that way. That being said I make the XControl comparison. Every XControl I've developed has taken what seems like multiple weeks of off and on development. And the first time I go to use it I realize there are UI features missing or properties I'm expecting and not implemented. So I go back and hack them in and add XControl work around and spend seemingly another week or two with it. Then the next time I go to use it I find even more features missing or ways I want to use it. In the end I always end up with a huge mess of a XControl that just never feels good and took way more time to make than it should. XNodes in my opinion are better in that all that extra time I put into making it better actually does make it better. The ways in which a developer interacts with a node seems more constrained than the ways a developer will allow a user to interact with their UI.
The biggest headache I find with XControls is the need to support Properties and Methods (not needed for XNodes). Also, when creating XControls, in many places I often need the same code every time; so instead of starting with the 'empty' templates NI provides, I use my own 'full' templates and just cut away the parts I don't need. I've also created a couple of XNodes for use in XControls.
The biggest problem I've found with XNodes is handling data mutation. I find that UpdateState sometimes works, but often doesn't, meaning that old owning VIs get broken (and can be hard to fix). Try to avoid making any changes to the State.ctl after you've started using the XNode (it you really need a change, better to leave it alone and make a new XNode with a slightly different name).
Getting a string "two wrongs make one right", "negative X negative = positive" vibe here 
.
Biggest problem I had was getting the referrer construction to work. The only documentation I could find was "do not use this, ever" (= "challenge excepted" in my XNode book). It does indeed not work 100% as expected. I won't post info on that, as it still crashes in some corner cases.
