Ignoring these shortcomings, it appears to not behave as expected: when selecting View>>Always Show Labels, collapsed library boxes expand laterally as if to accommodate the library label, but no label is displayed. I am labeling this as a bug, but maybe it isn't.

Similarly, a library is represented by said box with an icon inside. The icon seems to be picked up randomly from one of the VIs in the library. This is not helpful. There should be a way to set a "library" icon (not just a template as defined in the library "Properties" window.

Tested in Windows LV 2021 SP1 64 bit

Build-Transpose-Build sequence resulted in a non-empty array. This appears to be infinitely extendable (i.e. adding more transposes and builds increases the size of the 'Empty' output array)

- Joel

Feed an array comprised of non trivial equal numbers (e.g. a 1,000 values of 1.2345) to the Std Deviation and Variance.vi of the Mathematics>>Probability & Statistics palette and look at the standard deviation output using a display format such as that shown below:

You will be surprised to see that the standard deviation is non zero and within the range of the precision for the type (~1E-15).

While this might not be an issue in most use cases, it is still not an optimal result, and suggests that the calculation done in the called DLL is not optimal (it probably uses the standard formula, but because of round-off errors, the outcome is non-zero).

I am posting this in the "bug" category, although it is not strictly speaking one, just to warn unsuspecting users (like me), that dealing with floating point numbers comes with its load of gotchas.

Here is a snippet to experiment with the phenomenon:

Again the display format of the standard deviation indicator needs to be chosen wisely to reveal the round off error.

The above formula works fine. If I want to check the value of the Boltzmann constant by adding an indicator where indicated:

Things look fine but they are not:

tested in LV 2021 SP1 64 bit

I have a main VI that start a spawn which mission is to execute code after a some delay :clock: (ex:2s). The spawn is start when the "VI:Mouse leave" is triggered.

Now, if the user re enter the VI before the delay :clock: expire (ex: before 2s has elapsed), I do no longer wish to execute the code, so I kill my spawn using VI:Abort.VI method.

As long as I do not kill my spawn, everything work like a charm, but as soon as I kill my spawn, "VI:Mouse leave" and "VI:Mouse enter" events are generated (?!?!!?) :thumbdown: and I am entering an infinite loop because in "VI:Mouse leave" I generate the spawn and in "VI:Mouse enter" I kill it which generate VI:Mouse leave ....

If someone could confirm this (or even better prove me wrong) that will be great.

System: Win2k with LV7.0

Attached is some code that will demonstrate the issue

Download File:post-16-1079896891.zip

https://www.ni.com/en-us/support/documentation/bugs/22/labview-2021-sp1-known-issues.html

Here is the output:

No better luck with long messages:

here is the result:

notice the "Standard" added to the text.

Windows LV 2021 SP1 64 bit

According to the help, which I paste here for the record:

b is the scale parameter and c the shape parameter of the Gamma distribution.

However, if you do that, the generated RV are bogus, because it turns out that b is the shape parameter and c is the scale parameter, as defined for instance on Wikipedia:

This can be easily verified by generating a large number of RV and comparing their normalized histogram with the functional form above.

Tested in LabVIEW 2021 SP1f3 on Windows 10 64 bit

No comments and couldn't care less whether it is fixed or not.

Run.

The Open Session Node transmits the warning (so doesn't generate an error) but the following Python Node converts the warning into an error (same code, TRUE status and source = Python Node in Calling VI name).

That is unexpected.

The error constant is just here to provide a cluster input to the node (which is what the "Marshal to Named Tuples" is supposed to handle).

The Always Copy node is here to go around the known problem that the comment arrow will snap to the middle of the wire it is attached to, NOT where the user connects it to the wire (and that of course will never change).

The comments indicate that the first node input (which happens to be the return argument, but that has no bearing o the observed behavior) has been right-clicked and "Marshal to Named Tuples" was used.

By contrast, the second node input has had no modification applied.

The result (surprising to me) of the "Marshal to Named Tuples" option was that the wire broke, as if the node lost its ability to "read" the cluster element names. Obviously no such thing happens when making a copy of anything (you can still hover over the lower branch of the wire with a probe and the Help window will show all 3 cluster element names).

I am erring on the side of calling this a bug, but it might just be some kind of arcane feature of the node which only its author is familiar with (and I don't really whether or not it changes in the future since I am dug in 2021 SP1).

But here it is for every one to gawk at.

I'm trying to pinpoint a bottleneck in a new process I wrote, but I'm seriously questioning the results here...

The numbers for those four VIs do not change over the lifetime of an execution, or if I execute the application multiple times within the same instance of the IDE. If the IDE is restarted, some of the VIs will return the same numbers, others not so much.

Also, some of the more reasonable looking large numbers, like the VI which has reportedly been executing for 179 seconds are definitely wrong, as the application had been running for less than a minute.

Some clues as to what might be going on:

• These VIs with astronomically large metrics fall into one of two categories: they are VIs which are responsible for spawning asynchronous tasks; or are VIs which contain the main loop for asynchronous tasks. Note the later VIs are reentrant.
  
• I can start a new async task, and the new main loop VI will show up in the list a very similar large number.
  
• Not all of these async tasks however show up with huge numbers. Some which are always spawned as the application start up do not show this behavior (but others do).
  
• These async tasks are launched via the async call by reference primitive.
  

Maybe this is old news with timing reentrant/async methods, or is there something else afoot?

-m

Since the NXG style plot legend scrollbar is buggy (see this report and the linked thread), providing this index display as a backup for users to navigate the plot list in the absence of a mouse wheel, is not elegant has its visibility cannot be controlled (AFAIK).

It is still present in LV 2021 SP1.

• LabVIEW has issues with images from other applications in the clipboard. When I have something copied from KolourPaint (an open source MSPaint clone) LabVIEW will often crash, sometimes immediately, sometimes not until I try to paste it. (This happens immediately after launching it as well.) From other applications I've tested, LabVIEW appears to ignore the image entirely. If something other than an image was in the clipboard before the image, it'll paste that; otherwise, Paste will just remain disabled as if the clipboard were empty.
• A lot of times, I'll select a custom control using the "Select a Control..." right-click menu item, and it'll display the outline of the control for a split second, but then it'll go away as if I pressed Esc. I don't recall whether this has happened with subVI's, but it's possible. (edit: it just did, so yes.)
• Sometimes, often when I drag something on the block diagram, wires will suddenly move to illogical locations. One place where I've noticed this often is with tunnels on the bottom edge of a structure, where the wire will suddenly arrange itself so it connects from the left instead (while the tunnel remains on the bottom.)
• The audio input/output VI's don't work, instead saying the selected device is invalid. (This does not include the audio file ones, which work as expected.) Trying to place an "Acquire" or "Play Waveform" Express VI shows no detected devices in the dialog, and if I click OK anyway, LabVIEW crashes.
• Dragging and dropping files into LabVIEW does not work; instead, the files go to the window behind the LabVIEW window.
• I'm not sure whether or not this is actually a bug, but whenever LabVIEW opens a file dialog, it uses the crude built-in one, like in the Windows version when you select an LLB, instead of the normal system dialog. (If anyone knows of any way to replace the dialog with a custom VI, that would be great.)

I'm using Arch Linux with KDE Plasma, in case it helps.

As it turns out, Unflatten From JSON breaks on NUL characters, even though Flatten To JSON properly encodes them as ("\u0000").

I have confirmed the behavior in LabVIEW 2017, 2019, and 2020 (all with latest service packs and patches), currently waiting for confirmation by NI.

Workaround: Use JSONtext

You have a VI with at least one horizontal splitter. In each pane you have an object set to fit to pane (scale object with pane). (for example, a multi-column listbox).

The user maximizes the screen. They then move the splitter bar that separates the upper and lower panes below the previous (un-maximized) bottom of the window. Finally, they return the window to its previous size (by pressing the un-maximize, or restore button). The result is a totally messed up window.

Is there any way to avoid this? See attached VI.

Download File:post-2411-1239747456.vi

Before:

After:

Still there in LV2020

The corresponding VIs are attached.

Formula Node Shift Bug 2016.vi Formula Node Shift Bug 2020.vi

In this example, the set is serialized and de-serialized without changing any data. The code runs in a loop to increase the chance of crashing LabVIEW.

Here is the type descriptor. If you are familiar with type descriptors, you'll notice that something is off:

Here is the translation:

• 0x0008 - Length of the type descriptor in bytes, including the length word (8 bytes) => OK
• 0x0073 - Data type (Set) => OK
• 0x0001 - Number of dimensions (a set is essentially an array with dimension size 1) => OK
• 0x0004 - Length of the type descriptor for the internal type in bytes, including the length word (4 bytes) => OK
• ???? - Type descriptor for the internal data type (should be 0x0008 for U64) => What is going on?

It turns out that the last two bytes are truncated. The Flatten String To Variant function actually reports error 116, which makes sense because the type descriptor is incomplete, BUT it does not always return an error! In fact, half of the time, no error is reported and LabVIEW eventually crashes (most often after adding a label to the numeric type in the set constant). I believe that this corrupts memory, which eventually crashes LabVIEW. Here is a video that illustrates the behavior:

Can somebody please confirm this issue?

LV2019SP1f3 (32-bit) Potential Memory Corruption when (de-)serializing Sets.vi

With video and code.

I would be eternally thankful if anyone could try to reproduce on various Linux RT targets with LabVIEW 2020.

found in LV2019 SP1, if someone could check LV2020, it would be nice.

Error 1122 occurred at Dequeue Element in Process GUI Events.vi:34->Engine 422.vi

Possible reason(s):

LabVIEW: Refnum became invalid while node waited for it.

The wierd thing is, as far as I know, this can ONLY happen if the queue is destroyed in some parallel process while this VI is waiting for an element to be enqueued. But, I have searched all the VIs and the only one where the queue is destroyed is in the cleanup VI that comes after this VI and is connected by the error wire. So, there is no way that cleanup VI could execute before the VI that is waiting.

I have a sneaking suspicion that there are some latent bugs in the queue feature. I have a large number of reentrant VIs running and I create a lot of unnamed queues that I pass inside a cluster to sub VIs. So, there are many many instances of this queue (all unique, supposedly) that exist within each tree of reentrant VIs. I thought labVIEW used a GUID to name unnamed queues so they could never step on each other, but maybe because I have so many, the 'name' is getting reused?

Any other ideas? I am at a total loss.

thanks,

-John

segmentation fault: LabVIEW caught fatal signal 7.0 - Received SIGSEGV.

Reason: address not mapped to object

The quick fix is described in an NI Knowledge Base entry here.

Worked for me!

This VI is executable in LV2019 SP1 f3, which means that you can actually build that into an executable without noticing.

I have reported this, but there is no CAR yet.

This should produce two maps

• <"key", 0>
• <"key", 1>

But the actual output is

• <"key", 1>
• <"key", 1>

As it turns out, Map Get / Replace Value breaks dataflow. There are two workarounds for this issue.

1. Use the Always Copy function
2. Wire the Action terminal of the write node

This was reported to NI with the bug report number #7812505.

There seems to be a bug in the coercion of data to variant when a cluster contains a single element that is a variant. (original post here).

Note: This bug appears to be very old, going as far back as LV2012. This has been reported to NI in the LV2020 Beta forum. I don't have a Bug ID / CAR yet.

Coerce to Variant Fail (LV2019).vi

Note that adding another element to the outer cluster causes the problem to go away.

You can fix it by downloading one VI and replacing the version that ships with LabVIEW. Details here:

https://forums.ni.com/t5/LabVIEW-Shortcut-Menu-Plug-Ins/Bug-Fix-for-ALL-Right-Click-Menu-Plug-Ins-LV2015-to-2019/ta-p/4016064

The bug? Don't close your refnum while you're still using the refnum. *head smack*

And for those of you who tell me that refnum programming is easy, I'm adding this as evidence number N+1 that, "Sure, it's easy... easy to screw up." Long live dataflow! 🙂

I Hope someone can answer my doubts.

have you came across this one before?

https://forums.ni.com/t5/Real-Time-Measurement-and/building-lvlibp-on-real-time-does-not-include-version/td-p/3926789

KR, Benjamin

Maybe others have seen this but I only became aware of it recently so I apologise if there is already a CAR for it.

The following demonstrates a difference in behaviour between LabVIEW 2017 and previous versions (back as far as 2009, maybe further).

The VI registers an event when it starts (in the timeout case) and generates a user event when the Increment button is pressed.

The expected behaviour is that the counter will increment by one every time the button is pressed. This is the case for LabVIEW versions prior to 2017. In 2017, the user event is never fired, nor is there an error emitted by the generate user event.

To get the VI to operate as expected in 2017; change the event refnum tunnel to a shift register. This seems to indicate that the refnum prototype is stomping on the dynamically allocated reference whereas in previous LabVIEW versions it would not. Note also, that when using the shift register, the cases do not need to be "wired through" as would be expected with similar functionality in a normal case statement.

evnt.vi

When you run the attached VI, both Boolean LEDs should output False, but one is False and the other is True.  I'm running LV 2015 f2.

Thanks.   -Joe

Bug demo of In Range And Coerce.vi

Plot area.vi

If you open the VI and run it, then proceed to do multiple window resize events you'll notice the left edge of the plot area slowly marches over. My recommendation is to maximize/restore/repeat a few times to see the effect. Take for example this series of images:

The offending code is simple, I'm setting the scale increment on a resize event:

If the VI is edited such that the property node is removed the behavior vanishes. I wouldn't expect setting this property to cause the issue, I think I smell a bug in here somewhere. Confirmation?

http://screencast.com/t/gfKwlvMcCsHI

The alpha channel is not interpreted correctly when a button is disabled and grayed out.

It should not gray out the part of the control image that is transparent.

Reported to NI. No CAR yet.

The reason why I wanted to make the main VI transparent on startup is because I wanted it to call a splash screen (instead of the splash screen calling the main VI) and the main should then stay invisible (no startup flash either) until the splash screen closes (it would have been great if you could set a VI to open in a hidden state, why have they not added that to the list of options:-( ). There are ways to work around the problem so its no big deal in this case, however it bugged me...so perhaps its a bug(?):-)

m

Here's the issue:

To put it another way, imagine you have a custom event that's wired to multiple event structures. However, not every event structure actually handles the event (i.e. they don't all have a case for it). When you fire that event, it will reset the timeout counter for all the event structures, even the ones that don't handle the event. This means it's possible to have an event structure in your code that never times out, and also never executes an event handler, even though it's got a non-zero timeout value.

This feels like a bug to me for the following reasons:

1. We register for Front Panel events by creating event cases for them, and events that don't have cases don't interrupt the timeout. Why would we not expect User Events to work the same way?
2. It's virtually impossible to detect when this is happening in your code. In the attached example, the event structure looks like it should be timing out, and in a complicated application it's almost impossible to tell why it's not.

However, at the CLA Summit there was some room for disagreement about this. LAVA, what do you think?

Screencast: http://screencast.com/t/qDIKpn9oQnlD

Snippet:

(note the snippet creation made those crazy non-static property nodes on the stop logic; that's not me )

Code (LV2009): Event Structure Timeout Bug.vi

CAR 429636

There is currently no way to build the installer including the application. It is not possible to add the offending VI to the library, as the library is locked & password protected. My solution was to build an installer for just the additional installers (runtimes, etc..) and to manually copy the application files to the target system. Here is a copy of the issue details from the initial thread that is also linked below. Please reffer to the thread to get more detailed information about the circumstances that causes the issue (and to see some actual pictures):

-----

The Automotive Diagnostic Command Set in version 1.2.0 does update the compatibility to LV2013 and adds a new feature that causes my problem.

Add an INI key to the LabVIEW.ini

NI_Appbuilder_logging=TRUE

The build log is created next to the *.lvproj file and directly shows the problem. Here is the important line of the build log:

The file at 'C:Program Files (x86)National InstrumentsLabVIEW 2013vi.libAutomotive Diagnostic Command SetDiagnostic Transport.llbOpen Diagnostic on LIN.vi' was expected to have the qualified name 'NI_Automotive Diagnostic Command Set.lvlib:Open Diagnostic on LIN.vi', but has the qualified name 'Open Diagnostic on LIN.vi'.

-----

Notice: I was able to start the build, because the installer has already been configured in LabVIEW 2011 SP1 & ADCS 1.1.0.

Here is the related topic:

http://lavag.org/topic/17137-error-generating-preview-in-installer-properties/

The solution ended up being something out of left field - the Windows Aero theme, which is default for Win 7.  R&D finally stumbled across this and was able to turn the issue on off by changing the theme away from Aero.  I gave a presentation at NIWEEK just recently and it seems I had 3 people in the audience that were experiencing this same/similar issue.  Therefore, I thought I would post this and maybe I could help some others.

All LabVIEW versions including 2012 are affected it seems.  I was developing in 2010 at the time, but R&D tried many versions to see if it was version-specific.

QUOTE (Yair @ Apr 27 2009, 02:37 PM)

That's the way it should be, definitely. Here's a VI showing an example where they aren't always (which is almost definitely a bug). I'm guessing that this is an issue which has to do with how the event structure handles a timeout when it has user events registered.Download File:post-5877-1240863213.vi

If you look at the block diagram, you'll see this:

You'd expect that the user event would be handled before the control value change event. I followed up on this. It is "regrettable but correct behavior." In other words, not intended behavior but a logical result from the rules of the system, so not really a bug.

When events fire, they are placed in a queue. They record a timestamp of the time they occurred. The timestamp has millisecond resolution.

There are separate event queues for dynamically registered events and statically registered events. In Yair's demo, the user event is registered dynamically and the value change is registered statically, so there are two queues. The event handler looks at each of its queues and takes the earliest timestamp. In this case, the timestamps are identical and the statically registered event wins.

Workarounds:

1. Dynamically register for both the user event and the value change event. [This is the preferred workaround.]

2. Add a millisecond delay after the firing of the user event before firing the value change event to guarantee different timestamps. [This is a hack.]

I found this bug in LV 2011 SP1 and it was reproduced in LV 2012 by an NI application engineer who filed CAR #385212 for it.

Basically, if an installer build specification has values under a key that you've created in the "Registry" section and that you delete the key without having deleted all the values before the build will fail.

The solution is either to recreate all the same keys and values and delete each value before deleting the keys or edit the lvproj file with a text editor to remove all the lines corresponding to the values and keys your want to get ride of.

The error I was getting when the build was failing was : 

*** Error: An internal tool or library returned an error. (Error code -21)
Error adding registry key:  Name: name_of_value
**************
*** Error Details:
Error in MDF API function: _MDFBuildDevPart_AddRegKey
nmdkAddRegKey returned error code 26051
*** End Error Report

LabVIEW Version 11.0.1f2

In a VI for a FPGA target, if an error cluster is wired to one input of an OR gate that has a Boolean wired to the other input, then in the "generate intermediate files" process that precedes the Xilinx bitfile generation, "stage 1 of 7" (analyzing VI hierarchy) will very repeatably crash while processing the VI. See attached PDF.

I've found a bug related to the "Generate User-Defined Trace Event" (GTE) which will crash LabVIEW routinely.  The bug has been submitted to NI and they've verified it.  For those of you watching from home, the CAR number is 412912.  I'm using LabVIEW 2012 SP1.  The crash did not exist for me in the 2011 version.

The crash occurs when you have a string control wired to GTE and that string control is connected to the connector pane of your VI.  If the string control contains text and the Desktop Execution Trace Toolkit (DETT) is listening than we get a crash.  If string is empty or DETT is not listening, then we're all set.  When used only with a numeric control, the GTE does not seem to crash.  The workaround  from NI is to use a property node to read the value of the string control and pass that onto GTE.

I've attached a sample project which demonstrates the crash and I've included the png of just the workaround below.

-Keith

GTE Crash.zip

Here's the code for a VI when it's opened on my main development machine. Note the unbundle by name primitive is selecting the ER field:

Now here's the same code opened up on my laptop:

Yeah, somehow the unbundle by name prim now selecting the DN field and the corresponding case structure has also mutated its type. Fixing this is dead simple, I just re-select the ER field, but the more important question is why is my source code changing as a function of which computer opens the VI? This scares me...

1. The cluster contains an array of clusters
2. The array of clusters is not the last item in the cluster
3. The array of clusters is empty
   

All three conditions must be fulfilled in order for the bug to appear. An AE was able to reproduce it and it has CAR #385089.

Background

There is a bug in the Event Structure where code in frames of an Event Structure can get re-associated with a different/wrong Dynamic Event when the input event reference data of a Register For Events node changes.

Short Video Demonstration of the Bug

And, here's an example VI that you can use to test it for yourself:

Download File:post-17-1235239395.vi

Steps to Reproduce

• Open "Dynamic Events Bug.vi"
• Cycle through the Event Structure frames
  • Note the contents of the frames for Event A, Event C, and Event D.
  • Note the cluster constant with user event reference constants for Event A, Event B, Event C, and Event D

  [*]Delete the Event B user event constant from the cluster constant.

Observed Results

• Cycle through the Event Structure frames
  • Note that contents of the Event Structure frames for Event C and Event D got swapped: the contents for Event C are now associated with Event D.

Expected Results

• The contents of the Event Structure frames for Event C and Event D should remain unchanged (they should not be swapped)

It seems that it it a problem with the latest lvanlys.dll in the run-time since older installations do not exhibit the problem. It affects all labview versions (from 2009 onwards) and both 32 bit and 64 bit.

This is the result from an installation using lvanlys.dll version 9.1.0.428

And here from an installation using lvanlys.dll version 10.0.1.428

The problem is that the output is switching sign at arbitrary intervals as can be seen in the following table:

Ton

SetLibVersion.vi

EDIT: CAR NUMBER 347359

Turns out an error in the start up logic of one of my applications would request a duty cycle of NaN to a counter output I'm using for pulse width modulation. The problem is the NaN request goes through without returning an error. But the next request to update the duty cycle hangs the DAQmx write VI. After hanging, there's no way out, aborting the calling VI leaves LabVIEW in a sorry state.

Example:

WARNING: Running the snippet above can leave LabVIEW in an undefined state. Save your work before you do so!

Now obviously a NaN duty cycle makes no sense, but I'd expect DAQmx to be able to handle such requests gracefully, either by ignoring them, or preferably issuing an error.

I've observed this behavior on the USB-6343 device.

Open and run the attached VI first in LV2010SP1, then try in LV 2011f2.

Greetings

Wolfram

BugReg.vi

I have came across a nasty bug that caused Labview 2010 SP1 (Running Win 7 Ultimate x64 bit) to crash without any warning.

To replicate the bug do the following:

1. Add a numeric control and another indicator to the front panel
   
2. Switch to block diagram and add a feed back node
   
3. Connect the initializer terminal of the feed back node to the output of the control
   
4. Now do ANY of the following to cause the bug:
   
   • Press the run button (which is broken due to not connecting the input of the feed back node) it will turn to a normal run without displaying the error
     
   • Do an extra action and undo it, the run button will turn from list error normal
     

• So far the Vi can be saved normally. Now connect the output of the feed back node to the indicator and try any of the followings:
  
  • Save the VI
    
  • Close the VI
    
  • Create a new project and select to add the VI to the project
    

  This will cause Labview to crash without any notice!

When you are at step 4, the bug is there but harmless. Once you combine it with step 5 (connect to indicator), the bug is active and cause crashing. I have attached a snapshot of how the Front panel/block diagram look like before saving (since it can't be saved). Notice how the run button is enabled although the input of the feedback node is not connected.

I have tried to replicate the error on Labview 2009 but couldn't.

The coercion persists regardless of what floating type is presented. I see this behavior if the array is any integer type.

Is this intended?

Set the properties Active Cell and Edit Position to a row in the middle of the ones you populated.

Set the value to that same row.

Set the key focus to true.

Create a simple while loop to keep the VI running after all these setting are applied.

Run the VI. The row you set should be selected.

Use the up/down arrow keys to move to another row more than 2 rows away.

Stop the VI

Run the VI again.

Use the arrow keys to move the selection again. Instead of moving relative to the programmatically selected row that is highlighted, it will jump to the row that was (up/down) from the row you moved to right before you last stopped the VI.

Why does it do this? Why does it remember the last selection you navigated to? How can I override this so the selection I set programmatically is the one it will move relative to when the use uses the arrow keys?

Is this a bug?

-John

Download File:post-2411-1198024019.vi

Watch the following screencast to see me struggle with it:

<!-- copy and paste. Modify height and width if desired. --> <object id="scPlayer" width="295" height="225" type="application/x-shockwave-flash" data="http://content.screencast.com/users/TonPlomp/folders/Jing/media/e0735a7d-d1e6-45b8-9f6d-af40de115bcf/jingswfplayer.swf" > <param name="movie" value="http://content.screencast.com/users/TonPlomp/folders/Jing/media/e0735a7d-d1e6-45b8-9f6d-af40de115bcf/jingswfplayer.swf" /> <param name="quality" value="high" /> <param name="bgcolor" value="#FFFFFF" /> <param name="flashVars" value="thumb=http://content.screencast.com/users/TonPlomp/folders/Jing/media/e0735a7d-d1e6-45b8-9f6d-af40de115bcf/FirstFrame.jpg&containerwidth=295&containerheight=225&content=http://content.screencast.com/users/TonPlomp/folders/Jing/media/e0735a7d-d1e6-45b8-9f6d-af40de115bcf/LV2011Resizehotspot.swf&blurover=false" /> <param name="allowFullScreen" value="true" /> <param name="scale" value="showall" /> <param name="allowScriptAccess" value="always" /> <param name="base" value="http://content.screencast.com/users/TonPlomp/folders/Jing/media/e0735a7d-d1e6-45b8-9f6d-af40de115bcf/" /> Unable to display content. Adobe Flash is required.</object>

Anyone else noticed this?

TOn

The invoke node fails with Error 1 on me when I execute the "Variant" case. That is Control Value:Set doesn't seem to be able to apply an empty variant to the control. This strikes me as a bug, or is there some esoteric reason this is an intended behavior?

LV2010 SP1.

When saving a config (INI) file, the original file is "replaced" (deleted and then a new file created in its place, as opposed to simply opening and flushing the contents of the original file).

The problem with this are as follows:

1) A user might have write permission on the file, but might not have permission to create new files. So, attempting to replace the file will cause a file permission error, even when the user has write permission on the file itself.

2) The new file might have different permissions than the original file. When the original file is deleted, all its permissions/ownership settings are lost. The replacement file will have default permissions based on the user creating the new replacement file.

Here are some screenshots of the buggy version and the fix for this issue:

And, here's the fixed VI:

Save Config File -- FIXED.vi

This arises from investigating why my code breaks down in LV2010 (LVOOP Event Handler in code repository).

In LV2009, it used to be possible to make an array of events where the event refnum of child classes could be carried on the wire of the parent class event refnum.

This has changed in LV2010 as it is no longer possible.

Digging a little on this issue, I found out that the "equals" primitive has also changed behavior between versions.

It seems that if the datatypes can be arrayed, it should also be allowed to compare them, right?. Granted, it should still return "false" if the refnums are not pointing to the same objects, but why the broken wire in 2009? This behavior has been corrected in 2010 so it seems that LV recognized that these are of the same type (or at least in a parent/child perspective). So why would it be impossible to make an array to these?

At least, we can still pass a child object on the parent event refnum... and not a parent object on a child event refnum (consistent).

Anyone can confirm that this is a bug and not expected behavior? And obviously, one version has a bug... which one? Both?

Background: I have a re-use library which defines classes which are extended in other libraries or projects. Often when working on my projects, my re-use library files will be modified despite me having never explicitly done so.

I just got this when I was doing a checkin:

At the bottom of the list is a modified file in the LabVIEW.Messaging.2.0 library, which should not have been changed. I was working on classes extending from those defined in the messaging library, but never made explicit changes to the messaging library itself. There is a single offending line in the class file:

Working copy (truncated):

<Property Name="NI.LVClass.FlattenedPrivateDataCTL" Type="Bin">%!#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!%"15F.3

Base copy (also truncated):

<Property Name="NI.LVClass.FlattenedPrivateDataCTL" Type="Bin">%!#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!%!I5F.3

Both class files (just the XML, none of the supproting VIs etc) are attached, v10.0f2. Though not in this case, I've also seen dynamic dispatch VIs from the base class become modified as well. Am I the only one that sees this behavior?

classdiffs.zip

-m

Basically, that the Not A Refnum primitive returns true for non "native" types of refnums even if they are valid refnums. Why does this primitive even allow refnums to be used when the behavior is at best inconsistent? I swear it should either behave properly or be removed from the palette.

Sorry, venting. I know this is a well documented bug feature, has been so for some time, and the "proper" way of dealing with these refnums is using the Not A X Refnum.vi methods, but seriously? This primitive ends up more often being a source of bugs for me than not. I guess the C-style programmer in me just can't stop thinking of code such as:

if (pRefnum){    // Operate}else{    // Panic!}

Sigh...

-m

[CAR#: 252210]

[Update: I just tested this in LabVIEW 2010 SP1 and it seems to be fixed The CAR Number (252210) is also in the list of LabVIEW 2010 Service Pack 1 Bug Fixes. Thanks NI!]

I found an odd LabVIEW 2010 bug that will cause a hard crash. The bug appears to be related to how LabVIEW operates on data in-place and some interaction between clusters, arrays, and the Aum Array Elements node. It's hard to describe verbally, so I'll just draw you a picture

LabVIEW 2010 CRASH.vi

Lately I came across a weird behavior on XControl. I think I've find out the issue but want to you to confirm the behavior.

As far as I understand XControl execution theory, it's impossible to have facade VI executing only one iteration loop (just TimeOut case called). However I can obtain this on certain condition. This should not be a problem if data (display state and Data) was not reseted to default value. Ui refresh code called with these inconsistent data give some really weird behavior (NB: data are not lost, next call give the consistent data...)

Here you can find the step to reproduce the issue :

1. Create an XControl
2. Add a slider on facade.vi FP
3. Add beep.vi in a "0" case, outside the while loop, link selector to while loop "i"
4. Add "Slide:Value change" event case
5. Add "Slide:Mouse Enter" event case
6. Drag the Xcontrol in a new VI FP

Issue appears after step 5.

You'll find an example of this behavior in attachment.

I've reproduced the issue in LV2009-SP1 and LV2010. Can you confirm me that you have the same behavior on your side ?

Work around is easy, but I think this deserves a bug fix from NI.

Regards,

Olivier

XCTimeOutIssue-2009.zip

I've been wondering if this behavior is a bug or an intended feature and would like your opinion.

Personaly I think it's a bug... but I might be biased by the end result I'm trying to reach.

The issue is that when one uses String.TextSelction.Start and End properties to change the font of a string subset, it works as one should expect. But as soon as you append a string to it, the whole string text reverts to the font of the last property set instead of just adding the text at the end and keeping the fonts for the rest of the string. To better understand, try out the VI below. I've deliberately added a delay to allow for more dramatic effect...

I can see why this "bug", if it is one, would be tough to get rid of. It has implications in how a string constant/control/indicator works. For example, if the font color from index 7 to 14 is "blue" and I insert a string subset at index 10, then it should follow that the text I insert would be "blue" also.

The current workaround is to read the fonts of all characters in the string before appending/inserting and to rewrite each fonts after the operation, to restore the colored lines. It is nice when working on short strings, but imagine a log system with hundreds if not thousands of lines, all different colors for informations, alarms, data, etc. Even with panel update differing, it would be time-consuming...

Change line color LV85.vi

Change line color LV86.vi

LabVIEW 2010 Know Issues

Could A LAVA admin please pin this as the 2009 thread is thanks

Danny

yesterday I noticed an f2 patch for LabVIEW 2010, just thought I'd post it here as nobody else has

LabVIEW 2010 patch f2 Details

It appears that the Variant to Data primitive *or* the Control Value.Get method does not like to work with complex typedef'd data.

This used to work in LV2009SP1 but now give me error 91 in LV2010.

Has anyone else run into this?

-John

Variant to Data bug.zip

Classes added to Library with protection property and set to locked generates an error at build time.

At the link there are example files and a video demonstrating what I am seeing: Locking LabVIEW Project Libraries and Building Applications

Cheers

-JG

Exe > installer > web service. Thus, when you make edits to the web service code and do a build all, your changes will not be picked up unless you build all twice, since the web service would be build AFTER the installer.

The work-around was to drag the build specs around to rearrange them so the web service came before the installer that needed it. I reported this and said that a better fix would be for the project to detect this dependency and build the components in the right order.

Well, in LV2010, not only has this not been fixed, but you can no longer drag the build specs to rearrange them and work around the bug.

So, better plan your project completely before trying to build any part of it...

Anytime I right-click on the FP, and dismiss the tool menu, I get a selection rectangle. If I don't catch it, moving outside the bounds of the FP will cause the FP to scroll to continue my unwanted "selection". So far this has been repeatable every time.

I am running LabVIEW 8.6.1f1, so I am curious to see whether this exists in LV2009. Also, I don't remember seeing this with previous versions, but it's hard to recall.

What do you all think? (I can't imagine this being expected behavior)

-Ian

The problem: when creating class methods which define a property, the property nodes are often (initially) unusable.

For example, here's a screen shot showing the property definition for a class I'm working on:

And the corresponding VIs, along with a chunk of code trying to use the VIs via a property node.

These are new VIs I've just defined, and are in fact the default VIs you get when you create an accessor VI. Notice how both VIs are executable, however the property node is black: it can not be wired. The blackening of the node is normal if you select a property which you do not have access to, however the code which uses the property is in a VI which is a member of the class, so it will always have access, and besides, the VIs are defined as public since I hadn't gotten around to changing them to a more restrictive scope yet.

What I've been doing when I come across this is forcing the VIs to recompile by switching a terminal on the connector pane of one of the VIs, thus breaking both VIs, then switching the terminal back. Everything works thereafter.

Weird is all I can say. Anyone else been playing this game? Any ideas on what's going on? It doesn't seem to happen all the time...

I should add that the code that uses the property is actually acting on a DVR wire of the class...

http://forums.ni.com/ni/board/message?board.id=170&message.id=492924

I can't be the only one...

This bug affect (at least) LabVIEW 2010 and LabVIEW 2009 (I did not test it on any more version)

Platform:

Windows (XP and 2007)

Description:

If you have a tree control with filter event case for "Edit Cell?", "Item Open? and "Item Close?" then clicking the node expand/collapse glyph (the"+" or "-") while editing another column will result with the text entered be applied to the node column (the first column) instead of the column that was being edited.

More info:

See attached video and attached example VI (treebug.vi).

<object id="scPlayer" class="embeddedObject" type="application/x-shockwave-flash" data="http://content.screencast.com/users/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/jingswfplayer.swf" height="471" width="587"><object id="scPlayer" class="embeddedObject" width="587" height="471" type="application/x-shockwave-flash" data="http://content.screencast.com/users/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/jingswfplayer.swf" >

<param name="movie" value="http://content.screencast.com/users/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/jingswfplayer.swf" />

<param name="quality" value="high" />

<param name="bgcolor" value="#FFFFFF" />

<param name="flashVars" value="thumb=http://content.screencast.com/users/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/FirstFrame.jpg&containerwidth=587&containerheight=471&content=http://content.screencast.com/users/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/2010-08-05_0849.swf&blurover=false" />

<param name="allowFullScreen" value="true" />

<param name="scale" value="showall" />

<param name="allowScriptAccess" value="always" />

<param name="base" value="http://content.screencast.com/users/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/" />

</object>

treebug.viLabVIEW 2010

<param name="movie" value="http://content.screencast.com/users/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/jingswfplayer.swf">

<param name="quality" value="high">

<param name="bgcolor" value="#FFFFFF">

<param name="flashVars" value="thumb=http://content.screencast.com/users/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/FirstFrame.jpg&containerwidth=587&containerheight=471&content=http://content.screencast.com/users/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/2010-08-05_0849.swf&blurover=false">

<param name="allowFullScreen" value="true">

<param name="scale" value="showall">

<param name="allowScriptAccess" value="always">

<param name="base" value="http://content.screencast.com/users/pjm_jki/folders/Jing/media/392e8fc4-8f7f-4bc8-9574-b1abc6f1eb22/">

</object>

Drop a waveform graph on the FP. Make visible all the legends and the Graph Palette. When you're done it might look something like this (I've grouped all that stuff together to make a smaller pic):

Drop some other control on the FP (I suggest a numeric just because it's small). Group it with the graph. Right-click on the graph and select "Scale object with pane".

Expand/contract the window. Keep your eye on (what I think is called) the Cursor Movement tool. It's in the bottom right hand corner of the above pic -- the square thing with the 4 diamonds in it.

Unlike any of the other palette/legend objects, the cursor tool changes size along with the graph. Even setting the pane back to the original size does not get the diamonds the right size and lined up again in the box. Resize the window a few times and the tool is completely unusable.

This resizing ot the cursor tool does not happen if the graph isn't grouped with another control. Unfortunately, I have to have the graph in a group so all controls resize together.

I can't find any way to access that box and the diamonds programmatically. My fallback is to program my own right/left cursor movement controls, which isn't difficult, it's just annoying when there are tools to do it built in to LV.

Is this a bug or a feature? All I know is it's bugging me.

See attached VI: crashtacular.vi

Steps to reproduce:

Open attached VI, set a path to a file which will be written. Execute the VI. Notice how the execution succeeds, and the file is written.

Open the block diagram of the VI. Look for the following code...

Note the call to NI_XML.lvlib:Close.vi in the diagram disabled structure. Swap the cases such that the close call is made.

Warning! This will crash LabVIEW, make sure you've saved any other data you have open: Execute the VI.

Expected behavior: After obtaining a new reference to the Document, I expect I should have to close it as I would any other reference I obtain dynamically. I'd only expect the Document to fall from scope after the last reference to it has been closed, instead closing any reference appears to destroy the data.

This bug has existed as long as I can remember, but after being bitten by it again I decided to try to document it. What are your opinions?

My $0.02: It's a bug. If it's by design, it is at best inconsistent with how references are used in the rest of the library, let alone the rest of LabVIEW or programming in general. I see no mention of it in the list of known issues, however I've seen previous posts regarding the issue over at ni.com in the past.

-Michael

It occurs when programmatically setting the text color through a property node as well.

Only occurs with System Style and when backgroup is transparent.

That's annoying.

The problem comes when you want to strip a network path that looks like this "\\server\dir\subdir".

When stripping the path with the "Strip Path" primitive, it would correctly output "\\server\dir" for the stripped path and "subdir" for name.

Doing it a second time should return "\\server" for stripped path and "\dir" for name.

Instead, you get an empty stripped path and the input is copied to name output (Incorrect results). Furthermore, if the stripped path output is wired, it will most likely crash LabVIEW. The current workaround is to assign a drive letter to the network path using "Map Network Drive" in Windows. (Dunno for other OS) It works fine with path that start with "X:\"

This has been tested with LV2009 on 32-bit system (WinXP).

Note that it doesn't tell you what file(s) are missing. This makes it a real pain to figure out what is 'wrong'. Note: the reason I got this dialog is because LabVIEW crashed while I was editing my class so some changes to the class library (including members that were renamed) were lost.

Here's how to duplicate my issue:

1) place a path control on a front panel

2) click the browse button and navigate to a write-protected file

3) select the write-protected file, and then click OK

For me, doing the above actions causes a dialog box to be displayed that says something to the effect "You have selected a write protected file. Please select a different file" (or something very similar). It happens whether the VI is running or just in edit mode.

This is without trying to even read the file, just selecting it. Has anyone noticed this behavior? Is it Vista? Is it LabVIEW? Is it the interaction between them?

This issue precludes me from reading in the contents of any read-only file. Bizzarre.

Any help would be appreciated. Do you have the same issue? Does reading a write-protected file work OK for you?

Thanks very much, in advance, Rob.

LabVIEW 2009 Known Issues

In LabVIEW <=8.6, you could update the inputs to a suspended VI and rerun your code and it would use those inputs to determine code execution.

In LabVIEW 2009, if you change the inputs of the suspended VI, the VI still runs with whatever the caller VI passed into the VI.

Here's a video to demonstrate this issue.

http://content.scree...f8/00000135.swf

LabVIEW 2009 f2 Patch Details

The LabVIEW 2009 f2 patch resolves the following issues:

ID Description

151665 Memory leak when using .NET callback in LabVIEW

178614 Type defined constant can lose value when updating to edited typedef if feedback node also on diagram

182053 Custom About screen not displayed with a LabVIEW built application

183560 Graph does not display timestamps on X-axis as expected when using timestamp data type

185219 Error 1502 while building a LabVIEW application

185348 VIs with very large type descriptors (like the Enum with 2000 items) will crash on load after being saved in LabVIEW 2009

185362 Timed loops using a timing source terminal upgraded from LabVIEW 8.6 to 2009 will function correctly, but incorrectly indicate the built-in timing source is used.

185980 Editing An Event Structure With A String Event Might Crash Localized Versions Of LabVIEW 2009

186276 Certain references (SoftMotion, WSN...) may incorrectly refer to data associated with a different reference

186418 Image Display control does not update using Value property node in a LabVIEW built application

186602 Application Builder uses too much memory, which may result in build failures

187759 Cannot launch LabVIEW 2009 when using Microsoft Mandatory User Profiles

I guess many of you have encountered this issue with the tab control.

Is this a bug or something everybody knows about and always just manage to live with it.

The problem is that the Tab Control don’t always changes Tab when you programmatically changes is using a local variable, if you at the same time updates a control or indicator using the property node which is located on any of the tabs.

Why??

(LV 8.6)

//Mikael

TabTest.vi

My version of LabVIEW is behaving odd when it comes to Data Entry limits.

Have YOU seen the same problem?

When I open the “Data Entry…” option for a numeric the first time it does show me the right limits for that control.

When I open the same option for the next numeric control these values don’t show the correct values.

They still show the first opened control’s Data Entry-limits.

And if I change the values, that values changes for the other control not the one I open the dialog from.

This is in LabVIEW 8.6

Cheers,

Mikael

I'm seeing a behavior where LabVIEW's List Folder primitive returns incorrect results for a folder on a mapped network drive, if the folder contains a file whose name starts with any of:

(I suspect it's actually any ASCII character whose value is less than or equal to 0x2D, but some of those are illegal and/or unprintable).

OS: WindowsXP

LV Version: LabVIEW 8.6 and LabVIEW 2009

Steps to Reproduce

(1) Map a network drive to a drive letter (I'm not sure that a mapped drive is necessary, and the network drive in this demonstration is a samba share from a Linux system).

(2) Create a file in a directory on the network share from #1, e.g. "Z:\list-folder-bug\file.txt".

(3) Note that LabVIEW's List Folder function returns correct results when listing the folder you just created.

(4) Rename the file you created in #2 above, changing its name to !file.txt. (The key is that the filename must start with !, or any of the other characters listed above.)

(5) Note that LabVIEW's List Folder function now returns two elements in folder names that don't really exist.

Why This Is Important

This is important because these phantom directories "." and ".." are expanded to "current directory" and "parent directory," which means LabVIEW thinks that the target directory contains a copy of itself and its parent. This produces an infinite recursion when listing directory contents recursively. In particular, the OpenG function List Directory Recursively is affected by this bug and enters an infinite loop when run on the directory shown in #5.

Bonus Information

Note, also that the dir command at the Windows Command Prompt sorts the file list in an odd way for files that begin with the aforementioned characters, but only on network shares.

Joe Z.

x-post to http://forums.ni.com/ni/board/message?board.id=170&message.id=437600

• If the first part of the video, the code use the "Pane": Mouse Move static event and the result is very snappy and fast.
• In the second part I change this to use the mouse move pane registered event and suddenly everything is a lot more sluggish (and it is not usable).

This is too bad because the event registration make for nicer reusable code...

<object width="1092" height="444"> <param name="movie" value="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/26599c2f-fc26-4068-8a54-fc0138c08228/jingswfplayer.swf"></param>'>http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/26599c2f-fc26-4068-8a54-fc0138c08228/jingswfplayer.swf"></param> <param name="quality" value="high"></param> <param name="bgcolor" value="#FFFFFF"></param> <param name="flashVars" value="thumb=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/26599c2f-fc26-4068-8a54-fc0138c08228/FirstFrame.jpg&containerwidth=1092&containerheight=444&loaderstyle=jing&content=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/26599c2f-fc26-4068-8a54-fc0138c08228/2009-09-02_1042.swf"></param> <param name="allowFullScreen" value="true"></param> <param name="scale" value="showall"></param> <param name="allowScriptAccess" value="always"></param> <param name="base" value="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/26599c2f-fc26-4068-8a54-fc0138c08228/"></param>'>http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/26599c2f-fc26-4068-8a54-fc0138c08228/"></param> <embed src="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/26599c2f-fc26-4068-8a54-fc0138c08228/jingswfplayer.swf" quality="high" bgcolor="#FFFFFF" width="1092" height="444" type="application/x-shockwave-flash" allowScriptAccess="always" flashVars="thumb=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/26599c2f-fc26-4068-8a54-fc0138c08228/FirstFrame.jpg&containerwidth=1092&containerheight=444&loaderstyle=jing&content=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/26599c2f-fc26-4068-8a54-fc0138c08228/2009-09-02_1042.swf" allowFullScreen="true" base="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/26599c2f-fc26-4068-8a54-fc0138c08228/" scale="showall"></embed> </object>

Note: This is in LabVIEW 2009

PJM

Broken since... erm, 7.1ish?

To see the bug, select the first element in the MCL, scroll to the bottom, and shift click the last element. It pegs a processor core, too.

To see the correct behavior, restart the VI, scroll to the bottom of the MCL, select the last element, scroll to the top, and shift click the first element.

I'd hate for it to fall off the bug list.

Joe Z.

x-post to http://forums.ni.com/ni/board/message?board.id=170&thread.id=436150

MCL_Bug.vi

c:\builds\penguin\labview\branches\Saturn\dev\source\linker\xlinker.cpp(739) : DWarn: GetAbilityVI should never have to actually load the VI; Nick Neumann was wrong. Go yell at him now!

c:\builds\penguin\labview\branches\Saturn\dev\source\panel\xctlVICalls.cpp(353) : DWarnInternal: Expected async ref, something's gone awry!

x-posted to: http://forums.ni.com/ni/board/message?board.id=170&thread.id=435384

If you run the attached VI you will see that the scrolling will stop even tough you did not "mouse up".

If you remove the mouse move event, everything is back to normal.

Somehow the mouse move event is interfering with the scrolling.

<object width="886" height="530"> <param name="movie" value="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/jingswfplayer.swf"></param>'>http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/jingswfplayer.swf"></param> <param name="quality" value="high"></param> <param name="bgcolor" value="#FFFFFF"></param> <param name="flashVars" value="thumb=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/FirstFrame.jpg&containerwidth=886&containerheight=530&loaderstyle=jing&content=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/2009-08-20_1533.swf"></param> <param name="allowFullScreen" value="true"></param> <param name="scale" value="showall"></param> <param name="allowScriptAccess" value="always"></param> <param name="base" value="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/"></param>'>http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/"></param> <embed src="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/jingswfplayer.swf" quality="high" bgcolor="#FFFFFF" width="886" height="530" type="application/x-shockwave-flash" allowScriptAccess="always" flashVars="thumb=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/FirstFrame.jpg&containerwidth=886&containerheight=530&loaderstyle=jing&content=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/2009-08-20_1533.swf" allowFullScreen="true" base="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/" scale="showall"></embed> </object>

Note: while this does not seem that bad in the video above, in some situation it is so bad that it becomes very difficult to scroll.

mouse move scroll bug.vi

PJM

Hidden objects don't move when resizing a window, which causes display problems when you want to show them. I've attached a sample VI demonstrating the problem.

Bruce

http://forums.ni.com/ni/board/message?board.id=170&message.id=432116#M432116

Resize Window while Control Hidden Test.vi

<object width="456" height="426"> <param name="movie" value="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/58a1706c-ad69-4ae0-ae13-a88575dec213/jingswfplayer.swf"></param>'>http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/58a1706c-ad69-4ae0-ae13-a88575dec213/jingswfplayer.swf"></param> <param name="quality" value="high"></param> <param name="bgcolor" value="#FFFFFF"></param> <param name="flashVars" value="thumb=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/58a1706c-ad69-4ae0-ae13-a88575dec213/FirstFrame.jpg&containerwidth=456&containerheight=426&loaderstyle=jing&content=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/58a1706c-ad69-4ae0-ae13-a88575dec213/2009-07-31_1746.swf"></param> <param name="allowFullScreen" value="true"></param> <param name="scale" value="showall"></param> <param name="allowScriptAccess" value="always"></param> <param name="base" value="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/58a1706c-ad69-4ae0-ae13-a88575dec213/"></param>'>http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/58a1706c-ad69-4ae0-ae13-a88575dec213/"></param> <embed src="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/58a1706c-ad69-4ae0-ae13-a88575dec213/jingswfplayer.swf" quality="high" bgcolor="#FFFFFF" width="456" height="426" type="application/x-shockwave-flash" allowScriptAccess="always" flashVars="thumb=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/58a1706c-ad69-4ae0-ae13-a88575dec213/FirstFrame.jpg&containerwidth=456&containerheight=426&loaderstyle=jing&content=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/58a1706c-ad69-4ae0-ae13-a88575dec213/2009-07-31_1746.swf" allowFullScreen="true" base="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/58a1706c-ad69-4ae0-ae13-a88575dec213/" scale="showall"></embed> </object>

I think this happen only with string that have formatted text.

Note: This bug is present from LabVIEW 8.21 all the way to LabVIEW 2009.

Bold Redraw Bug.vi

LV 8.21

PJM

Workaround: use a U16 to I32 converter before joining the numbers.

join-bug.vi