Phillip Brooks

Cross link from the Idea Exchange: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-References-to-be-Wired-into-Case-Selectors-to-Check-for/idi-p/1022833 Would the implementation of this idea make this situation less likely?

Also, if the queue is created as a result of an error using enqueue, the subsequent pass through the loop does not pass out the newly created queue (use default if unwired). Zombies!

Sounds great! Just please don't use "Three Button Dialog CORE.vi" as a starting point

I just contributed to a post on the dark side where I discovered that the fractional seconds component <%<digits>u> of the scan from string uses the regional settings to evaluate the input string. My signature's "%^<%Y-%m-%dT%H:%M:%S%3uZ>T" is ISO 8601 compliant for CREATING a string because the spec allows for either separator to be used, but LabVIEW will always use the locale settings to PARSE the string. In order to properly interpret an OpenG configuration file for this case, I don't see how it can be done without adding a section to the INI to store the regional settings for the last write to the file using the OpenG functions.

Were you thinking of the Map thread? http://lavag.org/topic/5983-map-implemented-with-classes-for-85/

The TestStand API includes something called "DecimalPointLocalizationOptions" http://zone.ni.com/r...izationoptions/ Rather than trying to guess what the decimal point is, maybe the Variant Config library could add a [OpenG_Locale] section within the INI file that would store the locale specific data at the time the INI was written. Presumably the Variant Config INI file will be read using the library functions. The saved settings in the INI file could be compared to the runtime locale settings (%c) and the library could convert if necessary. The default-defaults could be used if the section was missing (non-OpenG INI or upgrading to new version of lib).

I don't use either library often, what caught my eye was the locale decimal point part. The addition of a specifier for the separator and the implications are being discussed in the other thread.

Google is your friend. LabVIEW Array of X-controls http://lmgtfy.com/?q=LabVIEW+Array+of+X-controls

I've been asked to allow editing of a database table in a multicolumn listbox. I used to use a dialog to edit the record's contents, but now it would be nice to edit 'in place'. If you select a row and then select a cell, the cell changes into edit mode. I've tried various combinations of properties and looked through the methods to try and find how to set a cell to 'edit mode' programatically, but just can't find the right combination. The fields marked <REQUIRED> would be set to edit mode in succession until all <REQUIRED> fields are filled in or until the user selects a different control on the FP. Anyone know how to coax the cell into 'edit mode' programatically?

The inability to change the NI picktime VI was noted in this Idea Exchange discussion. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Calendar-control-that-does-not-block-the-GUI/idc-p/1419606#M9804

There is an active review of the variant tools in this thread

Here is our default image for our generic dialog. I smile every time I fail to wire a real image...

You can also drag and drop the icon of one vi to another vi without copy/paste. No keystrokes required... (front panel to front panel)

Where's the LAVA "Me Too" button? Mel Brooks may have a few words he'd like to share with you...

Here are a couple of VIs I wrote for a tool that used the MCL. The first iterates over the MCL ItemNames to determine the max width. It looks at each cell's formatting to see if font customization have been made. Use the output to set the widths (AKA autofit width). MCL Get Max Col Widths.vi The second colors the rows with alternate colors. MCL Set RowColors.vi The assumption is that you have already deferred panel updates. These could probably be optimized, but they worked for my project.

Combined with the Variant Configuration File VIs, you could persist an operator's preferences without a separate "configuration options" screen.

I noticed this post on the dark side instructing someone to look into OpenG. The openg.org URL at this point is confusing, and also seems to be contaminated with spam. In order to help new folks find and use the OpenG libraries, I think a new URL is needed. Maybe something as simple as a pinned topic in this section on LAVAG. Just sending folks to OpenG.org is not going to "spread the goodness"

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.

For basic architecture and programming techniques, I still like "A Software Engineering Approach to LabVIEW". It predates event structures and LVOOP, but makes you think about the same sorts of issues such as loose coupling and strong cohesion. These same ideas apply to database design. http://www.amazon.com/Software-Engineering-Approach-LabVIEW/dp/0130093653