bjustice

For what it's worth, I echo Hooovahh's thoughts here

Wow, I didn't realize that Emerson also publicized correspondence with NI over the last year:

https://www.emerson.com/en-us/news/2023/emerson-national-instruments-announcement

It seems like the NI board of directors is not interested, and is getting pushed into their actions by Emerson's increasingly aggressive engagement.

Updating a very old thread:

I bumped into some of the limitations of Tree/Listbox drag/drop as discussed here.

I chose to write a G-code implementation of drag/drop behavior for Tree/Listbox controls with a few notable improvements.

Anyone who finds this thread in the future might want to take a look:

https://www.vipm.io/package/blue_origin_lib_better_drag_and_drop/

24 minutes ago, ShaunR said:

It can. This is how you clear a shortcut if one was set.

ooooooooooh, ok, I didn't recognize this.

Now it makes more sense why NI chose to implement this the way they did.

Yeah, Neil understands me here

A shortcut cannot be a blank string.  So, I would expect a blank string, which is also the default value of the input, to yield a no-op.

I created my own abstraction layer to sit on to of the low level menu API.  My abstraction layer is used by both by my main menu as well as by control references.  So, this behavior forced me to write a comical piece of code where I case structure 2 copies of this NI primitive, where 1 case does not wire up the shortcut input.

Ok, I found something.  And it really feels like this disobeys the Laws of LabVIEW physics.

It would be my expectation as a LabVIEW developer that both the top and bottom code should execute exactly the same.  (The constant short-cut cluster wired into the "Set Menu Item Info" function is the default value of the cluster, created by right-click + create constant from the terminal of the VI.)  I would expect the default/blank value to yield a no-op.

However, if you run the attached VI, you will find that the top screenshot produces an error.  The bottom does not.

button right click menus are not allowed to have shortcuts.  And that's fine.  But I can't figure out how to wire a cluster to this NI primitive in a way that let's me communicate a desired no-op behavior.

I'm scratching my head trying to determine how this even works.  Does this mean that the NI primitive is able to have code that discerns and reacts to whether or not an input terminal is wired?  It seems like that breaks LabVIEW paradigm.

Ok, that's all.  Saw something weird and wanted to share.

Menu example.vi

BlueSerialization v2.3.3 uploaded to VIPM.

I improved the cacheing scheme a bit as well given this new code addition.

Thanks for all the input.  I'll go with this solution

BlueSerialization is currently LabVIEW 2020.

hmm... okay.  How bulletproof do you think your VI might be?  Would LabVIEW ever be "smart" enough to not load a classes' *.ctl file into memory if it was blank or something like that?  Or perhaps drop it from a build if it were blank?

If you think this is pretty bulletproof, I'll just use this and push a patch to the BlueSerialization library.

I am already cacheing the results, so speed is probably not a huge issue.

yeah, it looks like the latter VI is doing exactly that.  Opening the library reference, and then using that invoke node.

I suspect that this is slower than your solution, but probably a bit more bulletproof

ooo, interesting.

One of these isn't available until LabVIEW 2021

LogMAN,

thanks for the input.  This certainly works in a pinch.

I was really hoping that there might be something a bit more native.  This also doesn't seem like it would be super fast to me.

I ran into a situation where I need to return the class hierarchy of an object as a concrete object array.  (If you are curious, this is used in the BlueSerialization toolkit)

The following code snippet demonstrates how I accomplished this.
Unfortunately, I just discovered that this algorithm doesn't work if a class also inherits from an interface class.  (My algorithm here assumes that a class can only inherit from 1 other class.)

Naturally, my immediate question is this:

Is there a graceful NI primitive or mechanism for determining if a given object is an interface class or a concrete class?

If yes, then I could just filter out interface classes in my code here and move on with life.

I did find the "Get LabVIEW Class Parent and Member VI information VI.  But, I can't get this VI to work recursively.  On the 2nd loop iteration, this NI primitive returns that results for a base LabVIEW object even though the wire probe shows this as not being a base LabVIEW object.

Get Class Hierarchy.vi

check to make sure that the input terminals are the same setting as well:

"required, recommended, optional."

This matters

2 hours ago, drjdpowell said:

Does a Property Node, with multiple Properties set, execute as a single action, without a parallel Property Node executing in the middle?   If so, then resetting the Active Plot in the second Property Node in the bottom loop would prevent any race condition.

I would really like to know the answer to this question.  I would expect the answer to be "yes" since property nodes all run in the UI thread

Thanks for the link, I had not found that forum post!

Another network question:

Do I have to implement reconnect logic when using UDP?

More pointedly:

If I successfully open a UDP port, then will this UDP connection ID ever become invalid or closed somehow in a way that would force me to close it and then reopen it to reestablish communications?

Example: TCP requires proper handling of reconnect logic.  When the client or server closes the TCP connection, then the connection is closed on both ends.

Question: is it possible to determine the local address and local port selected when using "TCP Open Connection" to connect to a TCP listener?

It seems weird to me that the "TCP Wait on Listener" resolves and returns this information, but the TCP Client does not have a way to determine this information.  Maybe I'm missing something.

To be clear, I'm specifically considering a situation where my computer has multiple NICs.  And I'd like to know which NIC is being used.

I found a relevant idea exchange thread on asking to allow for LabVIEW to specify which NIC to use.  https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-user-to-select-the-which-NIC-to-use-for-network/idi-p/1497368#comments

Thanks!

I found this DMC slide.  I wasn't quite sure when to use Floating vs Modal, and this helped me a bunch.

In my situation right now, I like and am going to use Hoovahh's code to set to modal through VI server.  Graceful.  I really do appreciate this code that you shared.

https://www.ieee.li/pdf/viewgraphs/user_interfaces_in_labview.pdf

Thanks Hooovahh, I love this.

When do you typically use "Floating" vs "Modal"?

How much to bribe you for sharing this code?

Very pretty, and cool to see good usage of the channel wire

This is cool.  I hadn't considered moveblock.  Thanks for sharing

Hooovahh in the hole!

Really?  You're suggesting that there's potentially a faster way to convert a u8 byte array to an array of DBLs?  I hadn't considered that.  I really thought that TypeCast would have been the fastest option.  But, I also didn't realize that type cast used the string unflatten code under the hood until AQ communicated this.