Rolf Kalbermatter

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. 😃

We use our internal SVN services so this might not be the answer you look for. But I generally refrain from adding the build executables to the repository and prefer to set tags for each release. Yes this means that I might have to go back to a specific tag and rebuild the executable, which is time consuming and has the potential to not create exactly the same executable anymore depending on driver installations that happened in the meantime for another project. But this happens very rarely as most times you want to have the latest and greatest software version. Obviously if you develop a product that might be sold to different customers over the years and might require you to be able to reproduce old versions frequently to support a specific client, this might be something that makes this approach very unusable. And I definitely never ever add the Installer to the repository. That is going to mess with your repository big time, no matter what.

Why do you post this in the LAVA Lounge and not in the LabVIEW->External Code forum? You really need to give more information. You mention .Net, C++ and CLI. That is all possible to combine, though not necessarily the most common way. You talk about native pointers and managed memory in a somewhat ambigous way that makes it very hard to know what you really have. A memory pointer is not simply a memory pointer. It is important to know how it was allocated and with which exact function. That determines if a simple pointer is still valid when accessed from a different managed environment or not. Generally memory allocated in one of the involved managed environments (.Net or LabVIEW) can only be accessed through functions of that managed environment, otherwise you need to do marshalling, which LabVIEW does automatically when you use the .Net functionality in LabVIEW. If your C++ code explicitly allocates memory through Win32 API calls or Standard C runtime calls (C++ allocations could be trickier especially in combination with compilation as .Net assembly), this memory is not managed by .Net but by your code. If you pass this pointer to LabVIEW and make sure that the pointer remains valid (no realloc() or free() calls at all ever between passing the pointer to LabVIEW and trying to access it in LabVIEW) you can simply use the function MoveBlock() as mentioned in those linked articles. Of course you need to understand the difference between a pointer and a pointer reference in order to be able to correctly pass this pointer to the MoveBlock() function. Show us your code and what you think is not working there. One other question is why do you use C++ when you want to create a .Net assembly (or the opposite, why create a .Net assembly when you want to use C++). It is not the most logical combination as your .Net assembly still contains non IL compiled code, so is equally binary platform specifc as a normal DLL. Creating a real DLL instead might be more straightforward.

That sounds bogus.

If you install it in instr.lib or user.lib and do a menu refresh (application property node) it should be added anyways although with a default icon but what else would you want to add there? Creating a nicer default icon?

I would tend to say that it is overkill. If you really want to handle this it coudn't really be more than a 1:1 copy of the complete content to the user selected destination directory. Personally I find that this is easier to handle in 7-zip or similar on windowed desktops and on the command line if you work predominantly there (though why would you use LabVIEW then 😀).

I think a better "workaround" is to use the paths from the hierarchy as read from disk to fixup the paths in the hierarchy list after loading and renaming the VIs, before writing it back with the Write VI Hierarchy method. Having to click away warnings sounds pretty unintuitive.

Well yes I do build my own .opg package with a version of the OpenG Package Builder. And this version does indeed not do many things and none that are required to support new post 8.0 features like lvlib, lvclass, etc. The only fixing that is done during the build process is renaming the VIs with a postfix then packing everything up into the opg package which is basically still the same as a vip. If VIPM indeed does fixup the library names on package creation, which it may not even do intentionally but simply may be a side effect of the part where the entire hierarchy is first read into memory and then saved back to the VIs, then there is a serious problem. If the fixup only happens at masscompile time after installation there should be no problem at all. The part in the OpenG Package Builder that does the postfix renaming uses in fact the same method to load and modify and then save the renamed hierarchy but I do execute it in pre 8.0 LabVIEW as the VIs are saved in the format of the LabVIEW version in which this step is performed. As all of the wildcard magic in the library name except the shared library ending itself is really only 2009 and higher gimmicks, it may be that the according function in later LabVIEW versions fixes up the library names on recompilation and then the built package indeed ends up with an undesired fixed library name. In that case VIPM should in fact restore the wildcard shared library names after renaming and recompolation before writing the VI hierarchy back to disk in order to keep the original names. Also I obviously only use the shared library file ending wildcard and not the others for 32/64 bit library distinction. Instead I install both shared libraries to the target directory and then use a post install hook that renames the correct shared library for the current platform to the generic name without bitness indication and deletes the other one. That way the VIs can always use the same generic library name without need to distinguish between bitness there.

Error 1 is not only a GPIB controller error but also the canonical "Invalid Argument" error. And since there is obviously no GPIB node involved here (it's the old 488 and 488.2 GPIB functions that return such errors, not the VISA nodes, so it is actually VERY unlikely that anyone nowadays is even running software that uses them) it must mean that the property node considers the value you pass to it to be an "Invalid Argument". 😀

The header file is indeed not necessary when you have a good and complete documentation. However I haven't seen many such documentations. More often than not the documentation contains typos or remains from older versions of the library that are not valid anymore. The header file should be considered the canonical documentation about data types and function prototypes, and the accompagning documentation contains hopefully more than just a bare repetition of what a good C programmer could determine from the header alone. It should contain things like what errors a function can return, what special memory allocation certain parameters may need, the exact meaning of every parameter and its possible and/or allowed values, or the minimum memory size a string or array pointer should have for the function to write into. If it is really good it also documents things like what prerquests a function may have such as other APIs that need to be called first and in what order. In the end however this last part is best learned from sample code that comes with the library and which you then need to translate to LabVIEW. If you create a library of VIs that resembles the dll library functions, this is not very difficult. But your VIs should NOT be a one to one mapping of parameters on the front panel to function parameters in all cases. In C you may have to pass an array into a function and as a second parameter a size. In LabVIEW the array size is part of the array itself so creating a front panel that contains both an array and a numeric for the array size is pretty stupid (which is what the Import Library Wizard for instance does, because a C header file does not tell the C compiler (and hence the Library Wizard too) which parameter is definining the size of the array buffer). That is left to the programmer to know, either from the naming of the parameter names or much better because it is documented in the documentation like that.

It seems to work fine for the OpenG ZIP library and other libraries I did in the past. So not exactly sure what the problem would be. Of course you need to make sure that the .so and .dll and .framework all end up in the same location relative to the VIs, the shared library name needs to be the same except a possible lib prefix on the Linux platform, and the calling convention needs to be cdecl on all platforms (where you have choice). Most new platforms only know one possible calling convention, so no choice there anyhow. Windows 64-bit for instance uses a new calling convention called fastcall, but that is the only one supported (and generally used outside kernel space).

the last step in the description on the sourceforge post could be made simpler: Instead of changing the library path in all Call Library nodes to <some long path>/lvzmq32.so and having to maintain two versions of the VIs because of the different library name ending, you should replace the .so with .*. LabVIEW will then replace the .* with whatever file ending is standard for the current platfom (.so on Linux, .dll on Windows, .framework on Mac)

Usually the lib library only is the import library for the DLL. C can't directly and magically call DLL functions. Somehow it needs to know in what DLL they are and how to load them into memory. This can be either done explicitly by calling LoadLibrary() and GetProcAddress() or by linking the import library that came with the DLL. The import library is simply a precompiled lib file that does all the LoadLibrary() and GetProcAddress() stuff already. In LabVIEW you can't link in a lib library but have to use a Call Library Node, which is the LabVIEW interface to LoadLibrary() and GetProcAddress().

I never really liked the new combined probe window. The old one I used frequently, yes sure you could get into a real mess with probe windows all over the place and it could be hard to find the one with the new value from the wire you were just single stepping through. But the new probe window doesn't solve that at all, you still need to find the specific probe entry in the list, click on it to see its value in the graphic probe view and then get that damn probe window out of the way again ASAP as it covers so many other things. I usually decide then that I can just as well get rid of it, except "Are you really sure you want to close this window?" Damn it! No of course not, I clicked on the upper right corner by accident and never ever would think about getting rid of this huge monster window on my desktop screen.

I"m not sure it's conflation only. Many seem to be focused specifically on the fact that LabVIEW GUIs don't look like the latest hyped Office version, which of course will be again different over 2 years when yet another modern style design guide claims that everything needs to be high contrast again, or maybe alpha shaded with psychadelic animations (you need to find reason to sell high end GPUs to spreadsheet jugglers). Your second point is indeed one thing I feel LabVIEW could have made more advances. Dynamic control creation while indeed complicated to get into the dataflow paradigma of LabVIEW would be possible with the VI Server reference model, although it would not be classical dataflow programming anymore for such GUIs at least for the part that you use such dynamic instantiation in. XControls was a badly executed project for an in principle good idea, Splitters are a God send for more dynamic UIs together with Subpanels, but to try to edit splitters once they are placed on a frontpanel really can be an exercise in self control. In doing so I feel the same frustration as when I'm forced to edit some Visio drawings. The editor almost seems to know what you want to do, because it always does the opposite of that, no matter what.