Dropping control from palette: making it wire up the conpane?

[Steen Schmidt]

Hi.

I have this 'Error & Warning' toolset with a functions and a controls palette:

The controls palette contains only a single control, basically a subVI dropping its contents on the front panel when dragged there. That contents is two error clusters so I don't have to visit the control palette twice to get those (there are a small number of additional changes to these controls, mainly label and caption formatting to match GPower style). When dragged and dropped I have this on the FP:

When dropping these it'd be nice if some additional stuff happened, like they automatically got wired to the correct connectors on the conpane (if they are available), maybe they placed themselves more conveniently than where you just happened to drop them etc. Now, I have been wrecking my brain about how to do make them do this. If I turn them into XControls it could probably be done, but I'd hate to turn something as fundamental as the error cluster into a proprietary XControl and litter those all over my (and other people's) VIs.

I can't seem to get anywere with scripting on this one - the VI isn't being run when it spills its contents when dragged from the palette.

Do you have any ideas, or is this too much work? I could maybe register some internal LV app event when the 'Error & Warning' toolset gets installed (it's a VIP), but that seems like a lot of work.

Cheers,

Steen

Edited November 19, 2012 by Steen Schmidt

[Yair]

If you do make XControls, you could probably have the it initiate a separate process when it's dropped which will receive the references to the dropped controls. The process will then delete the XCtls (or it could possibly be a single XCtrl and it will replace it with two clusters), replace them with error clusters, wire them and then terminate. I don't know if this has any potential pitfalls, but it seems like it should be doable.

Incidentally, I hate the no error text on the error cluster. If you're already making a template, you might as well remove it (and of course get people to vote for the relevant ideas:

Get rid of the "(no error)" part of the error cluster

Show the default value of controls in subVIs which aren't required in the tip strip

).

[crossrulz]

I was thinking of simply making a quick drop shortcut to do this. Just haven't found the time to make it yet.

[Steen Schmidt]

Yair, making an intermediate XControl delete itself after doing its stuff is actually a novel idea. I'll ponder that for a moment...

/Steen

[Steen Schmidt]

Incidentally, I hate the no error text on the error cluster. If you're already making a template, you might as well remove it (and of course get people to vote for the relevant ideas:

Get rid of the "(no error)" part of the error cluster

Show the default value of controls in subVIs which aren't required in the tip strip

).

I actually missed the above part when reading your post the first time - probably because the font was so large and in a different color that I mistook it for a commercial or something like that .

But anyways, I have already modified the label and caption of those error clusters. The labels are now "Error in" and "Error out" instead of "error in (no error)" and "error out". The captions, which were empty before, does now hold the default value by default. I remove those default value parentheses when "Error in" is required (which it actually is for some of the functions in my "Error & Warning" toolset).

The GPower style guide contains these rules (among others) regarding control/indicator labels and captions:

- No default value nor unit in the label.

- Labels start with a capital letter and every following word in the label start with small letters (thus "Error in" and not "Error In").

- Labels must be in bold.

- Control captions are "<Label><space><(default value)><space><[unit]>".

- Indicator captions are "<Label><space><[unit]>".

- The <Label> part of a caption is in bold, the rest in plain text style.

- Units may be left out of captions if the value is unit-less, else unit is required (also when there is no default value specified).

- Default value specifier may only be present in the caption if the control isn't a required input on the connector pane.

- Default value must also be specified for empty values (if the above rules state so). Such empty values could be "" (for strings), <empty> (for arrays), <none> (for variants) etc.

So, following the above these GPower error controls and indicators have captions like the ones you see in the image in my OP; "Error in (no error)" and "Error out". I remove the " (no error)" part of the caption when "Error in" is required.

I don't agree that the error cluster control should have special treatment when it comes to indicating its default value. I do find the connector pane tip strip indication (of some kind) of the default value a really good solution that would enable us to get rid of stating the default value in the caption of controls and indicators. So I've kudoed that idea. But no special treatment of the error cluster from my side. That said, the NI error clusters don't follow the GPower style guide, therefore they are updated for my use.

I'm not sure how a better indication of unit should be implemented. It would be great to get rid of units in the captions as well, and I don't think the current unit implementation on controls in LabVIEW cuts it for this purpose - it's much too rigid to use in practice, so I never specify units on controls in reuse VIs (you know, the unit field that can be enabled for numeric controls).

Regards,

Steen

Edited November 19, 2012 by Steen Schmidt

[Stagg54]

If you do make XControls, you could probably have the it initiate a separate process when it's dropped which will receive the references to the dropped controls. The process will then delete the XCtls (or it could possibly be a single XCtrl and it will replace it with two clusters), replace them with error clusters, wire them and then terminate. I don't know if this has any potential pitfalls, but it seems like it should be doable.

When i first read your post I immediately had the same idea. Yair beat me to it.