LabVIEW 2009 Bug: Listbox Scrollbar Size Setting Lost Upon Saving VI

Please do the following to recreate the problem:
1. Drop a list box
2. Customize the listbox by going to Advanced -> Customize
3. Make the scroll bar bigger.
4. Go to the block diagram and create a property node of the control.
5. Save the VI.
6. Re-open the VI.
7. The scroll bar resets itself to original size.
The problem occurs only when there is a property node. It is very annoying. Is there a way to control the scroll bar size programmatically so we can work around this bug?
Thanks!

Ian,
I just accidently posted the below to the other thread referenced. I'm reposting it here as well:
I first reported this behavior (well, alright, I was using a table control/indicator, not the MCL) back in LabVIEW 8.0. The discussion thread can be found on the LAVA forums, starting September 14, 2006. In that discussion, Scott Menjoulet and jhoskins seemed to be able to work around it with the "custom control in a project fix", but I could never get that to work, at least not when I built the custom table into an executable. I filed a bug report on the next beta cycle, but I can't find my old bug reports/CARs online anymore.
But I'm reasonably certain it's been an identified bug since 8.5.
Dave
David Boyd
Sr. Test Engineer
Philips Respironics
Certified LabVIEW Developer

Similar Messages

Is this a bug? master rowid value lost when saving on a master/detail form

master/detail forms seem to lose the rowid after saving, if the unique identifier is set to ROWID
to reproduce the problem:
1) create a master detail form on DEPT/EMP
-- choose 'Managed by Database (ROWID)' on the 'Define Primary Key' page.
-- do not include master row navigation (but i don't think this matters)
-- choose 'Edit detail as tabular form on same page' on the 'Choose Layout' page
-- include the master report
2) on the master/detail page, change the conditional branch that returns to the master report page
-- the normal condition for this branch is request in SAVE,DELETE,CREATE
-- change it to request in DELETE,CREATE
3) run the form and save a change
-- saves fine, session shows the ROWID value is still set
4) save a second change
-- change does not save, form reverts to Create mode
this problem does not occur when using the primary key columns instead of rowid
see http://apex.oracle.com/pls/apex/f?p=60813:7 for the ROWID version
see http://apex.oracle.com/pls/apex/f?p=60813:11 for the PK column version

Hi Saverio,
Bug *13563808* has been logged to track the reported issue, and a fix will be made available in a future release. Just to clarify, this issue is only arising when the APEX-generated Master-Detail is modified post-generation, so for users who have not modified their Master-Details using ROWID to manage their DML processes, they should not experience this issue.
In relation to my workaround, my suggestion works in my test environment, which I verified before posting the initial suggestion. Please note that the 'Reset Page' process is, by default, conditional on the "Delete" button being pressed. If you have made further modifications to your Master-Detail page, then this might explain why you're seeing different behaviour to me. You might using the "Debug" option on the Developer Toolbar useful. Viewing the debug information should help you to decipher what's going on/wrong on your page. If you still can't resolve the issue, then the safest option might be to revert the page back to it's original state, meaning the user navigates back to the Report page upon submitting changes to the Master-Detail Form page.
Regards,
Hilary

Bug? LabVIEW 2009 Enum in Datalog Refnum Loses Data in LabVIEW 2010+

Hi
Can I please get support from an AE?
Attached is a LabVIEW 2009 VI with a Control of an Enum in a Datalog Refnum.
Whereby the Enum's FP Object is represented as an image.
In LabVIEW 2009 this works fine however, in any higher version (I have definitely tested with LabVIEW 2011, but have been told LabVIEW 2010 is the same) the image is blank.
Is this a bug - is data being lost?
Interestingly enough, if I remove the LabVIEW 2009 Enum from the Datalog Refnum then load in LabVIEW 2011 this image displays correctly.
Is there anything I can do (setting? etc...) in LabVIEW 2009 that will correct this problem so it displays correctly in later versions?
This issue originated in this LAVA thread.
Cheers
-JG
Certified LabVIEW Architect * LabVIEW Champion
Attachments:
Datalog Refnum Enum_LV2009.vi ‏10 KB

This was reported to R&D (# 311354) for further investigation.
As a possible workaround, if you move the enum control out of the datalog refnum before saving in LV 2009, when you open your VI in LV 2011 the image will still show up for the enum control. You can then move the enum control back into the datalog refnum and it should work fine.
Thanks for the feedback,
Daniel H.
Customer Education Product Support Engineer
National Instruments
Certified LabVIEW Developer

BUG: LabView 2009 WebServer crash

Here is a simple VI containing no controls, functions or libraries in LabView 2009 f3.
WebServer
settings are default. After Tools->Web Publishing Tool operation
from other PC we are connecting to this panel (IE6 for example) and
putting a finger to F5-button not raising it.
Web page with the VI is refreshing continiously.
There are 3 results.
1. In DevEnv: LabView die.
2. In DevEnv: Need to restart LabView so WebServer reloads and connection restores.
3. In App.exe: die
4. In App.exe: LabView interpreter loose some while-cycles in case they exist but connection stored.
5. In App.exe: connection lost but the application working good.

Link to original post
Justin Parker
National Instruments
Product Support Engineer

Font size on Windows 7 with LabVIEW 2009

Hello,
after installing labview 2009 on windows7, I have a problem with the font size of my old application written in 8.6.
the Application Font has seemed to default to another style under windows7 so I searched the forum for the default font under XP when I used lv 8.6. Tahoma 13pt seemed to the correct choice, however when i changed all default fonts to Tahoma 13pt it helped and they look very similar, but the Tahoma under windows7 is slightly longer that the original and it looks like there is some sort of font smoothing going on... perhaps windows is doing its "cleartype" thing by default and influencing its length (thou i thought this shouldnt be the case).
This small difference is causing havoc in my GUI as objects are being resized in a bad way.
Please see the screenshot for an example of my concerns
Another question on the side... is there a Font I can use that will keep the appearance and size over all OSs?
Any help would be appreciated...
Best Regards
Alex.
:. LV2010 SP1 ... W7 .:
Attachments:
Font Difference.png ‏3 KB

Actually this problem affect LabVIEW itself even while editing!
Many of NI's screens suffer from the same problem. Configuring events is one of the most obvious cases. Since teh edit events screen does not allow for resizing, there are some events that you can only guess what they are.
I tried reporting this but the AE wanted me to spoon feed screen shots and ....
I think what really irks me over this problem is that I purchased a laptop with the biggest screen available just to let me do LV and in the end LV can't handle the laptop.
Double -
Ben
Message Edited by Ben on 05-06-2010 10:13 AM
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Error when trying to set up OPC I/O server with LabView 2009

Hi.I get an error when I try to set up OPC I/O server with LabView 2009 and the DSC module. If I open an empty project, right click ”My Computer”. Select new / I/O Server… and then OPC Client, the following error appears: Unable to browse OPC Server from the selected machine.Error -2147467262 occurred at GetOPCServerList.viPossible reason(s):LabVIEW: (Hex 0x80004002) No such interface supported. I have tried to repair LabView, but with no luck. Any idea what it could be?

The problems are not related to each otherOk then. Lets try getting this solved. Lemme dig......

Potential Bug with LabVIEW 2009, Report Generation Toolkit, and MS Office 2003

We have discovered an issue with the above listed software. Specifically this pertains to Print Report.vi in the Report Gen palette. Basically, we have discovered that with Office 2003 installed the VI will error out. We've been using it in an executable, and the executable physically fails (and asks us to report an error to Microsoft). With Office 2007 we don't have a problem. We've tried building the examples into executables, and those work because they are printing HTML reports.
Also, we have converted back to LabVIEW 8.6 and rebuilt the executable and installed and it works perfectly. Its on the combination of LabVIEW 2009 and Office 2003 that seems to fail.

yeah, we had seen that, and been told about it by another user. we tried, to no avail. we still have ended up having to migrate back to 8.6.1 to get the executable to run properly.

Run-time engine problem in Labview 2009 and Labview 2010

I have a problem with Labview 2009 and Labview 2010. I updated my Labview 2009 into 2010. But it turned out to be a trial one, because i did not have the serial number. So I uninstalled the Labview 2010. however, the funny stuff came over. I cannot use my Labview 2009. So i uninstalled Labview 2009 again. But eventually, I could not reinstall Labview 2009. Every time i had a runtime error and i could not proceed with the installation. in addition, any installation related to Labview is not permitted and the same error came up every time. it is very annoying.
So, What is the deal?
I attached the error here. Any comments or advice are welcomed and appreciated.
Attachments:
error.docx ‏2305 KB

By chance is this machine's language set to any non-English locale? You would check the locale setting by:
Opening Control Panel.
Opening "Regional and Language Options".
Looking Under "Regional Options" >> "Standards and Formats"
If it is set to something besides English, trying setting it to English and please report back what locale it was set to (or if this even solves the problem).
Regards,
- WesW

Migrating large project from DSC 7.1 to LabView 2009 Shared Variables ... What's the next step after recreating my variables?

I am in the process of migrating a large distributed (multi-workstation) automation system from the LabVIEW 7.11 DSCEngine on Windows XP to the LabVIEW 2009 Shared Variable Engine on Windows 7.
I have about 600 tags which represent data or IO states in a series of Opto22 instruments, accessible via their OptoOPCServer. There are another 150 memory tags which are used so the multiple workstations can trade requests and status information to coordinate motion and process sequencing. Only one workstation may be allowed to run the Opto22 server, because otherwise the Opto22 instruments are overwhelmed by the multiple communications requests; for simplicity, I'll refer to that workstation as the Opto22 gateway.
The LabVIEW 2009 migration tool was unable to properly migrate the Opto22 tags, but with some help from NI support (thank you, Jared!) and many days of pointing and clicking, I have successfully created a bound shared-variable library connecting to all the necessary data and IO. I've also created shared variables corresponding to the memory tags. All the variables have been deployed.
So far, so good. After much fighting with Windows 7 network location settings, I can open the Distributed System Manager on a second W7/LV2009 machine (I'll refer to it as the "remote" machine henceforth) and see the processes and all those variables on the Opto22 gateway workstation. I've also created a few variables on the remote workstation and confirmed that I can see them from the gateway workstation.
Now I need to be able to use (both read and write) the variables in VIs running on the remote workstation machine. (And by extension, on more remote workstations as I do the upgrade/migration).
I have succeeded in reading and writing them by creating a tag reader pointed at the URL for the process on the Opto22 gateway. I can see a way I could replace the old DSC tag reads and writes in my applications using this technique, but is this the right way to do this? Is this actually using the Shared Variable Engine, or is it actually using the DataSocket? I know for a fact that attempting to manipulate ~800 items via Datasocket will bog down the systems.
I had the impression that I should be able to create shared variables in my project on the remote workstation that link to those on the Opto22 gateway workstation. When, however, I try to browse to find the processes on that workstation, I get an error saying that isn't possible.
Am I on the right track with the tag reader? If not, is there some basic step I'm missing in trying to access the shared variables I created on the gateway workstation?
Any advice will be greatly appreciated.
Kevin
Kevin Roche
Advisory Engineer/Scientist
Spintronics and Magnetoelectronics group
IBM Research Almaden

I have found the answer to part of my question -- an relatively easy way to create a "remote" library of shared variables that connect to the master library on my gateway workstation.
Export the variables from the master library as a csv file and copy that to the remote machine.
Open the file on the remote machine (in excel or the spreadsheet app of your choice) and (for safety's sake) immediately save it with a name marking it as the remote version.
Find the network path column (it was "U" in my file).
replace the path for each variable (which will be either a long file path or a blank, depending on the kind of variable) with \\machine\'process name'\variable name
where machine is the name or ip address of the master (gateway) workstation (I used the ip address to make sure it uses my dedicated automation ethernet network rather than our building-wide network)
and process name is the name of the process with the deployed variables visible in the Distributed System Manager on the gateway machine.
NOTE the single quotes around the process name; they are required.
The variable name is in the first ("A") column, so in Excel, I could do this for line 2 with the formula =CONCATENATE("\\machine\'process name'\",A2)
Once the formula worked on line 2, I could copy it into all the other lines.
Save the CSV file.
Import the CSV into the remote library to create the variables.
Note: at this point, if you attempt to deploy the variables, it will fail. The aliases are not quite set properly yet.
Open the properties for the first imported variable.
There is probably an error message at the bottom saying the alias is invalid.
In the alias section, you'll see it is set to "Project Variable" with the network path from step 4.
Change the setting to "PSP URL" with the same path and the error message should disappear.
Close the properties box, save the library, and then export the variables to a new CSV file.
Open the new CSV file in Excel, and scroll sideways to the NetworkrojectBound field.
You'll notice it is False for the first variable, and true for the rest. Set the field FALSE for all lines in the spreadsheet.
Scroll sideways... you'll notice there are two new columns between NetworkrojectPath and Network:UseBinding
The first one is NetworkingleWriter; it should already be FALSE for all lines.
The second one is Network:URL. That needs to be set equal to the value for each line of NetworkrojectPath.
You can accomplish this with a formula like in step 4. In Excel it was =U2 for line 2, and then cut and paste into all lines below it.
There is a third new field, Path, which should already be set to the location of the variable library. You don't need to do anything with it.
Save the edited CSV file.
Go back to the remote library, and import variables from the just-edited remote library CSV file.
Once you have imported them and the Multiple Variable Editor opens, click on done.
You should now be able to deploy the remote variable library without error. (Make sure to open the Distributed System Manager and start the local variable engine. It took me a few failures before I realized I had to do that before attempting a deployment).
Voila! You now have a "remote" library of shared variables that references all the shared variables on the master machine, and which should be deployable on other machines with very little difficulty.
It actually took longer to write out the process here than to perform these steps once I figured it out.
Kevin Roche
Advisory Engineer/Scientist
Spintronics and Magnetoelectronics group
IBM Research Almaden

LabVIEW 2009 SP1 Run-Time Engine (Minimum) (32-bit) for Windows - Supported Features

Hi,
Can some one please point out what features are supported by the LV RTE (Minimum ) [LabVIEW 2009 SP1 Run-Time Engine (Minimum) (32-bit) for Windows]
1) Is there a limit on the size of the exe which can be run on it?
2) Will this support additional modules like DAQ etc.,? Or do we have to chose the regular installer ( 170 Mb ) for that purpose?
3) If a list of what it does or does not support is available, it would be extremely helpful.
Thanks In advance.
Regards,
Vijay

Anand,
I did go through both the links that you had sent earlier before posting on the forum. For eaxample refer the following link where it says,
http://joule.ni.com/nidu/cds/view/p/lang/en/id/1599
It does not contain the full run-time engine, but will allow some executables to run.
1) What do they mean by 'some' executables. Is there a list of yay's and no's available?
2) Can someone from NI reply to this and shed more knowledge?
Regards,
Vijay

Enum in a Typedef Reverts to Default (LabVIEW 2009)

When I add additional items to a typedef'd enum, constants of that enum on some BD's revert back to the default zero index enum value. In the past (8.6.1 and previous), adding items to an enum in no way would ever change constants that were already dropped on a BD. Now, in LabVIEW 2009, when I add items, about 60-70% of the constants dropped on different block diagrams will be changed to default value.
This happens in a "large" enum (~400 elements) that spans about 3 dozen VI's between RT and HMI block diagrams (a total of about 300 instances). This is a mature project that has never had this problem with 8.2, 8.5, 8.6, or 8.6.1...
I cannot post an example, because in the process of stripping down the VI, the problem goes away. It is extremely repeatable in the context of the project, but I cannot repeat it on an individual VI basis.
The current workaround is to edit the typedef'd enum while all referencing VI's are in memory. If the VI's that use the typedef are in memory, they will always properly recompile and maintain the correct constant value. However, if the VI is not in memory, and the typedef is changed, the next time the VI is opened, when it recompiles it will change the constants back to the zero index default value of the enum in only about 60-70% of VI's. Unfortunately, we cannot yet find a common thread in the VI's that recompile wrong, and the ones that recompile correctly.
Has anyone ever seen this problem? Suggestions?
Best regards,
Jack
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}

We just realized a flaw in our "workaround", as partially pointed out by Ben (he was probably typing his response as we were confirming it here). If the constant is inside of a cluster on the BD, even if it is in memory, it will null out the enum inside of the constant. Therefore, the "workaround" is to rewrite the clustered enum constants from scratch (in other words, there's no workaround). Two of us spent a decent portion of the morning finally nailing this as the source of what we thought was an unrelated bug... and that's after spending a long day yesterday trying to find a fix. Yes, we feel Ben's angst of reverting back to previous SCC editions and manually editing dozens of VIs.
The severity of this bug is a showstopper for us. We cannot risk adding elements to an enum and consequently have referencing VIs changing their constants.
Force compiling a VI one at a time is not an option for us. I know this bug manifests itself even after a mass compile. So, is there a way to "mass force re-compile" that we could test?
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}

Error in ni visa control out for usb in labview 2009

Hi,
I am using labview 2009 in which i have made a vi which communicates with a pic controller through USB interface.
the vi is working fine in labview 8.6. I tried it in two PCs. but when i run that vi in a PC with labview 2009 then the VISA CONTROL OUT.vi gives error "0xBFFF003E : Could not perform operation because of i o error.". while the control in.vi works fine in both the labview versions and any other PC that i tried.
I have run the application in total of 4 PCs with same set of cards/interfaces. two of them having labview 8.6 are running fine and giving no error but other two with labview 2009 are giving error.
and it doesn't stop here.... i searched in the vi and did some experiment and found that when i give Request value input to control out.vi as "0x36 "(as required by my PIC program) then it is giving error but when i give other value such as " 0x35 or 34 or 55"(used for other purpose) then it is not giving error.
Can it be a PIC programming problem? (i dont think so as everything is fine in other PC with LV 8.6)
I have already explored the ni forum for this error solution but could not find helpful.
Can anyone solve my problem?

I installed labview 8.6 in that machine and made a small program with only 3 vis (visa open session, visa close session and visa usb control out.vi) which is working in LV 8.6 platform.
Sorry the above statement is not correct actually.
When i run the program in LV 8.6 it giving that same error but this time it is not displayed as pop up window. so i could not judge that error was still there.

Excecutable VI generating an error 222 on Keithley 2612A although its run properly when starting from labview 2009 directly

Dear all,
I have a VI which runs perfectly and I can control, a Keithley 2612A for transistor measurements.
The VI run well when I excecute it from the computer which has the platform Labview 2009 (XP OS)
The equipment (ie Keithley 2612A) is linked to another computer which don't have labview 2009.
I installed Run-time-engine 2009 (OS XP 32 bits) on this computer.
Then I create an excecutable of my VI with the "build application" option.
The excecutable VI starts normally on the computer but when I want to run it, I am getting an error message from the Keithley 2612A (which was not the case when I ran the VI directly from the computer haing Labview 2009 installed on it). The error message is 222 (ie parameter too long)
I thought that I did something wrong and I create an excecutable from an original VI from Keithley (ie without any change). I am getting the same error message.
When I create an excecutable with run time engine 2009 included (as it is possible to do it wiht LB 2009) , I am geeting the same error message.
So I need no to check step after step when the message happens but
Does anyone knows anything about such an issue ?
Thank you
Solved!
Go to Solution.

Dear all,
Just for those who might encounter a similar issue.
I found the solution after tackling all possibilities.
The source of the problem was (for unknown reason) that the country setting of the computer was wrong
and decimal numbers were written with a , instead of a point.
Since I reset correctly the country setting, the stand alone files are running normally.
Best regards
Youki

Switch executive stops working after labview 2009 installation

Hi, After I've installed labview 2009 my old switch executive virtual device routes stop working in such a way even if I try to set a route from switch executive test panel the attached error message pops up.
I am using:
Labview 9.0.1
TestStand 4.2.1
Switch Executive 4.6.2
Many Thanks in advance
Mehran Fard
Mehran Fard
Attachments:
niSE.png ‏11 KB

Hi Fardm,
I might try doing a repair on LabVIEW, TestStand and Switch as it sounds like a dll might have become corrupt.
Kind Regards,
Owen.S
Applications Engineer
National Instruments

LabVIEW GUI Bug? - Try and post yours as well

While answering for a question I was playing with the Event structure and I saw the Find Control option when I right click that structure. Here is what I did after that
Selected the Find Control and it took me to the front panel showing a big box kind of selection. Out of curiosity I pressed down button along with shift and also up button I got a wiered screen and I have attached it here. I am using LabVIEW 2009 so is it happening in this version or is it still there in 2012 and other versions?. Who ever has higher version can do the same step and post what you got.
The best solution is the one you find it by yourself
Attachments:
Bug.PNG ‏90 KB
Bug 1.PNG ‏80 KB

The same happens in 2011.0. This is moving the pane of front panel out of the window somehow. When I resize window, everything going back to normal.
Using horizontal splitter I've even managed to add some "cinematic" feel of the front panel

LabVIEW 2009 Bug: Listbox Scrollbar Size Setting Lost Upon Saving VI

Similar Messages

Maybe you are looking for