Does anyone know how to create a custom popup or modal ?
The challenge I’m facing is that I need it to appear in front of all the other widgets. And I dont want to allocate any (maybe a little) space on on the step.
The workaround I have now is to create an event and setup a trigger for “Show message” but I would like to do this in JS and not do the extra work.
You hit on one of the key limitations I see with custom widgets as they exist right now, there isnt a way to make a widget truly disappear so it can be clicked through. The right way to approach this is something we are actively thinking about
Expose widget attributes within triggers, so you could set the size, position, show/hide, maybe more from triggers directly. This would enable clickthrough, this could enable truly hidden widgets, but also basically only suits this usecase (and a few other small ones).
Exposing this ability to hide the entire Iframe that contains the widget from the custom widget UI. This is the easiest short term solution, and something we are discussing.
There are two sticking points we are struggling with:
How do we display this on the app editor? If widgets can have multiple states on a single step, how do we expose each state?
This sort of functionality (especially the first approach from above) potentially enables an entirely different approach to Tulip app building. You could have a 1 step app where every widget for the whole app is off screen and triggers just move them into the frame for different steps. This is a mental model that is fraught with tons of issues that we are trying to avoid. We dont want you building apps like this.
Keep the ideas coming. They are driving great discussion.
Rockwell CCW shows the most recent state it was edited at, in properties there is a dropdown to select a different state.
Beckhoff TwinCAT (Codesys) left the iframe unpopulated. just a grey box.
I used this technique a lot in TwinCAT (CCW did not support iframes) where I had to show information from multiple similar machines. The iframe was populated with relevant info without changing the page. But I can imagine how supporting and troubleshooting something like this will be difficult.
@Pete_Hartnett, just a follow up question.
The HTML “<SELECT>” element used for single select are able to ‘spill’ out of the iframe. Ie, it is not bound by the dimensions of the custom widget iframe. In android (mobile phone) Tulip player the drop down actually comes up very nicely as well. I have not found any other HTML element that has this ‘spilling’ out property. Nor have I found out how or why the “<SELECT>” element is able to do this. I was not able to find any info online about this.
My thinking was that I should be able to use this ability to ‘spill out’ for other elements and create a popup that is outside the custom widget iframe. So far no luck at all on this idea.
A custom popup or a curtain menu like this will be so cool.
Im very new to HTML CSS JS, so pardon my ignorance.
Thanks for the insight about how others have handled these cases! I will feed that insight back into the development team for custom widgets! Certainly not insurmountable or challenges nobody has ever tackled, just something we need to come up with a gameplan for!
That spilling issues is a new one to me, can you export and share your custom widget here? A guide on how to do that is here:
This “spilling” out is not really an issue. It is a ability that I would like to harness. (Me calling it “spilling” was probably not a good idea, I didn’t know what else to call it) This feature is not limited to custom widget as well. If we consider the built in tulip “single select” and “multi select” widgets they too behave the same way.
When we create a step in the app editor these widgets takes the dimensions defined in the properties in its “non-expanded” form. However when we run the app and when we click on it is able to expand and show all the items in the list. This list appears in front of all the other widgets, and it is not bound by the dimensions defined in the app editor. (Which makes it a drop down.)
So how come only the select object is able to not have dedicated space defined but be able to grow when needed. So there should be something special about the “<SELECT>” HTML element. Can I use this same magical ability to create popups? If you tell me its just how it is, I will except it… , but there is possibility there is an CSS keyword that lets me control this magical feature… lol. customWidget-Custom_Dropdown_v1.json (7.8 KB)
So, the select dropdown is a native HTML component, so it acts a little different than any other custom widget. The select tag is managed by each operating system, which is why the same custom widget looks/works different on different device types. The device recognizes this element type, and when it is clicked on, all of the behavior is managed by device natively.
We are investigating the ability to enable the ability to completely disable a custom widget, so it would be click through. Can’t yet commit to a timeline to deliver this functionlity.