Re: Custom universal types, but outside an application
Stephen J. Butler stephen.but...@gmail.com écrivait: Shot in the dark, but looking at LSInfo.h it seems LSRegisterURL (with your bundle URL) might work: Doesn't. Out of curiosity, I also tried lsregister directly from the command-line, but (probably as expected) it returns a 'not an application' error. :-( ___ 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 universal types, but outside an application
Lee Ann Rucker lruc...@vmware.com écrivait: When you create the bundle, set NSFileExtensionHidden on it. OK, so IIUYC, this implicitely means that you need to do this for every such directory. In other words, there is no way to specify that a custom type, reified as a directory, should have its extension hidden. If that's correct, this is unfortunate, especially since my type conforms to com.apple.package... :-/ ___ 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: Lion breaks the ability to click-through transparent window areas when the window is resizable.
On Sep 9, 2011, at 12:41 AM, Andreas Mayer wrote: Am 05.08.2011 um 22:01 schrieb R R Hornback: I just found this message while searching for a solution to the same problem. With OS X Lion, even when the window background is transparent, the window still receives the mouse events. I have determined that this is related to whether or not the Window is resizable. If the window is resizable, the mouse events are handled by the Window. If it is NOT resizable, the events in the transparent areas are NOT handled by the window. Are you sure? For me the window always receives the mouse event, even if I use NSBorderlessWindowMask and nothing else. This is on 10.7.1. Have you already filed a bug? My clickthrough application still works on 10.7.1. It is not resizable, though, so I can't address the question whether clickthrough fails on resizable windows. If you want to try it, download Applidude from http://pfiddlesoft.com/pfiddles and turn off its Auto motivate preference. -- 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
NSURLConnection: Greedy Memory Eater and Error 303
Dir Members,
I'm trying to use a NSURLConnection to download a large data file (10 MB) from
a web service to the iPhone. Currently, testing on iOS 4.2.1, on a device. The
connection is established over WIFI.
The problem I get with NSURLConnection is, that it internally uses a lot
(really a lot) memory for its data buffers. It seems, the connection reads as
much data as it can from the network and a tries to safe it in internal
buffers, no matter what, apparently until the system cannot provide more memory.
In a simple test app, NSURLConnections quite quickly consumes up to 10Mbyte for
a number of its buffers - on the iPhone!, which is probably the maximum before
the app will be killed. With Instruments, it can be viewed quite easily.
The download works as long as the processing of each received buffer (NSData
object) does not require further memory. Otherwise, since almost all available
memory is allocated by the internals of NSURLConnection, the app will crash
quite early.
Another problem is, if I process the incoming data buffers more slowly, then
it may occur that NSURLConnection returns the following error:
Error Domain=kCFErrorDomainCFNetwork Code=303 The operation couldn’t be
completed. (kCFErrorDomainCFNetwork error 303.) UserInfo=0x3911830
{NSErrorFailingURLKey=http://ag-macbookpro.local:3000/download/download,
NSErrorFailingURLStringKey=http://ag-macbookpro.local:3000/download/download}
The slower I process the data, the bigger the internal buffers become, and the
sooner I get this error. It does also not make any difference if the thread
where the data will be received will be blocked (this slows down the insertion
of data objects into a FIFO, but anyway, NSURLConnection will consume the max
available memory for its internal buffers).
The NSURLConnection is setup using the asynchronous method. I tried two
approaches, first scheduling it on the main thread, and second scheduling it on
a secondary thread. There is basically no difference.
In the test, the processing of the data buffers will not require additional
memory, and due to this downloading works in this scenario - unless the speed
to process the received data buffers drops too a certain limit. However, my
real app would need to allocate additional objects when processing the data.
Then, there is a 100% guarantee that the app will crash. So, currently, I have
no idea how to make this work (using a NSURLConnection) unless I can tell
NSURLConnection to be less greedy, and throttle the reading of data from the
network somehow. And to be honest, this behavior seems to be a bug at least
when using it on the iPhone.
Any ideas?
Thanks in advance for tips!
Regards
Andreas___
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: NSURLConnection: Greedy Memory Eater and Error 303
On Fri, Sep 9, 2011 at 4:06 AM, Andreas Grosam agro...@onlinehome.de wrote: I'm trying to use a NSURLConnection to download a large data file (10 MB) from a web service to the iPhone. Currently, testing on iOS 4.2.1, on a device. The connection is established over WIFI. The problem I get with NSURLConnection is, that it internally uses a lot (really a lot) memory for its data buffers. It seems, the connection reads as much data as it can from the network and a tries to safe it in internal buffers, no matter what, apparently until the system cannot provide more memory. I don't know how to fix NSURLConnection, but an alternative would be to use the source to some other HTTP client. By having the source code, you would have full control over the buffering. For example, libcurl is available under the MIT License: http://curl.haxx.se/libcurl/ That would probably be the easiest route. You should file a bug with Apple at http://bugreport.apple.com/ Buffering a lot of data isn't a big deal on Mac OS X, but it's bad news on an embedded device like the iPhone. Don Quixote -- Don Quixote de la Mancha quix...@dulcineatech.com Custom Software Development for the iPhone and Mac OS X http://www.dulcineatech.com/custom-software-development/ ___ 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: NSURLConnection: Greedy Memory Eater and Error 303
On Sep 9, 2011, at 4:06 AM, Andreas Grosam wrote: The problem I get with NSURLConnection is, that it internally uses a lot (really a lot) memory for its data buffers. It seems, the connection reads as much data as it can from the network and a tries to safe it in internal buffers, no matter what, apparently until the system cannot provide more memory. In a simple test app, NSURLConnections quite quickly consumes up to 10Mbyte for a number of its buffers - on the iPhone!, which is probably the maximum before the app will be killed. With Instruments, it can be viewed quite easily. Try setting the memory size of the NSURLCache, something like [[NSURLCache sharedURLCache] setMemoryCapacity:0]. -- David Duncan ___ 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: NSURLConnection: Greedy Memory Eater and Error 303
On Sep 9, 2011, at 6:06 AM, Andreas Grosam wrote: Dir Members, I'm trying to use a NSURLConnection to download a large data file (10 MB) from a web service to the iPhone. Currently, testing on iOS 4.2.1, on a device. The connection is established over WIFI. The problem I get with NSURLConnection is, that it internally uses a lot (really a lot) memory for its data buffers. It seems, the connection reads as much data as it can from the network and a tries to safe it in internal buffers, no matter what, apparently until the system cannot provide more memory. In a simple test app, NSURLConnections quite quickly consumes up to 10Mbyte for a number of its buffers - on the iPhone!, which is probably the maximum before the app will be killed. With Instruments, it can be viewed quite easily. For another datapoint, I've got an app that can (optionally) download a 12.9MB data file which uses NSURLConnection, and it works fine - no threading, just the standard asynch delegate callbacks. I need to make sure that I'm accumulating the data in a file instead of in memory (in connection:didReceiveData:), but there's no problem with crashing or other weird errors. Glenn Andreas gandr...@gandreas.com The most merciful thing in the world ... is the inability of the human mind to correlate all its contents - HPL ___ 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: Lion breaks the ability to click-through transparent window areas when the window is resizable.
Am 09.09.2011 um 11:52 schrieb Bill Cheeseman: My clickthrough application still works on 10.7.1. Making a window completely ignore mouse clicks still works. But try this: Make Applidude active and click in one of the corners, outside the gray area. You are still able to move the window. That's the bug we are talking about. The click should fall through in transparent areas of the window. I guess I'll file a bug even though it seems to be a known problem. Andreas___ 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: Lion breaks the ability to click-through transparent window areas when the window is resizable.
On Sep 9, 2011, at 11:02 AM, Andreas Mayer wrote: Make Applidude active and click in one of the corners, outside the gray area. You are still able to move the window. That's the bug we are talking about. The click should fall through in transparent areas of the window. I see what you mean. (I succumbed to the perils of coming in on a thread late. Sorry.) -- 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
Re: NSURLConnection: Greedy Memory Eater and Error 303
On Sep 9, 2011, at 3:59 PM, David Duncan wrote:
On Sep 9, 2011, at 4:06 AM, Andreas Grosam wrote:
The problem I get with NSURLConnection is, that it internally uses a lot
(really a lot) memory for its data buffers. It seems, the connection reads
as much data as it can from the network and a tries to safe it in internal
buffers, no matter what, apparently until the system cannot provide more
memory.
In a simple test app, NSURLConnections quite quickly consumes up to 10Mbyte
for a number of its buffers - on the iPhone!, which is probably the maximum
before the app will be killed. With Instruments, it can be viewed quite
easily.
Try setting the memory size of the NSURLCache, something like [[NSURLCache
sharedURLCache] setMemoryCapacity:0].
--
David Duncan
I already did this:
-
(BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
// Return YES for supported orientations
return (interfaceOrientation == UIInterfaceOrientationPortrait);
}
and
[[NSURLCache sharedURLCache] removeAllCachedResponses];
[[NSURLCache sharedURLCache] setMemoryCapacity:1024*64];
NSTimeInterval request_timeout = 600.0;
NSURLRequest* request = [NSURLRequest requestWithURL:url cachePolicy:0
timeoutInterval:request_timeout];
Since I don't use a URL cache, I suspect the above cache settings are not in
effect anyway.
However, setting the timeout to a high value is crucial if the processing of
data is slow, otherwise I get error -1001 (kCFURLErrorTimedOut)
The problem seems really the buffers which will be used by NSURLConnection
internally. They grow up to about 1 MBytes, and severals of them may be
allocated. My app can be configured how many NSData buffers it keeps alive for
processing in a FIFO queue and this is currently the minimum: just one (if more
come in, the thread blocks).
So, all other buffers should be freed sooner or later by NSURLConnection. But
the huge sizes cause a problem on the tiny iPhone ;) and my code fights
against NSURLConnection to get a share.
One other thing is, using Instruments makes the scenario worse. When
Instruments is connected, the app crashes much sooner due to memory problems.
So, I support my observations on logs, too.
___
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: NSURLConnection: Greedy Memory Eater and Error 303
On Sep 9, 2011, at 4:15 PM, glenn andreas wrote: On Sep 9, 2011, at 6:06 AM, Andreas Grosam wrote: Dir Members, I'm trying to use a NSURLConnection to download a large data file (10 MB) from a web service to the iPhone. Currently, testing on iOS 4.2.1, on a device. The connection is established over WIFI. The problem I get with NSURLConnection is, that it internally uses a lot (really a lot) memory for its data buffers. It seems, the connection reads as much data as it can from the network and a tries to safe it in internal buffers, no matter what, apparently until the system cannot provide more memory. In a simple test app, NSURLConnections quite quickly consumes up to 10Mbyte for a number of its buffers - on the iPhone!, which is probably the maximum before the app will be killed. With Instruments, it can be viewed quite easily. For another datapoint, I've got an app that can (optionally) download a 12.9MB data file which uses NSURLConnection, and it works fine - no threading, just the standard asynch delegate callbacks. I need to make sure that I'm accumulating the data in a file instead of in memory (in connection:didReceiveData:), but there's no problem with crashing or other weird errors. Glenn Andreas gandr...@gandreas.com The most merciful thing in the world ... is the inability of the human mind to correlate all its contents - HPL This kind of use case seems to work. Writing to a file seems fast enough (relative to reading from a WIFI network), and it seems not to use much additional memory. The faster the data buffers are processed (relative to producing it) the smaller the buffers get. The smaller the buffers, the less memory will be used by the connection. I would rather process the data as they come in. Well, in theory I could process about 0.5..1.0 Mbyte per second on a slow old iPhone - if I had the CPU exclusively, and some RAM ;) If I can't find a solution, I have to resort to write to a temporary file. It seems strange however, that the internal buffers of NSURLConnection can grow that large and why these large buffers might be beneficial when streaming in from a network.___ 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: NSURLConnection: Greedy Memory Eater and Error 303
On Sep 9, 2011, at 6:10 PM, Andreas Grosam wrote:
I already did this:
I meant:
- (NSCachedURLResponse *)connection:(NSURLConnection *)connection
willCacheResponse:(NSCachedURLResponse *)cachedResponse {
return nil;
}
the infamous Copy and Paste error :)
___
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
Changing default file - application association
Hi folks, I have an application that we wrong. There is an older version of the application that I will call V0, and a newer version of the application that I will call V1. I have both V0 and V1 installed on my computer(s) (Mac OS X 10.6 and 10.7). Both V0 and V1 generate application specific documents (files) that can be opened by both V0 and V1. Mac OS X associates the all instances of my application specific documents/files with V1. When I try to change such association using: Right Click on File - Get Info - Open With - Select Application - Change All Mac OS X refused to change the association for an unknown reason (even though it lists V0 as a candidate). It is not clear to me why that is the case. Interestingly, when I try to change the association on just that particular file (not all files of the same type) it works like a charm. Any feedback would be greatly appreciated. Thanks, Abdul ___ 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 universal types, but outside an application
On Sep 9, 2011, at 2:20 AM, dvlc...@gmail.com wrote: Lee Ann Rucker lruc...@vmware.com écrivait: When you create the bundle, set NSFileExtensionHidden on it. OK, so IIUYC, this implicitely means that you need to do this for every such directory. In other words, there is no way to specify that a custom type, reified as a directory, should have its extension hidden. If that's correct, this is unfortunate, especially since my type conforms to com.apple.package... :-/ As far as I know, yes. Our app uses bundles and it's the first thing we do after creating it.___ 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
NSWindow title bar view height
I am wondering what could be the best way of creating a NSWindow that has a bigger title bar - similar to the AppStore app or iCal (to add some other NSViews). A project I found doing just that feels a little hack'ish https://github.com/indragiek/INAppStoreWindow Is there a better way? cheers, Torsten ___ 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: Introductions to OOP? [was: Re: Large over 100K pixel high ruler scroll view]
On Fri, 02 Sep 2011 10:04:54 -0700, Jens Alfke j...@mooseyard.com said: On Sep 1, 2011, at 9:26 PM, Julie Porter wrote: Again I am impressed with the help I received here. Hopefully others will be able to read these threads and learn from the experience of others. Julie: Youre welcome! Gang: One result of this is that Im realizing how difficult it is to explain the basic concepts of object-oriented programming to someone whos confused by them. Ive been using them so long, that its like a fish trying to explain how to swim. Id like to be able to point people to a good introduction, either online or in a book, but unfortunately I dont know of any. Can anyone recommend something? (It doesnt have to be Objective-C specific, although ideally it would describe dynamic languages, not static ones like C++ or Java.) Another common stumbling block seems to be nib loading, and the concept of wiring up your non-view objects so they can find each other at runtime. I think Im better at explaining this because I still remember learning it myself, but it would still be good to bookmark some clear descriptions. For nib loading, my iOS book pounds home all the key points (these are *instances* you're making and now you need a way to get *references* to them). The key chapter is available for free online: http://www.apeth.com/iOSBook/ch07.html The book does also introduce OOP concepts, of course, but it those chapters are somewhat spread out and aren't all available free, and are rather tightly tied to Objective-C and the particular behavior of the Cocoa frameworks; you'd have to see the actual book to decide if it's appropriate for your purposes (let me know off-list if you'd like a copy). There's also a fun OOP explanation in my Ruby intro, but it's rather tightly tied to Ruby: http://www.apeth.com/rbappscript/02justenoughruby.html m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ A fool + a tool + an autorelease pool = cool! Programming iOS 4! http://www.apeth.net/matt/default.html#iosbook___ 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: How to write song tags with iTunes and Scripting Bridge
On Mon, 05 Sep 2011 17:44:35 +0200, David Dengg david.de...@gmail.com said: Hello list, I have all the songs from iTunes as iTunesFileTracks (via Scripting Bridge). I want to write new tag information back into the tracks. I can do song.name = newSongTitle; and that works most of the time. Sometimes it fails. Sometimes it writes msng into the name This implies that you have set the title (name) to missing value. Under what circumstances could such failure take place? I've been mass-processing iTunes tracks by changing their names via scripting for years, and I've *never* seen a failure. Perhaps it would help if you showed more about your code. In particular I'm feeling somewhat suspicious about where you're getting the value of newSongTitle from, but that's just a guess - as it would have to be, given that you're not providing any specific information about what you're doing. m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ A fool + a tool + an autorelease pool = cool! Programming iOS 4! http://www.apeth.net/matt/default.html#iosbook___ 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: How to write song tags with iTunes and Scripting Bridge
On Mon, 05 Sep 2011 17:44:35 +0200, David Dengg david.de...@gmail.com said: Hello list, I have all the songs from iTunes as iTunesFileTracks (via Scripting Bridge) Is there a preferred way to write tags back into the tracks? Should I use apple events directly? You *are* using apple events directly. (Sorry to post twice on the same question but I just noticed this.) A scriptable app like iTunes is utterly neutral and ignorant about who created and sent the apple event and how - there is no difference whatever between what it sees whether you do this with scripting bridge, with AppleScript, with Appscript, with a raw Apple event that you construct using Carbon calls, etc. etc. (as discussed in Appendix B of my AppleScript book). Now, to be sure, an Apple event can be constructed well or badly, and scripting bridge *does* construct some Apple events badly, as I discovered the very first (and, not coincidentally, the last) time I tried using it: http://lists.apple.com/archives/applescript-implementors/2007/Nov/msg00034.html But it isn't getting *this* Apple event wrong. m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ A fool + a tool + an autorelease pool = cool! Programming iOS 4! http://www.apeth.net/matt/default.html#iosbook___ 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: NSBrowser column titles disappear when scrolled [SOLVED]
I do hope you're filing bugs on all of this! m. On Tue, 06 Sep 2011 06:30:33 -0400, Bill Cheeseman wjcheese...@gmail.com said: The solution is to set the Titled checkbox in Interface Builder instead of calling -setTitled: in -awakeFromNib. Surely this is a bug in NSBrowser, and it must have been around since Jaguar or earlier. I also notice that setting Titled in Interface Builder causes Separators to be checked when you close the Interface Builder editor and then reopen it. It isn't nice to have Interface Builder automatically changing settings behind my back like this. Also, if I call -setSeparatesColumns: along with -setTitled in -awakeFromNib instead of using Interface Builder, the column titles still don't work right. So this is clearly a case of Interface Builder settings working when the corresponding methods do not work correctly. To add to the mystery, the documentation for -setSeparatesColumns: says its value is ignored if -isTitled: does not return no. The double negative must have confused the author of that sentence, because the value of YES does seem to be required (at least in Interface Builder) for column titles to work correctly. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ A fool + a tool + an autorelease pool = cool! Programming iOS 4! http://www.apeth.net/matt/default.html#iosbook___ 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: NSBrowser column titles disappear when scrolled [SOLVED]
On Sep 9, 2011, at 4:03 PM, Matt Neuburg wrote: I do hope you're filing bugs on all of this! m. On Tue, 06 Sep 2011 06:30:33 -0400, Bill Cheeseman wjcheese...@gmail.com said: The solution is to set the Titled checkbox in Interface Builder instead of calling -setTitled: in -awakeFromNib. Surely this is a bug in NSBrowser, and it must have been around since Jaguar or earlier. I also notice that setting Titled in Interface Builder causes Separators to be checked when you close the Interface Builder editor and then reopen it. It isn't nice to have Interface Builder automatically changing settings behind my back like this. Also, if I call -setSeparatesColumns: along with -setTitled in -awakeFromNib instead of using Interface Builder, the column titles still don't work right. So this is clearly a case of Interface Builder settings working when the corresponding methods do not work correctly. To add to the mystery, the documentation for -setSeparatesColumns: says its value is ignored if -isTitled: does not return no. The double negative must have confused the author of that sentence, because the value of YES does seem to be required (at least in Interface Builder) for column titles to work correctly. Thanks for reminding me. I certainly will. -- 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
Re: nonatomic vs atomic assign/retain
On Wed, 07 Sep 2011 13:06:28 -0500, glenn andreas gandr...@mac.com said:
Anyway. But I am curious - can you provide an example where you
modified an outlet?
On iOS, a common technique to make complex table view cells is to put them in
their own nib files, have a table view controller have:
@property (nonatomic, retain) IBOutlet UITableViewCell *loadedCell;
and then:
- (UITableViewCell *)tableView:(UITableView *)tableView
cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:
self.identifier];
if (!cell) {
[[NSBundle mainBundle] loadNibNamed:@ComplexTableViewCell
owner:self options:nil];
cell = [[self.loadedCell retain] autorelease];
self.loadedCell = nil;
}
// configure and return cell...
}
(1) I don't think that's an example of modifying an *outlet*, though. What you
did was to modify the value of an ivar. The outlet is the name loadedCell
embedded in the nib; you didn't do anything about that (i.e. you didn't
magically change the *name*). You just *used* the outlet, in a perfectly normal
way: you loaded the nib with self as the owner and KVC was used to cause a
certain newly created instance (the cell) to be passed to setLoadedCell:.
(2) On iOS 4 it's better in this repeated loading situation to use UINib
instead of NSBundle to load the nib:
UINib* theCellNib = [UINib nibWithNibName:@ComplexTableViewCell bundle:nil];
[theCellNib instantiateWithOwner:self options:nil];
m.
--
matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___
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: Set a view's delegate using IB
On Wed, 07 Sep 2011 14:12:26 -0700, Quincey Morris quinceymor...@rivergatesoftware.com said: There's something code-smelly about putting a view controller ... in a nib file at all. I don't see why. On iOS this is so common that it is in fact built into many of Apple's own included project templates. m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ A fool + a tool + an autorelease pool = cool! Programming iOS 4! http://www.apeth.net/matt/default.html#iosbook ___ 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: NSURLConnection: Greedy Memory Eater and Error 303
On Sep 9, 2011, at 4:06 AM, Andreas Grosam wrote: I'm trying to use a NSURLConnection to download a large data file (10 MB) from a web service to the iPhone. Currently, testing on iOS 4.2.1, on a device. The connection is established over WIFI. The problem I get with NSURLConnection is, that it internally uses a lot (really a lot) memory for its data buffers. It seems, the connection reads as much data as it can from the network and a tries to safe it in internal buffers, no matter what, apparently until the system cannot provide more memory. That does seem wrong. I haven’t noticed such behavior, but I’ve been using NSURLConnection mostly on Mac OS. It is definitely used by many apps for large resources, though. I’ve used it for MP3 audio streaming, for example, and haven’t seen any excessive memory use. You should repost this question on the macnetworkprog mailing list on this site. More of the networking experts hang out there — several Apple engineers with CFNetwork expertise reply to questions pretty regularly. Another problem is, if I process the incoming data buffers more slowly, then it may occur that NSURLConnection returns the following error: Error Domain=kCFErrorDomainCFNetwork Code=303 The operation couldn’t be completed. (kCFErrorDomainCFNetwork error 303.) According to CFNetworkErrors.h, this is kCFErrorHTTPParseFailure. That’s rather strange; I can’t think of any reason why slowing down reading the data would cause CFNetwork to have trouble parsing the HTTP response. What is the server on the other end? (Actually, don’t answer that here; but you could include that info when you repost to the macnetworkprog list.) —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: NSURLConnection: Greedy Memory Eater and Error 303
On Sep 9, 2011, at 6:54 AM, Don Quixote de la Mancha wrote: I don't know how to fix NSURLConnection, but an alternative would be to use the source to some other HTTP client. By having the source code, you would have full control over the buffering. For example, libcurl is available under the MIT License: IMHO this would be more trouble than it’s worth, unless there turns out to be some intractable problem with the standard libraries. CFNetwork is very optimized to work well in the environment of a Cocoa app, and a 3rd party library would need to have bridging written around it, in particular to manage threading. —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: NSURLConnection: Greedy Memory Eater and Error 303
On Sep 9, 2011, at 9:10 AM, Andreas Grosam wrote: One other thing is, using Instruments makes the scenario worse. When Instruments is connected, the app crashes much sooner due to memory problems. So, I support my observations on logs, too. That sounds suspicious. You may have memory errors in your code that become worse when run under Instruments. If some of those are leaks, it could explain the excessive memory use you see. In particular, make sure you’ve got “malloc scribble” turned on (in Xcode 4 it’s a checkbox in the Run tab of the scheme editor) and run the static analyzer to see if it can find errors. —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: Set a view's delegate using IB
On Sep 9, 2011, at 1:41 PM, Matt Neuburg wrote: I don't see why. On iOS this is so common that it is in fact built into many of Apple's own included project templates. m. I think you’re both right. A UIViewController is not the same thing as an NSViewController. —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: NSWindow title bar view height
On Sep 9, 2011, at 11:41 AM, Torsten Curdt wrote: I am wondering what could be the best way of creating a NSWindow that has a bigger title bar - similar to the AppStore app or iCal (to add some other NSViews). A project I found doing just that feels a little hack'ish I have never seen a non-hackish way to tweak the title bar in such a way, unfortunately. There are some methods to access and adjust the standard buttons, but the layout and drawing of the title bar are done by undocumented internal classes. (If you want to see real hackish, you should look at the code Chromium uses to manage its fancy windows with the tabs in the title bar. It works, and I don’t know of any better way to do what it’s doing, but it’s quite scary.) —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: NSOutlineView and -reloadDataForRowIndexes:columnIndexes:
Yes; for a cell based tableview all it does is invalidate the row/column pairs. For view based, it drops the view and queries it again. corbin On Sep 8, 2011, at 12:12 PM, Sebastien Boisvert wrote: Does -reloadDataForRowIndexes:columnIndexes: work on NSOutlineView? I'm trying to use this to refresh some rows, but I get no indication that anything in my delegate is being queried to refresh the data. ___ 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/corbind%40apple.com This email sent to corb...@apple.com ___ 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: NSWindow title bar view height
I have never seen a non-hackish way to tweak the title bar in such a way, unfortunately. There are some methods to access and adjust the standard buttons, but the layout and drawing of the title bar are done by undocumented internal classes. (If you want to see real hackish, you should look at the code Chromium uses to manage its fancy windows with the tabs in the title bar. It works, and I don’t know of any better way to do what it’s doing, but it’s quite scary.) Alright, I guess I'll give the INAppStoreWindow a try then :) Thanks, 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
Locking an NSDocument
Hi all, If you adopt the new +autosavesInPlace feature on Lion, documents that haven't been opened in a while will get a Locked message in the titlebar, which the user can override by clicking and choosing Unlock, or by attempting to make a change to the document and choosing Unlock from the resulting sheet. I'm trying to force a document to open as locked. The use case is for upgrading documents from our previous file format. In the past, if the user tried to open an old file, we'd upgrade the document, place the new version alongside the old version, and open the new version. We can't do that in the new sandboxing world. So we thought we would open the old version Locked, and if the user tried to make a change we'd present a sheet saying the document was locked because it was in an older file format; the sheet would contain a Duplicate and Upgrade button. Unfortunately, it doesn't look like there's any public API to force a document to be locked. The closest I've come is -[NSDocument checkAutosavingSafetyAndReturnError:], but it doesn't seem to be called at all the times I'd expect it to be called (for example, a new document), and returning NO doesn't put the Locked text in the titlebar; it just prohibits the user from making any changes without duplicating. Likewise, returning YES from -isInViewingMode just makes it impossible to make any changes to the document. We already support the notion of read-only documents in this application, and it would be a shame to reimplement something similar to NSDocument's concept of locked documents, especially if the two fight with each other. Is there any way to hook into the locked documents machinery? Thanks, --Kyle Sluder ___ 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: Locking an NSDocument
On Sep 9, 2011, at 15:05 , Kyle Sluder wrote: I'm trying to force a document to open as locked. The use case is for upgrading documents from our previous file format. In the past, if the user tried to open an old file, we'd upgrade the document, place the new version alongside the old version, and open the new version. We can't do that in the new sandboxing world. So we thought we would open the old version Locked, and if the user tried to make a change we'd present a sheet saying the document was locked because it was in an older file format; the sheet would contain a Duplicate and Upgrade button. While not claiming to have a complete (or even good) response to your question, I'll offer the following perspective: 1. The Locked attribute belongs to the user, and is not yours (the developer, the application, whichever) to manipulate, even with the best of intentions. Surely, when an old-file-format document receives an editing change in the Lion UI world, what you want to do is to immediately and without user interaction create a new version of the document (that is, whatever the Save a Version… menu item does). 2. The Duplicate solution, even if you could get there in the way you propose, doesn't seem like the best way to proceed in the Lion UI world. My reasoning is this: 1. If the document happens to be locked, the normal unlock?/cancel?/duplicate? interaction will occur (or will have occurred -- I don't remember without looking it up exactly when this is triggered). If the document is not locked, it's editable as far as the user is concerned, so involving the user in a decision about what to do just makes your problem (what to do with the old format) the user's problem instead. And though there's no *necessity* to do anything special, as a courtesy to the user it seems desirable to preserve the document as it was before the format change, as a separate version. 2. Part of the value of Versions is that sweeps away all that old cruft about sidegrading documents for reasons such as file format changes. It relieves the user of the need to create (directly or indirectly) multiple distinct copies of a document just in case something happens that creates a new to go back. The Versions mechanism itself provides a better safety net, and it does it automatically (or automatically). By better, I mean the user isn't faced with the file management implied by having multiple differently named files. In short, I guess, the new Versions UI metaphor relieves you of the burden of implementing all of the old safety nets yourself. Does that make any sense? ___ 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: Locking an NSDocument
On Fri, Sep 9, 2011 at 4:34 PM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: 1. The Locked attribute belongs to the user, and is not yours (the developer, the application, whichever) to manipulate, even with the best of intentions. Surely, when an old-file-format document receives an editing change in the Lion UI world, what you want to do is to immediately and without user interaction create a new version of the document (that is, whatever the Save a Version… menu item does). The problem with that is that the actual loading process might be lossy. So if the user receives a version 1 document in an email, and only has version 2 of the application, they will never have an opportunity to use the Versions UI to see the file as Version 1 would present it, and AppKit might autosave the document as soon as it is reverted, which of course will also be a (perhaps even more) lossy process. 2. The Duplicate solution, even if you could get there in the way you propose, doesn't seem like the best way to proceed in the Lion UI world. My reasoning is this: 1. If the document happens to be locked, the normal unlock?/cancel?/duplicate? interaction will occur (or will have occurred -- I don't remember without looking it up exactly when this is triggered). I believe providing a custom recovery attempter from -checkAutosavingSafetyAndReturnError: will give me the opportunity to provide my own custom interaction before the standard behavior is tried: When autosaving in place is turned on an NSDocument may invoke this method when it receives notification from its NSUndoManager that the user changed the document, or undid or redid a change. (Or it may not. NSDocument does not invoke this method for scripted changes or after some kinds of reverting.) If an error is returned it presents the error to the user, allowing the user to choose a recovery option. If the error is recovered from then it repeats this until no error is signalled, to make sure that all checks have been done. This means that when you signal an error and the user's choice of recovery option indicates that they have seen and disregarded a safety concern you must record that fact, and not do that particular safety check again. Once all errors are recovered from NSDocument continues on by invoking -updateChangeCount:, which it has done in response to NSUndoManager notifications since Mac OS 10.0. If an error is not recovered from then NSDocument invokes -[NSUndoManager undo] or -[NSUndoManager redo] to roll back the change. So, some of the NSError recovery options you let the user select, like NSDocument's own Duplicate and Cancel, should indicate failed recovery and that will cause the document to be unchanged afterward. If the document is not locked, it's editable as far as the user is concerned, so involving the user in a decision about what to do just makes your problem (what to do with the old format) the user's problem instead. And though there's no *necessity* to do anything special, as a courtesy to the user it seems desirable to preserve the document as it was before the format change, as a separate version. 2. Part of the value of Versions is that sweeps away all that old cruft about sidegrading documents for reasons such as file format changes. It relieves the user of the need to create (directly or indirectly) multiple distinct copies of a document just in case something happens that creates a new to go back. The Versions mechanism itself provides a better safety net, and it does it automatically (or automatically). By better, I mean the user isn't faced with the file management implied by having multiple differently named files. Leaving the old document aside would be consistent with our old behavior, but consistency isn't required or even necessarily desirable here. It just seemed like the best way to ensure the user had a clear way to fall back to a non-lossy-imported version of their file. The benefit of using the Duplicate machinery for this would be that it's now a standard system behavior that doesn't silently create new files on disk; the old file remains intact, and the new file gets autosaved to the temporary location until the user explicitly chooses to Save it, at which point they're prompted for a location. In short, I guess, the new Versions UI metaphor relieves you of the burden of implementing all of the old safety nets yourself. Does that make any sense? It makes sense, but I don't know if it sufficiently handles the case of upgrading a file from a different file format, since there's no way for the Versions UI to present the original, un-upgraded version of the file—it will always be shown through the filter of upgrading. I feel like explicitly locking and duplicating the file makes the user feel safer. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the
Re: Changing default file - application association
Abdul, I don't know what you mean by Mac OS X refused to change the association. I presume that your V0 and V1 have different bundle identifiers; otherwise there's probably no difference between the two as far as Mac OS X is concerned. Inexplicable problems sometimes occur with document type associations when versioning or copying projects. Here's something that worked for me once: • Do a full clean of All Targets, with Also Clean Dependencies and Also Remove Precompiled Headers. • Rebuild Launch Services database with this command: /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user ___ 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: Lion breaks the ability to click-through transparent window areas when the window is resizable.
Follow-Up:
While doing some additional testing before writing a bug report, I noticed that
Apple's RoundTransparentWindow sample code did work as expected!
Turns out that setIgnoresMouseEvents:NO will do the actual breaking.
Thus:
Bug ID# 10104405
Summary:
Sending setIgnoresMouseEvents:NO to a borderless window makes the transparent
parts of the window opaque to mouse events.
Steps to Reproduce:
1. Take RoundTransparentWindow sample project
(https://developer.apple.com/library/mac/samplecode/RoundTransparentWindow/)
2. Add
[self setIgnoresMouseEvents:NO];
to the CustomWindow class' initializer:
- (id)initWithContentRect:(NSRect)contentRect
styleMask:(NSUInteger)aStyle
backing:(NSBackingStoreType)bufferingType
defer:(BOOL)flag {
// Using NSBorderlessWindowMask results in a window without a title bar.
self = [super initWithContentRect:contentRect
styleMask:NSBorderlessWindowMask backing:NSBackingStoreBuffered defer:NO];
if (self != nil) {
// Start with no transparency for all drawing into the window
[self setAlphaValue:1.0];
// Turn off opacity so that the parts of the window that are not drawn
into are transparent.
[self setOpaque:NO];
// this following call will make the transparent parts of the window
opaque to mouse events!
[self setIgnoresMouseEvents:NO];
}
return self;
}
3. Run project.
4. Click and drag inside the window's frame but outside the visible content.
The window will move.
Expected Results:
Mouse events should be ignored for transparent parts of the window.
Actual Results:
Window receives mouse events everywhere inside its frame, regardless of opacity.
Regression:
This did work as expected in versions of Mac OS X prior to 10.7.
Notes:
Regarding this specific example: Since the window was initially (per default)
set up to NOT ignore mouse events anyway, setIgnoresMouseEvents:NO shouldn't do
anything at all.
Andreas___
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: Lion breaks the ability to click-through transparent window areas when the window is resizable.
On Sep 9, 2011, at 10:43 PM, Andreas Mayer wrote: While doing some additional testing before writing a bug report, I noticed that Apple's RoundTransparentWindow sample code did work as expected! Turns out that setIgnoresMouseEvents:NO will do the actual breaking. Bug ID# 10104405 Summary: Sending setIgnoresMouseEvents:NO to a borderless window makes the transparent parts of the window opaque to mouse events. Hmm. I'm not so sure that isn't intended. From the old AppKit release notes, circa 10.3 https://developer.apple.com/library/mac/#releasenotes/Cocoa/AppKitOlderNotes.html: We fixed -setIgnoresMouseEvents: so that it works more reliably for opaque windows that want to be transparent to mouse events, and also works for transparent windows that want to receive mouse events. In Jaguar, this API only somewhat worked for ignoring events, and did not work at all for receiving mouse events in transparent windows. So, it is apparently intentional that setIgnoresMouseEvents:NO will make a transparent window non-transparent to mouse events. I recognize that this seems to be a change in Lion vs. Snow Leopard, but the Lion behavior seems to restore intended behavior. I guess you'll know for sure when Apple responds to your bug report. 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: Lion breaks the ability to click-through transparent window areas when the window is resizable.
Am 10.09.2011 um 06:21 schrieb Ken Thomases: So, it is apparently intentional that setIgnoresMouseEvents:NO will make a transparent window non-transparent to mouse events. I recognize that this seems to be a change in Lion vs. Snow Leopard, but the Lion behavior seems to restore intended behavior. I guess you'll know for sure when Apple responds to your bug report. I don't think that is the way to interpret that paragraph. As far as I remember, setIgnoresMouseEvents:YES didn't work prior to 10.3 or 10.4; you had to use Carbon calls for this. I know since I just removed the old code. And even if it was as you say, what would be the way to get the initial behavior back after setIgnoresMouseEvents:YES? (Currently, as a workaround, I create a completely new window and move the content view over. Ugh.) Andreas___ 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
