Rolf Kalbermatter

In terms of CPU there is definitely less resource consumption by an invisible control, quite independent on how it was made invisible (made invisible, on an invisible tab, window minimized or hidden). In terms of memory resources there is not really any difference, the control still is there and needs to manage its state and data. This also means that it is not 100% idle. If you change properties, or the value in any way, it will take some processing power to update the internal state of the control even if it is invisible. However this is typically significantly less of an effort than even just updating a single numeric control on a front panel. YMMV of course, updating a graph with a multi mega samples array will take some time as the data may have to be copied into a new data buffer, but the drawing of invisible controls is postponed until they get visible again (if LabVIEW knows that the control is invisible, that might be different for a control that is on a technically visible panel but outside of the bounds of your screen).

In addition to all the above remarks, your found issue may be anyhow a red herring. The NI INI File VIs read the INI file in the Open Config Data.vi and store its contents internally in a memory list. It is only written back in Close Config Data.vi if the write file if changed (T) boolean is set/left on true AND the ini settings changed in any way by calling actually one of the Write Key.vi methods or the Remove Key.vi or Remove Section.vi. So collision of read and write to that file only can happen if an open and close can compete simultaneously for control of that file. The error you see in your simple example is expected behaviour by the way. LabVIEW allows to control the access right and the deny right when opening a file through an explicit File Open node. Your implicit use of the File Open by wiring directly a path to the File Read and File Write opens the file for each operation and for the Write with the deny read and write access. The implicit File Open in the File Read will then bail out with an error as it can't open the file again if the Write managed to grab the file first. In the other case the implicit File Open in the File Write will bail out with an error since it tries to open the file with write access but the File Open in the File Read has opened the file with the deny write specification to prevent inconsistent data during read operations. Accessing any global resources concurrently requires careful planning and considerations. You either have to allow concurrent access and risk inconsistent data when reading and writing at the same time or you have to handle the sequential access to the file in some way so the read and write won't happen simultanously (and then you could play with the deny and access modes for each to allow the read to open the file anyhow eventhough the write has it open too).

We used to have a Toolkit that would allow a LabVIEW application to properly interact with the Service manager so it could itself behave like a real service. It consisted of a DLL part that does the real work of interfacing to the Service Control interface in ADVAPI32.DLL. This also involves callbacks so a DLL is really unavoidable here. I'll have to check about the status of this toolkit and if we can make it available to external parties. From what I remember it was a substantial development effort.

As far as I know, the ActiveX server interface in LabVIEW dates back to LabVIEW 6.0 or something and that is in fact before such features were available through VI server. It seems there was very little changed on the ActiceX server interface since, while the entire VI server itself received a huge workout with many new features including the whole scripting API. The most simple solution might be to create a VI library that provides the necessary functionality through use of VI server and build a DLL from it.

PNGs definitely can contain zero bytes in their datastream. It's a fully binary format.

That's a very old recommendation back in the days when NI added source code control integration to LabVIEW (version 6 or 7 or something like that). They used the Microsoft source control API for that which was only really supported for the now defunct Microsoft Source Safe offering. Some companies developed additional plugins for that API that interfaced to other source control solutions but the Source Safe API used the old checkin/checkout methodology like what CVS had been using and didn't support any of the other methods like what SVN, Hg and Git nowadays support. As such the Source Safe API was severally limited and never really could catch on, probably also helped by the fact that Source Safe was a notoriously bad source control system, that could actually corrupt your source code randomly if you were unlucky. NI later improved the source control interface in such a way that you could install LabVIEW based source control provider plugins, so if you want to use SVN and have it integrated in LabVIEW directly you should probably install the Viewpoint SVN plugin instead. The only problem with LabVIEW based project plugins is however that they can affect the performance of LabVIEW IDE operations. There have been reports that installing any of the LabVIEW SVN plugins start to severely impact edit time performance if a LabVIEW project file reaches a certain number of VIs. But PushOK SVN is certainly the worse solution for use with LabVIEW. That all said we use SVN for our development, but we usually don't install any source code control plugin in LabVIEW. Most simply use the Tortoise SVN Windows shell integration. You have to be careful when moving, renaming, or deleting files as you have to make sure to first do those changes in Tortoise SVN and then change the project to reflect the new situation but it works pretty well if you keep yourself disciplined.

I second what drjdpowell says. This never happened AFAIK. What you describe about reinitialize to default can happen when you use VI server to load a VI into memory and then call it, both with Run VI, or Call By Reference (asynchronous). When loading the VI with Open VI reference it will be loaded into memory and then all the controls will indeed be initialized to their stored default value. Another thing you may be confusing is that controls wired to the connector pane will always use either the value wired to that connector pane or the configured default value. But that has been like that since the beginnings of LabVIEW and still is. Controls that are not connected to the connector pane however will simply retain their last value for as long as the VI stays in memory and that has been like that since the beginnings of LabVIEW too. And the use of local variables instead of shift registers/feedback nodes is discouraged because of performance reasons!

I personally created a Veracrypt partion as a file in my personal folder and install it on boot up as drive P:\ for projects. All my development work is on there, which has the extra benefit that it is password encrypted and can't be accessed by unauthorized people if the computer ever gets stolen. (This is a company requirement that all project work needs to be in some encrypted form that can only be accessed with the correct credentials).

A yes! I remember that. The Picture control does maintain a background pixmap that is redrawn on front panel refreshes and pixmap extractions. And it is in fact independent of the size of the actual Picture Control although I think that for refreshes of the image it will clip the drawing operations to the visible area. But did you notice the rect input to the Picture to Pixmap.vi function? With that you can define a clipping rectangle to which the returned image will be restrained! From the help to that function: rect is a cluster that contains coordinates that describe the bounding rectangle of the image you want to convert. The default is to return the entire image. Horizontal coordinates increase to the right, and vertical coordinates increase to the bottom.

The post install action is run in the context of the installer so it should have the same elevated rights. That SHOULD be enough, but I'm sure there is a possible scenario with custom policies and such from a heavily guarded IT departement that could allow users to install applications but not change firewall rules. Most likely not intentionally but still!

I"m not quite sure if you mean to advocate a class hierarchy for an "has" relation. Part of the sentence sounds like it, then again the other part seems to indicate you mean not. One of the first principles in OOP anyone needs to understand is that two objects can either have an "is" relationship or a "has" relationship. For an "is" relationship inheritance is usually the right implementation, for "has" you should make the "owned" object a value/property of the owner, which could be by composition.

I believe you should read the Drawable property and downcast it to the SceneMesh class. At least that is the class hierarchy, but I'm not sure if the Drawable is really a multiple inheritance object interface that simply implements all the SceneBox, SceneMesh and so on interfaces or if there are different drawable types that a scene object can have. If it is the second, I think the LabVIEW interface simply doesn't provide a way to do what you want.

I never worked with that Toolkit but if it is even possible to use the PDA Toolkit for development of Windows Embedded Compact 7.0 targets (there might be some serious trouble since Windows CE 5.0 is really a quite different platform than Windows Embedded Compact 7.0, almost as different than Android and iOS in comparison. Windows CE 5.0 was mainly for MIPS based platforms which was what Microsoft thought would be the future for embedded, although it also supported x86 and ARM platforms, but I'm not sure if the PDA Toolkit comes with support for all these platforms). But, I have a feeling that if it is possible, there are some object libraries that need to be linked with the compiled object files that were created by the PDA Toolkit. These object libraries provide all the LabVIEW manager functions in one way or the other. So it might be enough to simple create a C file that calls these functions and add it to the list of files to compile and link to create the final executable. The PDA Toolkit works AFAIK such that LabVIEW basically creates C++ files from the VI files, that then get compiled and linked with Toolkit provided support libraries to the final executable with the help of the Microsoft CE development system and compiler. So those functions must somehow call the manager functions too to manipulate the used memory blocks. I remember that it was kind of tricky to get at the according C++ files as the build process creates them only temporarily and then deletes them immediately after the C compiler compiled them into the object files. But I remember that when I played around with one of the Toolkits back in the very old days, I actually managed to get at those files somehow.

Haven't forgotten this but there needs to be some more work done as I also updated the whole source code of the shared library in the past and I need to do some more tests. But for now I'm taking off for some well deserved vacation.

That won't work for sure!! This strange offset of 2 you added inside the loop would indicate that the according C code was not compiled with standard padding. A completely valid possibility although pretty unusual for DLLs that were not specifically compiled for LabVIEW. Instead you should most likely have changed the constant in front of the loop with the value 4 to 2 to get this properly working!

The (none) in parenthesis means simply that if you leave this input unconnected, that there will be no password applied. Theoretically you could also apply an empty password, which would result in an encrypted file but with a very week password key. In the OpenG library there is no difference in wiring nothing to the input and wiring an empty string to it. LabVIEW doesn't give the ability to distinguish between the two for subVIs with the normally available possibilities. Still I feel it is useful to indicate in the control label what the default value of a control does mean, especially since there is this possible ambiguity between using an empty password or none. Simply wire your password to that input and then the specific file should be encrypted with this password and stored in the archive. Theoretically you can even use different passwords for each file but that will be problematic with most other ZIP archive viewers as they typically don't allow to enter different passwords for different files inside an archive. Testing this would have cost you not more time than writing your post here. Simply connect a password to that input string and then try to open the ZIP file in some other ZIP utility (Windows explorer extension, WinZIP or my favorite 7-ZIP).

Thanks I'll have a look at this over the weekend. EDIT: I did have some look at this and got the newer code to work a bit more, but need to test on a real x64 cRIO system. Hope to get my hands on one during this week.

Duplicate post

Without documentation of the .Net interface for this component, there is no way to say if that would work. This refnum that is returned could be just a .Net object wrapping an IntPtr memory pointer as you hope, but it could be also a real object that is not just a memory pointer. Without seeing the actual underlaying object class name it's impossible to say anything about it. It is to me not clear if that Memory object is just the description of the image buffer in the camera with methods to transfer the data to the computer or if it is only managing the memory buffer on the local computer AFTER the driver has moved everything over the wire. If it is the first, your IntPtr conversion has absolutely no chance to work, since the "address" that refnum contains is not a locally mapped virtual memory address on your computer but rather a description of the remote buffer in the camera, and the CopyToArray method does a lot more than just shuffling data between two memory locations on your local computer. If it is indeed just a local memory pointer as you hope, I would not even try to copy anything into an intermediate array buffer but rather use the Advanced IMAQ function "IMAQ Map Memory Pointer.vi" to retrieve the internal memory buffer of the IMAQ image and then copy the data directly in there. However you can usually not do that with a single memcpy() call for the entire image since IMAQ images have extra border pixels which make the memory layout have several more bytes per image line than your source image would contain. So without a possibility to see the documentation for your .Net component we really can't say anything more about this.

How do you look at those ZIP files? Through the OpenG library again or a Unix ZIP file command line utility?

The LabVIEW PDA Toolkit is not supported anymore as you may know and that is the only way to support Windows CE platform. That said, labview.lib basically does something like this which you can pretty easily program yourself for a limited number of LabVIEW C functions: MgErr GetLVFunctionPtr(CStr lvFuncName, ProcPtr *procPtr) { HMODULE libHandle = GetModuleHandle(NULL); *procPtr = NULL; if (libHandle) { *procPtr = (ProcPtr)GetProcAddress(libHandle, lvFuncName); } if (!*procPtr) { libHandle = GetModuleHandle("lvrt.dll"); if (libHandle) { *procPtr = (ProcPtr)GetProcAddress(libHandle, lvFuncName); } } if (!*procPtr) { return rFNotFound; } return noErr; } The runtime DLL lvrt.dll may have a different name on the Windows CE platform, or maybe it isn't even a DLL but gets entirely linked into the LabVIEW executable. I never worked with the PDA toolkit so don't know about that.

You should probably simply pass a Byte array (or string) of 2 + 2 byte padding + 256 * (4 + 256) elements/bytes as array data pointer and then extract the data from that byte array through indexing and Unflatten from String.

If you talk about patterns, then this follows the factory pattern. The parent class here is the Interface, the child classes are the specific implementations and yes you can of course not really invoke methods that are only present in one of the child classes as you only ever call the parent (interface) class. Theoretically you might try to cast the parent class to a specific class and then invoke a class specific property or method on them, but this doesn't work in this specific case, since that would load the specific class explicitly and break the code when you try to execute it in the other LabVIEW version than the specific class you try to cast to.

I'm also seeing it in Chrome on Windows when not logged in.

Tortoise SVN (+command line tools for a few simple LabVIEW tools) both at work as well as on a private Synology NAS at home.