Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/08/2023 in all areas

  1. Pretty much anything is possible. Some tasks may require some know-how, most a lot of trial and error. If you haven't checked it out, you may want to look into the Vision Development Toolkit (and its associated Vision Assistant), as it has a bunch (lots) of functions to process and analyze images. But again, you will have to do your own research and experimenting. Wait a few years and you might be able to ask this to L"AI"BVIEW and it will be done automagically.
    2 points
  2. I don't post on the dark-side but I thought Darren's Occasional Nugget 08/07/2023 was a nugget well worth commenting on over here. I have used this behaviour for a very, very long time. Every time I use it, I always have to convince myself that NI will not "fix the bug" like they did with events and tunnels. I always thought it was an anomaly when compared to the other API's-but a very welcome one which, as Darren rightly says, "this behavior makes event programming more straightforward than other APIs". Darren's example may seem a bit contrived and convoluted so I would like to add a real-world, concrete, practical example which would not work correctly without this behaviour. The example (which is one of many that use this behaviour) relies on the "On Status" event being fired after the the event reference is destroyed in the "Close" function. Actually it is fired twice. Once for "Closing" and once for "Closed". If the event on the structure's queue was not retained and actioned after destruction, then the "Closing" and "Closed" events may never reach the loop - it may not terminate. There would be a high probability that a "Closed" status may not be received and it would be a race between the event structure executing and the "Close". A specific "shutdown" event would have to be added and managed - greatly increasing the diagram complexity. (this one reason why "Tunnels" and "Actor Framework" are so complex). But it gets better. Regardless of the Destroy primitives, all data and status' from the "Get" function, in the executed order, are also maintained independent of the speed of execution of the event structure. This means that when in debugging mode we can see all the events' data and execution even after the Destroy function has been executed in the "Close". As Darren has pointed out, a queue reference would not behave in this way and report "Refnum No Longer Valid" making debugging a much more difficult task.
    1 point
×
×
  • Create New...

Important Information

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