coloring a strictly typedefd FP control crashes LV (Linux)

[Enrico_Segre]

I thought something that macroscopic would just qualify for a CAR, but my local AE replied "post on forum". Well, here it is. Anyone else sees it, or is it just me?

Support Question
Attempting to color a strictly typedefd FP control crashes LV (linux)

Steps to Reproduce

1. create a custom control, e.g. with a numeric
2. make it strict typedef
3. create a new VI
4. drag the icon of the custom control from its window corner to the FP of the new VI
5. select the paintbrush on the Tools palette
6. click anywhere on the control on the VI FP as if to color it

LV crashes with:

LabVIEW caught fatal signal
12.0.1 - Received SIGSEGV
Reason: address not mapped to object
Attempt to reference address: 0x0xe2e2e6
Segmentation fault (core dumped)

on stderr.

Perfectly reproducible on two different systems.

Software Details: LabVIEW Base Development System 2012 SP1 and 2014 SP1
Operating System: Ubuntu 14.04 (ok, not officially supported, but)

[johnsold]

While this does not explain the crash, it does tell you that you cannot do that. From the LV help:

"

Strict Type Definitions

A strict type definition forces everything about an instance to be identical to the strict type definition, except the caption, label, description, tip strip, and default value. As with type definitions, the data type of a strict type definition remains the same everywhere you use the strict type definition. Strict type definitions also define other values, such as range checking on numeric controls and the item names in ring controls. The only VI Server properties available for strict type definitions are those that affect the appearance of the control or indicator, such as Visible, Disabled, Key Focus, Blinking, Position, and Bounds."

You cannot change the color of a strict typedef. If you need to cahnge the color, use the standard (non-strict) typedef.

Lynn

[Enrico_Segre]

Obviously. But it is quite easy to end up doing it accidentally, on a FP which has lots of custom elements, some strict and some not. And the punishment of losing at once all the unsaved work is a bit exaggerate imho. A system beep, a dialog "Dummkopf!! RTFM" would be more gracious.

[johnsold]

I agree that LabVIEW's response should be an error, not a crash.  Let's hope that someone frm NI with the Linux version tests to see if they can reproduce it.

Lynn

[johnsold]

- duplicate post. sorry

[Craig_S.]

CAR 526281.  Should be fixed in 2015 (but not in the beta).

[NateBraska]

Just an FYI, the CAR for this issue is filed under 526291.

Best Regards,

Nathan Burke

Product Support Engineer | LabVIEW R&D