Re: runModalForWindow() doesn't re-activate former window upon return
Re: runModalForWindow() doesn't re-activate former window upon return
- Subject: Re: runModalForWindow() doesn't re-activate former window upon return
- From: Kyle Sluder <email@hidden>
- Date: Thu, 25 Aug 2016 15:36:54 -0500
On Thu, Aug 25, 2016, at 01:51 PM, Andreas Falkenhahn wrote:
> On 25.08.2016 at 19:47 Keary Suska wrote:
>
> >> On Aug 25, 2016, at 9:45 AM, Andreas Falkenhahn <email@hidden> wrote:
>
> >> Tested it, the window is clearly main and key, this is the debug output:
>
> >> CHECK: 0x10040b4d0 0x10040b4d0 0x10040b4d0
>
> >> i.e. [NSApp mainWindow], [NSApp keyWindow] and my NSWindow pointer are
> >> exactly the same before runModalForWindow() is called.
>
> > What are they *after* the modal loop has ended?
>
> They are both set to a window pointer that doesn't belong to my
> application.
-mainWindow and -keyWindow don’t return pointers to windows outside of
your application. (How could they? Other applications have their own
address spaces.) They either return pointers to windows in your app
(which might be windows owned by the framework), or they return nil.
--Kyle Sluder
> I've logged both pointers directly after runModalForWindow() returns.
>
> > What happens if you add -orderOut: to the button action method?
>
> Ok, this solves the problem. But still, shouldn't this be handled
> automatically
> by runModalForWindow()? Why does it activate a window that doesn't belong
> to
> my application when it returns? That doesn't look reasonable to me at
> all...
>
> --
> Best regards,
> Andreas Falkenhahn
> mailto:email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden