Leaderboard

I've never built a DLL using LabVIEW before, but am starting to think this may be the way to go for a component I'm working on. However I have one concern where my google-fu is failing me and thought I'd lob this one over the fence since at least of the lava gurus here likely knows the answer. Consider this situation: My DLL is built and includes SharedLibrary.lvlib (version 1). My EXE is built and includes SharedLibrary.lvlib (version 2). That is both the DLL and EXE reference the same library, all be it incompatible versions. Each fully includes all the dependencies they need to run on their own. With respect to each library version, the namespaces are identical-- that is we don't have SharedLibraryVersion1.lvlib and SharedLibraryVersion2.lvlib, but two different versions of SharedLibrary.lvlib. Now let's say my EXE needs to dynamically load my DLL: Do I have a problem? Am I going to run into any weird namespace collision issues? I would hope everything should be locked properly behind their respective boundaries, but... If this is a problem it's no big deal, I could always change the DLL into another executable, but I'd rather not as it makes a bit of a mess of passing data in and out.

I really wish the LabVIEW picture control would be improved. It scales vector based images just fine but does so horribly for raster content. When you look at performance considerations the opposite is true: it can handle huge raster images, but even a moderate amount of vector content absolutely kills any hope of having a fluid experience.

Well you can start by not quadruple posting the same question. Seriously this is bad internet etiquette to have on any forum. That being said I do have a solution for your question which uses the .NET picture box. The reason I used that instead of the native 2D picture control is because it has the Stretch, or Zoom feature that resizes images very nicely. LabVIEW's picture control does have the Zoom Factor but it makes the image look like crap. I made the picture box control fit to the panel, and then set the panel to resize objects as the window resizes. This gives a more or less fluid resizing of the image. Picture Full Screen.zip

You wouldn't say that if you worked at Onbarcode.com

There is no easy answer to this. As with most things the right answer is: it depends! If your LabVIEW DLL was created with a different version than the LabVIEW version you are running your lvlib in, you are safe. The DLL will be executed in the context of the runtime version of LabVIEW that corresponds with the LabVIEW version used to create the DLL. Your LabVIEW lib is executing directly in the calling LabVIEW system, so they are as isolized from each other as you can get on the same machine instance. However if you load the DLL into the same LabVIEW development system version as was used to create it, things get more interesting. In that case LabVIEW loads the VIs inside the DLL into the same LabVIEW system to save some performance. Loading the DLL into a different LabVIEW runtime requires marshaling of all function parameters across process boundaries, since the runtime system is a different process than your LabVIEW system, which is quite costly. Short circuiting this saves a lot of overhead. But if the VIs in the DLL are not in the same version as the current LabVIEW version, this can not be done as the DLL VIs are normally stored without diagram and can therefore not be recompiled for the current LabVIEW platform. So in this case things get a bit more complicated. I haven't tested so far if VIs inside DLLs would get loaded into a special application context in that case. It would be the best way to guarantee as much of similar behavior as if the DLL had to be loaded into a separate runtime. But it may also involve special difficulties that I'm not aware of.

Hi again Regarding the post above I took the liberty of adding the functionality to the project. I have attached a zip file containing only the VI's I have added or changed (folder structure has been kept) - feel free to add it to the project if you want.. Changes: + Added VI's for updating an existing JSON Collection Object value - by Array of names + Added VI's for removing a JSON Collection Object - by Array of names * Changed polymorphic Set VI to include new features .. the 'Set Object' function has been made into a submenu.. Best Regards Stinus Changes to tcplomp-json-api-labview-0c0d17447fc4.zip

Excited to see you guys. I also have door prizes for this year. Any excuse to come!

Yes. In fact, it can be and array of anything including other objects and/or arrays so even this is valid: "myarray":[[123,223,{value1:MyVal1}], value2:"wally"] This is why, for LabVIEW, it is much better for us to rely on the programmer to decide how to get the info out since with the polymorphic VIs we limit his options to valid LabVIEW types with a fall-back of the raw string. On a similar note: You don't have to have quotes around a string value value either (it's only required for labels). I have no position on this. I took the decision in the SQLite API to encode NaN as a string rather than NULL but that was so that extra detection wasn't needed when converting back to LabVIEW types (Search and Replace NULL for NAN). It was an issue of performance that we may not be so fastidious about here. Other languages may not have a representation for NaN, but LabVIEW doesn't have a concept of NULL either except perhaps "empty string" which converts to zero for numeric types. Off:Topic: Way to go to get the last word in (comment then get the mods to remove it all...lol)