Zyga

Looks very nice, but I doubt anyone here would risk to use it if it's not open source. Nice idea to make such a project, but my opinion is it would had to be community powered to get to broader audience.

Good to know, I have that license and even this is not a solution for me due to platforms limitation, I will surely check how it works. Cheers!

Thank you for your thoughts. DSC solution seems to be easiest, still own implementation like ShaunR might be needed as I met requirement to prevent some users from using keyboard on a few controls. So this approach might be extended not only to visibility but also other properties.

That not what I have in my mind. I explain myself wrongly. By UAC I meant user access control inside application, not UAC as a Windows functionality. Access controls like Basic User, Maintenance, Super User so on.

Hello, I am just wondering - without any particular need - do you have strategies to implement UAC in your application? Any generic solution that are not tightly coupled with the architecture of the software? So far my cleanest solution is to check elevation before loading module UI, but even though the implementation is fairly simple it has limitations. Do you have your own libraries that are applicable to different applications with different complexity or is this something which is tailored depending on client needs. Zyga

Just got an answer from NI and they says that nothing is changing for partners license. Neither price and neither coverage.

Does anyone know for how long perpetual license will be available? Could not find any information. In the FAQ there is nothing mentioned abut partner licenses in which we have for example a VDM which is not covered by any of a subscription plans. Does anyone knows what happens with partner licenses?

2020 works for me. It was not populated under the list of available installations, but works after manual addition.

Try: apt install xfonts-75dpi xfonts-100dpi Then reboot.

We did such a thing for dalsa camera. It indeed require to write wrapping functions, but there is a help which describes how IMAQ image is stored in the memory so you should be able to cast vendor image format to LV IMAQ. If you do not need any suphisticated camera and acquisition control this library is pretty basic and I have used it with success. I might be missing something but I do not think that OpenCV has a good cam acquisition support.

Hello, On a debug purposes I would like to open reference to a privately scoped vi from outside class (or from parent class vi). But while I am trying to do this I am getting error 1390. Which makes all sense. But is there any way to walk-around this? Without ofcoure adding code to the class. I see that Caraya developers has encountered similar issue and did not resolve it. Anyone who has an idea? Thanks for your help.

Thank you for your answers and sorry for not being here for a while. Based on information from you, I have achived what I needed, but there are still things that are mistery for me. That was my thinking before I wrote this post. But it somehow did not fit to what was happening in my project. I was loading a class, changing its VI properties and then call this VI using dynamic dispach mechanism. It wasn't modified as I expected. So I suspected that LV preallocate clones for dd VIs while loading class (and I wrongly assumed that those are VI with "instance" suffix). And this would fit to what was said after: So I have created this example: And this is what happens when I call this VI first time I open the project: What supprised me most is that even though LV has allocated single clone for dd vi right after class loading, changes made on reference to its prototype applies to the clone as well (which, for some reason, is not the case in my project..). And changes applies to clones that are created afterwards which is expected. Exactly the same behaviour can be seen in executable built based on this example. Second run after project loading, has both clones in the memory from the beginning. Now operating on the reference has no effect on both clones.

I wonder if someone has found a way to retrieve reference to a vi that is overriding method and has reentrancy set to shared clone. What exactly I am trying to do is to change properties of this VI controls by using externally opened reference. Actually I would like to localize FP at application loadtime (without placing code on "to be localized" VI blockdiagram). When I list all VIs in memory I get stuff like this: sDataAcquisition.lvclass:editWindow.vi:Instance:6cc60448-8771-4aea-ad60-5635b7cb9c6a.vi sDataAcquisition.lvclass:editWindow.vi:Instance:b60c6bed-8161-4566-ab34-ae4092625b90.vi sDataAcquisition.lvclass:editWindow.vi sDataAcquisition.lvclass:editWindow.vi is a method that overrides one from parental class. sDataAcquisition.lvclass:editWindow.vi has not yest been called when above list has been populated, just owning class loaded into memory. Can someone explain what Instance:xxx-xxx.vi suffix mean? Can I be sure that if I find all of instances there will be no more alocated at app runtime? I also can find stuff like that, which has longer suffixes tree: loadDrivers.lvclass:execute.vi:Instance:ed894b20-902d-486d-ae3e-062689901cdc.vi:Instance:c1440502-af17-4937-acbe-a4f891f270d2.vi loadDrivers.lvclass:execute.vi:Instance:ed894b20-902d-486d-ae3e-062689901cdc.vi loadDrivers.lvclass:execute.vi I assume that this is correlated to ancestry hierarchy somehow, but is there any documentation how/when this clones are created? Getting back to my original goal. I would like to change properties of e.g. sDataAcquisition.lvclass:editWindow.vi and all its clones.

I do not believe this is a disadvantage. Serialization is special... if the parent is not serializable then the child is not serializable. Requiring inheritance from a base Serializable does not seem to me to be a bad requirement. Even in other languages where serialization is an interface, mostly they have to add special syntax checking to make sure that the interface is implemented by the eldest class or else it doesn't work. Serialization isn't functionality that can be injected on a descendant level. It's all or nothing to be meaningful because failure to preserve parent state means you aren't actually saving the state of the object. Thus the requirement to inherit from specific base seems absolutely reasonable to me... indeed, it is an advantage because it syntactically assures that the ancestors are included. Now when I am thinking of it, it sounds obvious. I am possessed by flatten to/unflatten from xml ease of use.. Flattening the names of the complete ancestry into every flattened string would be an incredible bloat of the flattened size of data. Once again, now mentioned it is perfectly plain. For me it is hard to imagine using more than 3-4 inheritance levels, but looking on e.g. VI Server I see it is reasonable to have more than that.

From what I see they are not. Correct me if I am wrong, but this lib enforce "serialize" method to be overwritten and then calls it through whole hierarchy. Disadvantage of that solution is a need to change inheritance. Ok, but enough of moaning. We will use one of existing solution. Just wanted to point out where retrieving ancestry list would be useful (wonder why this information is not in the class flattened string?).