Ignition 8.1.20, Perspective:
I'm curious what the best practice is for closing the respective popup which contains a 'Close Popup' button? ...if a popupId is not known? ...if the 'Close Popup' button exists within an Embedded View of that popup?
Per insight from link below, we are using a script action within onActionPerformed of a Button object.
Is it desirable to name the popup Id during closing? If so, is there a clean method of grabbing the popup's Id property?
Perhaps another question would be: What is the specific action that is performed when the built-in "X" is pressed (located in title bar, when 'Show close button' is selected on popup creation)?
I forgot to mention, there is an issue with the aforementioned script we are using, whereby the 'Active Popup' closes instead of the parent popup containing the button.
This issue rears its ugly head only when multiple popups are open, and when the user clicks quickly on the close button of an inactive popup.
The native X button of the Popup does not care about the ID - that's the browser operating on HTML components without regard for their content. If you want Perspective to operate on a Popup, you really need to provide the ID of the Popup. I recommend that every time you open a Popup you do so one of two ways:
Using a Script Action or Popup Action, pass the identifier used for the Popup as a param to the View. Then from within the View, any Button should reference that id param of the View. If you need to have your "close" button in an Embedded View of this View, then you need to continue passing the param down the chain. This is the best approach because No View is responsible for hanging onto some ID that might be changed elsewhere.
Are there any updates planned that will enable a popupclose(self) feature?
I have implemented the workaround of passing the popup id into the popup as a parameter however I am getting problems when people implement standard popupclose('') in my project.
I nice solution would be to add to the popup component a property naming the specific popup id.
No, because Views (and by extension their children) have no idea they are even in a Popup. Views are - for the most part - not very intelligent and only know about the Page they exist on because they understand they must exist on a Page and therefore have access to page properties. There's no such guarantee any View belong to a Popup, or a Docked View.
Even if we opted to create a new function along the lines of system.perspective.closeWhateverPopupILiveIn(), There could be instances where it's invoked by a component that doesn't live in a page. Is the function idempotent when invoked within a View which is not in a Popup? The abstraction I mentioned earlier where Popups don't know much about how they fit in the grander scheme holds true for Embedded Views as well, and so how would this function work nested one, two, or N levels deep inside a View?
There is no Popup "component", but I'll assume you just meant to the Popup concept or mechanism. How would the View rendered for the Popup access this "injected" property? We'd have to have some sort of mechanism for the Popup to expose its ID to the View which will be rendered within. Something like... you guessed it: View params.
Couldn't ignition just sort of handle this for you?
In some sense, a view COULD know it's been opened as a popup... because on creation it was created by a popup action or a script system.perspective.openPopup() call.
Ignition could pass a flag to the view marking it as a popup.
Then, if it's ever called to system.perspective.closeSelf(), it checks its is_popup flag, and if true, closes itself (presumably the id is known behind the scenes). If it doesn't have the flag, the function does nothing.
Or, you pass the popup id as a parameter to the view, then use that id to close the popup. It's hardly more complicated than having more built-in functions. I don't think we need IA to hold our hand on this.
Which works perfectly...when all Designers are aware of this feature / limitation, and it is correctly implemented. It's not an issue that rears its ugly head until a power-user shows up (opens/closes multiple popups) and starts asking questions. Often, the closePopup('') button passes the initial test, & popup is deployed...
The software architecture matters here... but happens to be different from nearly every other HMI platform out there. I'm happy with the proposed solution, but also believe it's a reasonable (& minor) grievance.
Conveniently, an update was made which might alleviate some headaches on this topic: from Ignition 8.1.30 Release Notes:
"Fixed an issue that was causing the last opened popup to be closed instead of the top most popup when system.perspective.closePopup is called with an empty string passed in as the popup ID."
I understand that it might not be the way other platforms do it, but I'm pretty sure we love Ignition for what it does differently. Would we want IA to change direction and start copying others ?
In this particular case, maybe concurrent platforms offer a self.close built-in function. But are the possibilities of their popups as vast as what ignition allows ? Is passing an id to the popup to have complete control over it too high a price ? I'm fine with it and I'm sure most people here will agree with this.
A feature regression is not at all on my want-list.
On the contrary, I prefer to take advantage of the named popups, especially with Toggle Popup. Zero complaints there...
To be clear, what I'd like is:
system.perspective.closePopup('SomePopupId') to continue to operate exactly as it does. Close the popup with Id that is passed to the function.
system.perspective.closePopup('') to either:
a) Close 'THIS' popup (note that this works much better as of 8.1.30). Have the function work the same way as the 'X' close popup button does. Well, because, what else would you expect it to do?
b) Have no effect at all. Remove the limitation and force designers to pass a popup Id in order to close the popup. This, to me, is preferrable than inadvertent closing of the wrong popup.
Since neither (a, b) are likely to happen. I'm content with the solution in this thread.
A feature regression is not at all on my want-list.