using control refnums in srtict typedef cluster

[Baji]

Hi JK,

  Thats Cool, Ya if there is such option as u metioned will be great. I also suffered with this problem many times. In the upcomming versions NI Incorparate this feature will be great. Comments are welcomed.

[Ben]

I don't have time to go through the code but here are ideas.

1)

Stricts are used to control appearence standards. Go with non-strict type defs if possible.

2)

Maintaining a type def to a tab control will be rough since any changes to its conents will require it be updated.

...

Ben attempts to outline proceedure.

 ....

Defines type def for tab control.

....

Edits typed

aply changes

....

LV 8.5 crashes!

There is a bug hiding here and have to go to work now so can not X-shoot anymore.

Create a type of a tab control

Drag it into a ref container

Use container to type cast ref from a tab control.

Edit the type

crash.

Gotta run!

Ben

[psmorris]

I agree that there appears to be a bug hiding in here somewhere, I did what ben outlined whilst playing with this earlier and had two crashes (8.6.1) in a row... but only when the refnum was inside a cluster... If I do:

Create tab control type def and save

create control refnum

Open tab type def, drag into refnum

create cluster

drag refnum into cluster

I get no error.

If I put the refnum inside the cluster and then try to drag the typedef'd tab control into it - then it would crash.

In response to the other bits.. the reason I went with a strict typedef of the tab is that I found myself inadvertantly resizing the tab in my main app whilst playing with the FP. So I strict typed it so as I couldn't do that!!

Maintainin a type def of a tab is not so bad. Its only the page names and order which are stored (not any controls placed on it - in fact you cannot create a custom control consisting of a tab controls with any other control placed inside it...) or, in the case of a strict typedef, its the page names/order and the overall appearance - again excluding page content... 

The problem I'm having does appear to be as JK said, the two strict typedefs (i.e. the refnum to the typedef'd tab control and the tab control itself) do not appear to "communicate" with each other... I really think they should!

Any more thoughts anyone? NI got anything to add?

Cheers

Paul 

[SheelaS]

Paul,

Sorry there's been a delay getting back to you.  I have been trying to recreate the issue, and find out why you are seeing this issue.

I agree there is certainly an issue with linkage between the tab control strict type def and the refnum for it in the code you originally posted.  However, if I create the setup from scratch, I do not run into any of the issues that have been mentioned in the thread so far.  LabVIEW has not crashed on me, and changes to the tab control refnum do not cause a broken arrow.  Please see the attached vi and ctl files, changes to the tab control strict type def do not cause any errors.

FYI, the steps I used to build this VI and the ctls:

1. Place tab control on front panel

2. Customize and save as strict type def, replace existing control with new s.type def.

3. On Front Panel, right click tab control, select Create > Reference

4. On Block Diagram, right click reference, select Create > Control

5. On Front Panel, place cluster container

6. Place tab refnum control in cluster

7. Customize cluster and save as s.type def, replace existing control with new s.type def

8. On block dia, place unbundle by name, and wire in cluster and tab reference, save the VI

9. Edit and save changes to tab s.type def - no broken arrows.

10. Add boolean to page one of tab control

11. Create reference and refnum control as per steps 3&4 above

12. Disconnect the cluster from the s.type def

13. Place boolean refnum control in the cluster

14. as step 7

15. Extend the unbundle node and wire in teh boolean reference, save the VI

16. as step 9, still no broken arrow

Repeat 10-16 to include the string, slide and numeric.  Any changes to the tab control s.type def updates fine.

I have also tried the steps given in your last post, and this still works, in both 8.6 and 8.6.1

If there is something you have done differently in your way of creating the VI please let me know, as so far I cannot see an explanation for the errors.

Regards,

Message Edited by SheelaS on 03-23-2009 11:46 AM

[Ben]

Are you creating a type def'd refernce to the type def tab and then editing the tab's typed def?

That where LV blows-up.

Ben

[psmorris]

Note to self... don't try to reproduce crashes in labview whilst the same machine is running an experiment using labview code...

The order of things outlined by Sheela seems, at first glance, to prevent the crash and also prevents the type def'd cluster containing the refnum from becoming broken. But it seems (during my last try - I'm not able to try again because of the afformentioned experiment!!) that the refnum no longer contains the real tab control. For example, if you click the refnum and select show control, the control shown will not reflect changes to the type def'd tab control.

By the way, adding controls to the tab control doesn't affect the typedef in anyway... these controls are not part of the tab as such (try adding a control to the tab within the .ctl file of the type def...) and so don't affect anything. The thing that breaks it, is adding a page, or (in the case of strict typedef) any modification to the appearance (i.e. size, colour etc)  of the tab control.

If I have time I'll install labview on a seperate machine later on and see if I can try again following sheela's instructions!

Thanks!

Paul

[SheelaS]

Hi Paul,

The reason I included the extra controls was to see if it was something to do with the cluster that was causing the refnum to cease updating. 

I have been trying out the drag and drop method of creating the refnum, and it would seem that if you customize the refnum and save it as a strict type def (in or out of a cluster) that this is where changes to the tab control fail to fully update the refnum control.  Although, if you show the control in the refnum, the visual changes do update.  My thought is that there is something about the data in the reference itself that changes and cannot update once the refnum control is either a type def or strict type def (or contained within a cluster saved as a type/strict type def control)

My recommendation for a work around at the moment would be to leave the refnum controls as controls, as these accept and update with the changes to the tab control strict type def.

I will keep looking into why this is the case tho, and if it is expected behaviour or not.

kind regards,

[Ben]

Hi Sheela,

Could you please post the CAR# for this issue?

Thank you!

Ben

[SheelaS]

Hi Ben,

I will indeed post a CAR# as and when I create a CAR for this issue, however at the moment I am still investigating the reason for this.

I will keep the thread updated, promise!

[Ben]

---

SheelaS wrote:

Hi Ben,

I will indeed post a CAR# as and when I create a CAR for this issue, however at the moment I am still investigating the reason for this.

I will keep the thread updated, promise!

---

Please escalate this issue if you are having trouble.

The earlier a CAR is filed the earlier we can realize the fix.

Ben