PDK Limit "Write Parameter" ?

[ddufour]

Hello,

I am developping a plugin asking for a I32 and I would like to know if it was possible to limit the value so the user can't enter a value under 10 for example.

Is there another way than checking in the Configure Session.vi if the value is okay?

Also, is it possible to write a comment in the settings window of the plugin? For example : Don't enter a value under 10

Thank you!

[Kevin_F]

Checking the value and setting it back to an in range value in Configure Session is the only way to achieve this today. We have considered adding functionality that made it so the UI knew about the range and didn't even pass it to the plugin.  If that would be useful for you we can add it in a future release.  If the user entered a value out of range would you want it to coerce their value to something in range or highlight the control as an error and prevent them from starting the test until it was fixed - it could also have an auto-generated tooltip saying that the value is out of the acceptable range?

The only text you can currently change in the settings window of the plugin is the label of the controls. I can see the value of being able to add a status control to the popup that lets you display read-only text.  I can see it being useful as normally formatted text inline or as a special text field at the top or bottom of the control with formatting to draw the users attention.  Do you have a preference/other ideas on how you would like it to look/behave.

Longer term, our working plan is to allow plugin developers the option to have complete control over the settings UI, probably by letting you plugin in a NXG VI in place of the settings dialog. If there is demand for this level of control of the plugin UI we could potentially start working on that sooner.

[CyGa]

Hi Kevin,

Checking limits is a must have.

It is a very bad user experience to say that configuration is not good after closing the popup. When you press OK, you expect that everything entered is valid. Other wise you can't click OK, or at least you get a message preventing the configuration popup to close with unvalid settings.

If the detection can be 'live' (right after the user enters a value), I expect the value to be coerced.

If the detection of a wrong value is done at the time of closing the popup, then I would expect the control to be highlighted.

To me the tooltip should not only appear at the time of validating the values. It should be always visible and reminding the min/max value authorized.

For the read-only text, we use the labels for now. And it is very ugly, both on the user interface and on the diagrams.

Having a free text zone (like in VeriStand) would be great. It would be like adding a control on the interface but it does only retain the text enter at edit time. And it cannot be modified by the user (so it is a Disabled String Control). Being able to set the font and colors inside this indicator would be great (maybe using some sort of markdown).

In the long term, if we could build the interface ourselves would be wonderful. We could still map intersting values to configuration data thanks to the API. But it would give so much value to the configuration !

In our previous plugin, we had to develop kinda 2 setting popups to enter and validate the email settings.

If we were able to design the configuration popups ourselves, we could have use tab controls to separate settings and to interact with the email server directly from one popup.
This option would be really really great ! Except for one thing : developing a plugin would require LV CurrGen and LV NXG development... IMO that's one IDE too many.

[Kevin_F]

Thanks for the feedback.  I'll add these to the top of the PDK feature request list and I can update here when we get them into a release. 

Also thanks for the "IMO that's one IDE too many" feedback. This is something I have been wondering what plugin developers would think about.  We also eventually plan to support a NXG plugin. If you had to pick the order you got those things would you rather have the NXG plugin first or the completely configurable UI that required two IDEs first?  Hosting a CurrentGen panel inside FlexLogger is something we would like to avoid for a couple of reasons, including that its very difficult to get right.  

[CyGa]

Hi Kevin,

To answer your question, it depends of the plugin ! 

If the plugin requires functionalities that are all well supported by NXG, then going full NXG would be fine ! Most of the complexity is handled by the API, so I guess we could develop it all with NXG.

The two IDEs combined is a non sense to me if it is only to build an HMI.

When adding webVIs to an existing project, I can understand that I need to go with NXG AND LV CurrGen, because LVCG do not have the feature to do it alone.

But for a simple HMI... It would make the development (and support) complicated just because we need an HMI...

So I'd go with an NXG plugin first !

[CyGa]

Hi Kevin,

To answer your question, it depends of the plugin ! 

If the plugin requires functionalities that are all well supported by NXG, then going full NXG would be fine ! Most of the complexity is handled by the API, so I  we could develop it all with NXG.

The two IDEs combined is a non sense to me if it is only to build an HMI.

When adding webVIs to an existing project, I can understand that I need to go with NXG AND LV CurrGen, because LVCG do not have the feature to do it alone.

But for a simple HMI... It would make the development (and support) complicated just because we need an HMI...

So I'd go with an NXG plugin first !