corrupted TypeDef

[ThiCop]

Hello **bleep**enhauser,

I'm not a LV Only AE (rather an NI anything AE 😉 )

If you want me to, then I can do my best to look into this.

Do you also have a non-corrupted version of the files?

This way I can use this as a comparison sample.

Did you by any chance have a crash during the saving of your application or while you were working on the typedef?

Which OS have you been using?

Windows 7 sometimes can kill LabVIEW ("Force Shutdown") in a not so nice way.

I haven't so much problems with it, but have seen some corruption (not specific to typedefs) happening this way.

[Fagenhauser]

thanks for your offer,

in the .zip i attached in one of my posts i put a corrupted and a not corrupted typedef and a VI that uses both these typedefs for comparison. I use Windows 7 and the VI I worked on containing the typedef that got corrupted was sometimes very slow, for example dragging a control on the FP could take in the order of seconds, very frustrating and now idea why that happened. Sometimes I would see the message in the VI-window (Not responding). No crashes as far as I can remember.

[ThiCop]

Hello **bleep**enhauser,

It might seem stupid, but when I test it at my side.

The example code seems to act the same for the corrupted and the non-corrupted booleans.

Which version (also build number) of LabVIEW are you using?

Intaris, can you also provide me with thsi information?

I want to make sure I have exactly the same set-up here.

[Fagenhauser]

OS: Windows 7

LV: LV2011 SP1 V11.0.1(32-bit)

I just contacted NI and it turned out that the problem didn't occur on a PC with:

OS: Windows 7

LV: LV2012 SP1

We tend to get closer to the root cause. I hope this information helps to pin it down. Thanks for your help so far.

[ThiCop]

To be complete:

I had a very similar issue with a customer in LV 2011 SP1 and I think there was a CAR about it.

I'm going to search in some older files to see if I can find it back.

[ThiCop]

Hello **bleep**enhauser,

I didn't directly find the correct information, so I could have been mistaken before.

Did you experience a LabVIEW hang/crash when you were making the controls?

Did you experience this one time or multiple times?

[Fagenhauser]

no crash as far as i can remember but very often the VI was very slow, hanging, unresponsive. I have a lot of controls placed on a Tab-Control in the VI where the problem arose. dragging a control sometimes takes a very long time (fractions of seconds up to a second). If you have to position a lot of controls this adds significantly to the time it takes to build a UI. 

[ThiCop]

Hello,

That behavior is indeed not normal.

Were they originally placed inside of a cluster or an array?

And did you drag them outside of it.

Or did you move them around different structures?

Do your remember to whome you had talked at NI?

Then I can let him/her know about this corresponding Service Request.

[Fagenhauser]

Unfortunately i don't know the person's name who helped me this morning. I talked to NI technical support Germany.

The Engineer I talked to knows about this post.

I took a system-button-control and made a typedef of it, i might have started with a normal button-control, made a typedef and then replaced it with a systembutton-control and I also might have changed the mechanical action of the button after i made a typedef of it.

What I said about the dragging of controls being very slow applied to all controls, also when dragging or reshaping a decorations-border it would be very slow. The VI contains 200+ controls and as many references.

[ThiCop]

Is the dragging and dropping only slow with the "corrupted" version or is it also the case for the non-corrupted version?

Dragging an dropping being slow can sometimes be caused by other factors.