Re: cString
On Thu, Nov 27, 2008 at 20:48, Luca Ciciriello [EMAIL PROTECTED] wrote: Hi All.Recently I've installed the new Xcode 3.1.2 and I've removed my old Xcode 2.5.I've compiled with Xcode 3.1.2 (using the optional compiler GCC 4.2) one of the my Objective-C++ project. No problem, but I've got a warning about the code line: string elem = [[[gridArrayObjc objectAtIndex:i] stringValue] cString];The warning is: Warning: 'cString' is deprecated [...]. Well, in which way can I modify my code line in order to eliminate the deprecated cString? Hi Luca, Have you noticed that you can hold down the ALT modifier key and double click on a method name to bring up the relevant documentation for that method? If you do that on cString, you'll see something like this: Returns a representation of the receiver as a C string in the default C-string encoding. (Deprecated in Mac OS X v10.4. Use cStringUsingEncoding: or UTF8String instead.) Regards Mattias ___ 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 [EMAIL PROTECTED]
Duplicating NSWindow's title bar buttons
Hi list, In NSWindow there's the following two functions: - standardWindowButton: + standardWindowButton:forStyleMask: The first one returns a reference to the actual window button in question. The second one, the class method, returns a new instance of a window button. This button (returned from the class method) acts just like a _normal_ button, and this is different from the actual buttons in the title bar; they have mouse moved tracking associated with them so that when hovering over any of the buttons in the title bar, the other ones will light up as well. Is it possible to bind some property of the new close button (lets pose that we asked for a close button) to the close button in the title bar, so that when the image of the actual close button (in the title bar) receives a hover event and hence changes its image, our new button changes image as well? Regards Mattias ___ 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 [EMAIL PROTECTED]
Re: Menu item issues when programmatically updating an application's main menu
On Wed, Sep 24, 2008 at 02:32, Kyle Sluder [EMAIL PROTECTED] wrote: Your best bet might be to file a bug report at http://bugreport.apple.com . Done, see rdar://problem/6253819. Thanks Mattias ___ 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 [EMAIL PROTECTED]
Re: Receiving mouseEnter and mouseExit events.
On Tue, Aug 19, 2008 at 23:50, David Alter [EMAIL PROTECTED] wrote: I just realized that NSTrackingArea is 10.5 and up. I need to support 10.4. mouseEntered and mouseExited have been part of NSResponder from 10.0. To receive these events in 10.4 what should I do? Sorry for the very late reply, but you might still be interested in MATrackingArea, which can be found at http://mattgemmell.com/source. It's almost identical in functionality to NSTrackingArea, and supports 10.4+ (which seems to be just be what you need). Regards Mattias ___ 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 [EMAIL PROTECTED]
Menu item issues when programmatically updating an application's main menu
Hi list, We have some code in an application of ours that replaces the main menu using NSMenu's setMainMenu:. This has been working just fine since day one but ever since the introduction of Leopard we have noticed some strange behavior with the Help menu. I have also noticed this behavior in RealPlayer.app and in Flickr Uploadr.app (so if you want to see it in action, just repeat the below steps in any of those applications). The behavior I am about to mention does _not_ occur when the application is running under 10.4, _or_ if the Help menu item is renamed to something else (like Helpz). Now let me try to explain my problem... After having set the main menu on startup (using setMainMenu:), the main menu (and all items in the submenus) works exactly as in every application. But... after the next (and on each successive) call to setMainMenu: the Help menu item starts to act weird. When trying to highlight Help and then either pressing the left arrow on the keyboard or moving the mouse left (so that it's now placed above the Window menu) the system first dismisses the Help menu and then very briefly displays the Window menu but then dismisses (closes) it. Re-opening the Help menu again and repeating the above mentioned steps will repair stuff - the Help menu is dismissed, and the Window menu is shown. The main menu will now work correctly until next call to setMainMenu: - and then you will have to repeat the above steps before the Help menu works as expected again. The problem can also be spotted if you try to open the Help menu (after setMainMenu: has been called) and try to perform any of the items within it - they simple won't work (until you've dismissed the Help menu and the invoking it once again). Does anyone have a clue what I could do debug this? I'm really puzzled after having tried to figure out the cause this afternoon... / 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 [EMAIL PROTECTED]
Assert trigged in -[NSEvent eventNumber]
After having tried to debug an error related to mouse tracking (using MATrackingAreaw, [1]) a few weeks ago, I occasionally saw an error message from the system in the console log. The error claim that an assert has failed in -[NSEvent eventNumber] - and each time this occured, our custom mouse tracking seemed to stop working. Unfortunately, I do not have access to the log at the moment. What would be the right™ thing to do here? Since it isn't an exception, I cannot catch it myself, so I'm fumbling in the dark at the moment. Any ideas or suggestions are welcome. [1]. http://mattgemmell.com/files/source/matrackingarea.zip Regards Mattias ___ 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 [EMAIL PROTECTED]
Re: Tab-based (document-based?) application
On Thu, Jun 19, 2008 at 7:04 AM, Jacob Bandes-Storch [EMAIL PROTECTED] wrote: I'm creating an application that will have an arbitrary number of basically identical windows (document-like) which each have tabs (or something of the sort) in them that represent the actual documents, per se. Would it be best to start out with a Document-Based Application or just a regular Cocoa application? Any tips on doing this? I suggest you read the following article to get some inspiration on the concept of an all-in-one window: http://katidev.com/blog/2008/04/09/nsviewcontroller-the-new-c-in-mvc-pt-1-of-3/ Then there's the PSMTabBarControl that e.g. Adium uses: http://www.positivespinmedia.com/dev/PSMTabBarControl.html Good luck Mattias ___ 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 [EMAIL PROTECTED]
Re: capture modifier key events
Hi Apparao, On Wed, Jun 18, 2008 at 7:55 AM, Apparao Mulpuri [EMAIL PROTECTED] wrote: I have a NSTextField, in which i have to update with new string value when ever user presses Cmd, Control or Option keys. I have tried with keyDown and controlDidChange methods. These are working with combination of other keys includes nemuric, character and functional keys. Is there any provision, to capture only modifier keys (with out pressing on other keys) events in Cocoa. If you have a subclass of NSTextField (or any class that inherits from NSResponder) you could override the flagsChanged: method. It will be called as soon as the user holds down any of the control keys. Read more about it in the documentation set on NSResponder. Good luck Mattias ___ 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 [EMAIL PROTECTED]
Re: opening default email and browser from the code
2008/6/17 Angelo Chen [EMAIL PROTECTED]: Hi, I got two questions: 1) I have an email address in the code, I'd like to open default mailing program from the code with the email address as the recipient. 2) I have a NSImageView, when mouse move over it, the cursor should be changed to a hand, and when it is clicked, it will open a URL in the default browser. As for the cursor being changed, take a look at the NSTrackingArea class [1]. It requires Leopard but is indeed much better than the older functionality provided by tracking rect tag (NSTrackingRectTag). [1] http://developer.apple.com/documentation/Cocoa/Reference/NSTrackingArea_class/Reference/Reference.html Regards Mattias ___ 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 [EMAIL PROTECTED]
Re: clickable NSImageView
Hi Angelo,
2008/6/17 Angelo Chen [EMAIL PROTECTED]:
Hi,
I use the code at the end to let user click on an image and open a URL, this
works, but not really satisfactory as when the mouse is moved over the image,
the cursor was not changed to point-hand shape, any idea to improve this?
Thanks,
Angelo
@interface BannerView : NSImageView
{
}
- (void)mouseDown:(NSEvent *)theEvent
{
if ([theEvent clickCount] ==1) {
NSURL *url = [NSURL URLWithString:@http://www.cnn.com;];
[[NSWorkspace sharedWorkspace] openURL: url];
}
}
You really shouldn't create new threads for a question you've already
asked about; it would have been enough to bump the original thread
(opening default email and browser from the code) again. The
original mail did include two questions, which number one had already
been answered.
Regards
Mattias
___
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 [EMAIL PROTECTED]
Re: NSTextView and changing the selected text's color
On Wed, Jun 11, 2008 at 6:15 PM, Mattias Arrelid [EMAIL PROTECTED] wrote: Hi Douglas, On Wed, Jun 11, 2008 at 5:30 PM, Douglas Davidson [EMAIL PROTECTED] wrote: On Jun 11, 2008, at 3:24 AM, Mattias Arrelid wrote: Haven't anyone stumbled upon something similar, or a solution to this? I believe it was answered. You don't want to use setMarkedTextAttributes:, because marked text is the uncommitted text you see while using an input method. You can use setSelectedTextAttributes: instead. It seems that I forgot to mention that I've tried that without success. I can successfully set the background color of the selection using this (in the initWithFrame: method of my custom text view): NSMutableDictionary *dict = [[[self selectedTextAttributes] mutableCopy] autorelease]; [dict setObject:[NSColor redColor] forKey:NSBackgroundColorAttributeName]; [self setSelectedTextAttributes:dict]; Now, any selected text will have a red background selection. Changing the NSBackgroundColorAttributeName attribute to NSForegroundColorAttributeName makes the selection background color the system's default again, but doesn't affect the color of the selected text. Am I missing something here? Just to test things; I did setup a simple test project, and in there it works just fine setting the foreground color. Back to the debugger to see where that call to setSelectedTextAttributes: is going. Thanks again. / Mattias ___ 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 [EMAIL PROTECTED]
Re: NSTextView and changing the selected text's color
On Thu, Jun 12, 2008 at 11:14 AM, Mattias Arrelid [EMAIL PROTECTED] wrote: On Wed, Jun 11, 2008 at 6:15 PM, Mattias Arrelid [EMAIL PROTECTED] wrote: Hi Douglas, On Wed, Jun 11, 2008 at 5:30 PM, Douglas Davidson [EMAIL PROTECTED] wrote: On Jun 11, 2008, at 3:24 AM, Mattias Arrelid wrote: Haven't anyone stumbled upon something similar, or a solution to this? I believe it was answered. You don't want to use setMarkedTextAttributes:, because marked text is the uncommitted text you see while using an input method. You can use setSelectedTextAttributes: instead. It seems that I forgot to mention that I've tried that without success. I can successfully set the background color of the selection using this (in the initWithFrame: method of my custom text view): NSMutableDictionary *dict = [[[self selectedTextAttributes] mutableCopy] autorelease]; [dict setObject:[NSColor redColor] forKey:NSBackgroundColorAttributeName]; [self setSelectedTextAttributes:dict]; Now, any selected text will have a red background selection. Changing the NSBackgroundColorAttributeName attribute to NSForegroundColorAttributeName makes the selection background color the system's default again, but doesn't affect the color of the selected text. Am I missing something here? Just to test things; I did setup a simple test project, and in there it works just fine setting the foreground color. Back to the debugger to see where that call to setSelectedTextAttributes: is going. Sorry for my many replies... It turns out that if you set the NSForegroundColorAttributeName of the attributed string in NSTextView's text storage, the call to setSelectedTextAttributes: doesn't have any effect when called as described below: NSMutableDictionary *dict = [[[textView selectedTextAttributes] mutableCopy] autorelease]; [dict setObject:[NSColor redColor] forKey:NSForegroundColorAttributeName]; [textView setSelectedTextAttributes:dict]; Setting the background color works fine though. I cannot see anything regarding this limitation in the documentation - is it by design or is it a bug? Best regards Mattias ___ 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 [EMAIL PROTECTED]
Re: NSTextView and changing the selected text's color
On Thu, Jun 12, 2008 at 5:40 PM, Douglas Davidson [EMAIL PROTECTED] wrote: On Jun 12, 2008, at 2:47 AM, Mattias Arrelid wrote: It turns out that if you set the NSForegroundColorAttributeName of the attributed string in NSTextView's text storage, the call to setSelectedTextAttributes: doesn't have any effect when called as described below: File a bug and we'll look into it. A bug has been filed: rdar://problem/6003324 Regards Mattias ___ 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 [EMAIL PROTECTED]
Fwd: NSTextView and changing the selected text's color
Haven't anyone stumbled upon something similar, or a solution to this? Best regards Mattias -- Forwarded message -- From: Mattias Arrelid [EMAIL PROTECTED] Date: Fri, May 30, 2008 at 1:25 PM Subject: NSTextView and changing the selected text's color To: cocoa-dev@lists.apple.com Hi everyone, We have a subclass of NSTextView (SPTextView). A couple of these have some text with [NSColor grayColor] set as the NSForegroundColorAttributeName. It looks good, but when the user starts selecting text things go bad ™. Since grey on light blue (the default system selection color) isn't very readable one could argue that we should change the selection color. That is pretty straight forward, but we'd rather not mess with this since the user might have her own highlight color set (through System Preferences / Appearance). The next approach would be to use NSTextView's setMarkedTextAttributes:. It takes a dictionary as paramater, with the following restrictions (according to the documentation): A dictionary of attributes used to draw marked text. Text color, background color, and underline are the only supported attributes for marked text.. Regardless of how I try to specify these (I assume the attributes that are valid are NSForegroundColorAttributeName, NSBackgroundColorAttributeName, NSUnderlineColorAttributeName and NSUnderlineStyleAttributeName), that call doesn't affect the view. As a last resort, we could implement setSelectedRange:affinity:stillSelecting: in our NSTextView subclass, and set the foreground color of the selected range... but that would mean that we would have to change it back to whatever color it had before the selection took place. That doesn't feel right. Reading http://developer.apple.com/documentation/Cocoa/Conceptual/TextEditing/Tasks/SetFocus.html indicates that setMarkedTextAttributes: should do just this, but I cannot seem to get it working. Any suggestions? Best regards Mattias ___ 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 [EMAIL PROTECTED]
Re: NSTextView and changing the selected text's color
Hi Douglas, On Wed, Jun 11, 2008 at 5:30 PM, Douglas Davidson [EMAIL PROTECTED] wrote: On Jun 11, 2008, at 3:24 AM, Mattias Arrelid wrote: Haven't anyone stumbled upon something similar, or a solution to this? I believe it was answered. You don't want to use setMarkedTextAttributes:, because marked text is the uncommitted text you see while using an input method. You can use setSelectedTextAttributes: instead. It seems that I forgot to mention that I've tried that without success. I can successfully set the background color of the selection using this (in the initWithFrame: method of my custom text view): NSMutableDictionary *dict = [[[self selectedTextAttributes] mutableCopy] autorelease]; [dict setObject:[NSColor redColor] forKey:NSBackgroundColorAttributeName]; [self setSelectedTextAttributes:dict]; Now, any selected text will have a red background selection. Changing the NSBackgroundColorAttributeName attribute to NSForegroundColorAttributeName makes the selection background color the system's default again, but doesn't affect the color of the selected text. Am I missing something here? Regards Mattias ___ 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 [EMAIL PROTECTED]
NSTextView and changing the selected text's color
Hi everyone, We have a subclass of NSTextView (SPTextView). A couple of these have some text with [NSColor grayColor] set as the NSForegroundColorAttributeName. It looks good, but when the user starts selecting text things go bad ™. Since grey on light blue (the default system selection color) isn't very readable one could argue that we should change the selection color. That is pretty straight forward, but we'd rather not mess with this since the user might have her own highlight color set (through System Preferences / Appearance). The next approach would be to use NSTextView's setMarkedTextAttributes:. It takes a dictionary as paramater, with the following restrictions (according to the documentation): A dictionary of attributes used to draw marked text. Text color, background color, and underline are the only supported attributes for marked text.. Regardless of how I try to specify these (I assume the attributes that are valid are NSForegroundColorAttributeName, NSBackgroundColorAttributeName, NSUnderlineColorAttributeName and NSUnderlineStyleAttributeName), that call doesn't affect the view. As a last resort, we could implement setSelectedRange:affinity:stillSelecting: in our NSTextView subclass, and set the foreground color of the selected range... but that would mean that we would have to change it back to whatever color it had before the selection took place. That doesn't feel right. Reading http://developer.apple.com/documentation/Cocoa/Conceptual/TextEditing/Tasks/SetFocus.html indicates that setMarkedTextAttributes: should do just this, but I cannot seem to get it working. Any suggestions? Best regards Mattias ___ 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 [EMAIL PROTECTED]
[ANN] CocoaHeads, Stockholm (Sweden) - First meeting ever, June 2
Hi everyone, It is with great joy I invite you to the very first CocoaHeads Stockholm (Sweden) session. We'll kick of next Monday (June 02) at the Spotify office at Humlegårdsgatan 20 (Stockholm), at 18:00 CET. We'll start with a short introduction of ourselves, and then talk about the coming WWDC and our expectations (nothing fancy, just a discussion where everyone is welcome to share their thoughts on Steve's upcoming keynote). There's a projector available if anyone wants to bring their laptop and show stuff for the rest of the audience. During the meeting, we will also try to plan the coming sessions; guest speakers, location etc. Finally (for those who want); after the meeting, we'll go out together and try to find some place to get some tasty food. Questions? Just reply to this mail (do _not_ use the Reply all option) and I'll get back to you in a jiffy. Looking forward to see you next Monday; welcome! Regards Mattias ___ 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 [EMAIL PROTECTED]
Re: NSTextfields and keyboard equivalents - am I missing something?
On Mon, Apr 21, 2008 at 7:05 PM, John Stiles [EMAIL PROTECTED] wrote: In The Path Of Key Events in the URL you posted, the #1 item in the list is key equivalents. AppKit checks keyDown events to see if command is held; if it is, it tries to match it against the menus before passing it through the responder chain. Is this really the case? The control actually gets the chance to respond to the event in the performKeyEquivalent: according to debugger - before_ the menu item gets the event. And after re-reading #1 again, I really can't see that holding down the command key should bypass the ordinary chain? A key equivalent is a key or key combination (usually a key modified by the Command key) that is bound typically to some menu item or control object in the application. Pressing the key combination simulates the action of clicking the control or choosing the menu item. The application object handles key equivalents by going down the view hierarchy in the key window, sending each object a performKeyEquivalent: message until an object returns YES. If the message isn't handled by an object in the view hierarchy, NSApp then sends it to the menus in the menu bar. Some Cocoa classes, such as NSButton, NSMenu, NSMatrix, and NSSavePanel provide default implementations. Am I missing something here, or what do you base your claim on? :) I think your best bet is to dim your menu item or remove its key equivalent when a text field gains first responder, and then restore it when the text field loses first responder. I thought about that, but that really isn't a clean solution; if the user so wants, the menu item action should still be able to be performed by the user choosing the item in the menu - even if the text field has focus (and in this case, I'd say it would be reasonable if the menu item's target would get the action message). What do you think? Mattias Arrelid wrote: I have a simple test application with a few custom menu items. Let's assume that _none_ of these items has a key equivalent of COMMAND + (right arrow) for now. When the first responder of the application is an NSTextField, and the user produces COMMAND + (right arrow), the insertion point is being placed right after the last character in the text field. This is true as long as the text field stays the first responder. As mentioned earler, I _don't_ have a menu item with such a key equivalent at this point. If I add a menu item that _has_ a key equivalent of COMMAND + (righ arrow), what happens is that this item's action is performed when I press the above key combo - even if the text field is the first responder. Is this supposed to happen? When reading the Cocoa Event-Handling documentation, I stumbled upon this: http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/EventArchitecture/chapter_2_section_3.html#//apple_ref/doc/uid/1060i-CH3-SW10 Inspired by that, I enabled some breakpoints in my project. From these, I can see that the text field doesn't seem to care about saying yes, I do respond to COMMAND + (right arrow) when its performKeyEquivalent: is called, which explains why the menu item gets the action eventually. Is this correct? To sum things up: I want the text field to respond to all standard key equivalents (move cursor to front, end, move word forward/backward etc.), even if I have a menu item with such a key equivalent. There are applications that behave like this, e.g. iTunes, and I do think that this is the correct behavior. Could anyone point me in the right direction here? Regards Mattias ___ 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/jstiles%40blizzard.com This email sent to [EMAIL PROTECTED] ___ 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 [EMAIL PROTECTED]
NSTextfields and keyboard equivalents - am I missing something?
I have a simple test application with a few custom menu items. Let's assume that _none_ of these items has a key equivalent of COMMAND + (right arrow) for now. When the first responder of the application is an NSTextField, and the user produces COMMAND + (right arrow), the insertion point is being placed right after the last character in the text field. This is true as long as the text field stays the first responder. As mentioned earler, I _don't_ have a menu item with such a key equivalent at this point. If I add a menu item that _has_ a key equivalent of COMMAND + (righ arrow), what happens is that this item's action is performed when I press the above key combo - even if the text field is the first responder. Is this supposed to happen? When reading the Cocoa Event-Handling documentation, I stumbled upon this: http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/EventArchitecture/chapter_2_section_3.html#//apple_ref/doc/uid/1060i-CH3-SW10 Inspired by that, I enabled some breakpoints in my project. From these, I can see that the text field doesn't seem to care about saying yes, I do respond to COMMAND + (right arrow) when its performKeyEquivalent: is called, which explains why the menu item gets the action eventually. Is this correct? To sum things up: I want the text field to respond to all standard key equivalents (move cursor to front, end, move word forward/backward etc.), even if I have a menu item with such a key equivalent. There are applications that behave like this, e.g. iTunes, and I do think that this is the correct behavior. Could anyone point me in the right direction here? Regards Mattias ___ 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 [EMAIL PROTECTED]
mouseMoved: behaving correctly when application isn't frontmost
Hi all, Our application it setup to forward all mouse moved events to our content view, regardless if our application is the frontmost one. Now, we have some areas of the content view that are to be highlighted when the mouse hovers over them. This works ok (with work, I mean it looks acceptable) if the area in question is fully visible, e.g. our content view and the tracking area are not covered by another window. What does not work is when the tracking rect is partially covered - it looks strange if the mouse pointer is hovering over another window covering our window, and we start highlight stuff in our window... Get me? To see what I mean (and how I want to solve the problem); open up Safari (i have 3.1 installed). Make sure that you have a couple of bookmarks in the bookmark bar. Now, make another application the frontmost application. Move the new application's window so that it partially covers one of the bookmark items. When hovering over the (now inactive) Safari window and the partially covered bookmark item, the item will highlight while the window directly under the mouse pointer is Safari - otherwise it does _not_ highlight. How can you tell, inside mouseMoved: or similar, if the window beloning to the view isn't covered by another window where the mouse pointer currently is? Thanks in advance Mattias ___ 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 [EMAIL PROTECTED]
Re: Relaunching an application
On 3 mar 2008, at 18.14, Nir Soffer wrote: On Mar 3, 2008, at 18:24, Mattias Arrelid wrote: I have an application that I need to restart. Why do you want to do that? A scenario could be that the entire contents of the .app bundle has been replaced with new stuff (e.g. the case with Sparkle). An easy way to do this could be: [[NSWorkspace sharedWorkspace] launchApplication:executablePath]; [NSApp terminate:self]; The problem is that the above solution results in confusion in the system dock; sometimes the original application does manage to quit before the new instance, other times not. If it does NOT manage to quit before the new one is launched, the dock ends up with two icons for my application; one that indicates that the application is launched, another one that's indicates that it's not launched. This is NOT good. I've seen other programs in need of a restart (e.g. the Sparkle framework) using a separate helper application that simply checks whether the original process has quit properly before re-launching it. This sure does work, but it isn't a pretty solution. Seems pretty to me. You want use a separate process to make this work reliably. It works, but I'd say it was prettier if there was a framework call to accomplish this. Regards Mattias ___ 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 [EMAIL PROTECTED]
Combining NSLineBreakByWordWrapping + NSLineBreakByTruncatingTail in NSTextView
Hi there. Occasionally I need to display some very long strings. These string can have sentences that would span several lines depending on the width of my NSTextView. Example of such texts: This is the first line which spans over to the second line and then it stops. This is another line, note the line break above Now, if the size of my text view is not large enough to display all lines, the last word gets truncated so that stuff looks like this (standard behavior): This is the first line which spans over to the second line and then it I'd like to show something like: This is the first line which spans over to the second line and then... I've tried e.g. this: NSRange range= NSMakeRange(0,[[aView string] length]); NSTextStorage *textStorage = [aView textStorage]; NSMutableParagraphStyle *paragraphStyle = [[NSParagraphStyle defaultParagraphStyle] mutableCopy]; [paragraphStyle setLineBreakMode:NSLineBreakByTruncatingTail]; [textStorage addAttribute:NSParagraphStyleAttributeName value:paragraphStyle range:range]; That doesn't work that good, since it will give me something like: This is the first... This is another... I'd like to somehow use word wrapping, as far as possible, and then, at the last line, truncate the last word. Is this easy to implement? Does anyone have any clues or could point me in some interesting directions? Thanks Mattias ___ 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 [EMAIL PROTECTED]
