Rolf Kalbermatter

I'm afraid they aren't. The according palette isn't called "HTTP Client" for no reason. Implementing TLS on a listener (server) isn't that much different when using OpenSSL on C programming level but it does require a bit of a different setup than when implementing it on a client connection. And the glue to map it to a system similar to the standard LabVIEW network functions does get a little more complicated.

Many possibilities. 1) There might be a new and different INI file key that enables the dialog editor. 2) The dialog editor was completely removed in the released LabVIEW source code and only is present in NI internal builds of LabVIEW for testing and debugging. One or two strategically placed #if !RELEASE_BUILD ......... #endif pairs are enough for that. 3) There might be now a seperate NI internal tool (written in LabVIEW or compiled from the LabVIEW C++ source code) that you now have to use when wanting to edit those resource files. I would bet it is either 2) or 3).

Well to be honest LLVM won't be able to process a header file that references other header files with declarations that are used in your header without access to them. It needs access to those referenced headers somehow too and I doubt it comes preinstalled with all Mac OS X, Windows SDK, etc. etc. headers so you end up installing them somehow to your disk too and pointing LLVM to them. The import library wizard has internally this informations too, but once you start going down the path of creating the wrappers with such advanced functionality through scripting you end up in hell. There is simply no way such a "Wizard" can really know how the different information in such structures may or may not interact with each other and with other things in the API so you end up with a overly complicated interface that is very difficult to understand and allows you to still do lots of illegal things. The purpose of a proper LabVIEW DLL wrapper is to simplify the API as much as possible for the user without saddling him with subtleties like if you want this function to return 1000 samples you have to set this numeric to 8000 AND also Initialize an array with 1000 double values in order for the call to not crash. Or to return a string from the function to require the user to even have to specify the size of the buffer as the function documentation specifies that the function requires a buffer of at least 256 characters to fill in. Even such a simple thing as an API where you pass in a buffer that the function should fill in with information and a second parameter that tells the function how big the buffer really is, is already a total nogo for even the most advanced wizard, since there is no way the C syntax can describe the specific dependency between these two parameters. So the wizard will create two controls on the front panel and the uninformed user will wire a 1000 to the buffer size but leave the string control that should now contain 1000 bytes at its default of an empty string and -> boom! We humans after quite some dealings with these kinds of APIs often can infer the correspondence between these two parameters because of a more or less useful naming correlation between the two but even that can often go wrong (is the number in bytes, characters or numeric elements of the array type?). The only real information comes from the documentation, which surprisingly often fails to document these things accurately too, and then the only thing that remains are hopefully sample source code that shows you how these parameters are supposed to be assigned.

Please also note that your quote of NI-IMAQ I/O is probably making you bark up the wrong tree already. This is just the software driver needed to access the I/O on the supported IMAQ cards. If you program the FPGA on those boards yourself you can define your own RT Fifo etc communication method between the FPGA and RT parts. What you try to do however is accessing the camera part as an image aqcuisition device from within real-time which would require support from NI-IMAQdx instead, a completely different type of software driver than NI-IMAQ I/O. (Yes I agree that NI hasn't always been very great in naming their driver architectures in a clear and concise way). I haven't used any of those frame grabber boards but I believe if you want to use them from realtime you would have to treat them as their own FPGA target and develop some FPGA software on it to communicate through some RT FIFO or similar between your frame grabber implementation and your realtime target. The FPGA programming of the camera grabber interface is possible and has been done by several people on here or the NI forum, but is far from trivial.

I only usully install LabVIEW about every 3 years when the old labtop starts to show signs of going soon death. But then I usually do it for at least about 5 or more LabVIEW versions. HAve recently resolved to put rather old versions on a seperate VM as they tend to get tricky to run on the newest OSes and also newer LabVIEW installs tend to trample more and more on older installations.

I thought it was not relevant when trying out things as I did various trials to get this working (The Control Editor has "particular" behaviour and controls easily can get in a weird state where for instance some of the parts end up in places where they seem not selecatable anymore in the customize mode, they still are but the position where you need to click to select them doesn't match the position on the front panel where they really appear.) 2) Right click on it and select Advanced->Customize (or double click) => The path control opens in the control editor 2.5) Change to Customize mode (click on the Allen key which then changes to a pincer) 3) Right click on the browse button and select Advanced->Customize Double click on the Browse button => The browse boolean control opens in the control editor For step 2) double click and step 3) you might need to have the option enabled to open the custom control editor on double click, which is one of the first things I always enable when installing a new LabVIEW version, right after disabling auto tool and auto wire routing 🤢.

Why would you need an Open Sourced LabVIEW for something like that? This was possible in the Control editor since LabVIEW 3!!! (Discloser: the Browse button in the Path control was not added before somewhere around version 6 to 8 but the principle worked in LabVIEW 3). 1) Place a path control on your front panel 2) Right click on it and select Advanced->Customize => The path control opens in the control editor 3) Right click on the browse button and select Advanced->Customize => The browse boolean control opens in the control editor 4) Save this as your Browse Boolean.ctl file or whatever you want to call it. 5) Use as you wish and enjoy that it automatically adapts to the platform style for the system you run it on Browse.ctl

You realize that the Enque Element in the Run VI part is not guaranteed to be executed before you close the VI reference itself? In the CBR case you guarantee to call it before you attempt to close that VI reference.

The root loop is definitely per process. It’s simply the primary thread started up by Windows for a process in which the GetMessage(), TranslateMessage(), DispatchMessage() Windows API calls are made over and over again, with minor LabVIEW specific adaptions. This thread is associated with a hidden window whose window procedure then translates everything into a Platform independant message infrastructure that very much resembles the Mac classic message loop. This is basically the famous root loop with the message procedure in the hidden window being a sort of platform wrapper around it. Under Windows there comes in a potential extra complication as the OLE marshalling hooks into the process GetMessage() API, completely outside the control of LabVIEW. So if you interface with OLE/COM/ActiveX and to some extend even .Net compenents things can get interesting,

Yes that is inside the unzip.c code from the minizip program, so there should be no need to do that again in the caller. Will check how this code executes, as there are conditionals for the execution of this with raw format being one exception as it can’t be checked at that point and password protected entries have a different code path as the crc is also used as encryption seed.

That is what supposedly happens and fast file format should not have any influence on that. The LabVIEW exe is instantiated as OS process and loads very early on the lvrt.dll into the process space and then hands over control to the runtime dll. The runtime being a dll is mapped into the process space and the data segments (where globals are located) are copied into newly created memory areas inside the process and from there on the runtime dll is operating as an independant entity from any other LabVIEW exe that may use the same dll. No data sharing between the LabVIEW exes is possible except through explicitly created IPC channels (network, pipes, shared memory, etc) or if you happen to use a zero day vulnerability in Windows process space separation.

I'm not sure what is happening exactly but the crc32 is calculated wen extracting the data with unzReadCurrentFile() and then checked when closing the file entry with unzCloseCurrentFile(). If the crc32 doesn't match, this function should return UNZ_CRCERROR (-105). The only time this check is not done is if you do raw extraction, but the OpenG ZIP library only uses that when deleting a file entry from an archive as it needs to create for that a new archive and instead of inflating each of the non deleted file first and then deflating it again, which would require the password if a file entry is password encoded, it simply retrieves the raw data stream and copies it over into the new archive, without unzipping,decrypting and then encrypting/zipping it again.

Without seeing more of the DLL it is hard to say for sure. But if you talk about two different LabVIEW programs (EXEs or different IDE instances) the DLL is loaded into each instance seperately and no normal global variables will be shared between them. They have no way of accessing each others global variable space as that is what process memory separation is all about. So if two different instances of a process block somehow inside the DLL there must be something else going on. It could be explicit shareing through IPC (network, shared memory, etc) or it could be through access of a kernel device driver that is of course not running in the process itself but in the kernel and might somehow block resources that the DLL tries to access from the other process and somehow locks up. That would be of course bad programming of the DLL programmer. The DLL should detect that the resource is not available and return with an error instead of just blocking.

As far as LabVIEW is concerned, yes! LabVIEW simply uses the Windows API LoadLibrary() and that only distinguishes based on the DLL name itself. If a DLL with that name is already loaded into the process, even from a different location than what you request at that point, Windows will simply return a handle to that DLL and increment a reference counter for that DLL. However there is something like SxS (Side by Side Assembly) loading, that despite its names not only works for .Net assemblies but really any DLL. A DLL when compiled can add a manifest to its resources that specifies a specific version for one or more of its dependent DLLs and when Windows loads that DLL it will attempt to honor that version compatibility even if another version of that DLL with the same name is already loaded. The specifics of how to make that yourself is kind of badly documented and IMHO, while invented to help battle the so called DLL hell (different modules inside an application process having been compiled with different versions of dependent DLLs such as C runtime libraries that are binary incompatible to each other) it usually replaces DLL hell by DLL chaos.

It's your right to do the homework for other people, but don't be upset about other people not wanting to do that :-).

Try to add dialogEditor=true to your LabVIEW.ini file. This worked at least in the LabVIEW 7.x days and still might be present. See here https://labview.brianrenken.com/INI/ for some details about this.

This is a reference to Monnie Anderson who worked at NI long long ago. Not sure where he is now.

No idea how they did it specifically but as you saw in the other thread in lvdialog.rsc this frontpanels are simply dialog resources that can be loaded as templates by LabVIEW C code. There is a hidden File menu entry that allows loading these resources to edit them and technically they are VI Frontpanel resources. A neat way to use the already existing UI elements from the C code too.

The nodes are actually not private anymore but rather part of the scripting extension. Look for New VI Object and then there is an enum where you can select the object to create. The owner refnum obviously has to be the correct frontpanel or diagram refnum depending if the object is a diagram node or a frontpanel object and the object class refnum has to be compatible with the object too. Lots of preconditions that must be correct and therefore it's not really a tool for generic use at all. The enum for the PixMap has the same (warning: dangerous) message appended. Basically you are working here in the attic of LabVIEW and should accept that there are rusty nails that can stick out of the floor and walls and on which you can hurt yourself pretty badly if you don't watch out carefully. And don't run to mommy and rant about the evil LabVIEW engineers who left those rusty nails in there. You are not supposed to be in that attic at all, and if you go anyways assume the risks yourself! Basically any bug report about such features will be silently dropped in the round binder, you know the one where you also drop your dirty paper handkerchiefs and such stuff. 😃

This existed back in LabVIEW 3 already (although you only could create it on a frontpanel with some super private nodes that came available with the new VI server interface in around LabVIEW 6 and crashed LabVIEW back then quite quickly too if you got that far) and I"m pretty sure it is from the Mac only version of LabVIEW alrady (2.x). In fact it seems like the bitmap edit control in the old icon editor, which looks exactly like that, but that icon editor was a dialog written in C inside the LabVIEW core. So while it is functional enough to be used with the LabVIEW internal C dialog API it obviously never received any extra love to adapt it to the property node interface that was later created and to make it useful as a generic LabVIEW control. Since the old default icon editor is still an option to choose, I'm sure that removing it from LabVIEW at this point is also not an option. But making it a fully public control is definitely also not going to happen. For this it is to limited in functionality to even spend half an hour to make it more functional.

Which card is that? If you use one of the Comsoft (Kunbus) cards that NI resells, you should already have received a driver medium with it that you can install and will put the necessary LabVIEW VIs in the correct location for use in your program. If it is a different card you will first have to find out what LabVIEW support the manufacturer provides if any. For a Hilscher card there exist some community examples but Hilscher themselves doesn't seem to feel comfortable with LabVIEW. So you would end up having to interface their cifX DLL API through the use of LabVIEW Call Library Nodes. The mentioned community examples tend to be fairly badly working minimalistic examples without a proper implementation.

That's pretty much how it all works. Of course that doesn''t mean that you can't bend the system if you have particularly deep pockets to buy the necessary lawyers to get a court ruling that may sound and feel like the opposite of this. Generally however the money involved is not high enough for such things. The only real problem if flarn would want to sue someone using that VI is of course to find out about the illegal use first and then to proof that that other person didn't invent it themselves independently of his posting. But that is an entirely different story. Having right doesn't always mean to get that right. Who knows, Oracle might buy his rights some day and then go and sue everybody. 😃

Legally that is indeed how it works, unless you live in a banana republic maybe 😃 Copyright is gained automatically when a work is created. At least in the US, works first published after March 1, 1989 need not include a copyright notice to gain protection under the law. It legally prevents anyone from copying it, unless it is accompagnied by a license that specifically allows that.

The difference is that Mouse Down is generated first for the control that the user clicks on, then if that processes successfully the Key Focus is changed to the new control which commits the value to the control that had previously the Key Focus, which results in the Value Changed event for that control. So at the time the Mouse Down event is processed, the Value Change event for the previous control has not been processed yet. When you use the Value Change event for the button instead, it is guaranteed that the Value Change event for the string that is a result of loosing the Key Focus for that control, has been already processed.

Very nice tool. I don't generally customize wires but this looks like a fun project. 😃