LabVIEW
Case structure not working for string
Solved!
@RavensFan wrote:
Those two block diagrams looked pretty equivalent to me. They had exactly the same number of components.
Yup totally agree with that one. Those that know enough about the subject (on both sides) can argue either side because they know it well enough.
Hello everyone,
thank you very much, and especially to @Ben, for the review of my post, and giving me valuable feedback!
In that post I didn't put my statements to some absolute - because everyone is doing things in a way how he likes, or how he found it will be useful. The same is with state machine - someone finds benefits in enums usage, someone finds in strings usage. And some other guy would tell to forget about all of those, and implement code using OOP Command pattern, and forget about "state-data" approach, but incapsulte everything to classes.
Personally me, as you see, prefer strings. Also, I'm a bit fan of JKI State Machine, b/c it is easy to use in some small applications; and it is also string-based.
Right after post was posted, one of my friends pointed out, that the example with converting enums to string is not correct - and really, I realized that it's more proper to convert it via "Format Into String" function, and no property node is needed. So, that point is not valid anymore.
Regading this point from @RavensFan I would not agree:
@RavensFan wrote:
I'm curious about that poster's comment under #2 where they they claim that one particular block diagram was better than the other. He said the one using string commands was simpler than the one with enum commands. Those two block diagrams looked pretty equivalent to me. They had exactly the same number of components.
b/c they don't have the same number of components. In the first case it has 1 cluster with state + data; in the second it has 3 different clusters (different - b/c they are different typedefs, used for different queues). 1 is not equal 3 
In the first case I can reuse one cluster to N queues, in the second - for N queues I need to create N constants/instances of "their" typedef clusters.
Maybe, it was not the best example what I wanted to show; b/c in that particular case of application stopping, more proper to use broadcast messages, thus - User Events, for examples (and such approach is recommended, for example, in this example from Elijah_K). Then there will be one message to stop them all.
But I understand this topic from another point of view, and I realize all benefits of enums also. Just, in that post I expressed my thoughts about this topic, and I'm really very happy that you gave me feedback to it.
Sincerely, kosist90
I think of strings vs. enums another way. Most of us have probably seen these things (or something similar) somewhere before in real life:
Look in one of those in a small office setting, and everything is sorted. But look at one in a public park, and everything is just crammed in everywhere and you may as well not have bothered.
As such, I feel that strings work fine if it's private code created and maintained by one person, but if you have a team of designers or if you're going to be inviting the general public to use your code then enums are the way to go, as it becomes impossible to try to enter a state that doesn't exist.
Kyle97330, thanks for your reply!
One can do mess with whatever he will use - with enums, strings, etc. If one does not structure the code, he will get mess with enums also. I know it, because I was doing it when I just started programming.
Regarding team work on the code - yes, I agree; but for nevetheless: if I'd implement public modules I'd use API for them (so others can't break internals of the module by not proper message sent); but for contribution yes, enums will be more safe then.
Sincerely, kosist90
@Kyle97330 - That's a pretty good analogy, but I feel like it isn't 100% accurate. In code I post publicly, someone else is making a copy, and doing what they want. So it is more like me setting up the bins nice and organized, then someone taking it to their home, and then shoving things in random holes instead of using it properly. I don't really care that they screwed it up, I set soft rules in place, and it is their responsibility to use it, and test it.
Then there is the fact that users aren't really anonymous. I mean in a park I can walk up and put the wrong thing in the wrong bin and no one knows, but if a member of my team edits the code in a poor way, I have the SCC change log. And in that case (as with the bins example) it is probably an issue of educating the user on how to properly use the bin (or how to properly use a state machine). Anonymity and the human behavior is a fascinating subject.
