LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LV 6.1 Tab Control Crash

I've created an application that uses a tab control to show data to a user. Which tabs I want visible depend on what data the user wants to see; but I have found that hiding tabs and making them visible again programatically using a property node causes LabVIEW to crash. Sometimes I get a memory.cpp error with line 563 (I do not have a delete from array VI anywhere in my program), other times it gives me a windows general memory fault where the memory cannot be 'read'.
 
I am going to create a VI to replicate this problem, as all I have to do is hide and show tabs; but I will probably not have it until next week. I was wondering if anyone has run into simliar problems with LV version 6.1? I guess if there is no fix for it, I can always just create entirely different tab controls and hide the whole thing instead of hiding and unhiding tabs?
 
Thanks for your help.
0 Kudos
Message 1 of 5
(2,962 Views)

This bug was fixed in LV 7.0 and later...

 

Joel

0 Kudos
Message 2 of 5
(2,958 Views)
Does that mean I'm out of luck unless I upgrade?
0 Kudos
Message 3 of 5
(2,946 Views)
I wrote an application in LV 6.1 where the central part of the UI was a tab control. Each page (tab) was labeled according to function, etc. The user's level of privilege determined what pages were visible. In order to do most of the useful things possible, the user had to initialize hardware. I kept hardware-enabled pages disabled and grayed until successful initialization. I had no problems with that strategy.
 
I never tried to programmatically hide or show pages except at startup (user login). Maybe it's lucky I didn't.
 
As a user, I'm not sure I'd want tabs disappearing and reappearing. It might be confusing. It may be better to disable and gray, then re-enable, instead of programmatically hiding and showing. That's just a thought, as I haven't seen what you're working on.
 
But I'm happy to know that programmatically hiding and showing tabs in LV 6.1 may not always work well. Thanks for the info.
 
::Marty
0 Kudos
Message 4 of 5
(2,931 Views)

I don't have LV 6.1 to test, but I thought I remembered a bug like that...

 

I would write a real simple app to test the crash behavior (4 tabs, one control per tab, that sort of thing).  I could be that there is a certain type of control (blinking property = true, a graph, a thermometer, etc) that is causing the issue and not the tab control.  The above test app would help to test that.

 

As for alternatives, there are two that I can think of.  The first (and least hack-ish... while still being a hack...) is to move a decoration (via property nodes) on top of the page that you want to dosable.  You can track vs what page is showing, and if page = magic page, and user = magic user, then move a decoration (that normally lives "off screen" over the tab page.  Giant hack, it requires very little code, and can be easilly removed when you upgrade later.  The second requires more work.  You can put the objects on the tab control pages into a cluster, and then disable the cluster.  This requires (lots) more work, but would give a more consistent user interface to the operator.

 

Other than that, I can't think of any elegant workarounds...

 

I definately recommend building the small test application first.  You want to make sure that the tab control is cauing the problem before attemping any hacks.  I know that LV 6.0 had issues like this, and I was surprised to hear that you are seeing this problem with LV 6.1.

 

I tested in LV 7.1, and the crash does not occur.  After I tested, I came up with something else you can try.  Try setting the disabled state for the page(s) to "Disbaled and Grey" (state 2) instead of making it invisible.  Then the tabs won't have to redraw, which might work you around the crash.

 

Let me know if you have any questions.

Joel

0 Kudos
Message 5 of 5
(2,918 Views)