Window closes on its own
Hi,
the window created through the following code closes on its own after one
second. Why?
PWSuggestionsWindowController *newCon = [[PWSuggestionsWindowController
alloc] initWithWindowNibName:@"PWSuggestionsView"];
[[newCon window] makeKeyAndOrderFront:self];
And the subclass of window:
- (id)initWithContentRect:(NSRect)contentRect styleMask:(NSUInteger)aStyle
backing:(NSBackingStoreType)bufferingType defer:(BOOL)flag
{
self = [super initWithContentRect:contentRect
styleMask:NSBorderlessWindowMask backing:bufferingType defer:NO];
if (self) {
// Initialization code here.
}
return self;
}
Neither windowShouldClose is called on this occasion. It seems it is so known
and obvious it is not documented any place one can easily google or find. This
wasn't the case pre-10.5 though afaik.
Please, can someone shed light on this?
Thank you
Alex
___
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 your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Window closes on its own
I added canBecomeKey, now it stays open. Has this been changed after 10.4?
Am 05.09.2011 um 09:08 schrieb Alexander Reichstadt:
> Hi,
>
> the window created through the following code closes on its own after one
> second. Why?
>
> PWSuggestionsWindowController *newCon = [[PWSuggestionsWindowController
> alloc] initWithWindowNibName:@"PWSuggestionsView"];
> [[newCon window] makeKeyAndOrderFront:self];
>
> And the subclass of window:
>
> - (id)initWithContentRect:(NSRect)contentRect styleMask:(NSUInteger)aStyle
> backing:(NSBackingStoreType)bufferingType defer:(BOOL)flag
> {
> self = [super initWithContentRect:contentRect
> styleMask:NSBorderlessWindowMask backing:bufferingType defer:NO];
> if (self) {
> // Initialization code here.
> }
>
> return self;
> }
>
> Neither windowShouldClose is called on this occasion. It seems it is so known
> and obvious it is not documented any place one can easily google or find.
> This wasn't the case pre-10.5 though afaik.
>
> Please, can someone shed light on this?
>
> Thank you
> Alex
>
___
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 your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
NSBrowser column titles disappear when scrolled
Long ago, I found that NSBrowser column titles disappear when the user manually scrolls the browser horizontally, or clicks a cell that forces the browser to scroll horizontally to show the children of the new selection in the next column. Manually resizing the window or any column causes them to reappear immediately. (This is with the browser set so that each column takes its title from the previous column's selection, and the user is allowed to resize columns.) This seems like it must be a bug in NSBrowser. For many years, I cured the problem by implementing the -browserDidScroll: delegate method and calling -setNeedsDisplayInRect: on the title frame of the last column. That fix no longer works in Lion, and I can't find any other way to fix it. Do others see this problem? How do you fix it? -- Bill Cheeseman - b...@cheeseman.name ___ 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 your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Embed time stamp on recorded video
Hello all, Is there a way to embed the time stamp in recorded video in iphone? Because I want to see the time still when I play the recorded video. Thanks, Charisse ___ 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 your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Windows and views and controls, oh my!
Okay, I'm having a tizzy here. Most of the '...learn MacOS X...' programming books gloss over the nitty-gritty of actually creating and displaying various windows, either assuming they're going to be document windows (as part of a document-based app), or they're just there as part of an example of some other topic. While I can create the UI easily enough in IB, what I don't understand is how to actually load, instantiate, and display the window from my view controller object. If it were REALbasic, I would create a window subclass (wndMain, say), put my UI on it, then - from somewhere else - I would do: ... Dim w as wndMain w = New wndMain() // like [[wndMain alloc] init]; w.myProp1 = "Foo" // Declared as a Public property of type String w.myProp2 = 3 // ditto, but declares as an Integer ... // any other property setups... w.Display() // calls wndMain::Display If (w.ButtonClicked() = 1) Then // User accepted (clicked OK button) Else // User cancelled (click Cancel button) MsgBox "Aborted." End If w = nil// GC called here, in ObjC would be [w release]; followed by w = nil; ... Sub wndMain::Display Me.Setup() // Private method to set the control's visual state based on myProp1, myProp2, etc... Me.ShowModal() // or Me.Show, for a non-modal window End Sub and... wndMain Public Property myProp1 As String Public Property myProp2 As Integer Protected Property fButtonClicked As Integer // Effectively an @property (nonatomic, readonly) NSInteger fButtonClicked Public Function ButtonClicked() As Integer Return fButtonClicked End Function Private Sub wndMain::Setup() lblFoo.Caption = myProp1 popBar.ListIndex = myProp2 // presumably, the 4th item in the popup menu ... End Sub where wndMain would be implemented as the view controller, and the actual 'window' would be in IB. I realize the view controller has to load the nib, but how do I: 1) make sure the window isn't displayed until all it's views (controls) have had a chance to initialize their default (visual) state properly 2) actually display the window, either modally, or not. 3) if modal, how does my client code make sure it doesn't return from the operation until the user closes the window (by clicking the close box, or by dismissing it in code from an IBAction tied to an NSButton whose caption is "Done" or some such.) 4) Pass information to/from the client code and the view controller? 5) Prevent the window from closing (if non-modal) if the contents are 'dirty'? I prefer to actually make each window and its view controller as a pair, rather than rely on the provided window in MainWindow.xib; this way I'll have to actually know how to tie a .xib and a view controller together, rather than rely on whatever may be in the provided MainWindow.xib in the blank project ___ 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 your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Windows and views and controls, oh my!
On Sep 5, 2011, at 9:32 AM, William Squires wrote: > Okay, I'm having a tizzy here. Most of the '...learn MacOS X...' programming > books gloss over the nitty-gritty of actually creating and displaying various > windows, either assuming they're going to be document windows (as part of a > document-based app), or they're just there as part of an example of some > other topic. > While I can create the UI easily enough in IB, what I don't understand is how > to actually load, instantiate, and display the window from my view controller > object. > I realize the view controller has to load the nib, but how do I: > > 1) make sure the window isn't displayed until all it's views (controls) have > had a chance to initialize their default (visual) state properly > 2) actually display the window, either modally, or not. > 3) if modal, how does my client code make sure it doesn't return from the > operation until the user closes the window (by clicking the close box, or by > dismissing it in code from an IBAction tied to an NSButton whose caption is > "Done" or some such.) > 4) Pass information to/from the client code and the view controller? > 5) Prevent the window from closing (if non-modal) if the contents are 'dirty'? > > I prefer to actually make each window and its view controller as a pair, > rather than rely on the provided window in MainWindow.xib; this way I'll have > to actually know how to tie a .xib and a view controller together, rather > than rely on whatever may be in the provided MainWindow.xib in the blank > project Read the "Window Programming Guide" in the API docs (I don't have a web link but Xcode will get you to the right place). It pretty much answers all your questions. It sounds like you are coming from iOS development--forget what you know about view controllers. The Mac OS X equivalent (NSViewController) is another animal altogether. Specific to your question you are interested in NSWindowControllers. There is also no root controller class such as in iOS. HTH, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" ___ 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 your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Windows and views and controls, oh my!
On Sep 5, 2011, at 10:32 AM, William Squires wrote: > While I can create the UI easily enough in IB, what I don't understand is how > to actually load, instantiate, and display the window from my view controller > object. A common approach is to: * Create a custom subclass of NSWindowController. Since a custom window controller is usually intimately tied to a specific NIB, one usually hard-codes the NIB name in the init method. That is, your custom init method will invoke [super initWithWindowNibName:@"YourNIBName"]. (Note: this is a window controller, which is different from a view controller.) * Create a NIB containing your window. In the Identity inspector, set the class of the File's Owner placeholder to be your custom window controller class. * Connect the "window" outlet of File's Owner to the window in the NIB. If your custom window controller has other outlets, connect them, too. * In the code which knows that it wants to display the window (often the app controller), instantiate your custom window controller class. Then either invoke -showWindow: on it or request its window property and directly manipulate it -- for example, send it -makeKeyAndOrderFront:. > [...] how do I: > > 1) make sure the window isn't displayed until all it's views (controls) have > had a chance to initialize their default (visual) state properly Either the views should obtain their state on demand, such that the very act of drawing themselves makes sure they are showing their proper state, or they should initialize themselves in -awakeFromNib or the like. In other words, this isn't usually something you have to manage manually from the point of view of the code that displays the window nor the window controller. If the window controller does need to set stuff up after the window was loaded, do that in an override of -windowDidLoad. > 2) actually display the window, either modally, or not. Described above. To run a window modally, use -[NSApplication runModalForWindow:]. > 3) if modal, how does my client code make sure it doesn't return from the > operation until the user closes the window (by clicking the close box, or by > dismissing it in code from an IBAction tied to an NSButton whose caption is > "Done" or some such.) -runModalForWindow: won't return until something invokes -stopModal, -stopModalWithCode:, or -abortModal. > 4) Pass information to/from the client code and the view controller? The code which instantiates the window controller should either pass arguments to a custom initializer of your own design or simply invoke methods, such as setters, to configure the window controller. > 5) Prevent the window from closing (if non-modal) if the contents are 'dirty'? Set the window controller to be the window's delegate by connecting the window's delegate outlet to File's Owner in the NIB. Then have the window controller implement -windowShouldClose:. Regards, Ken ___ 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 your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Windows and views and controls, oh my!
Thanks! On Sep 5, 2011, at 11:07 AM, Ken Thomases wrote: > On Sep 5, 2011, at 10:32 AM, William Squires wrote: > >> While I can create the UI easily enough in IB, what I don't understand is >> how to actually load, instantiate, and display the window from my view >> controller object. > > A common approach is to: > > * Create a custom subclass of NSWindowController. Since a custom window > controller is usually intimately tied to a specific NIB, one usually > hard-codes the NIB name in the init method. That is, your custom init method > will invoke [super initWithWindowNibName:@"YourNIBName"]. (Note: this is a > window controller, which is different from a view controller.) > > * Create a NIB containing your window. In the Identity inspector, set the > class of the File's Owner placeholder to be your custom window controller > class. > > * Connect the "window" outlet of File's Owner to the window in the NIB. If > your custom window controller has other outlets, connect them, too. > > * In the code which knows that it wants to display the window (often the app > controller), instantiate your custom window controller class. Then either > invoke -showWindow: on it or request its window property and directly > manipulate it -- for example, send it -makeKeyAndOrderFront:. > > >> [...] how do I: >> >> 1) make sure the window isn't displayed until all it's views (controls) have >> had a chance to initialize their default (visual) state properly > > Either the views should obtain their state on demand, such that the very act > of drawing themselves makes sure they are showing their proper state, or they > should initialize themselves in -awakeFromNib or the like. In other words, > this isn't usually something you have to manage manually from the point of > view of the code that displays the window nor the window controller. If the > window controller does need to set stuff up after the window was loaded, do > that in an override of -windowDidLoad. > >> 2) actually display the window, either modally, or not. > > Described above. To run a window modally, use -[NSApplication > runModalForWindow:]. > >> 3) if modal, how does my client code make sure it doesn't return from the >> operation until the user closes the window (by clicking the close box, or by >> dismissing it in code from an IBAction tied to an NSButton whose caption is >> "Done" or some such.) > > -runModalForWindow: won't return until something invokes -stopModal, > -stopModalWithCode:, or -abortModal. > >> 4) Pass information to/from the client code and the view controller? > > The code which instantiates the window controller should either pass > arguments to a custom initializer of your own design or simply invoke > methods, such as setters, to configure the window controller. > >> 5) Prevent the window from closing (if non-modal) if the contents are >> 'dirty'? > > Set the window controller to be the window's delegate by connecting the > window's delegate outlet to File's Owner in the NIB. Then have the window > controller implement -windowShouldClose:. > > Regards, > Ken > ___ 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 your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Window closes on its own
On Sep 5, 2011, at 12:08 AM, Alexander Reichstadt wrote: > the window created through the following code closes on its own after one > second. Why? I’m guessing there’s an extra -release call (or insufficient -retains) and the window’s getting dealloced after the autorelease pool drains. Try setting a breakpoint in the -dealloc method, adding a generic -dealloc if you don’t already have one. —Jens___ 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 your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Window closes on its own
I can't due to using the garbage collection. Am 05.09.2011 um 20:47 schrieb Jens Alfke: > > On Sep 5, 2011, at 12:08 AM, Alexander Reichstadt wrote: > >> the window created through the following code closes on its own after one >> second. Why? > > I’m guessing there’s an extra -release call (or insufficient -retains) and > the window’s getting dealloced after the autorelease pool drains. > > Try setting a breakpoint in the -dealloc method, adding a generic -dealloc if > you don’t already have one. > > —Jens ___ 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 your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Custom Cell Bindings
On Sep 3, 2011, at 11:35 PM, Seth Willits wrote: >> I believe that invoking -sendAction:to: on the table view is the X you're >> looking for. > > It's not. sendAction:to: is always called from the mouse tracking for > instance, even when the cell's target and action are both nil, but the table > view still doesn't do any propagation of the value. I guess I'll ask DTS and file a report in some order. Before that I should probably investigate the view-based NSTableView in Lion and see if it's magically any different or at least allows a more elegant solution than is required on SL. -- Seth Willits ___ 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 your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Windows and views and controls, oh my!
Thanks for the description below. It's good. I, too, am floundering when it comes to specifics that are not shown in examples from Apple or BNR books or websites. I understand the examples, but I don't see how to extend them. So, understanding how the windows and views should be structured together will help me. Perhaps an analogy might make this clearer. It's like having a cookbook with all kinds of well-understood recipes and no idea how to plan a banquet menu that will use the recipes in a good order. The examples I've seen all show a window with a view in it and how to draw in that view. But I want to put up a window with a couple of views in it and draw in them individually, sometimes clearing and redrawing, sometimes adding more drawing. (Controller code that takes input from pushbuttons and data entry are not a problem.) Do I need an NSWindow Controller at all? Ditto NSViewController? I tried separate drawRect's in controllers but couldn't make them work. An outline of how to do this will be greatly appreciated. I'm using 10.6.8 and Xcode 3.2.4 on an iMac. No iOS. Nick On Sep 5, 2011, at 9:07 AM, Ken Thomases wrote: > On Sep 5, 2011, at 10:32 AM, William Squires wrote: > >> While I can create the UI easily enough in IB, what I don't understand is >> how to actually load, instantiate, and display the window from my view >> controller object. > > A common approach is to: > > * Create a custom subclass of NSWindowController. Since a custom window > controller is usually intimately tied to a specific NIB, one usually > hard-codes the NIB name in the init method. That is, your custom init method > will invoke [super initWithWindowNibName:@"YourNIBName"]. (Note: this is a > window controller, which is different from a view controller.) > > * Create a NIB containing your window. In the Identity inspector, set the > class of the File's Owner placeholder to be your custom window controller > class. > > * Connect the "window" outlet of File's Owner to the window in the NIB. If > your custom window controller has other outlets, connect them, too. > > * In the code which knows that it wants to display the window (often the app > controller), instantiate your custom window controller class. Then either > invoke -showWindow: on it or request its window property and directly > manipulate it -- for example, send it -makeKeyAndOrderFront:. > > >> [...] how do I: >> >> 1) make sure the window isn't displayed until all it's views (controls) have >> had a chance to initialize their default (visual) state properly > > Either the views should obtain their state on demand, such that the very act > of drawing themselves makes sure they are showing their proper state, or they > should initialize themselves in -awakeFromNib or the like. In other words, > this isn't usually something you have to manage manually from the point of > view of the code that displays the window nor the window controller. If the > window controller does need to set stuff up after the window was loaded, do > that in an override of -windowDidLoad. > >> 2) actually display the window, either modally, or not. > > Described above. To run a window modally, use -[NSApplication > runModalForWindow:]. > >> 3) if modal, how does my client code make sure it doesn't return from the >> operation until the user closes the window (by clicking the close box, or by >> dismissing it in code from an IBAction tied to an NSButton whose caption is >> "Done" or some such.) > > -runModalForWindow: won't return until something invokes -stopModal, > -stopModalWithCode:, or -abortModal. > >> 4) Pass information to/from the client code and the view controller? > > The code which instantiates the window controller should either pass > arguments to a custom initializer of your own design or simply invoke > methods, such as setters, to configure the window controller. > >> 5) Prevent the window from closing (if non-modal) if the contents are >> 'dirty'? > > Set the window controller to be the window's delegate by connecting the > window's delegate outlet to File's Owner in the NIB. Then have the window > controller implement -windowShouldClose:. > > Regards, > Ken > > ___ > > 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 your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/pu56ucla62%40alumni.purdue.edu > > This email sent to pu56ucl...@alumni.purdue.edu ___ 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 your Subscription: http://lists.apple.com/mailman/options/co
Re: Windows and views and controls, oh my!
On Sep 5, 2011, at 20:43 , N!K wrote: > The examples I've seen all show a window with a view in it and how to draw in > that view. But I want to put up a window with a couple of views in it and > draw in them individually, sometimes clearing and redrawing, sometimes adding > more drawing. You're misusing the term "view" and I have to conclude that you've mis-absorbed what a view is. A view is not so much a construct for breaking apart the visual *appearance* of a window as a construct for organizing the *process* of drawing window contents. That is, views are mostly about apportioning responsibility, and not so much about providing a canvas (although, in the end, they are that too). In Cocoa, you really don't "draw in" views. Rather, views draw themselves. That's the first conceptual hurdle you need to overcome. The second hurdle is that in Cocoa the view appearance is conceptually redrawn from scratch as necessary. That is, having drawn something, a view doesn't just assume its previous appearance is persistent and can be erased. Instead, the window appearance is achieved by layering the drawing done by each view in a controlled manner, and this happens every time the window contents needs to be drawn or redrawn. Now, a view certainly *can* cache its own previous visual state (as a bitmap, or via some other intermediate representation), but that sort of thing is generally done only if necessary for performance reasons, because it's a lot more coding work. Thus, if you have a custom view that draws one or more graphs superimposed, where there is a user option to control which graphs are shown, you don't add a second graph simply by drawing it on top of something that already exists from a previous drawing pass. Instead, you "add" it by redrawing the entire view, but with 2 graphs instead of 1 (except, of course, in the exceptional case already mentioned case of manually caching previous drawing). You say you want to put up a window "with a couple of views in it", but we have no idea what this means. You want to draw a couple of graphs, or something like that? Well, then, your task is about implementing a custom view that draws itself with some kind of custom appearance. That has, typically, very little to do with the mechanics of the window as a whole. > (Controller code that takes input from pushbuttons and data entry are not a > problem.) FWIW, keep in mind that buttons and text fields are views, too. > Do I need an NSWindow Controller at all? Nothing in your considerations of views has anything do with the question of whether there's a window controller or not. Others may disagree, but I believe that there's basically no reason ever *not* to use a window controller. Its prime function is to load and manage the nib resource file of its associated window, so using a window controller relieves you of the responsibility of writing that management code yourself. Window controllers are also useful as controller objects in the MVC sense (that is, as places to put certain business logic that links the window contents to the data model) and as window delegates (that is, as places to put certain code that customizes some of the window behavior). > Ditto NSViewController? No, view controllers are, paradigmatically, analogous to window controllers except that they manage loadable view resource files rather than window resource files. Unless you are swapping various different views in and out of a window a different times, you most likely will put your view resources in the window nib file, which means they get loaded with the window, and don't need to be separately managed. It is certainly possible to use view controllers in more subtle ways (such as dividing controller responsibility when there is a lot of controller code). However, for fundamental purposes, you should simply consider that every window nib file should be paired with its own window controller (set as the nib's File's Owner object), and every view nib file should be paired with its own view controller (set ditto). > I tried separate drawRect's in controllers but couldn't make them work. The 'drawRect:' method belongs in a (custom) view, not in window or view controllers. It is the mechanism via which the view is told to draw itself -- it's something you implement but don't call yourself. At this point you should probably stop trying to understand the Cocoa drawing architecture by examining sample code, and read some essential Apple documents. Start with the NSView Class Reference document, and read everything listed there as a "companion guide". Same thing starting from the NSWindow Class Reference. ___ 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 your Subscription
Re: Long delay of NSPopUpButton first click
On Mon, Aug 29, 2011 at 6:40 PM, Glenn L. Austin wrote: > <...> > Also, just because you're using an image for the menu item doesn't mean that > you can't set the title of the item. > Yes - I can set the title of item with an image, but I don't need "duplicated" title which is presented by both - image and title itself: https://www.dropbox.com/s/9psws3vavxpkya4/Duplicated-menuitem-title.png All I need is "nice" font preview (which should be done by using image) and keep first letter of title shortcut. Regards, Rimas M. ___ 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 your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Long delay of NSPopUpButton first click
On Wed, Aug 31, 2011 at 6:04 PM, Glenn L. Austin wrote: > > Having worked on that code at one time, they are doing *exactly* what I > outlined -- they are pre-creating item images (image with mask) and putting > plain text titles in the menu item and drawing the images with the proper > menu background for the menu item content. > > They are NOT using AttributedString. > Going to try masked image way right now. As for plain text title, I am confused, because if I do that, menu items have two titles - image and plain text: https://www.dropbox.com/s/9psws3vavxpkya4/Duplicated-menuitem-title.png Regards, Rimas M. ___ 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 your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Getting notification about new font is available
Hello list, During weekend I was trying to figure out how to know when new font becomes available. The only method I was able to find is - (BOOL)fontManager:(id)* theFontManager* willIncludeFont:(NSString *)*fontName* of NSFontManager. But according to the documentation: * Important:* This delegate method is not called in Mac OS X versions 10.3 and later. So it does not work... (I have tried - just in case). For example: if I have a RTF file with "Noteworthy" family font (which is available by default on Lion, but not in SL), after opening it on SL (TextEdit) the font becomes visible in NSFontPanel for that app running session. I need to catch that moment to update my own fonts popup. Any thoughts are very appreciate. Best Regards, Rimas M. ___ 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 your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
