Leaderboard

Hi Porter, I'm happy to hear that! Do you have any specific expectations for the next versions? Any features you'd like to see? I have one cool feature coming already: the build specifications editor. So far it doesn't look very impressive, but everyone who's ever waited for LV to open exe/installer properties will understand this plugins hidden beauty

View File Flatline Controls A set of custom controls, following the trend of a more flat UI design. Heavily influenced by Google’s Material Design, though constrained by what can be done with available tools and options in LabVIEW. Uses icons from Google Material Design. — Buttons based on the system booleans (with hover effects). Icons can be added as decals (such as from materialdesignicons.com) — Matched sets of controls for numeric/string/enum/etc., based on Silver controls, but swapping out all ‘chrome’ for simple boxes and lines. — flattened versions of switches/sliders/arrays/graphs etc. Now on the LabVIEW Tools Network JDP Science Tools group on NI.com. Submitter drjdpowell Submitted 06/13/2016 Category User Interface LabVIEW Version 2011 License Type BSD (Most common)

Sorry I don't have an answer for you, but I do want to clarify that there's no OCR happening. Instead, when LabVIEW prints the front panel, it sends the text portion to the printer driver as text, with coordinates as to where that text should go on the page. This allows the printer to use information from the font to take advantage of the full printer resolution, making the text look cleaner. It also allows a printer driver such as for PDFs to include text as text rather than as part of an image. LabVIEW also provides a "Get Front Panel Image" method which is what I assume is used by the LabVIEW-specific PDF drivers, and in that case it's retrieving the entire front panel as a single image which includes all the text. While I understand your desire not to be tied to a single PDF printer driver, the best route is probably to research the available PDF printer drivers and find one that provides the features you want.

Here is a demo button based on Silver buttons (instead of system buttons). No hover effects, but one can colour ON and OFF state differently, which you can't with system buttons. Flatline Non-hover button.vi

SQlite is single writer, multiple readers as it does table level locking. If drjdpowell had followed through with the enumeration it would (or should) have been in there. The high level API in the SQLite API for LAbVIEW insulates you from the Error 5 hell and "busy" handling (when the DB is locked) that you encounter when trying simultaneous parallel writes with low level APIs. So simultaneous parallel writes is not appropriate usage.....sort of . You can mitigate some of these operational aspects as you are attempting to do but in reality you are now just starting out the process of proving my rule of thumb:

Yes but I'll need a bit of effort to put together something that can be understood easily, since right now it mostly consists of big Excel sheets with raw data. I'll try to post something soon-ish.

Yes, I try not to shoot myself in the foot.

Well. As I said. For me it's.polymorphic VIs because they have the menu in lieu of an enum (same thing but different) and de-clutter the compane. However. I don't think I have required global storage like that for a long time. Using a DB makes AEs (and a lot of other things) almost redundant since you just craft a query string.So for your average N sensors example it would be a one liner like SELECT avg(value) from Sensors WHERE status='active';

I don't use the Actor Framework, but do use an actor design (multiple parallel loops that are asynchronous and have dedicated tasks with messaging between). The design you describe sounds like it would work but here is a design I use. There is a configuration actor (module) that handles all the File I/O parts. It has a window just like LabVIEW's Tools >> Options dialog, where there is a listbox of settings, and a subpanel that a VI gets loaded into. The control values are what are saved and loaded into a single INI file. Each page in the config is a separate section in the INI. The page VIs are running, but they don't have to be, they can literally be just a set of controls but some times you want feedback so they run, and listen for the global quit message all actors get and stop if they see it. I also setup a slow polling so if the reference is invalid they pages stop too. This way hitting CTRL+. will stop them too, even though they are also asynchronous. On startup of the program, before any actors are started, a VI is called that loads the INI file and puts all the application settings into a global. Where they can be read but not written. Each actor during its init will read from the global the settings they want. Then when the user opens the config actor, makes a change, and then presses OK or Apply, the control values are all read, then re-written to the INI, and re-written to the global. Then a single message goes out to all actors telling them there are new settings that were applied. This is a 1-to-N message where there is no waiting on responses. In this message is data telling each actor which pages of the config were changed. This way each actor can look at the pages and determine if the data changed, is applicable to them. If I changed a COM port for a power supply, then the power supply actor now needs to cleanup and re-init with the new settings, but the DMM actor doesn't need to do anything. So in my setup one actor handles all File I/O, with the only exception is a single VI that is called before all actors start which does the initial read. Config is done in pages, which are just a collection of VIs and controls. This makes adding new settings easy, just add a new control, then read from the global which is a variant. This way when I add a new setting there is no type defs or controls that need updating, and no new code to write, just add the control to the page VIs, and now that setting is in the INI and global for the rest of the application to read. There is a chance for some runtime errors because of this, but these types of errors you see once in development, then make it the correct type, and never see again. You aren't changing the type of the data mid application. If I have a string data type that is Project Name, I'm not going to change that from a string, so once all the places that I'm reading Project Name are set to string you won't really see any errors again. In your design you mentioned each actor being responsible for their own settings, but I have a few settings that aren't specific to one actor. Under the Advanced page of my config I have a hardware simulation mode. If this is on each actor knows to pretend it is talking to hardware and return random, or semi-random data. I may also have multiple pages for each actor. I have a sequence engine, and it may have multiple sequences that could be in multiple pages, or a single page with a drop down of which sequence to edit. My point is I can have as many settings or as few, which can be shared between actors. A downside of this design comes when you want to just run a single actor without having to run the configuration actor. I realize my design adds some coupling that is generally not desired. So I had some extra code to detect if the configuration actor isn't running, and to use predefined defaults for that actor, if it's not.

The answer to my surprisingly fast read times (Given the physical work required to actually perform head seeks and factoring in rotational speed of HDDs) is that Windows does a rather good job of transparently caching files int he background. If you look at the area labelled "Standby" on the memory tab in Task Manager - this is cached file data. Search for RamMap from Sysinternals for a tool to allow you to empty this cache and otherwise view which files are in cache and which portions of the files..... Very interesting stuff. And stuff I knew nothing about until a few days ago.

Attached is a quick example. Basically you set the values as a look up table where a string corresponds to a value. Then you can get that data back by providing the string and performing a read. This is apparently a very efficient method of getting data. You'll need to convert the variant read back into something useful and for that you need to know the data type that it was written in. Here you may run into errors. Like in my example if I tried to read all attributes and said that the data type was string, one would read fine, the other 2 reads would generate an error because the data type isn't the same as it was written with. EDIT just saw you use 2010 so here is the same VI in 2010. Variant Attribute Example.vi Variant Attribute Example 2010.vi

You're probably thinking of a tab in an ActiveX or .NET container. Why are you using a tab at all? Just use a single subpanel and use the "tabs" (a ring or a list box works well) to control which VI is currently displayed in the subpanel. Then you can add as many items as you want at run-time.