Leaderboard

I would just use a strict typdef enum along with "Format into String" and "Scan from String". A change to the lower level API would only require updating the typdef.

We recently discovered this VI among the utilities: vi.lib\Utility\VariantDataType\GetNumericInfo.vi that returns all the string values for an Enum. We have found it quite useful. (You can then index the array to get the specific string.) (I just tried it and it doesn't seem to work for a ring control. I always use Enums anyway.)

It's a combination of the price and time. I (the author) work on the LabVIEW Language team and developing libraries for users is not one of my job responsibilities. Most of the work on the bar codes is done during my free time or on our free form test days. I recently added (but have not yet cleaned up / tested / published) support for PDF417, which may be an acceptable alternative to QR codes. I noticed recently that tcpdf supports QR codes and it's distributed under the LGPL. I may be able to port it, but it's not very well documented (and neither is the source of their QR code support. It seems like a very complex bar code from what I've seen, so I'm not optimistic about being able to implement it quickly. (I'd also need to double check with NI's legal department regarding porting from LGPL code)

Here are the VIs after some work on icons and adding an additional function to return the fully-qualified class name. I’ve made the smaller VIs “inline”. I also changed “Get Default Object” to being based on “Preserve Runtime Class” as I found that the zero-iteration method sometimes didn’t work when in an inline VI (some detail of the complier that I don’t understand). PS to jgcode> what is the next step in possibly getting these into OpenG? OpenG Suggestions.zip

If the DLL call and ActiveX call are both UI threaded (ActiveX as said is most likely, DLL depends on the Call Library node configuration but if it is a driver you haven't written yourself I would be vary to change a possible UI thread setting to re-entrant as that could cause all kinds of weird problems in the DLL if its functions aren't explicitly written to be re-entrant) you get most likely following scenario: Since the ActiveX call takes a certain amount of time, LabVIEW can't interrupt it midway to switch to the DLL call and let it take over the same UI thread. Once LabVIEW hands over control to an external code (ActiveX or DLL) it can only wait for that code to return code back to LabVIEW before doing anything else in that same thread. There is not a single way around it. I can give you a solution that will work. Create two LabVIEW executables, one calling into the ActiveX component and the other into the DLL, and let them communicate through Inter-application Communication together. That solves the problem since both components now reside in separate processes and will be simply multitasked by Windows itself. Changing the Call Library Nodes to run re-entrant might be a solution, but without knowing the underlying DLL code I would never make such a change myself. If it is not set re-entrant this has most likely a reason. It could be just an omission from the actual programmer but the chance that the DLL uses global variables and resources between functions without protecting them explicitly is very high and in that case changing the VIs to allow re-entrant calls could in the best case lead to crashes in the worst case to strange and almost impossible to debug effects. One other option is to change the Call Library Node to be re-entrant and assign all Driver VIs to a specific execution system. Now you go into vi.lib/utility/sysinfo.llb/thread config.vi and run it. In that VI set the execution system you have chosen to assign to all driver VIs to only have one thread. This will likely work fine but has the disadvantage that the thread configuration is not part of the VI but of the LabVIEW runtime setup. So you will have to make sure to add the according lines in labview.ini, that this change will create, into any executable ini file as well as any other LabVIEW development system ini file that you may use, such as other LabVIEW development versions you may use or other LabVIEW installations on any other machine that wants to make use of that library.