Hi,
I have a simple window with a WebView and an NSButton that I want to display as
a modal window. The window is loaded from a NIB using MyCompanyAlertController,
that also acts as the WebView's delegate (set in the NIB).
When run as a sheet in my main window (using method showAlertIn
NSLog(@“Do I get called?”);
> });
> }
This make it look like there’s something else wrong. I don’t think a modal
window should block the main queue.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or mode
On Aug 24, 2015, at 12:53 PM, Alex Kac wrote:
>
> I’ve also tried this…and the code in the dispatch_async never gets called.
> I’ve seen other code on github that does something similar so obviously it
> *should* work.
>
> - (IBAction)enterRegCode:(id)sender {
>
> registrationWind
On Aug 24, 2015, at 10:41 , Alex Kac wrote:
>
> registrationWindowController = [[RegistrationWindow alloc]
> initWithWindowNibName:@"RegistrationWindow"];
>
> [self.window beginSheet:registrationWindowController.window
> completionHandler:^(NSModalResponse returnCode) {
>
}
> On Aug 24, 2015, at 11:41 AM, Alex Kac wrote:
>
> I’ve got a modal window which opens a sheet to let the user enter a
> registration code. If the Reg code is accepted, I want to close the window
> after the sheet ends. However it doesn’t. I’ve tried a ton of different
>
I’ve got a modal window which opens a sheet to let the user enter a
registration code. If the Reg code is accepted, I want to close the window
after the sheet ends. However it doesn’t. I’ve tried a ton of different things
and I believe it has something to do with the runLoop because dispatch
t get events itself, assuming it is actually running inside your app.
>
> Take a look at the runModalSession: type of handling modal windows. This
> allows other things to happen while your modal window is up. This might be
> what you need to get the fontWindow to respond properly. I
> On 14 Jun 2015, at 2:30 pm, Kurt Sutter wrote:
>
> It does not help — the panel i actually already in front when it appears, and
> calling -orderFront: does not help. It only works when it is the key window.
OK, it’s time to show your code.
What’s odd is that you say your font panel is vis
> On 14 Jun 2015, at 14:32, Uli Kusterer wrote:
>
> On 13 Jun 2015, at 21:30, Kurt Sutter wrote:
>> It does not help — the panel i actually already in front when it appears,
>> and calling -orderFront: does not help. It only works when it is the key
>> window.
>
> Coming late in here: Have y
On 13 Jun 2015, at 21:30, Kurt Sutter wrote:
> It does not help — the panel i actually already in front when it appears, and
> calling -orderFront: does not help. It only works when it is the key window.
Coming late in here: Have you remembered to uncheck “visible on launch” in the
XIB for that
ed.
>
> Best regards
> Kurt
>
>> On 14 Jun 2015, at 06:55, Ken Thomases wrote:
>>
>> On Jun 13, 2015, at 12:08 AM, Kurt Sutter wrote:
>>
>>> I have a modal window (run with [NSApp runModalForWindow:]) that sports a
>>> view that is a descendant
changeFont: selector of my
textView is (correctly) called.
Best regards
Kurt
> On 14 Jun 2015, at 06:55, Ken Thomases wrote:
>
> On Jun 13, 2015, at 12:08 AM, Kurt Sutter wrote:
>
>> I have a modal window (run with [NSApp runModalForWindow:]) that sports a
>> view that is a
On Jun 13, 2015, at 12:08 AM, Kurt Sutter wrote:
> I have a modal window (run with [NSApp runModalForWindow:]) that sports a
> view that is a descendant of NSTextView. The view has key focus and text is
> selected therein. I then bring up the font panel calling [NSFontPanel
> sha
It does not help — the panel i actually already in front when it appears, and
calling -orderFront: does not help. It only works when it is the key window.
Kurt
> On 14 Jun 2015, at 01:40, Graham Cox wrote:
>
>
>> On 13 Jun 2015, at 6:33 pm, Kurt Sutter wrote:
>>
>> Calling setWorksWhenModal
> On 13 Jun 2015, at 6:33 pm, Kurt Sutter wrote:
>
> Calling setWorksWhenModal:YES and/or setBecomesKeyOnlyIfNeeded:YES does not
> seem to resolve the issue either.
>
> I am at a loss here.
>
What happens if you set those to YES first, then show it with -orderFront:
(i.e. without the makeK
Thanks, Graham!
However, I don’t want the panel to get key focus by default. Just as in
TextEdit, the font panel should come up, the focus should however remain with
the text window. The user can then e.g. click another font in the font panel
(which will update the font in the text window) and
> On 13 Jun 2015, at 3:08 pm, Kurt Sutter wrote:
>
> I then bring up the font panel calling [NSFontPanel sharedFontPanel]
>
> The font panel comes up, and does not have key focus
Just asking for the sharedFontPanel isn’t enough. You still need to show it
using -makeKeyAndOrderFront:, and as
I have a modal window (run with [NSApp runModalForWindow:]) that sports a view
that is a descendant of NSTextView. The view has key focus and text is selected
therein. I then bring up the font panel calling [NSFontPanel sharedFontPanel]
The font panel comes up, and does not have key focus. When
Thanks, Ken and Graham. Somehow I must’ve deleted windowNibName by accident.
Previously, my Source View window ignored any attempt to set the text color of
an item, then after updating to 10.10.2, suddenly text colors worked. Because
that change in behavior related to the OS, I also associated t
> On 9 Feb 2015, at 2:38 pm, Graham Cox wrote:
>
> a subclass of NSWindow required for modal dialogs
On further thought I think that's not true - NSWindow can work modally, but
it's usual to make it NSPanel. If you use a plain window, I think there are
restrictions on which kinds can be used
> On 9 Feb 2015, at 10:44 am, Charles Jenkins wrote:
>
> 2015-02-08 16:24:04.159 MyApp[2989:720882] An uncaught exception was raised
> 2015-02-08 16:24:04.159 MyApp[2989:720882] Modal session requires modal window
Big clue here!
In IB, you need to make sure that the window's
On Feb 8, 2015, at 5:44 PM, Charles Jenkins wrote:
> I updated my OS yesterday, and now my modal window doesn’t work (which
> probably means I’m doing it wrong and just got lucky before).
>
> I created the window by asking XCode to create a subclass of
> NSWindowController
I updated my OS yesterday, and now my modal window doesn’t work (which
probably means I’m doing it wrong and just got lucky before).
I created the window by asking XCode to create a subclass of NSWindowController
and making sure the “also create xib” checkbox was checked. Then I designed the
ements.
>
> In Case 1 I must click the control in order to get mouse movement.
>
> So the question is “how to get Case 2 behavior when the custom control is in
> a modal window”
>
> I have -setWorksWhenModal with no change in behavior.
You're not giving us enough inf
movement.
So the question is “how to get Case 2 behavior when the custom control is in a
modal window”
I have -setWorksWhenModal with no change in behavior.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or
I created a simple project that uses a modal window. The quit
execution works are stated in the docs even though the window is modal.
Which means I am doing something wrong. More investigating to do.
On
19/10/2013, at 3:01 PM, Ken Thomases wrote:
> On Oct 18, 2013, at
6:35 PM, t
On Oct 18, 2013, at 6:35 PM, trid...@ihug.co.nz wrote:
> Problem : quit menu stays active
> when a window is presented using [NSApp runModal:window].
What is the target of the Quit menu item? What is its action method? A
typical setup is that its action method is -terminate: and its target is
Is it an error message that you display at the time your user quits the
application?
/Mikael
On Oct 19, 2013, at 1:35 AM, trid...@ihug.co.nz wrote:
>
>
> I have done a net search concerning the problem and I have found
> discussions on it, but no solution.
>
> Problem : quit menu stays acti
I have done a net search concerning the problem and I have found
discussions on it, but no solution.
Problem : quit menu stays active
when a window is presented using [NSApp runModal:window].
Quitting
causes the menu item to be permanently disabled.
[window
setPreventsApplicationTerminati
> On Mar 18, 2013, at 12:15 PM, Chris Tracewell wrote:
>
>> I have a main window which has a child/auxilary window. When the user
>> presses a button in the UI the main window controller inits the child,
>> assigns itself as the object for the child window's myOwner property and
>> then launche
On Mar 18, 2013, at 12:15 , Chris Tracewell wrote:
> I can't really include the parent header in the child window controller as it
> is included in the parent window controller.
You can, if you need to, since the #import mechanism prevents recursion.
However, it's unlikely you need to.
Leavin
On Mar 18, 2013, at 12:15 PM, Chris Tracewell wrote:
> I have a main window which has a child/auxilary window. When the user presses
> a button in the UI the main window controller inits the child, assigns itself
> as the object for the child window's myOwner property and then launches the
> ch
I have a main window which has a child/auxilary window. When the user presses a
button in the UI the main window controller inits the child, assigns itself as
the object for the child window's myOwner property and then launches the child
window as a modal via NSApp runModalForWindow. This worked
Maybe you needed to send the window orderOut: and/or close?
--Andy
On Aug 23, 2012, at 3:56 PM, tridiak wrote:
>
> On 24/08/2012, at 7:44 AM, Jens Alfke wrote:
>
>>
>> On Aug 23, 2012, at 12:06 PM, tridiak wrote:
>>
>>> I dismiss the panel using [NSApp stopModal]. It consists of a single O
On 24/08/2012, at 7:44 AM, Jens Alfke wrote:
>
> On Aug 23, 2012, at 12:06 PM, tridiak wrote:
>
>> I dismiss the panel using [NSApp stopModal]. It consists of a single OK
>> button and an editable textfield (with a number formatter).
>> Would the edit field being screwing things up?
>
> No,
On Aug 23, 2012, at 12:06 PM, tridiak wrote:
> I dismiss the panel using [NSApp stopModal]. It consists of a single OK
> button and an editable textfield (with a number formatter).
> Would the edit field being screwing things up?
No, that all sounds reasonable. And it also sounds as though
pr
On 24/08/2012, at 6:34 AM, Jens Alfke wrote:
>
> On Aug 23, 2012, at 10:52 AM, tridiak wrote:
>
>> I have a simple document app-wide modal window shown using [NSApp
>> showModal:].
>> It works all fine and dandy.
>> Problem is, if Cmd-Q is initiated, it do
On Aug 23, 2012, at 10:52 AM, tridiak wrote:
> I have a simple document app-wide modal window shown using [NSApp showModal:].
> It works all fine and dandy.
> Problem is, if Cmd-Q is initiated, it does a highlight of the Application
> menu, makes a beep
That's correct behavi
I have a simple document app-wide modal window shown using [NSApp showModal:].
It works all fine and dandy.
Problem is, if Cmd-Q is initiated, it does a highlight of the Application menu,
makes a beep and the Quit menu item becomes permanently disabled after the
modal window has been dismissed
On 03/01/2012, at 8:29 PM, Dany Golubitsky wrote:
> Calling for TextField and waiting for return value.
> Getting return value in some other place is not an option.
It simply doesn't work that way. In fact there's almost no code in Cocoa that
does work that way, with the possible exception o
On 3 Jan 2012, at 3:29 AM, Dany Golubitsky wrote:
> I am sorry, I am new to Cocoa and some things that looks completely obvious
> to you are completely unknown to me.
> (controlTextDidEndEditing: notification) - What is this function, where
> should it be implemented, who should call it?
It is
-
From: cocoa-dev-bounces+danyg=waves@lists.apple.com
[mailto:cocoa-dev-bounces+danyg=waves@lists.apple.com] On Behalf Of Seth
Willits
Sent: Monday, January 02, 2012 20:28
To: cocoa-dev cocoa-dev
Subject: Re: Modal Window for NSTextField
On Jan 2, 2012, at 4:02 AM, Dany Golubitsky wrote
On Jan 2, 2012, at 4:02 AM, Dany Golubitsky wrote:
> // Make the text field "in focus", and start an editing session on it
> [textField becomeFirstResponder];
-becomeFirstResponder is a notification method for when the responder becomes
first responder; it doesn't *make* it first responder. For
On Jan 2, 2012, at 9:22 AM, Dany Golubitsky wrote:
> Thank you!
>
> As for field editor - can it appear and disappear during runtime? Indeed, I
> do not familiar with this approach.
"The field editor is a single NSTextView object that is shared among all the
controls in a single window, includ
?
-Original Message-
From: Michael Babin [mailto:mba...@orderndev.com]
Sent: Monday, January 02, 2012 16:10
To: Dany Golubitsky
Cc: cocoa-dev@lists.apple.com
Subject: Re: Modal Window for NSTextField
On Jan 2, 2012, at 6:02 AM, Dany Golubitsky wrote:
> I need to implement the following th
On Jan 2, 2012, at 6:02 AM, Dany Golubitsky wrote:
> I need to implement the following thing:
> There is a control displaying numeric value. When you Double-Click on a
> control small white window appears where you can enter the value, and when
> you press enter the value will be updated.
> You
Hello everyone!
I would like to ask your help with a specific problem I have.
I need to implement the following thing:
There is a control displaying numeric value. When you Double-Click on a control
small white window appears where you can enter the value, and when you press
enter the value wil
Subclass NSApplication and override this method:
- (NSEvent *)nextEventMatchingMask:(NSUInteger)mask untilDate:(NSDate
*)expiration inMode:(NSString *)mode dequeue:(BOOL)deqFlag
{
NSEvent *event = [super nextEventMatchingMask:mask untilDate:expiration
inMode:mode dequeue:deqFlag];
On Nov 3, 2011, at 10:26 AM, Vojtěch Meluzín wrote:
> Ok, let's try from the other end - how would you implement a popup menu? I
> mean your own custom popup menu, where you want draw and do whatever you
> want, but the method which called it has to wait for its result.
I wouldn't. A popup men
Close the window in its delegate's -windowDidResignKey:.
You will need to architect your app differently, though. Blocking the main
thread waiting for the window to close will not work. You instead need to have
the appropriate delegate method (e.g. -windowWillClose:) call back into your
code (
Ok, let's try from the other end - how would you implement a popup menu? I
mean your own custom popup menu, where you want draw and do whatever you
want, but the method which called it has to wait for its result.
Vojtech
Dne 3. listopadu 2011 17:14 Scott Ribe napsal(a):
> On Nov 3, 2011, at 9:58
On Nov 3, 2011, at 9:58 AM, Vojtěch Meluzín wrote:
> Thanks. Ok, let's say I'm ok with "not making it modal". All I need is that
> when I show the window, the "method" that does that must return after the
> window has closed.
Well, that's modal unless you write your own event loop, which is proba
Thanks. Ok, let's say I'm ok with "not making it modal". All I need is that
when I show the window, the "method" that does that must return after the
window has closed. So basically it's still the same thing, I just can live
with the fact that the window may not be modal and rather closed when gets
On 11/2/11 5:46 PM, Vojtěch Meluzín wrote:
> Ok, folks please forget about the intentions, if they are bad, they will be
> badly rewarded :).
> Anyway I need it from Leopard. Is that really so hard to do such a trivial
> thing in Cocoa???
NSWindow's delegate protocol declares a -windowDidResignKey
On Nov 2, 2011, at 6:46 PM, Vojtěch Meluzín wrote:
> Anyway I need it from Leopard. Is that really so hard to do such a trivial
> thing in Cocoa???
No it's not, but you need to listen to what people are telling you...
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303)
Cocoa discourages behaviors that in normal UI practice are not wise. So when
you want to do something very unique/custom, then yes it can be hard, but never
impossible.
On Nov 2, 2011, at 7:46 PM, Vojtěch Meluzín wrote:
> Ok, folks please forget about the intentions, if they are bad, they will
ack toward Mac UI
> conventions are likely correct, in that there's no way a menu-like thing
> should be an application-modal window. In fact, a child window or floating
> panel sounds more & more like a better way.
>
> > Anyway folks please if you have any idea, let me kn
ointing you back toward Mac UI conventions are
likely correct, in that there's no way a menu-like thing should be an
application-modal window. In fact, a child window or floating panel sounds more
& more like a better way.
> Anyway folks please if you have any idea, let me know, but I
> > This is just a special case. In basically all platforms so far it was
> quite
> > easy to find a simple way to detect, when user clicks outside of the
> > window, so in case particular window should be a "menu", then I could
> just
> > close it on user click outside (or OS did that automaticall
On Nov 2, 2011, at 16:55, Vojtěch Meluzín wrote:
>>> I'm using modal windows using runModalForWindow and I'd like to implement
>>> probably a slightly untypical thing - when a user clicks outside of the
>>> window, it gets closed, like he clicked cancel button or something. The
>>> idea is that th
> > I'm using modal windows using runModalForWindow and I'd like to implement
> > probably a slightly untypical thing - when a user clicks outside of the
> > window, it gets closed, like he clicked cancel button or something. The
> > idea is that this would simulate a popup menu. I know it's not ex
On Nov 2, 2011, at 5:29 PM, Vojtěch Meluzín wrote:
> I'm using modal windows using runModalForWindow and I'd like to implement
> probably a slightly untypical thing - when a user clicks outside of the
> window, it gets closed, like he clicked cancel button or something. The
> idea is that this wou
Hi,
I'm using modal windows using runModalForWindow and I'd like to implement
probably a slightly untypical thing - when a user clicks outside of the
window, it gets closed, like he clicked cancel button or something. The
idea is that this would simulate a popup menu. I know it's not exactly
typic
On Nov 1, 2011, at 8:36 AM, Vojtěch Meluzín wrote:
> 'm using NSApp runModalForWindow to display a modal window, but it appears
> in background.
Um, you already asked this in another message. Let’s keep this in one thread to
avoi
Hi,
I'm using NSApp runModalForWindow to display a modal window, but it appears
in background. Also as a response to some action in the window there may be
additional modal window shown, so kind of a nested runModalForWindow. In
that case the new window, which should be in front doesn't
to work either. Again, the window displays but the
>main menu is still active.
>
>Can anyone suggest how I turn the main menu off (grey out all menu items)
>when displaying a modal window please?
>
>Thanks
>
>Darren.
>
>
>___
&
ve.
Can anyone suggest how I turn the main menu off (grey out all menu items)
when displaying a modal window please?
Thanks
Darren.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the li
wever after bringing the modal window up I want control returned
>> to the main runloop, not a modal runloop.
>
> You want -beginModalSessionForWindow:.
I'm not sure that will help. With modal sessions, you still need to run an
inner run loop. You don't return back to the
On May 7, 2010, at 10:28 AM, David Alter wrote:
> I need to bring a window up that is modal for the application (i.e. you can
> not make other windows active, and you can not use menus while this window
> is up). However after bringing the modal window up I want control returned
>
I need to bring a window up that is modal for the application (i.e. you can
not make other windows active, and you can not use menus while this window
is up). However after bringing the modal window up I want control returned
to the main runloop, not a modal runloop.
If I use runModalForWindow
Thanks, but surely there is _something_ I can do. Subclass NSTextField? In
Carbon I could peek at the event queue and intercept command+C and command+V
key down events; where might I do something similar for my modal NSWindow?
On Apr 7, 2010, at 4:11 PM, Kyle Sluder wrote:
> On Tue, Apr 6, 2010
On Tue, Apr 6, 2010 at 2:11 PM, Dave McCarthy wrote:
> I tried implementing keyDown in my window controller but it is never called.
> I tried subclassing NSWindow and implementing keyDown there but it is never
> called. Maybe keyDown isn't even the right place to be looking, but my Cocoa
> expe
Someone posted essentially this same question in 2004 but there were no answers.
I've got a Cocoa plugin running inside a host application. The plugin opens an
NSOpenPanel, and as a result of user action there, a modal window containing
two NSTextFields. I'd like the user to be able t
On Apr 5, 2010, at 6:18 PM, Kyle Sluder wrote:
> On Mon, Apr 5, 2010 at 3:12 PM, Jeremy Matthews
> wrote:
>> Oh dear?
>
> Yeah. It's a pretty heavy topic. Your use of a for loop inside a modal
> runloop to perform a lengthy operation leads me to believe you'll be
> starting at the ground level
On Mon, Apr 5, 2010 at 3:12 PM, Jeremy Matthews wrote:
> Oh dear?
Yeah. It's a pretty heavy topic. Your use of a for loop inside a modal
runloop to perform a lengthy operation leads me to believe you'll be
starting at the ground level.
Please read through the Threading Programming Guide. It prob
Oh dear?
Sent from my iPhone
On Apr 5, 2010, at 4:47 PM, Kyle Sluder wrote:
On Mon, Apr 5, 2010 at 10:15 AM, Jeremy Matthews > wrote:
for (mmm=0;mmm<150;mmm++)
{
[progressIndicator displayIfNeeded];
[progressIndicator setDoubleValue:mmm];
On Mon, Apr 5, 2010 at 10:15 AM, Jeremy Matthews wrote:
> for (mmm=0;mmm<150;mmm++)
> {
> [progressIndicator displayIfNeeded];
> [progressIndicator setDoubleValue:mmm];
> NSString *temp222 = [NSString stringWithFormat:@"%d",mmm];
>
I have a modal window with code to update both a progress bar and corresponding
text...the progress bar gets updated just fine but the textfield never does
(except if I re-run the method the last string I pushed to the textfield from
the previous run does appear).My understanding was that if
On 30.03.2010, at 2:27, Lee Ann Rucker wrote:
Well, if you're using runModalForWindow: and relying on it to show
the window, it goes away before the method returns, so there is no
point in the code after show and before hide.
I understand it of course. I told about the window controller cl
On Mar 27, 2010, at 1:23 AM, Alexander Bokovikov wrote:
On 27.03.2010, at 12:48, Ken Thomases wrote:
I'm not really sure what you're asking for. A modal window being
shown on screen is not something that happens spontaneously _to_
your application, it's something that your a
On Mar 27, 2010, at 11:01 AM, Alexander Bokovikov wrote:
> Finally, one extra question. When modal window runloop starts? Does it start
> after the window is shown on screen or before that? If it starts after window
> showing then I'd use performSelector:withObject:afterDelay: t
.
There's no need to expose the inner/private stuff to the app
controller, if you think it doesn't belong there.
OK, Finally I've come to some understanding.
Finally, one extra question. When modal window runloop starts? Does it
start after the window is shown on screen or bef
which owns it. In my case popup window may be larger than parent
> window. Therefore I've chosen a real modal window.
There may be reasons why a window-modal sheet is not suitable, but the relative
sizes of the windows should not be one of them, in my opinion. A sheet is not
&quo
rocess, whether
>> it is initiated before the window is show or after.
>
> Is "C" the window controller in my case? I believe, it is.
Well, the "C" means your controller layer, which may be implemented as one or
several controller classes/objects, as you think best.
t I had to call this "private" code from the main
AppController, rather than from a window controller of the modal
window. Probably I was not too clear with my terms.
I think you are used to Windows programming. Cocoa modal sheets are
modal to the owning form, not the whole app.
M
p processed all of the same events as the main
event loop, then it wouldn't be modal -- the user would be able to
do things outside of the modal window, like clicking on buttons in
another window, or selecting menus not related to the modal window.
So, I don't know how you expect
Hi Alexander
> I tried to achieve the next effect: some automatic process should be started
> on the modal window appearance on screen. A popup panel with progress
> indicator appears, etc. My idea was not to initiate such process from the
> calling code (where modal window is
cess
> should be completed to activate its subsequent functionality. Of course, we
> could show this progress before the modal window appearance. But I don't like
> it.
Huh? I didn't suggest showing the progress before the modal window appears. I
just suggested initiating th
te its subsequent functionality. Of course, we
could show this progress before the modal window appearance. But I don't
like it.
Well, first, you should consider whether a modal window
is the best design of your GUI. I would say there's a mild
recommendation that they be avoided i
On Mar 27, 2010, at 3:23 AM, Alexander Bokovikov wrote:
> On 27.03.2010, at 12:48, Ken Thomases wrote:
>
>> I'm not really sure what you're asking for. A modal window being shown on
>> screen is not something that happens spontaneously _to_ your application,
On 27.03.2010, at 12:48, Ken Thomases wrote:
I'm not really sure what you're asking for. A modal window being
shown on screen is not something that happens spontaneously _to_
your application, it's something that your application does. So,
whatever you want to do afte
On Mar 27, 2010, at 2:28 AM, Alexander Bokovikov wrote:
> On 26.03.2010, at 23:10, Fritz Anderson wrote:
>
>> On 26 Mar 2010, at 11:12 AM, Alexander Bokovikov wrote:
>>
>>> Is there any notification or NSWindow delegate method, called immediately
>>> after
On 26.03.2010, at 23:10, Fritz Anderson wrote:
On 26 Mar 2010, at 11:12 AM, Alexander Bokovikov wrote:
Is there any notification or NSWindow delegate method, called
immediately after the modal window is shown on screen? It looks
like windowDidExposed doesn't come to a modal windo
On 26 Mar 2010, at 11:12 AM, Alexander Bokovikov wrote:
> Is there any notification or NSWindow delegate method, called immediately
> after the modal window is shown on screen? It looks like windowDidExposed
> doesn't come to a modal window. Is there any solution?
Just to check
Hi, All,
Is there any notification or NSWindow delegate method, called
immediately after the modal window is shown on screen? It looks like
windowDidExposed doesn't come to a modal window. Is there any solution?
Thanks.
___
Cocoa-dev ma
On 24.03.2010, at 12:48, Ken Thomases wrote:
You need to invoke -readInBackgroundAndNotifyForModes: and pass an
array of modes which includes NSModalPanelRunLoopMode (or
NSRunLoopCommonModes, which includes NSModalPanelRunLoopMode by
default).
Many thanks! Really I should look at that me
are going to my
> popup modal window.At least getData method is never called, as debugger shows
> it.
> What is the problem reason? Is it possible to receive notifications in a
> modal window?
There are two things going on, and you should be careful not to confuse them.
The first i
ns in
a modal window?
Thanks.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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
On Mar 20, 2010, at 4:24 AM, Philippe Sismondi
wrote:
Had I not been compelled to support OS X 10.4 I would have re-
written the whole thing to use something better than threads - GCD
or NSOperationQueue capabilities are said to be safer, although I
have not yet learned them.
Let's nip
Thanks all. Those suggestions help.
BTW, I inherited the code that does the offending "while" loop. It came from
someone's previous attempt to solve exactly one problem: that the secondary
thread might finish before the main thread's modal window was even up. I hope I
1 - 100 of 147 matches
Mail list logo
