Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


bjustice last won the day on December 13 2021

bjustice had the most liked content!

About bjustice

  • Birthday 10/31/1990

Profile Information

  • Gender
  • Location
    Van Horn, Texas
  • Interests

LabVIEW Information

  • Version
    LabVIEW 2017
  • Since

Contact Methods

Recent Profile Visitors

2,622 profile views

bjustice's Achievements


Contributor (5/14)

  • Conversation Starter Rare
  • Dedicated Rare
  • First Post Rare
  • Collaborator Rare
  • Reacting Well Rare

Recent Badges



  1. ooooooooooh, ok, I didn't recognize this. Now it makes more sense why NI chose to implement this the way they did.
  2. 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.
  3. 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
  4. BlueSerialization v2.3.3 uploaded to VIPM. I improved the cacheing scheme a bit as well given this new code addition.
  5. Thanks for all the input. I'll go with this solution
  6. 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.
  7. 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
  8. ooo, interesting. One of these isn't available until LabVIEW 2021
  9. 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.
  10. 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
  11. check to make sure that the input terminals are the same setting as well: "required, recommended, optional." This matters
  12. 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
  13. Thanks for the link, I had not found that forum post!
  14. 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.
  15. 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!
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.