bjustice

The DMC GUI Suite has buttons that have: 1) "Boolean Button" --> 6 part items 2) "Boolean Light" --> 4 part items I can't seem to figure out how they were able to make this combination, because I can't find any control on the native palette with these item parts. For what it's worth, I'm really hoping to be able to create a custom button that has a circular click-radius, but also allows for me to important custom pictures for all 6 boolean states. Importing custom pictures into a NxG or System button control is easy to get work. What's slightly more difficult is that I'm hoping to be able to use a transparent "Boolean glyph" item part as the thing that dictates the click-bounds. That way the button doesn't appear as a circular image, with a square click bound. I recognize that there are lots of workarounds here, but I'm sorta just hoping that maybe there is some way to create the control with the item parts that I desire. This DMC button is sooooo close to being exactly what I need.

Request: A button that has the "parts": 1) Boolean Button --> round shape with 6 part items 2) Boolean Glyph --> must also have 6 part items For example, the standard LED is close to what I want, but it only has 4 item states, so there is no 5/6th states for hover-over value. Taking this a bit further: The NxG buttons all have 6 item parts. However, the NxG buttons don't have a "Boolean Glyph" item part. So, naturally, I would like to understand: am I able to "import" the "boolean glyph" item part from the LED into a NxG button control? All of the forum posts that I've found thus far only document how to add decorations, or how to modify existing item parts in a control. There is no documentation on how to actually add item parts to a control... which I suspect is sorta getting into a layer of code not exposed to me.

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/

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

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