drjdpowell

True, but how do I identify real dependancies from all the fake ones? LLBs don’t seem to be equivalent (though I never really used them). No namespacing, no Private scope.

I’ve used a single 2D picture control for similar work (no drag’n'drop, but I have full mouse-click logic including insert, delete, cut and paste, as well as “settings†and “disable†buttons built into the picture). It’s not that hard once you have made a “what is the mouse over†subVI that accepts mouse coordinates (you’ll need a cluster/class to hold the known coordinates of your icons). I would suspect that the VI server route would be harder.

Something I did not appreciate till today: If I have an LVLIB library in which I use one of its VIs, then any LVCLASS class referred to by ANY of the LVLIB’s members will be loaded into memory (along with all their dependancies). In addition, the fact that all library members show up under “dependanciesâ€, even if only a few are actual used, makes it difficult to get useful information about real dependancies. So, should I ditch the use of LVLIBs altogether as a hopelessly-flawed tool? — James Added later: Must be getting old, as I forgot that I already knew this. But the question remains of what to do about it.

I’ve modified the code to only escape ‘/' if it follows ‘<‘ (so ‘</‘ becomes ‘<\/‘), as it’s use in HTML <script>..</script> seems to be the reason that escaping of ‘/‘ is allowed in JSON.

I had never noticed that JSON allows, but does not require, / to be escaped as \/. Googling suggests this is due to some use of JSON embedded in other formats such as HTML that do use / as a control character. I believe our library as it stands should accept both versions. But what should it do on output?

The latest JSON package, where I have fixes some issues with corner cases, mostly by changing the string escaping (failed on strings like “C:\\“). Also extended escaping to the name strings of JSON Objects (which we had neglected to do). I will make this the latest CR version in a week or so if there is no objection. lava_lib_json_api-1.3.1.25.vip

I would say putting common logic in the parent is desirable behavior. And I don’t mind if some children will want to override the default parent behavior. For example, I have a project at the moment that uses cameras and “lockinâ€, the extraction of a periodic signal in the image. Most concrete camera types just override the "Get Image" method, and the parent’s "Get Lockin Image†method uses "Get Imageâ€. But one camera model has a built-in lockin mode, so I override “Get Lockin Image†in that case.

It’s worth breaking through whatever conceptual block you have, because the code you have shown is considerably more complicated (and will require a higher level of competence to execute correctly) than the OOP solutions shoneil and I are talking about. And there are no advantages I can see to the way you are doing things.

You can still push the details into the subClass. Your generic code only needs a "Show Configuration UI in subpanel" method and a "Poll Configuration UI" method. You'll be able to write vastly simpler code in the subClass itself (no Variants, no Open VI ref, no Property nodes).

All Devices can implement “Show Device Configuration UIâ€, so you do not have any problem. Your mixing two incompatible statements: you’re code is generic enough to switch types, but specific enough that it must use one specific type. If you organize your code in levels, generic and specific**, then each level will be a lot cleaner. **Note that you can have intermediate levels, such as a generic “power supplyâ€. Code can know that it is using power supplies (rather than generic devices) but not depend on the type of supply used.

I think your conceptual problem is here. Your high-level, handles-array-of-generic-devices, code shouldn’t want to know anything about specific device properties. One of the biggest advantages of OOP is the ability to have generic code that doesn’t need to be complicated by a 1001 specific details. Anything specific needs to be pushed down a level to the specific child classes. The high-level code may have dynamically dispatched methods such as “Get Device configuration as Stringâ€, “Set Device configuration as Stringâ€, “Get Human-readable Device Statusâ€, “Show Device Configuration UIâ€, and so on. It should never have anything as specific as “Set Rate Formulaâ€. Now if you do need to write specific code that “knows†what the devices specifically are, then use a cluster, not an array (note that you can use a cluster of arrays of specific types if you have a variable number of each device type).

Ignore it; it's not relevant to your OP.

My actors are already services. They’re private, rather than public, services, so access to them needs to be explicitly passed. Rather like an unnamed Queue is different from a named Queue. If I were to adopt the AF, such a “Notification†and “Routing†system using “Data Messages†would be the first thing I would do. Mouth would register for (and re-notify) Tongue’s Data Message. Brain would register Chew to receive Mouth’s re-notified Data Message (originally from Tongue), contained in a “Command Envelope†that tells Chew what to do with the info (Command Envelopes illustrated here).

I wondered if anyone, who has used this package in real-world applications, would kindly review it on the Tools Network.

A previous related conversation:"Decoupling message based systems that communicate across a network" Added later: I'm a strong proponent of message decoupling, even with the string-labelled messages I use instead of the Command pattern. I never want a component to explicitly contain text commands for anything that isn't a subcomponent of it. Instead, and command text is injected as part of the "reply address" attached as part of the initial message received from higher-level code. This has the great advantage of making it easier to follow code, since I don't need to place any actual commands in the low-level actors, and just need to study the high-level actors to understand the app. The low-level actors are also more simple and reusable.

User Events aren’t front panel events, and should never lock any front panels.

No. There’s a “Lock Panel until handler completes†shortcut menu item on the Register for Events node.

If one uses a named single-element queue, instead of a DVR, then one can get the lifetime of the queue to exceed that of its initial creator. This is because one can create multiple references to it; the queue continues to exist till all references to it are released.

If one needs a persistent reference, not tied to the lifetime of one VI hierarchy, then one can either: 1) Async Call a VI to create and own the reference as brink is doing. or 2) Use a Named Single-Element Queue with multiple references instead of a DVR to hold the session data. -- James BTW: If I were designing a persistent session framework I would probably combine both, in order to get around their individual weaknesses: (1) can't handle VIs that forget to call the Close Session method, in violation of LabVIEW's standard "refs don't outlive their creator" rule. (2) can't execute cleanup code, as the data in the SEQ is just dropped.

There is a related thread on the Actor Framework board (reply #15 and after) where I think the DVR goes invalid.

I suspect simply writing to an IMAQ image indicator inside the producer (and get rid of the consumer entirely) will be less overhead than your complex structure.

You’ll need to mark your Image Indicator as “Synchronous Display†if you want it to display before the Producer overwrites the buffer. Indicators are asynchronous by default and update at something like 60Hz, slower than your 400 frames/second. BTW, I can’t see how this code would interface with some other process doing the main application work on all 400 frames. What do you do with the full 400 frames?

I don’t have enough of a feel for your application to give specific advice, but are you sure it wouldn’t be simpler to attend to the main processing of your 400 images per second in a simple clean way, then just make a copy for display 20-30 times per second for the separate display part, rather than invent a complex locking system to avoid those 20-30 copies? You might be able to do the display with a single IMAQ reference, making it very simple.

I wish they would extend this to User Events. Last-only User Events could be very useful.

Again, check that your frame grabber isn’t already buffering, with a “Get latest frame†method. That is what I would expect it to do. And this would greatly simplify your program as you’ll only need one loop. However, you can get “lossy behavior†by getting the Consumer to flush the queue and only process the last element, passing any other IMAQ refs returned back to the C—>P queue. You might need more than 3 refs if your Consumer is very slow.