Disable and hide Input Widgets

Hey @Rakitha.

This is an area where work has started in the last couple months. We often get asks about things that fall into the bucket of widget formatting through triggers. These include:

  • Resize widget in trigger
  • Change widget width, height in trigger
  • Enable/disable button in trigger
  • Make widget invisible in trigger
  • Move the X and Y position of widgets in triggers

The underlying limitation right now is making it easy (or even possible) for you to select the widget you want to do these formatting changes to:

I have 25 buttons, how do I know which one is which from a dropdown? What if they all have the same text on them?

You may have noticed in r230, that all widgets now show up in the step tree-
image
Coming very soon you will be able to rename and group these widgets. This visibility to all of the widgets in your app in one step is the first step to being able to identify what widget you want to impact.

So in short - We are just beginning the work to enable this sort of functionality, but the scope of this work is fairly large, so I wouldn’t expect to see this functionality full incorporated in 2022.

Thanks for bumping things you run into, this is how we drive focus on what we work on.
Pete

Hi Pete, Great to see tulip team so active in the community. Every time I have a question I lookup knowledge base and the community. Thats why I keep bumping old posts.

I did notice the step tree, and I love it!

The underlying limitation right now is making it easy (or even possible) for you to select the widget you want to do these formatting changes to:

In terms of the above, from my previous experience (Rockwell CCW, Beckhoff TwinCAT) the Widget name can be edited in the properties pane. (I hardly renamed anything, there was no need for it)
The hide or disable options were also a field in the properties where we can link a variable. See the screen shots below. I believe Codesys has the same approach, not sure about Siemens.



The reason I compare Tulip to PLC HMI is because I think there will be more automation engineers using Tulip than front end developers.
Actually out of interest I would like to know what the demography of Tulip 'developers". (if you are in liberty to discuss).

Hey @Rakitha-

Thanks for this added context! We are always looking to duplicate the patterns seen in the other tools our customers are familiar with.

The typical app builder persona varies a whole lot, but to generalize-

  • Most app builders are engineers in a direct support role for manufacturing. Disproportionally new customers come from companies that either are new to production software, or have gone around and around and around with legacy systems, never getting the flexibility they need.
  • Common software experience: Excel (maybe a little visual basic), the microsoft suite, Email clients, some basic data visualization experience (but probably not sql), some programming of some sort (ladder logic, or something like python).

I came from a Tulip customer and fit this mold pretty much exactly. I constantly found places where I needed simple software solutions, but I didnt have the software background needed to make these tools (and make them stable enough for for 24/7 production), this is where Tulip slotted into my toolbelt.

Pete

1 Like

do we expect this feature in next release?

Hey @mcc6025 -

Sometimes we can sneak smaller features into the release cycle, but getting this done, and getting it done right is something that is a bigger engineering ask.

Widget configuration in triggers is at least a few months of work for a sizable chunk of the engineering team that works on the app editor. These bigger asks have to follow the normal product roadmap process (and cant sneak to the front of the line, like quick wins). right now that roadmap doesn’t have this work starting in 2022, but we don’t have too much clarity past the end of the year.

In the meantime, this can absolutely be done with custom widgets:

If you are interested I can make an example of this sort of custom widget and share it here.

Pete

1 Like

Hey @mcc6025 -

I threw together an example custom widget for this function-

This widget takes two inputs, a boolean for enabled or disabled, and the variable the user input will be written to. This is kinda bare bones and lacks some flexibility with the normal text widget (like font size, background color, etc) but that could quite easily be added to this structure.

This can be imported/edited/improved in your instance by going to account settings → Custom Widgets → Import. (must be on r230/LTS8 or later).

NOTE: I am not a software developer, and this widget hasn’t gone through the same level of code review a Tulip library plugin would, use this at your own risk
customWidget-Disable Text Input.json (2.3 KB)

It took longer to make this post than it did this widget.

Hope this helps,
Pete

2 Likes

I was trying out custom widgets last night and ended up doing the same as you did. But I cheated. I used this example from the Tulip library https://tulip.co/library/apps/custom-text-input-widget-unit-test/
Now Im learning more about HTML, CSS and JS. Very exciting !! :grinning:

Hey Pete,

I imported the custom widget, the custom widget works well . since we can control the disable/enable of textbox, we also can control the visibility as the same way via a boolean variable.
Thanks for your post!.

@mcc6025 Absolutely! A $('#inp').hide() and $('#inp').show() call on the element will make it completely disappear and reappear!

@Rakitha we share them so you can cheat from our examples!

Pete

1 Like

I read the article Custom Widgets Overview | Tulip Knowledge Base - Support for Building Operations Apps.
but unfortunately, the youtube website is blocked by China government. I am unable to watch the Example widget build video. I hope tulip team can demo or write an article how to build custom widget. such as disable text input custom widget.

Hey @mcc6025 -

Hadn’t thought about this limitation- Here are the videos in that article.

Should be able to import the widget I made into your instance and explore the code if you are curious.

Quick Overview - Custom_Widgets_Crash_Course.mp4

Demo Gauge Build - https://tulipinterfaces.wistia.com/medias/kmqr319jiw

Input that auto advances on enter - Auto_Advance_Inputs.mp4

Hope this helps-
Pete

Hi Pete,

Yes, I am curious those widget. Would you please import those widgets into my instance?

My instance is iff-chfi.tulip.co

Hey @mcc6025 -

Imported it here: Tulip

Pete

Hi Pete,

Thanks that you imported the widget for me. I also imported two widgets by myself.
by the way, do we have Combo Box custom widget?

Hey @mcc6025 -

Totally! It was as simple as changing the HTML to that of a single select. I used this webpage as an example:

The tricker part of this is making it act like a normal widget where you can pass it a list of options. To do this I:

  1. Added a Options prop
  2. Added a function that is called every time options changed
    3.This function first cleared out the list of options
  3. This function then added each option back.

Feel free to explore the code!

Note: This widget didn’t go through the code review process a normal Tulip Library Plugin would, use it at your own risk
customWidget-Disable Single Select.json (3.1 KB)

Pete

Hi Pete,

I added the ‘hide’ capability you mentioned earlier.

customWidget-Disable Text Input (copy) with hiding.json (2.6 KB)

@wkurth4008

1 Like

Reading this post I think it is obvious that we can achieve a lot by using custom widgets, but the original suggestion by simple configuration to hide existing pre-delivered input widgets using simple boolean variables is still very much relevant.
To get around it we e.g. make buttons transparent and make sure the trigger does not fire if transparent. Or we duplicate the step to make specific fields greyed out and place a box on top so they cannot be used to give the end user the feeling of specific fields made irrelevant for the data entry when not required. Managing this without resorting to custom widgets would still make sense to me.
Please vote for this product suggestion if you agree :slight_smile:

2 Likes

Hey @ASharp-J -

Totally agreed. This request has languished for some time because the right way to solve this is to enable a whole bunch of widget properties to be driven dynamically:

  • Focus
  • Disabled/Enabled
  • Hidden/Unhidden
  • Widget-specific properties, like labels
  • etc.

It’s a balancing act between a quick win and a long-term vision. We don’t want to build a point-solution without considering the longer-term gaps we want to fill. The underlying need for this sort of flexibility is something we are actively tracking, and a lot of thought is going into the right way to approach this problem.

Pete

Hi @Pete_Hartnett, do you have any updates on this feature and when it might be released? The ability to show/hide widgets would be really useful.

Thanks!

Hi @Pete_Hartnett,

I’m also interested in getting an update…

Also:
Maybe we should streamline those topics:

Being able to programmatically enable/disable objects - Product suggestions - Tulip Community

Hide button on Steps, click on print button - Support, Troubleshooting, & App Help - Tulip Community

Hide objects like single select - Support, Troubleshooting, & App Help - Tulip Community

Hide button in tulip - General - Tulip Community

Is there some way to hide or make visible a specific control - Product suggestions - Tulip Community

To me this shows there is a strong wish, but some do not use the search before posting, so there are several threads, that could be closed and linked to this one or so…

What do you think?

5 Likes