Hello Fred, you wrote on Tue, 14 May 2024 22:55:29 +0000:
> I think that I understand better the problem (maybe). You're probably on the track. > If you use a tfilenameeditx, via le Object Inspector, there is the > property "statfile" where you can assign a config file. ... That seems to be somewhat the same as I used for the popup calendar form, but that one is much simpler than the file dialog. Specifically, it does not have a controller. The filedialogcontroller acts as an _insulating_ layer between the caller and the finally displayed form, and as implemented does not even allow any direct data exchange with the form that it caters for, even creates, itself. With your extended file dialog, that assumption broke down, and you had to introduce a lot of _form_ state information in the controller to allow at least some control for the caller. The inception of the "newdialogs" version was even to have _full_ control of the visible form from the application level and to be able to save and retrieve it automatically The first goal was meant to be achieved by creating a fully initialized form (or passing one to the controller) for display and have the application take care of it, and the second was to be solved by the use of the - rather opaque and inscrutable - memory stat file mechanism. Both approaches worked quite well for the simpler dialogs, albeit with "a little help from some friends" for a couple of them (the calendar form, notably). The file dialog showed up as an exception, though, and mainly because of its special use of an insulating layer, the controller, which required a lot of modifications to even get close to my first goal, handing over a fully pre-initialized form, and makes it quite tedious to achieve the second one, although I _think_ I found a way to make it perform as I want. > So the trick is to assign to filedialogxfo the same "statfile" used by > > <tfilenameeditx. ... > I dont know if it is the problem that you related but yes, this could be > a solution. Yes, that's an indirect call to the whole stuff suffering from all the same limits, specifically it has to use all of the same tricks for retrieving and saveing state information of the deeply insulated form object. It cannot help to carry all these multiplied variables around and keeps the opacity of the construct. It's probabely meant for use from within some other object for casual use of a file dialog (a grid cell, perhaps?), which is by itself closely limited and which it can serve satisfactorily. I'd be more satisfied if no additional layer was needed. Many thanks for your valuable suggestions, and my apologies for my always overly lengthy explications As always, best wishes, and keep up the good work! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- _______________________________________________ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
