---------- Original Message ---------- To: <haiku-3rdparty-dev@xxxxxxxxxxxxx> From: Rene Gollent (anevilyak@xxxxxxxxx) Subject: [haiku-3rdparty-dev] Re: Modal dialogs Date: 12/06/2013 10:34:29a > On Tue, Jun 11, 2013 at 7:03 PM, Matthew Allen <fret@xxxxxxxxxxxx> wrote: > > > Ok so if I need the main window unlocked while my dialog is showing I do > > actually have to > > unlock and then lock. > > > > Hopefully I never encounter a case where I open a modal dialog from some > > place where the > > window wasn't locked. Ick. > > > > Are you sure you actually need to use this approach to modal dialogs > at all? The only reason that'd be needed is if you need the same kind > of functionality as BAlert where you're specifically waiting for a > response from the call that initiates the dialog, as BAlert does to > tell you which button was pressed. If you don't specifically need that > and all the dialog's functionality is either self-contained, or could > be done asynchronously by sending a message back to the parent window > in response to a user action, then you could, as previously mentioned > use the modal subset window feel flags to achieve the modal input > focus effect without all this trickery. All the applications that I've written that use the modal dialog system have been based on the premise of blocking the caller until the dialog is closed. Often the button pressed it passed back as the return value from GDialog::DoModal. If I change the way it works I would have to re-write hundreds of calls to show a dialog across various apps. This is because I originally started writing these apps on windows, which works like that. The calling thread blocks until your dialog is finished. Yes I should start doing things in a more async fashion but I have to keep in mind how it's all going to work on Win/Mac and Linux/Gtk. Because the whole thing is cross platform. In the meantime I need to support both the Modal and non-Modal methods. The unlock/lock idea is working for the moment. Even if it means using the non thread safe CountLocks API. Regards -- Matthew Allen The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.