How to create a type def of a tab control?

[Ben]

---

@DahlmanR wrote:

Hello!

Decisions are made on a case-by-case basis if a patch will be published. This usually depends on the effects of the patch itself (severity, number of individuals affected, etc). 

Did downloading the patch solve your problem?

Rachael Dahlman
Applications Engineer
National Instruments

---

Help an old man out.

Does that fix correct the problem I started this thread about?

I would like to avoid the "take two upgrades and call me back in the morning">

Ben

[JÞB]

---

@Ben wrote:

---

@DahlmanR wrote:

Hello!

Decisions are made on a case-by-case basis if a patch will be published. This usually depends on the effects of the patch itself (severity, number of individuals affected, etc). 

Did downloading the patch solve your problem?

Rachael Dahlman
Applications Engineer
National Instruments

---

Help an old man out.

Does that fix correct the problem I started this thread about?

I would like to avoid the "take two upgrades and call me back in the morning">

Ben

---

No Sir.  I hijacked the thread with other unrelated Tab issues then kept it in the original hijacked thread when I hit a bit of a side effect from the patch.  (While reinstalling about 54 products and 14 updates. ). I am not liking Tabs any better today.  But, at least reordering tabs in a container might crash LabVIEW less often.

I humbly crave your pardon.

[DahlmanR]

Hi, Ben! 

I'm following your workflow here (with "here" I am referring to the example you posted with 5.zip files) and working in LabVIEW 2015 (no patches, not SP1) as you mentioned you're working in it.   When I close the control editor, I'm see a broken run arrow on the main tabs.vi, but after hitting Ctrl+S to save, the VIs can all be compiled, the tab controls are updated to the new name,  and the constants in the subVI are updated with the new tab names. When I open your example, I have the coercion dot from the beginning in the main tabs.vi, even before editing the type-def. 

What specifically are you seeing in your example that is not what you expect/is causing concern? This forum post got a bit convoluted in the middle, and want to make sure I'm addressing the specific questions you have. 

(Jeff, from my testing I see the patch seemed to solve the tab reordering crash that you saw, but also didn't see a removal of modules on my side. An interesting thing that happened to you, but a separate issue from Ben's.)

[Ben]

I have seen multiple issues.

1) The broken run arrow

2) The coercion dots

3) If you play with the control editor, there are some times when it will prompt for "discard or abort" which only gives the option to throw away the changes or stuck in the control editor.

Keep poking at it. Eventually it should screw up. Frustrated the HE@# out of me trying to recreate the issue to share.

Ben

[JÞB]

---

@DahlmanR wrote:

Hi, Ben! 

I'm following your workflow here (with "here" I am referring to the example you posted with 5.zip files) and working in LabVIEW 2015 (no patches, not SP1) as you mentioned you're working in it.   When I close the control editor, I'm see a broken run arrow on the main tabs.vi, but after hitting Ctrl+S to save,  Hitting the broken run arrow or Ctrl+R also recompile and run the "Broken" vi.  VERY odd

the VIs can all be compiled, the tab controls are updated to the new name,  and the constants in the subVI are updated with the new tab names. When I open your example, I have the coercion dot from the beginning in the main tabs.vi, even before editing the type-def. 

From playing further with the zip (2016 no patch) Strictly type def-ing, the tab.ctl,  the ref to the tab container and the tab reference .ctl itself results in no initial coercion dots wiring the tab select enum to the value property of the tab container and tab name change updates to the Tab ctl type def are applied as expected.  HOWEVER! (comma - pause for effect) if any edits are made, like changing something to non-strict and then changing the tab names, a coercion dot will appear on the enum wire at the tab value property node input.  This appears to be un-recoverable! once you get that coercion dot it is there for good!  I have not found a repeatable method to get rid of that coercion once it appears. (Odder STILL!) 

What specifically are you seeing in your example that is not what you expect/is causing concern? This forum post got a bit convoluted in the middle, and want to make sure I'm addressing the specific questions you have. 

My Fault!  In my defense, I wanted Ben to consider other potential pit-falls then, after the thread got "Solved" I continued to hijack it it with other data.

(Jeff, from my testing I see the patch seemed to solve the tab reordering crash that you saw, but also didn't see a removal of modules on my side. An interesting thing that happened to you, but a separate issue from Ben's.) 

Yes, I'm working that separate with Austin.  I owe a call to a 512 number but, I slept in a bit late this AM after being up till 3:45 fixing my install. (I really need a SS Hard Drive!)

---

I'll touch base via PM with Ben and see if we need to split, merge, spawn or link some posts to hopefully improve the value of the knowledge gained here.  I still hate Tabs.

@Ben, Hit me via PM with ideas to help us fix my rude interruption of your needs

@ DalhlmanR- Can we get a bit of history on CAR 603092 (version found, versions impacted, developer summary.) also, any CARs related to Enum Type propagation that may be impacting Ben's woes?)  Feel free to reply to a forum under NDA. 

[Ben]

Correct me if I am wrong you seemed to confirm seeing the odd option dialog when trying to close the Control editor.

Why would I ever want to exclude the only other person that has actually seen the problem.

It would be like trying to shut-up the only other person that can attest to my sanity.

Interupt away!

Ben

[JÞB]

Just to close out a painful issue that showed up while helping out.  

Issue reordering pages in a Tab Control crashes LabVIEW : CAR 603092

"

Edit

Create a tab control
Type def it
Save it
Drop it on a new vi
Save the vi
Open the type def
select reorder tabs
reorder a tab
launch LabVIEW again- it just crashed"

is resolved with the LabVIEW 2016 f1 patch

Installing the mentioned Patch unregisters several LabVIEW Modules: 

RESOLVED by reinstalling NI Software Reference Library from Media and Re-installing Updates VIE NI Update Service.  Painful but, this cannot be duplicated by NI or Myself on another machine!  Working theory is that my specific machine has a service from AVG Technologies that interfered with registry entries during the update process.  

Thank you Angela Li (NI App Engineer) and the Service Support Team! 

[DahlmanR]

Did either of you have anything you consistently did when playing in the tab control that caused the "discard or abort" message? Trying to recreate on my end and haven't had any luck so far in 2015.

[Ben]

Selecting a tab near the middle of the collection and editing the name to make it larger... maybe?

It was hard to get the error but it seemed that it would give me more prompts to discard as I added more tab pages.

Ben

[JÞB]

Selecting a page that causes the page rows to display re-ordered or,increasing the page text strlen of a page such that the page row display refreshes by moving pages between rows seems to be a "Theme" for getting a strictly typed Tab Container.ctl to show that broken arrow on the ctl's callers.  (NOT rigorously tested but, there is no UT you could write to find it since UTF tests a scripted dup rather than source)  That means NI only investigation is really possible.  Sorry R.