Add output to type specialization structure that outputs the number or name of the subdiagram executed

[jacemdom]

Usefull for debugging misfiring or overifiring frames when building a VIM with a lot of datatypes. Could simply output the frame number

Or could also output the complete frame name as a sting so that if the frame names become partially editable as suggested here, all would be coherently managed.

[AristosQueue (NI)]

Back on this idea... would these be numbers/names that you would want to be stable when the frames are reordered? Or do you want them to change when the frames are reordered?

[jacemdom]

Also was replying to..."Back on this idea... would these be numbers/names that you would want to be stable when the frames are reordered? Or do you want them to change when the frames are reordered?"

And when i hit post i ended up in the no man's land!!! Post lost 

---

@jacemdom

[jacemdom]

I was also tempted to code something myself, i already have autosorts for Events and Case structures, so i told myself must not be so difficult to go get the subdiagram labels and sort the frames myself but i can't even find the type specialization structure in the object model. Is it hidden or just another object like a simple multiple frame struct?

[jacemdom]

It's just to allow to quickly know which frame is misfiring or overfiring...like for example a datatype that is supported by a function I didn't know supported it will fire instead of the intended one. So when testing the VIM i plug the different datatypes and verify that the right frame is executed. So as long as the output follows what is written in the frame name it would be nice.

Of course the ideal situation would be to have the ability to append something to the actual names of the frames and then output this as well. So everything would be coherent and easily "reordarable" lol.

As nothing to do to with reordering really, just output the number or name of the executed frame.

[jacemdom]

This thread is making my head spin hahahahaha

Posts appearing and disapearing 

[AristosQueue (NI)]

> Is it hidden or just another object like a simple multiple frame struct?

The scripting class  for disable structure has three modes: Conditional Disable, Diagram Disable, and Type Specialization. (I wish it were separate classes, but that decision was made for Cond Dis and Diag Dis long ago.)

[wiebe@CARYA]

Does that mean an numeric output on the type specialization structure will also add the output to Disable Structures and Conditional Disable Structures?

I was going to suggest that, but it would be useful less often compared to TSS. But if it's more work to disable that for (C)DS, I wouldn't mind. (Might even be nice sometimes for case structures and event structures ).

[thols]

Maybe it could be useful having that ability on all structures, but its never been anything I have missed. And how should the output be formatted for say a string case structure? And how should each case be identified, by a number or be named or be the string of the case structure? What if the case string changes? And I'm not sure it should be visible by default but enabled by right-click, like enabling case-insensitive match. 

[jacemdom]

I think the output should probably be a string for all structures and simply the same thing we see in the frame or case name, including "Default" or whatever. Make it as simple as possible for NI and let the developers handle the string.

Like in your example the output should be ""vims rock!", Default"

[AristosQueue (NI)]

I think doing this on all selection-like structures would be a big overreach.

1. Returning the frame index makes sense on the TSS because that's a structure where developers need to actually pay attention to the order of the frames. That's not true of the Conditional Disable, the Diagram Disable, the Case, or the Event structures. Moreover, providing such an output on a Case structure seems like an encouragement toward something that feels like a big hack... consider this diagram. It checks a numeric and divides it into low, medium, or high ranges. Today, someone writing this would return a string, an enum, or maybe an integer if they didn't know any better. But if there were an always available output for frame index, they might just use that. That would be a bad practice to encourage, in my opinion. I can see it might have some benefit for debugging, but I don't know if it is worth the trade off.

2. But instead of frame index, maybe we could use selection ring text? I think that's also problematic. I definitely wouldn't want to enshrine the text in the selection ring as part of the language... that would preclude any sort of improvements in the usability of those structures. There's a minor change to the selection text of case structures in LV 2019 and a radical change to Event Structure "text" in LV NXG. Other shifts of syntax have been proposed over the years. If people were depending upon the text of these strings in executable code, we couldn't make changes like that. (To enshrine an editor aspect as a piece of the language means to make the generated code depend upon that aspect of the editor.)

3. There was also a proposal to return the text of the subdiagram label. I got excited by that idea -- seemed elegant and universal. But someone pointed out to me that the work involved in typing a label to every frame is largely the same as adding a string constant to every frame, so have I really saved anything? Also, labels get localized into foreign languages... having a label text exposed to runtime complicates that. (I know... most people don't translate their VIs into foreign languages, but NI does and some of our larger library and tools partners do.) So it's not quite the happy idea that I thought it was initially.