Jump to content

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

Steen Schmidt

By Steen Schmidt,
in VI Scripting

 Share Followers 3

Recommended Posts

Steen Schmidt

Steen Schmidt 23

Posted
Posted (edited)

Hi.

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

post-15239-0-07675100-1353335070.png post-15239-0-67403500-1353335126.png

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:

post-15239-0-30746700-1353335168.png

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 by Steen Schmidt
Link to post
Share on other sites
Yair

Yair 227

Posted
Posted

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

).

Link to post
Share on other sites
Steen Schmidt

Steen Schmidt 23

Posted
  • Author
Posted (edited)

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 by Steen Schmidt
Link to post
Share on other sites
Stagg54

Stagg54 15

Posted
Posted

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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Followers 3
Go to topic listing

  • Similar Content

    • Flavien
      Control picture zoom
      By Flavien
      Hi guys,
      I am trying  to make a picture controler on my interface. I can drag and zoom my picture but my zoom is too bad ....
      My picture is big and I didn't find the way to make a zoom on the center of my indicator image with the zoomfactor. All my calculate tries failed and my reseachs on the web failed ...
      I am not really sure if i am clear but I can answer your questions.
      Best,
      Flavien
       
      Control_Picture.vi
    • Zou
      Refresh Palettes for All Installed LabVIEW versions
      By Zou
      I don't want to manually launch all installed LabVIEW versions one by one, and call this method.
      Is there a way to do this in one version to refresh palette for all installed versions?
       
    • Voklaif
      Finding Controls in LV executable
      By Voklaif
      Hello all,
      I am looking for a way to find controls on an executable LV program. 
      I need this function because I want to automate a series of tests (user mouse clicks for example) on an executable LV program.
      The normal tools who does it with windows objects are not able to recognize LV controls individually.
      My idea is to find a way to recognize LV controls so I can interact with them individually.
      If anyone knows any third party programs to do automation tests for a LV exe that would also be highly appreciated.
       
      Best Regards,
      Vlad
    • bbean
      Re-Label Wire Xnode (useful for event registration)
      By bbean
      I put together a simple xnode to relabel event registration reference wires that feed into dynamic events of event structures.  With the increasing use of event based messaging systems, I found myself manually changing the name of event registration references to clarify the event name when multiple event registration references were used in an object. I did this by manually creating a cluster constant on the build cluster before the dynamic registration terminal on the event structure and renaming each registration reference.  Being a lazy programmer, this seemed tedious after a few times so I decided to attempt to create an Xnode to accomplish the same thing faster.   This video shows the "problem" and the potential solution using the xnode: 
      Re-Label Xnode - Event Registration
      Here's another example showing another use case with ShaunR's VIM HAL Demo code:
      Re-Label Use Case ShaunR HAL Demo
      This may have been done before or there may be an easier way to do this, but I wanted to throw it out here to see if there's any interest and to see if people will try it out and give feedback.  I've found it works best using quick drop for initial use (highlight wire, CTRL-Space,type re-label, CTRL-I, type new name in dialog) and for replacing or renaming an existing instance on the diagram (highlight existing xnode, CTRL-Space, type re-label, CTRL-P, type revised name in dialog).  You can also use directly from the palette, but I found much faster from quick drop and also seen a couple crashes replacing through the pallete.  
      The Double Click ability is also a work in progress.  Its purpose is to allow you to quickly rename the relabel with the same dialog box, but when it executes it breaks the wire on the output connection.  You can still re-wire it to the event structure, but you will have to open the Event Structure Edit Events menu to get the event to "Re-link".  Something I'm trying to avoid.
      The Xnode generated code is simply a pass through wire with the output terminal renamed to the label of your choice.  This seems to update attached event structures.

      - B
      sobosoft_llc_lib_diagram_tools-1.0.4.1.vip
    • bI0ndin
      Adding plugin in "VI toolbar"
      By bI0ndin
      Hi everybody,
      While I was having some time to develop new scripting stuff i wondered "would it be possible to add somme scripting stuff in the VI toolbar ? " (the one with run, run-continuously, abort, police stuff and so on). My point is to add kind of a combobox that populate with every events in the current vi for a control when clicking on it. And of course show the effective event and make it blink when selecting it in the combobox.
      The scripting part is almost done but i now come to the real problem : 
      "How can I add this piece of code in the VI toolbar ?"
      I know i can create either a Quidrop Plugin or a shortcut menu plugin but they don't fit the way i wan't to use this plugin.
      I asked some NI guy that told me the only options where the one above but I can't imagine that LabVIEW is not in some way developed around a "plugin architecture" so if any of you as plunge deep into LabVIEW's files and know where and how to achieve this goal it would be really nice
      Thank's everybody and I hope my question was clear.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.

  I accept