Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 03/12/2024 in Posts

  1. I would actually suggest to implement it properly by extending the File Dialog Node. A double NULL terminated string array that is simply passed to a Windows API function is hardly a safe and proper LabVIEW datatype! 😁 And of course you saw it already coming, add support for that on Linux too 😁
    1 point
  2. The multiple patterns nugget was broken in LabVIEW 2023 Q1, but it works in LabVIEW 2023 Q3 and later.
    1 point
  3. I use User Events as the transport mechanism between asynchronous processes. As a result I wish there were a feature where there was an event generated when a reference goes invalid. I made an Idea on the Idea Exchange here. Similarly the work around is to have a timeout where the reference is checked to be invalid. A better solution is to send a stop command as some kind of global user event, or in your case enqueue. But as you've seen there can be edge cases where things stop unexpectedly and I just want all the running children to go through their cleanup process. Stopping on the error, or invalid user event reference, is a fairly simple way to do that.
    1 point
  4. The variant attribute cannot have duplicates. If you set it, it overwrites the previous values. With the "array with tag" you can have duplicates.
    1 point
  5. For your own long-term sanity, I do not recommend replacing any existing wires you have with a variant+attributes. Maybe I am misunderstanding your use case though...
    1 point
  6. Skimming thru this thread... try this: From C, call `PostLVUserEvent()`. Then, in LabVIEW, rather than registering that event reference into a `Register for Events` node, register the event reference with a `Register Event Callback` node. Here's the game-changer -- `PostLVUserEvent()` in C will behave differently depending on how the associated event reference is registered in LabVIEW. When a listener is bound to the event using `Register for Events`, `PostLVUserEvent()` is asynchronous and non-blocking, and does not wait for the consumption of the event. It "blocks" only long enough to copy data reliably into the queue shared by its message-reference-counting registrants, then moves along. On the other hand, `PostLVUserEvent()` will synchronously block until the Callback VI handler has finished executing. This means, your library can `Post` some pointers/handles into LabVIEW, LabVIEW can fill them in the Callback VI, and downstream logic from the `PostLVUserEvent()` needs no further gymnastics to synchronize/mutex.
    1 point
×
×
  • Create New...

Important Information

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