ensegre

So far the need occurred to me only in an application whose only undoable part was the assisted filling of a big table. Not being particularly sophisticated, I created a finite depth queue, which stored the last N states of that table. Each value change of that control - enqueue at opposite end a new state. Each call of the user menu 'Undo' - dequeue one value and Property/write Value it back to the table. The table itself was not so big that keeping a few historical copies of it in memory was tallying. As simple as that, but certainly not too representative of an application with a more complex state to be rolled back.

Cross post (OP is wasting readers time) and answered by Rolf:

You can do something along these lines trapping mouse events. The quick example is all but polished, but should give you the general idea. clickbutton.vi

VIPM 2017 on Ubuntu 18. Don't know if related to that CAR, but jibberish chinese anyway + very ugly fonts. Edit: quick search, I found this: https://forums.ni.com/t5/LabVIEW/Why-does-my-LabVIEW-occasionally-display-in-Chinese/m-p/1545242#M571786. Now my VIPM 2017 appears to be based on rte2015, and the closest to what suggested in that post is /usr/local/lib/LabVIEW-2015/English/lvapp.rsc - which in my case is present, no *.tmp in that directory instead.

Ok. For most of the points, I'm feeling a bit dumb now that I searched for it..... https://www.upvi.net/main/index.php/products/lvhdf5/lvhdf5-forum/11-standalone-exe-doesn-t-work#18 Write 100 times: Thou shall not use "Use Default If Unwired" for references Thou shall not use "Use Default If Unwired" for references Thou shall not use "Use Default If Unwired" for references ....... https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019L75SAE My coding mistake, I thought I was calling HF5Close when I wasn't. And closing the containing project was sufficient to remove the lock anyway. Sorry for the noise, I hope it may help someone else in future.

The LV error of point 2. above, BTW. on the second HD5write (create) of the chain, the first succeeds, apparently. Error 402760 occurred at Check Object Existence.vi Possible reason(s): An HDF5 Error Occurred Major: H5E_ARGS (Invalid arguments to routine) Minor: H5E_BADTYPE (Inappropriate type) invalid location identifier Complete Call Chain: Check Object Existence.vi OpenCreateReplace Dataset.vi Simple OpenCreateReplace Dataset (Variant).vi Simple H5Dwrite (Variant).vi

A project benefiting from HD5 data saving came up to me, so I'm looking at your package. For now nothing beyond just dumping some heterogeneous datasets into a single file, but I'm already having a few issues. All together your package looks so well invested into, so I think there is point in reporting them, and ask for assistance. I've been trying 1.1.1.86 (offered by VIPM) and 1.2.2.5 (your link). Single dev machine for now. LV20.01 32bit, Up/Downgrading between the two is not completely flawless, sometimes VIPM fails, but nothing that can't be solved with restarting LV a few times and clearing the compile cache. My issues: I have something working in the IDE, I can build it into an exe, but the exe is broken-arrowed. Pressing the arrow I get a dialog with a long list of "missing external function h5helper.dll". hdf5.dll and hd5helper.dll get copied into the built application data/ directory though. What am I missing? I made a minimal snippet and a more real VI using v1.1.1.86, both work (modulo some lack of understanding on my part about why certain datasets need to be declared as Unlimited etc., but whatever for now). However: the "real" VI (having some event structure, shift registers and a bit of other code) is very sluggish when being edited. I would tend to blame the fact that so many calls (essentially Simple HD5write) are Xnodes. If I upgrade to v1.2.2.5 and open the "real", in the IDE, I get Error 1055 complaining about invalid references. The thing goes on compiling and opens as white-arrowed, but if run, it fails in writing one of the datasets (not the first, by chance). I'm afraid I'd have to unwire and rewire it all again in order to convince shift registers to update stale references or something the like, Xnode weirdnesses.... If I end up with an opened hd5 file (e.g. because my writing chain errored somewhere), it stays locked till I quit LV. It seems that Close HDF5 File (HF5Close.vi) even with Force close=true cannot against it (modulo that I understood something wrong...). I can't either replace the file with LV, or delete it from OS. Open/Create/Replace HDF5 File, with argument "create or replace", when called on an existing filename still offers an "open" button in the dialog, which is wrong logic, imho. That in both package versions, though. Your comments highly appreciated!

I don't know about that tool, but doesn't Task Manager help, instead?

or simply implement your serial queries of both kinds via a single non-reentrant VI, so that only one loop at a time uses the serial resource? (more sophisticated, use a VISA lock)

Ah yes:

check also

Interactively in the IDE, Programmatically, I'd be sure it can be done with VI server invocations, the only difficulty might be in getting the exact ref to each individual clone - but I sort of remember that there is a way which I've used in the past.

There is no such a thing like a property node of an event structure which tells what event has been fired (at least in a simple way that I could know), but it is completely possible for the code inside an event case to fire other event(s), which cause other cases of the same or of another structure to be called. You can use anything which generate events: value (signaling) of any control, dynamic events, etc. Personally I do such things all the time in simple GUIs. However, an event calling another event already smells of "you need rather a state machine" or "you need to think at architecture".

If the only way of commanding your camera is through the vendor sdk, bleh. As Rolf wrote, though YMMV. If by chance the camera is supported by v4l2, there you go; shameless self ad.

I see. Thanks Rolf. In fact I am so used to see Qt used by vanilla OSS, that I overlooked the issue of licensing. All technical potential showstoppers aside, in any case.