Re: Modal dialogs not supported yet?

[Alexander Malmberg]

Fred Kiefer wrote:
> Andreas Hoeschler wrote:
> > I run a modal dialog as follows.
> >
> >    if ([NSApp runModalForWindow:panel] == NSRunStoppedResponse)
[snip]
> > When I click on the cancel button in the modal dialog which calls 
> > [NSApp abortModal] I get a "Abort Modal" exception.

Where do you get this exception? If you're handling it in something
called "between" the -runModalForWindow: call and the function/method
where you call -abortModal, you should, in theory, just propagate it. 
Some would claim that exception handlers should never do anything except
propagate an unrecognized exception. Unfortunately, that breaks down in
many cases, so it gets messy. Yet another reason to not use exceptions
for flow control. :)

I'd suggest using -stopModal unless you really really need the
-abortModal semantics.

> > - (void) abortModal
> > {
[snip assertions]
> >   [NSException raise: NSAbortModalException format: @"abortModal"];
> > }
> >
> > This method always raises an exception. Are modal dialogs not supported
> > yet? What am I missing?

Quoting [NSApplication -runModalForWindow:]:
""
  NS_HANDLER
    {
[snip session cleanup]
      if ([[localException name] isEqual: NSAbortModalException] == NO)
        {
          [localException raise];
        }
      code = NSRunAbortedResponse;
    }
  NS_ENDHANDLER
""

The exception thrown by -abortModal can't "leak" past
-runModalForWindow:.

(The handler really should be in -runModalSession:, but unless you're
using that method directly, that bug won't affect you.)

> The current code looks like a bug to me as this wont stop a modal loop,
> when executed from another thread.

True. The original mail didn't say anything about threads, though, so
that probably isn't the case here.

> But than again your code would also
> not work if GNUstep had it correctly, as then we would than return
> NSRunAbortedResponse, a case you don't check for. Also the cancle button
> should rather call stopModal than abortModal. Still we need to fix this
> code. Any suggestions? I cannot see what would be wrong with a line like:
> _session->runState = NSRunAbortedResponse;

The current -abortModal aborts the modal session right away, without
returning or waiting until the next run loop iteration or anything.
-stopModal returns, and doesn't stop the modal session until the next
run loop iteration (sortof). The semantics aren't really well specified
in the docs, though. It's worth noting that we can't get the current
-abortModal semantics when -abortModal is called from another thread.

It makes sense to me to just do the assignment in both cases, and remove
the exception stuff from -abortModal, _if_ we can get the modal session
to stop at the next run loop iteration in all cases (apple's docs imply
that eg. timers are special, but that doesn't seem useful to me; I think
we have the necessary run loop support to avoid special-casing). If so,
both -stopModal and -abortModal could be changed to work from other
threads by using -performSelectorOnMainThread:..., and they'd have the
same semantics as in the main thread.

I'll do some testing with NSRunLoop to see if this works. I already have
a local patch for it that clears up some timer issues, and I think it
will cover this case, too.

- Alexander Malmberg