How to get a Popover to remember its values?

I use a Popover on an Export button, but if the user clicks away, the Closing Event is called and all field values are lost. There is no CancelClosing Event.

Ideally, I would like to hide the popover instead, so I can re-show all the same values they might have changed on the previous popup, rather than have them reset each time. Is there a way to do this (without having to link the fields to a parent field, like in the examples)?

The implementation doesn’t support popovers existing beyond being shown once. Save data on control value change if you want to keep it around, then pass it to new instances when they are shown.

1 Like

HI @David_Cox

I think you can find oneExample Project that does exactly that. You can use some back class / model in the calling window / control to store the modified values of the Popover as the user changes them… so you can set them again before showing the Popover. Popovers for Xojo Desktop, Web and iOS – Xojo Programming Blog

I have tried holding the Container as a Property of the Parent window and displaying this and, it works once, but all values are lost when the Popover is forcibly closed.

I now have a Class on the Parent with the full set of Property values which I pass to the new Container to be displayed and the Container updates the class’ values if they change. This works. Thank you @Anthony_G_Cyphers and @Javier_Menendez .

I have tried holding the Container as a Property of the Parent window and displaying this and, it works once, but all values are lost when the Popover is forcibly closed.

Yes, that’s the wrong way of doing it… because when you call the “Close” method or the Popover goes away (the user clicked on any other spot outside the popover)… the contained controls are closed too, as when you use a ContainerControl in any other scenario where it (or its parent window) is closed. So, as stated in the mentioned blog post, you need to create a new instance of the ContainerControl every time, and not relying in it stored in a property, because in that way the property <> Nil, but the ContainerControl contents are… well… empty (not existing / initialised controls)

Al in all… is how ContainerControls do work. Storing them in some sort of property is ok… always the ContainerContainer instance never gets closed, and that’s not the case when they are shown in a Popover; but as soon it is closed and you try to “embed” or “display” the container referenced by the property… it won’t work.

Try to run this example project to better understand it: ContainerReferencedByProperty.xojo_binary_project.zip - Google Drive

I now have a Class on the Parent with the full set of Property values which I pass to the new Container to be displayed and the Container updates the class’ values if they change.

… and that’s the right way of doing it! :slight_smile: :+1:

Probably would worth mark some of the answers as the “right” one so users can find it? :wink:

Just to clarify… is not about the Popover “implementation” but about how ContainerControl instances do work… when used in combination with a wrapping popover window type… or on any other scenario where they are used.

The real problem is that popovers weren’t designed to be persistent. I believe they should have been created as their own unique project item like DesktopWindow, so you could hold a reference in memory and show them whenever and wherever you like as many times as you like rather than having two separate implementations (DesktopWindow and DesktopContainer) with different results and code required for the same functionality and the objects being disposed of after being shown only a single time. But I digress.

2 Likes

@Anthony_G_Cyphers

Windows can be hidden, popovers not. As soon they were closed… even with the approach you propose, we would be at the starting point. :man_shrugging:

I don’t see how it’s any different. Popovers are windows (even by your own responses). Popovers could have been coded to support being hidden without being destroyed. Assuming there’s some platform-specific issue on Windows, macOS, or Linux that prevents that, I would expect Xojo to handle that to provide a better experience.

1 Like

I don’t understand the problem. I give my windows the information they need for opening and on close they send some information back to the caller. I worked for days to have a modern listbox. But changing from window to popover was done in 10 seconds.

Nope, they can’t.

I’m sure they could, just maybe not the way they were implemented. I can’t imagine how it would be impossible to implement this the way I propose as I’ve built my own substitute popovers for nearly two decades now that do support this. At any rate, what’s done is done and there’s no changing now, I suppose.

1 Like

They can, that’s what a framework is for — hiding the details from the users. You just didn’t.

1 Like

Ummm, guys, it’s been solved now. Passing a Class works and is easy!