BreakPoint

cancel
Showing results for 
Search instead for 
Did you mean: 

Rube Goldberg Code


@johntrich1971 wrote:

@rolfk wrote:

@altenbach wrote:

 

(On a side note, I recommend to not comment in that thread. Seriously)


Jenny luckily took care of that. It’s a typical case of wanting to show they know better and challenging everybody having any critique. I pity his students if he really is teaching. 


Wow, that thread got really out of hand. And the guy actually believes that his approach is better. 


So, why didn't someone give the answer? 🙄

 

The ordering is (obviously) not always good nor bad. And most certainty not random...

 

The locals are created in revered Z order. That is, the front to back order of the controls on the panel.

0 Kudos
Message 2521 of 2,565
(1,256 Views)

wiebe@CARYA wrote:


So, why didn't someone give the answer? 🙄

 

The ordering is (obviously) not always good nor bad. And most certainty not random...

 

The locals are created in revered Z order. That is, the front to back order of the controls on the panel.


You probably don't know, but there was an even longer thread before with the identical questions that got deleted for very obvious reasons. I was actually the first to answer and said that the locals are not created in random order as claimed, but typically in reverse order. So the answer was given right then and there!

 

Obviously, the ordering is controlled by proprietary NI code that is not open source, and all we can really do is figure things by experimenting. We don't have control over it, but the OP wanted a way to control the ordering, basically have LabVIEW create 100s of locals at once in a 2D arrangement exactly as they (and only they!) wanted (not alphabetical, not z-order, not sorted by x coordinate, not in order of creation, etc.). 

 

So why reverse z order instead of plain z order, which would have been more intuitive? Only the original programmer from 30 years ago knows, but I am sure some thought went into it. 😄

0 Kudos
Message 2522 of 2,565
(1,224 Views)

@altenbach wrote:

So why reverse z order instead of plain z order, which would have been more intuitive? Only the original programmer from 30 years ago knows, but I am sure some thought went into it. 😄


Seems more intuitive to me with reverse order 😀 The same way you look at a deck of card: from the top!

0 Kudos
Message 2523 of 2,565
(1,177 Views)

@altenbach wrote:

wiebe@CARYA wrote:


So, why didn't someone give the answer? 🙄

 

The ordering is (obviously) not always good nor bad. And most certainty not random...

 

The locals are created in revered Z order. That is, the front to back order of the controls on the panel.


You probably don't know, but there was an even longer thread before with the identical questions that got deleted for very obvious reasons. I was actually the first to answer and said that the locals are not created in random order as claimed, but typically in reverse order. So the answer was given right then and there!


OK, thanks for clearing that up. Reading that thread I didn't really understood all the fuss, because everything seems quite polite.

 

To bad the answer was removed...

 


@altenbach wrote:Obviously, the ordering is controlled by proprietary NI code that is not open source, and all we can really do is figure things by experimenting. We don't have control over it, but the OP wanted a way to control the ordering, basically have LabVIEW create 100s of locals at once in a 2D arrangement exactly as they (and only they!) wanted (not alphabetical, not z-order, not sorted by x coordinate, not in order of creation, etc.). 

But you do have control over the Z-ordering, so you can control the ordering of the created locals by altering the Z-Ordering.

 

Of course if you really want to create a 2D array with individual controls* you can end up with the correct Z-Ordering if you copy in a logical way.

 

* There are use cases for it, like being able to change properties of the controls, or mixing controls and indicators, or mixing different controls.

0 Kudos
Message 2524 of 2,565
(1,165 Views)

@VinnyAstro wrote:

@altenbach wrote:

So why reverse z order instead of plain z order, which would have been more intuitive? Only the original programmer from 30 years ago knows, but I am sure some thought went into it. 😄


Seems more intuitive to me with reverse order 😀 The same way you look at a deck of card: from the top!


I suppose it's circumstantial.

 

Top most on top makes sense.

 

But if you start at the top and add controls downwards, it would make more sense if the locals have the same order.

0 Kudos
Message 2525 of 2,565
(1,162 Views)

For me, most intuitive would have been to get the xy coordinates of all selected terminals, then create a floating "herd" of locals in exactly the same relative xy arrangement to be placed with the cursor. If the terminals were far apart, the distances could be compacted while keeping the same x and y order.

 

Z order should be ignored.

 

 

Message 2526 of 2,565
(1,187 Views)

@altenbach wrote:

For me, most intuitive would have been to get the xy coordinates of all selected terminals, then create a floating "herd" of locals in exactly the same relative xy arrangement to be placed with the cursor. If the terminals were far apart, the distances could be compacted while keeping the same x and y order.


Agreed, although for large GUIs, like PnIDs this might not be convenient.

 


@altenbach wrote:

Z order should be ignored.


The FP Z-order could be copied to the diagram Z-order, which is (rightfully) mostly ignored...
 

0 Kudos
Message 2527 of 2,565
(1,177 Views)

Another beautiful Aztec pyramid made by… NI !

Seen in "Get GObject Label.vi" from the scripting palette:

 

raphschru_0-1686442196743.png

 

This one is more of a "I wish it were Rube Goldberg code, but actually it's not" (or is it ??). Indeed there is no easy way of trying multiple castings sequentially unless this idea is implemented.

 

My own attempt to "de-Rube" it:

raphschru_1-1686446731114.png

 

Message 2528 of 2,565
(866 Views)

I have resorted to your approach in the past but there is also an alternative. Using the LV Type library (not sure about the exact name) it is possible to determine the class of a LabVIEW object and then use a case structure. It’s similar to the Class Name property idea mentioned in that Idea, but somehow I always wondered if that would not be localized! Probably some knee jerk reaction from having to deal with Microsoft Office object hierarchies in the past. 😀

Rolf Kalbermatter
My Blog
0 Kudos
Message 2529 of 2,565
(854 Views)

@rolfk wrote:

Using the LV Type library (not sure about the exact name) it is possible to determine the class of a LabVIEW object and then use a case structure.


I guess you're talking about "Get Refnum Information.vi" from the Data Type Parsing Palette.

This is impractical because:

 - it does not really support scripting classes, as they all return the same enum value "kLVObjLVClassBDConst".

 - it only gives the type of the wire that was passed to the function, not the actual runtime class.

 - same problem as the "ClassName" property: what if you want to cast from Generic to an intermediate class like "Control". You would have to check the class hierarchy to see if it has "Control" in it.

0 Kudos
Message 2530 of 2,565
(821 Views)