bmoyer

Thanks, I was not aware of that bug (but I'm not using 2012 much yet anyway). Post 18 on that thread says there's a workaround, but I'm not sure what it exactly means. Anyway, I'll wait for the update.

Win 7 has some unexpected rules when it comes to the ProgramData folder, you can create and modify files (and folders) but if you switch users, they only have read access. So for this I have my installer create the folder where I will be storing the modified ini (by creating a new destination [Public App Data]<Company Name><Application Name>), and set the folder to unlocked.

What I do is I look for an ini file for my application in the COMMON_APPDATA folder (for Win 7 it's usually C:ProgramData<CompanyName><ApplicationName>) and if the file is not found, to copy it from the location of the exe to this location. That way, if they make changes to the default configuration, the changes are stored in the AppData folder. In the VI that reads the .ini, I have a the default settings stored, and if I happen to make a new setting or section, the new settings are created automatically in their copy of the ini but they get to keep all of their previous settings. I use the OpenG Variant Configuration libraries to handle creating ini's from clusters. Attached is a simple example. Bruce ini example.zip

...with attributes. http://zone.ni.com/reference/en-XX/help/371361H-01/lvwave/set_waveform_attribute/

It looks like a bug to me too (unless I'm not understanding the Scan Variant from String function correctly). Bruce

Using systemfontsPlay.vi as a starting point I made a VI that will determine all of the fixed-width fonts. It's slow but it seems to work. For your application you could have 2 hidden indicators (one with "iii" and one with "www") set to the system font and see if they're the same size using the Label.Width property. Bruce Find Fixed-width Fonts.vi

When using an exe, the VIs that are dynamically loaded need to have their compiled code in them in order to work. I have a program that loads a VI based on the header of a data text file and the VI won't load unless it has non-separated compiled code in the VI.

No issue here (on a Dell Precision T3500 64-bit Win7, LV2011 SP1).

This might be slightly off topic, but is there a 64-bit compatible version of this ZIP library? I really like the ability to extract a single file and the ability to save to a zipped string (I don't think NI's toolkit has this yet), but since everything's moving to 64-bit here, I had to change over to the NI ZIP libraries which are a lot more cumbersome. Thanks, Bruce

Glad to hear you were able to get some resolve on this problem. Sometimes what is perceived to be a serious short-coming of LabVIEW is really only a short-coming of our perception...but sometimes not.

Is this what you're trying to do? Bruce Output Intensity Graph.vi

I think I've uncovered the/my error. Apparently when converting to LV2011 I ended up with a space in the File Type value string ini header which was causing the ini file not to load properly because it didn't know that format of the file. The file seems to load properly now (after removing the trailing space) even with all of the quotes (at this point I don't know if other programs that were developed in 8.5 will be able to handle the change).

I'm in the process of updating some code to LV2011 (from LV8.5) and most of the updating went relatively smoothly (I've tried updating to newer versions (8.5->8.6.1, 2009) in the past and this time the process seems a lot better). Anyway, I'm noticing some differences with writing to .ini files (using Write INI cluster__ogtk.vi) and I was hoping that someone already had some experience dealing with this. The old format (LV8.5) only had quotes (") around strings that had spaces, and now it seems like every saved value has quotes around it. Even numerical values. This is causing some issues loading the file back in to a cluster since the enum/numerics are being translated as a string. Also it is incompatible with other programs which load ini files. Old Format (8.5): [Acquired Images] File Type=2 Images.<size(s)>=0 Relative Path="Acquired Images" New Format (2011): [Acquired Images] File Type="2" Images.<size(s)>="0" Relative Path="Acquired Images" Any ideas as to how to fix this? Thanks, Bruce LV85 Header.txt LV2011 Header.txt

JobDescription Position open for our Princeton, NJ office Summary: ISR Systems Princeton (formerlySensors Unlimited Inc) is the leading developer and manufacturer of indiumgallium arsenide one and two dimension focal plane arrays and cameras. Ourproducts have diverse applications in telecommunications, process/qualitycontrol, fiber optics inspection and military imaging industries. For additionalinformation on our business, please visit our website: www.sensorsinc.com. Develop and establish reliability of component parts, assemblies, and systems.Develop and maintain automated test system fixtures and test programming.Ensure that electronic designs are in conformance with company, customer,reliability, and safety standards. Enable modifications in the design toimprove yield, meet production and customer needs, and maintain the highestreliability standards. Get involved with debugging new system designs andperforming failure analysis on any returned systems. Resolve problems of amoderate scope and provide technical assistance to manufacturing and salesorganizations. BSEE required. MSEE preferred. 3~5 years electronics industry experience.Experience with electronic manufacturing processes and automated test systems.Significant experience implementing complex test and development procedureswith at least one of the following: LabView (preferred), Visual Basic, or C++.Experience with NI TestStand and/or JTAG test systems a strong plus.Demonstrated capabilities in failure analysis and troubleshooting electroniccircuits to the component level. Familiar with commercial electronicmeasurement and test equipment and in reading and understanding printed circuitboard schematics and firmware code. Essential responsibilities involve: • Developing Test Methods and creating test fixtures for testing camera basedsystems • Designing and implementing hardware, firmware, and software to test electronicprinted-circuit-board based systems • Transition to Manufacturing & Manufacturing Engineering Support • Performing Debug of new Electronic Platforms and Failure Analysis of anyreturned devices BasicQualifications : Four year degree in ElectricalEngineering. Masters degree is preferred. Requires 3-5 years of experience. Experience should be in testing integratedcircuits as well as designing probe cards/test stations for ICs and testing ofoptoelectronic devices. Please use the LAVA Forums PM (Personal Message) system for any inquiries.

Could you try this VI? I now realize that the issue was with when I turn anti-tearing ON. It works fine with anti-tearing OFF. (Anti-tearing is useful for preventing streaking that occurs when the image refreshes when the screen is in the middle of a redraw). Bruce IMAQ WindDraw Multiple Monitors Test (v2).vi

I don't know how it happened, but when I completely closed LabVIEW and restarted, and just ran the VI it works now! It was an odd behavior, if I see it again I'll let you know. Thanks, Bruce

I posted this to the NI Forums but I was hoping to get more input. I'm trying to develop an application using IMAQ drivers that displays the image fullscreen onto either the primary or a secondary monitor display. It works fine when operating on the primary window, but when I put the window on the secondary window it doesn't update. As an additional test, when I put half the window on 1 screen and half on the other, the part that is on the primary display updates while the part that is on the secondary display does not. Any ideas as to how to get this to work on the secondary monitor? Is this a coding error or a bug? (I've included an example VI to demonstrate the problem.) I'm developing using NI-IMAQ 4.5 with LabVIEW 8.5. Thanks, Bruce IMAQ WindDraw Multiple Monitors Test.vi

I was successful at implementing a .NET call. I've attached the VIs to do this. So that the dialog is associated with your GUI, there's inputs for the "Ref to GUI" and "Make This VIs Front Panel the Parent?". Bruce Win Font Dialog (.NET).zip

I was able to get it to printout properly by removing a surrounding front-panel decoration.

I'm in the process of making a VI that can printout a report that show barcodes that the user can use to scan for other purposes. I'm using the VI Invoke Node "Print.Panel To Printer" and for some of the controls it looks like it is printing out in full resolution true type, but for others it is printing using the screen resolution. Attached is a PDF of the problem. You can see it more clearly if you zoom. Why do you think this is occurring? (I'm using LabVIEW 8.5 if that matters, has this been fixed in a later version?) Thanks, Bruce Barcodes.pdf

Thanks for your input. Yes, that's what I was thinking. Just using the Fonts folder filenames doesn't work. You need the actual font names. I would think that this functionality would be "built-in" to LabVIEW by now. I guess I could try looking into using .NET methods to do this (this is how I implement a print dialog), but not sure if this will be easy or not. I think the Report Generation Toolkit used to have a way to open a font dialog (Report_Font_wizard.vi), but this is disabled and when I try to enable it gives an error (Class is not licensed for use in Report_Font_wizard.vi->Set Report Font.vi->Untitled 1.). Bruce

I'm trying to create/access a dialog to allow the user to select which font they would like to use so that I can then change some front panel controls based on their selection. Does anyone know how to do this? Thanks, Bruce

Oh, sorry about the misunderstanding, I assumed that since you knew it was from the OpenG toolkit that you had some experience with it. I got confused when you continued asking about it after I stated that it wasn't needed for the functionality of the VI. Sorry 'bout that, Bruce

I think you're making a mountain out of an mole hill since this isn't a required VI, but the VI finds the largest decoration on its caller's front panel and then fits the window around the decoration. The 0 argument refers to the border around the decoration. Bruce

Make your own OpenG substitutes. Develop VIs with the same functionality needed. There's only 1 OpenG VI anyway and it's not really even needed.