LabVIEW
Fast File Format causes application to ask for DDE.lsb
@dadreamer wrote:
- There's no need to adjust any parameters of CIN: you just pass the wires to it, generate a C template and start the coding. In DLL case you need to set up a calling convention, specify correct function arguments, their order and return value. The parameters' data type is defined by the settings of CLFN. I know there's "Adapt To Type" setting, but it's not so transparent for users as in CIN case.
Just read this again after the other discussion and I have to tell you that the Call Library Node supports exactly this too. Create your controls and indicators on the front panel, drop a Call Library Node on the diagram and wire all controls and indicators up to it, then right click on the Call Library Node and select "Create C code". E voila you have an empty function prototype that is guaranteed to match the parameter datatypes exactly as it would when creating a CIN. It's only when you go the other side, trying to interface an existing DLL to LabVIEW with the Call Library Node that you really need to think about how the different parameters should be configured. But even that is in many cases easier than with CINs, since you CAN configure the Call Library Node to match many existing DLL function parameters, with CINs you ALWAYS had to write a C code wrapper, no matter what!
Okay, since I took dotting the I's in the CINs history, I describe another CIN-related bug. I don't care if it would be fixed or not, it's just for the completeness.
It was introduced with the new Managers API (mgcore*.dll + friends), if I remember correctly, when LabVIEW 2009 was released. In earlier LabVIEW versions (8.x) when you copied CIN with holding Ctrl key and drag-n-dropping new node, some CINs context menu entries become grayed-out (Reload (x2) and Purge). In LabVIEW 2009 and later those entries are not disabled and not grayed for some reason, so the user could activate any entry.
Now we clean up code linking by choosing "Purge Bad Code Resource" at any of the CINs. One CIN becomes "clean" / non-linked, but the second is still marked as linked to the code, even though LabVIEW has unloaded and deleted its temp DLL. After that we try to save this VI -> BOOM!
The fix would be very easy (as in common Ctrl+C -> Ctrl+V operation), but it's absolutely clear, that no one is going to repair it ever.
@dadreamer wrote:By the way, I forgot to mention one more decorative "+" of CINs over DLLs. Imagine that you're developing your own DLL and at the same time debugging/checking it in LabVIEW. So, you have your favourite IDE (MSVC or whatever) open and LabVIEW is open too. When you select the DLL to be used and close CLFN, LabVIEW loads this DLL and locks the file. When you see that the DLL is not correct and needs to be justified, you have to close the VIs (the project) or shutdown LabVIEW to get your DLL unloaded from memory. If you don't do that, the compilation process in your MSVC or any other IDE fails and the IDE says that cannot compile due to a locked output file. CINs don't fall into this situation, because LabVIEW takes the original *.lsb file, extracts interior DLL to the Temp folder and only after that loads this DLL to the memory. When you recompile the codes, it is done just fine as the original file is not locked. I personally like this little advantage of CINs.
While that may be indeed sometimes annoying with DLLs, when you do this you are usually debugging. And there you have the choice to build the DLL directly to the location where you load it from the VI or some intermediate location (I always use the build location alongside the VC project file and then copy the DLL over to the LabVIEW project location when and as needed). In this case you do not have that problem anymore. Yes you still need to shutdown LabVIEW in order to eventually replace the DLL with the new one, but in the case of CINs you have to go into every single CIN node and purge and reload the code resource. So it is at worst a tis for tats situation, you loose some and you gain some with either solution.
And source level debugging with CINs is more tricky in any case, if you are not VERY careful with your code resource version maintenance. If the DLL inside the code resource is different even for one single bit to the internally calculated version signature of the current Visual C project, it won't be easily possible in Visual C to convince it to load the correct source files and to single step through them. That is with the DLL case the same but there you have a much easier way to ensure that the right DLL is loaded in the first place, without having to go into some code resource and purge and replace it just for the case that it may not be the right one. And even a single whitespace edit in your source files will change the resulting version signature for the DLL/CIN.
