LabVIEW
[UI] How to change condition color automatically according to data type ?
Solved!
Hello,
I'd like to know if there is an automated way to change
conditions' color following the linked data type on the
diagram, so that it's a little bit easier to know what kind
to processing is done when you don't have the whole
thing on screen. Currently I'm doing it manually :
David Koch
It would seem easier to make the code more modular and keep it on one screen instead.
If you really want to color the case structure frame according to the datatype wired to the conditional terminal, write it up as a idea in the Idea exchange and see how many votes it collects. 🙂
(What's up with all these value property nodes? Local variable would seem more appropriate if really needed)
Kochise wrote:Idea exchange : would have done that, but since long time requested features are still not yet implemented...
The point is to gauge user interest in the idea. If there is not interest nobody cares if it does not get implemented. Many good ideas from the exchange have been implemented over the last few versions.
@Kochise wrote:
Property nodes : they're like convenient pointers on value to me, avoid duplicating variables all over the place.
So you are duplicating property nodes all over the place to avoid duplicating variables all over the place?? 😮 What is the logic behind that???
Are you talking about local variables? Local variables and value property nodes serve the exact same function (at least in the way you are using them), except that value property nodes are much more computationally expensive. A large number of either typical points to poor code architecture and often causes subtle race conditions and fragile code.
@Kochise wrote:
Modularity : when tabs are added to Labview so that I don't have to open hundreds of sub VIs and stuff my task bar.
What is "stuff"? A well written, reusable subVI needs to be written once and never needs to be opened again. I don't see your point. What does any of this have to do with tabs?
altenbach a écrit :
The point is to gauge user interest in the idea. If there is not interest nobody cares if it does not get implemented. Many good ideas from the exchange have been implemented over the last few versions.
There's already 245 pages of ideas to implement, mine would drown amongst.
altenbach a écrit :
So you are duplicating property nodes all over the place to avoid duplicating variables all over the place?? 😮 What is the logic behind that???
Are you talking about local variables? Local variables and value property nodes serve the exact same function (at least in the way you are using them), except that value property nodes are much more computationally expensive. A large number of either typical points to poor code architecture and often causes subtle race conditions and fragile code.
I like to keep things consistent, programmatically and visually.
And the proprerty node is convenient, you just have to open it, select another property and link it.
If the 'Value' property is the common/default property that is the same as local variable, why is there no internal optimization to speed up things inside Labview ?
altenbach a écrit :
What is "stuff"? A well written, reusable subVI needs to be written once and never needs to be opened again. I don't see your point. What does any of this have to do with tabs?
That depend on the way you see things inside your head, organize your sub VIs, or organize things visually into nested conditions and loops.
Just have a look how things were done by a 'professional' Labview coder that passed certifications, enjoy the ride :
Look at this last example, this is a SQL statement construction !
I don't think I'm a bad guy, my task is to completely re-architecture things to be maintenable.
They had become a real mess scattered all over several VIs, something like 2200, 25 pages once printed.
I really, really, prefer having the various routines into one VI and call them using messages.
David Koch
Hi David,
the last image could be improved by using FormatIntoString instead of that giant ConcatString and by using AutoIndexing in the FOR loop. Using ArraySize to determine loop iteration number is most often RubeGoldberg…
"Value" property nodes serve more than just delivering a value:
- they also (try to) maintain DATAFLOW
- you can use more than just one property in a single property node
- are part of that whole property access stuff, so "optimizing " just that one property would lead to a big mess in the internal compiler stuff…
You are the programmer, you are responsible to create optimized code. Relying on a compiler to super-optimize your badly written code isn't the correct way…
String construction : I know that, but this is legacy undocumented code. Not my creation.
Property node : look why this is so practical :
Compiler : I'm not responsible about how things works inside the compiler.
Where is the info about the difference between 'local variable' and 'property node' ?
I found this :
http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/vi_memory_usage/
But why should I care in the first place ? This programming language is for noobs anyway.
Labview is supposed to be high level, hence abstract that kind of things for me.
Otherwise I would code in pure assembly and manage my cache misses by hand.
Even the way Labview doesn't abstract numeric representation is annoying (the red mark).
David Koch
Hi David,
Property node : look why this is so practical
That's what I wrote: you can chain several properties in one property node.
And I also mentioned: you are responsible for efficient algorithms. Fetching strings/values by switching threads isn't considered "efficient"…
You could replace this whole snippet by a FGV holding the strings/values in a shift register and looking things up using Search1DArray (or Variant attributes). No need to constantly force UI thread calls…
Hi David,
I'm not supposed to know what going on under the hood, the whole "you should optimize your code" stuff shouldn't even exist in the first place.
You can create code in each programming language. You can create bad code, you can create better code - in each language.
Once you want to create "efficient" code you need to know the internals of the compiler (or atleast the most important ones) - in each programming language…
Even when coding in pure Assembler you need to know how to optimize your code!
Is there a profiler I should waste my time on just to tweak things ?
Yes, there is a profiler. You can find it in the tools menu.
The shift register wouldn't do it.
Why not? I use that approach very often…
To answer your thread title:
Write a small VI using LabVIEW scripting to color your case structures as you like to. Maybe you can also use that VI as plugin in QuickDrop!
