Re: NSTerminateLater and thread
Return NSTerminateCancel when applicationShouldTerminate calls ExecuteLogOutTask to be performed in a secondary thread. At the end of your ExecuteLogOutTask method, call something like [myApplicationDelegate performSelectorOnMainThread: (logOutTaskDidFinish) withObject:nil waitUntilDone:NO]. Then, in logOutTaskDidFinish, call NSApplication's -terminate: method and set a flag indicating that ExecuteLogOutTask was already executed. The next time applicationShouldTerminate is called, return NSTerminateNow if this flag is has been set so ExecuteLogOutTask is not called forever. Cheers, Peter Am 03.06.2011 um 13:49 schrieb Leonardo: I would like my application executes a given task before the log-out. I almost succeeded but since this task could take a few minutes and since I have to launch it on a separated thread (so the user could stop it), I am getting some trouble. In the applicationShouldTerminate method, I know that the Quit has been invoked by the log-out thanks to the NSWorkspaceWillPowerOffNotification So from within applicationShouldTerminate I invoke: [self ExecuteLogOutTask]; return NSTerminateLater; In this case the task gets executed properly but the user cannot cancel it. The application looks unresponsive to the user. So I tried: [NSApplication detachDrawingThread:@selector(ExecuteLogOutTask) toTarget:self withObject:nil]; return NSTerminateLater; But I get a dialog saying: You haven't been logged out because the application MyAppLogOut failed to quit. Try logging out again And the ExecuteLogOutTask has not been called at all. If I return NSTerminateCancel I cancel the whole log-out, which is not what the user expects. So how to manage this case? Regards -- Leonardo ___ 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: NSTerminateLater and thread
Besides from the fact I didn't care about the aborted logout, I was wrong anyway due to bad memory :( But you can bring up an application modal window after detaching the secondary thread in applicationShouldTerminate, giving the user options like cancelling, showing a progress indicator etc.. Repeatedly call runModalSession until the task is finished or the user cancelled. This worked fine for me in a similar situation. I guess a logout will time out anyway if the task takes too long. Cheers, Peter Am 03.06.2011 um 22:23 schrieb Leonardo: Thank you Kyle, however, I realize, it's incredible there is no way to execute a task before quitting the app. I easily run a task at launch but I can't run a task before quit. The problem is that the task could a few minutes and the app should remain responsive to the user, in the best Mac tradition. I will struggle myself some day more on this issue. Let's cross the fingers. Regards -- Leonardo Da: Kyle Sluder kyle.slu...@gmail.com Data: Fri, 3 Jun 2011 11:35:41 -0700 A: Peter Lübke sound-fab...@gmx.de Cc: Leonardo mac.iphone@gmail.com, Cocoa Developers cocoa-dev@lists.apple.com Oggetto: Re: NSTerminateLater and thread 2011/6/3 Peter Lübke sound-fab...@gmx.de: Return NSTerminateCancel when applicationShouldTerminate calls ExecuteLogOutTask to be performed in a secondary thread. At the end of your ExecuteLogOutTask method, call something like [myApplicationDelegate performSelectorOnMainThread: (logOutTaskDidFinish) withObject:nil waitUntilDone:NO]. Then, in logOutTaskDidFinish, call NSApplication's -terminate: method and set a flag indicating that ExecuteLogOutTask was already executed. The next time applicationShouldTerminate is called, return NSTerminateNow if this flag is has been set so ExecuteLogOutTask is not called forever. That's not going to resume the aborted logout. Leonardo, you will need to either finish your task in the time allotted by NSTerminateLater, or you will need to abort logout. --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: Properly comparing file NSURLs for equality?
[ [someURL absoluteURL] isEqual:[otherURL absoluteURL]] should return correct results. Cheers, Peter Am 28.05.2011 um 01:13 schrieb Sean McBride: Hi all, What is the correct way to test if two NSURLs refer to the same file system object? I've just learnt the hard way that one can have two URLs that refer to the same file system object but because they are subtly different, isEqual: returns NO: ex: file://localhost/Volumes/Disk/Users vs file:///Volumes/Disk/Users isEqual: returns NO. I guess this makes some sense, but it's not the kind of equality I'm looking for. What would best practice be? Convert to full path, and compare those? Note: I'm not concerned about resolving symlinks or aliases. (Aside: I was surprised to see that there is no isEqualToURL:, analogous to isEqualToString, isEqualToSet, etc. I wonder why...) Thanks, -- ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Properly comparing file NSURLs for equality?
Douglas, That's perfect! But for, shall we say, older cats :), would be next best thing be CFURLGetFSRef() FSCompareFSRefs()? It seems ideal since it solves the problem of needing to canonicalize paths. Peter, I tried absoluteURL but it doesn't change the result when the difference is only the 'localhost' part. :( Yes I know. ( [myAnswer wasAbsolutelyPointless] == YES ); Am 28.05.2011 um 01:38 schrieb Peter Lübke: [ [someURL absoluteURL] isEqual:[otherURL absoluteURL]] should return correct results. ___ 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
Table view with NSImageCell scrolls A LOT slower with bindings than with dataSource
Hi all, I have a table view with all columns bound to keys of an NSArrayController. The array controller implements some data source methods, mainly for drag and drop support. One of the columns uses an NSImageCell to display 32 x 32 icons. Scrolling the table view vertically gets very slow if the icons's column is within the table view's visible portion. Surprisingly, it gets a lot faster if I implement - tableView:objectValueForTableColumn:row: in the data source (= the array controller). - tableView:objectValueForTableColumn:row: returns the value for the corresponding key, which is exactly the same key as used by the bindings. The table view doesn't show this behaviour for its other columns which use the default data cell (NSTextFieldCell). Any ideas what might be going on here? Nice weekend to everybody, Peter ___ 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: delete entries in a tableView with the backspace-key on the keyboard
Am 29.04.2011 um 23:19 schrieb Sean McBride:
See:
http://lists.apple.com/archives/cocoa-dev/2010/Apr/msg01044.html
Sean,
is there a special reason why the sample code is working with [event
characters]?
I've merely been doing
if ( [event keyCode] == 51) {
... }
to determine if the backspace key was pressed to delete a table row.
Is this a bad idea? Is the keycode for the backspace key possibly
subject to changes?
- Peter
___
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: Aliases with NDAlias not appearing where I tell them to be.
Am 27.04.2011 um 21:09 schrieb Quincey Morris: ..., and I don't see NDAlias having a documented 'writeToFile' method at all, and (even if it did) ... It actually does, as I just found out looking at Nathan Day's homepage: http://homepage.mac.com/nathan_day/pages/source.xml He and Sean McBride updated NDAlias and, besides adding other stuff, added a category to read and write alias files. Cheers, Peter ___ 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: icon radio buttons, NSToolbar?
In cases alike I sometimes find the UIElementInspector application quite helpful to get an idea about which objects make up a view hierarchy. - Peter Am 19.04.2011 um 00:50 schrieb Todd Heberlein: I'm trying to get a row of buttons to look and behave like the buttons across the Preview app's preference window. It seems like a nicer way to do a tabbed view. Is that just an NSToolbar with custom graphics/icons, or is that NSMatrix with icon radio buttons? Or is it something else entirely? Thanks, Todd ___ 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: renaming directories and moving files into them (NSFileManager)
Am 15.04.2011 um 08:51 schrieb Scott Anguish: It always creates a new directory wit the new name, in the existing shootPath directory (for example /tmp/boo/Friday) with Friday-APPL instead. and then copies the newly found files into that. If I get you right, the *real* path for the new directory is /tmp/boo/ Friday/Friday-APPL? If this is true, how can the newly found files end up there if you copy them to /tmp/boo/Friday-APPL? You should also log the path when the newly found files are copied. - Peter ___ 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: Preventing View Update in NSTableView
Am 14.04.2011 um 04:20 schrieb Graham Cox: On 14/04/2011, at 10:13 AM, Peter Lübke wrote: I'd like to temporarily 'freeze' the cells in the table view while the data displayed in those cells are changed so they are not continuously redrawn. When the changes are completed, they should be updated at once. This is what happens by default. The redraws do not take place until the event loop completes, so if all your changes are made within the event cycle, you'll only get one redraw. If you are changing your data model one item per event loop - which you'd have to go to a lot of trouble to accomplish - then you'll get the table updating for each change. This is of course true if the changes are made in the main thread. I should have mentioned that I'm changing the data in separate worker threads. Actually, it's possible that there are several worker threads changing data of different tables in different windows at the same time, while the associated windows display attached sheets showing progress. Permanently redrawing the tables's cells at this stage is confusing and also undesirable for performance reasons. Am I missing something I could override in my table view or array controller? Thanks, Peter___ 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: Preventing View Update in NSTableView
Silly me! The data model objects *do *set some of their bound ivars when performing the task in question on the background thread (writing to files, sending apple events ...). I was using a data source before, so this was no problem. I just rewrote my code to use bindings / NSArrayController, but didn't review those objects's class implementation. I'll go with your proposal to defer changes to the data model, and update the data in another iteration when the background thread is done. Thanks for pointing me to the right direction, Peter Am 14.04.2011 um 20:49 schrieb Quincey Morris: This is of course true if the changes are made in the main thread. I should have mentioned that I'm changing the data in separate worker threads. Actually, it's possible that there are several worker threads changing data of different tables in different windows at the same time, while the associated windows display attached sheets showing progress. Permanently redrawing the tables's cells at this stage is confusing and also undesirable for performance reasons. This *seems* to be wrong at several levels, although perhaps that's just because there's information missing. If processing in background threads is causing table views to update directly, then your application design is very seriously broken. All drawing should be done from the main thread, which means that KVO notifications must be issued on the main thread, which means that the data model must be updated on the main thread, as far as KVO compliance is concerned. You cannot bind UI elements to objects whose KVO-compliant properties are updated directly by a background thread. It's possible that you mean that the updates *are* happening on the main thread, and you have a mechanism that the background threads use to pass the updates to the main thread. But if not, you're going to have to invent such a mechanism. Avoiding refreshes of the table views is a different issue. By binding your table columns to an array controller, which is in turn bound or connected to your data model, you have *opted in* to a mechanism (KVO) that is explicitly designed to push updates as and when they occur. So, complaining that refreshes occur as and when updates are pushed seems a bit misguided. You're going to have to either opt out of that mechanism, or you're going to have to modify its behavior: -- You can use a data source instead of bindings. With a data source, nothing gets updated till you tell the table view to display or to reload (or till something a user does triggers redrawing). You'll lose some of the free functionality that array controllers provide (if you're using it), but it shouldn't be hard to implement for yourself. -- You can invent a mechanism for deferring changes to your data model, until a point where UI refreshes are appropriate. It doesn't sound like you can take this approach, because it sounds like your background threads depend on the current state of the data model being generally available. -- You can use a mediating controller, for example the window controller, to capture the KVO notification data from data model updates, and to withhold it from the UI until a suitable refresh time arrives. In this case, your array controller's content can't be the data model, but has to be a intermediate data model or a proxy data model in the mediating controller. ___ 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 enable accessibility for Screen Change
You should rather post your question to Accessibility- d...@lists.apple.com. Am 13.04.2011 um 11:30 schrieb Symadept: Hi, I am looking for a multiview app, if I am navigating to Page 2 from Page 1 is there a way I can enable accessibility such that, Voice Over can read as I am transitioning to Page 2. Glad to see your responses. Regards symadept ___ 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
Preventing View Update in NSTableView
Hi, I have an NSTableView subclass bound to an NSArrayController. I'd like to temporarily 'freeze' the cells in the table view while the data displayed in those cells are changed so they are not continuously redrawn. When the changes are completed, they should be updated at once. For various reasons, executing the changes on a copy of the array controller's content is no option. Thoughts? - Peter ___ 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: Access main window of other Applications
Am 07.04.2011 um 17:01 schrieb Florian Pilz: Hi there! I'm looking for an easy way to access the main window of another Application, thus not my own. (The key window would be fine as well, if that is easier.) I already searched via Google to solve this task and I found the following solutions: * use AppleScript to perform this task and integrate it into the Objective-C/Cocoa App with a Wrapper class, i.e. NSAppleScript * use Quartz Window Services * use the NSAccessibility Protocol All three solution don't satisfy me, because a) I wanted to perform the task in Objective-C (not AppleScript) There's nothing bad about using Cocoa NSAppleScript in a Cocoa app. Presumed the target app is scriptable. (Apple Script:) tell application someAppName set theWindow to window 1 end tell , b) the Quartz API looks complicated and inappropriate (maybe I'm wrong - feel free to correct me) and c) I couldn't find any examples on using the NSAccessibility protocol to retrieve the main window, kAXMainWindowAttribute not mentioning the discomfort that the user may activate access to accessibility features first. Agreed. The answer depends on your goal. Which information do you need about the window? Do you want to change its properties? - Peter ___ 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: Display a Red frame on the screen
Am 08.04.2011 um 19:24 schrieb eveningnick eveningnick: I was thinking about the window. But then it has to be something with a big hole inside. This hole ought to be transparent for mouse clicks (so if there's something below my window, that 'something' has to be clickable and focused, and receive keyboard input)? Is it possible to do somehow? Borderless is a window without a title (as i understand). What kind of properties should i specify to make a window as that Red frame? I mean, i really want it to be just a mark for the user, without any windowing behaviour (well, the user can drag it, if he clicks on the 'red frame' with mouse, but that is the only relation to a real window it should have). In OS Windows i would probably use Regions API, but i have no idea what to do in Mac OS. Could you give me a clue? Invoke -setIgnoresMouseEvents: on the borderless window. Cheers, Peter ___ 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: API to determine a list of installed scriptable applications
Am 02.04.2011 um 11:56 schrieb jonat...@mugginsoft.com: Is there an API to determine a list of installed scriptable applications? Such a list is displayed by the AppleScript Editor menu item Open Dictionary... Application bundles can be queried for using MDQuery and the scriptability of a given application can be be determined. I don't think that ASE uses this approach as its existence long predates Spotlight etc. Also the ASE list includes items that have not been previously launched. Regards Jonathan Mitchell The list of the applications shown in AppleScript Editor menu item Open Dictionary... is stored in a plist file: home/Library/Preferences/com.apple.ScriptEditor2.plist (key: LibraryApplications). I think the reason you see items that haven't been previously launched is that these are Apple Applications / Additions that might already be in the plist when the OS is installed. Maybe you can use these as a starting point and add items to your own .plist file as you or your users found more scriptable apps? Just out of interest: how do you determine scriptability of an application without launching it? Cheers, Peter ___ 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: Hash Values in Custom Classes
Am 28.03.2011 um 20:06 schrieb Sean McBride: Are you aware that starting in 10.6, the OS provides 'file reference URLs' which are much like FSRefs. See: http://developer.apple.com/library/mac/#releasenotes/Cocoa/ Foundation.html Good to know. I'm very interested in your experience related to: - Under which circumstances will fileReferenceURL break when decoded from an archive? (Item moved, overwritten ...) - What about performance? I often find that NSFileManger is a lot slower than my custom classes - would I have to expect the same with fileReferenceURL? For right now, I'm happy with my wrapper classes - they are highly reusable, I'm using them in several apps which all are backward compatible back to 10.4, and they have initializers for about anything that can possibly be used to get a file reference. Cheers, Peter ___ 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: Hash Values in Custom Classes
Am 29.03.2011 um 23:26 schrieb Jean-Daniel Dupas: Am 28.03.2011 um 20:06 schrieb Sean McBride: Are you aware that starting in 10.6, the OS provides 'file reference URLs' which are much like FSRefs. See: http://developer.apple.com/library/mac/#releasenotes/Cocoa/ Foundation.html Good to know. I'm very interested in your experience related to: - Under which circumstances will fileReferenceURL break when decoded from an archive? (Item moved, overwritten ...) File reference should not be archived. They are valid only for the application lifetime. Obviously. This makes me think that somewhere inside fileReferenceURL there is an FSRef in use. Use Bookmark (provided by NSURL class too) for archiving. I was referring to this statement in the Release Note: When asked to perform keyed archiving, file reference URLs will encode their minimal bookmark data and when decoded will resolve to a file path URL (if you wish to receive a file reference URL from this, please call -[NSURL fileReferenceURL] on the resulting item). ...so it seems we are talking about the same point. But right, my question was obsolete because I overlooked that fact that bookmarks are alias files - so this will give me what I can expect from Alias Manager. Thank you for pointing me to this, Peter ___ 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: Hash Values in Custom Classes
To be more detailed: my custom class and its subclasses are wrapper classes containing file informations. They are based on FSRef rather than using paths - I do a lot of lengthy iterations so paths are much too fragile. I also heavily use NSSet to store instances, and I wanted -isEqual: to be as fast as possible. So I thought I could just return a unique hash value for each custom class and return (FSCompareFSRefs (ownRef, otherRef) == noErr) for -isEqual:, thus avoiding the need to *first* compare the objects' classes. Am 28.03.2011 um 01:23 schrieb Mike Abdullah: http://www.mikeash.com/pyblog/friday-qa-2010-05-28-leopard- collection-classes.html Good link, particularly NSPointerArray might come in handy in future projects. I trust you have profiled your code etc. before deciding this is worth your while… For my current project, NSSet works fine. I'll test for class identity before calling FSCompareFSRefs() in the -isEqual: methods of my custom classes, so I'm not dependant on *absolute* uniqueness of the values they return for -hash. Cheers, Peter___ 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: copyPath:toPath:handler: more reliable than copyItemAtPath:toPath:error: ???
Am 26.03.2011 um 16:41 schrieb Matt Neuburg: On Fri, 25 Mar 2011 12:08:53 -0700, Laurent Daudelin laur...@nemesys-soft.com said: I've been trying to copy items from a local disk to an AFP-mounted volume with copyItemAtPath:toPath:error: and I found it to be unreliable in the sense that it will fail to set the modification date of the item copied to match that of the original item. It doesn't report any error, just silently continues. I'm curious as to how performFileOperation:source:destination:files:tag: does with this. But I don't hold out much hope. Also, cp now handles resource forks okay, and it has a -p option that preserves dates. So that might be another thing to try. In my own application, which relies on mod dates (it syncs folders), I had so much trouble with all this that in the end I resorted to Apple events telling the Finder to perform the copy - and then more Apple events to fix the mod dates afterwards. In recent versions of the system I've been able to eliminate the mod date fixing part; the Finder now gets this right. Of course this relies on the Finder running. Still, wasn't the big advertisement for copyItemAtPath supposed to be that it does the same thing the Finder does? So if it fails to do that, that would be a bug. I don't believe that copyItemAtPath preserves Spotlight Comments, so anyway it does not the *same* thing the Finder does. Or am I wrong on this? Peter ___ 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: Hash Values in Custom Classes
Am 26.03.2011 um 14:57 schrieb Mike Abdullah: To be more detailed: my custom class and its subclasses are wrapper classes containing file informations. They are based on FSRef rather than using paths - I do a lot of lengthy iterations so paths are much too fragile. I also heavily use NSSet to store instances, and I wanted -isEqual: to be as fast as possible. So I thought I could just return a unique hash value for each custom class and return (FSCompareFSRefs (ownRef, otherRef) == noErr) for -isEqual:, thus avoiding the need to *first* compare the objects' classes. This is pretty much what NSSet will be doing for you. It uses -hash to narrow down possible matches, before calling -isEqual: only on those that share a hash. This was about the only point that was evident to me :-) You should find this plenty enough fast enough if your hash values actually are unique. This was the reason for my silly question. I know my app will only add instances of appropriate classes to the sets, but nevertheless I want to do it the right way. If not, about the only optimization from there is a NSHashTable or CFSet setup to test equality on -hash. Could you point me to a documentation that could help me understand NSHashTable? Thanks again, Mike. Cheers, Peter ___ 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: Hash Values in Custom Classes
If not, about the only optimization from there is a NSHashTable or CFSet setup to test equality on -hash. Could you point me to a documentation that could help me understand NSHashTable? Badly expressed - I meant documentation / sample code about how to use an NSHashTable for such an optimization. ___ 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
Hash Values in Custom Classes
Hi, I'm wondering if there exists a listing of the hash values used by the various Cocoa / CoreFoundation classes. I override -isEqual in my custom classes and want to make sure I don't assign hash values that interfere with the framework(s). Thanks, Peter ___ 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: Hash Values in Custom Classes
Thank you, Mike, for showing me I was taken away by my own fantasy about hash... Am 26.03.2011 um 01:22 schrieb Mike Abdullah: It sounds like you're rather misunderstanding what -hash does. Cocoa classes are free to cover the full range of possible hash values. In the meantime, I read some related posts on the list and had to recognize this, too...Sorry, this was the first time I was looking at hash values at all. You can't have a value that interferes with the framework; at worse you could reduce performance IF putting custom objects in the same container as framework-provided classes. Even then you'd be hard-pressed to do this regularly. To be more detailed: my custom class and its subclasses are wrapper classes containing file informations. They are based on FSRef rather than using paths - I do a lot of lengthy iterations so paths are much too fragile. I also heavily use NSSet to store instances, and I wanted -isEqual: to be as fast as possible. So I thought I could just return a unique hash value for each custom class and return (FSCompareFSRefs (ownRef, otherRef) == noErr) for -isEqual:, thus avoiding the need to *first* compare the objects' classes. ___ 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: iPhone: NSFileManager/NSDirectoryEnumerator Crash?
What about your files collection? Are you sure it is still valid
AND mutable on the second invocation?
Peter
NSString* directory = nil;
NSFileManager* fileManager = nil;
NSDirectoryEnumerator* walker = nil
directory = [NSHomeDirectory()
stringByAppendingPathComponent:@Documents];
if(directory == nil)
/* handle error and exit */
// fileManager = [NSFileManager defaultManager];
fileManager = [[NSFileManager alloc] init];
if(fileManager == nil)
/* handle error and exit */
walker = [fileManager enumeratorAtPath:directory];
if(walker == nil)
/* handle error and exit */
NSString* file = nil;
while((file = [walker nextObject]) != nil)
{
BOOL isDirectory = YES;
if([fileManager fileExistsAtPath:file
isDirectory:isDirectory] !isDirectory)
[files addObject:file];
}
...
[fileManager release];
___
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: WindowID to front
Hi Benedikt, this is Interapplication Communication, so it seems it's time for you to get into AppleEvents:-) Send an AppleEvent to the other app to set the window's index to 1 (indexes in AppleEvents are 1-based!). Cheers, Peter p.s.: Schöne Grüße aus München Am 27.02.2011 um 13:55 schrieb Benedikt Iltisberger: Hello everybody, I read tons of information on how to set and get the PID but i need a way to set a window to front (and not a window of a PID). The problem is that if I set a PID to front, it might not be the exact window i want because the process can have multiple windows. With help of the CGWindowListCopyWindowInfo I can get all window IDs and filter out the needed one. But how can I now set the selected window ID to front? (Note: It is a window of a foreign application which I want to set to front. My own app wouldn't be a problem.) It would be very glad if somebody has a advise for me. Thanks in advance. Cheers Benedikt ___ 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: WindowID to front
There's no problem accessing a window by its (application specific!) ID by AppleEvents / AppleScript. (Must have been decades since you last opened Script Editor, Uli :-) ). Of course this depends on the application supporting AppleEvents... Just run this script in Script Editor: tell application otherApplication properties of every window end tell Look at the result to see whether there´s an ID property. Since I guess Benedict is working in the sphere of Accessibility anyway, it might indeed be more appropriate to just call AXRaise on the AXWindow element. The reason I proposed AppleEvents was because he was asking for adressing the window by its ID. Am 28.02.2011 um 10:33 schrieb Uli Kusterer: On 27.02.2011, at 13:55, Benedikt Iltisberger wrote: But how can I now set the selected window ID to front? (Note: It is a window of a foreign application which I want to set to front. My own app wouldn't be a problem.) Not sure you can use that information for anything (I don't think AppleScript deals in Window IDs, but that may have changed since I last had to put up with it). You may have more luck using the accessibility APIs to both list the windows and then bringing one to front. Cheers, -- Uli Kusterer ___ 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: WindowID to front
I'm pretty sure you don't really need CGWindowListCopyWindowInfo() to do this. Am 28.02.2011 um 11:51 schrieb Benedikt Iltisberger: Hi Peter, exactly what I thought. But how do I obtain the AXUIElementRef of a window which I looked up from the Window-Server (with CGWindowListCopyWindowInfo)? First of all, by which criteria do you select the window in CGWindowListCopyWindowInfo() ? What kind of informations do you have about the window? Iterate over the kAXWindowsAttribute elements. For each AXWindow element, get the attribute value for the attribute you know ( AXUIElementCopyAttributeValue() ) until this value is equal to the desired value. In other words: (Example) I have 4 Finder windows and I want to AXRaise a certain one. Therefore I create a list with CGWindowListCopyWindowInfo and select the right one. But how can I come from this step to the equivalent AXUIElementRef, which I need to have in order to set the AXRaise? Sorry for bothering you like that but I guess this is also an interesting issue for other users. Your'e welcome... Cheers, Benedikt On 28.02.2011, at 11:19, Peter Lübke wrote: There's no problem accessing a window by its (application specific!) ID by AppleEvents / AppleScript. (Must have been decades since you last opened Script Editor, Uli :-) ). Of course this depends on the application supporting AppleEvents... Just run this script in Script Editor: tell application otherApplication properties of every window end tell Look at the result to see whether there´s an ID property. Since I guess Benedict is working in the sphere of Accessibility anyway, it might indeed be more appropriate to just call AXRaise on the AXWindow element. The reason I proposed AppleEvents was because he was asking for adressing the window by its ID. Am 28.02.2011 um 10:33 schrieb Uli Kusterer: On 27.02.2011, at 13:55, Benedikt Iltisberger wrote: But how can I now set the selected window ID to front? (Note: It is a window of a foreign application which I want to set to front. My own app wouldn't be a problem.) Not sure you can use that information for anything (I don't think AppleScript deals in Window IDs, but that may have changed since I last had to put up with it). You may have more luck using the accessibility APIs to both list the windows and then bringing one to front. Cheers, -- Uli Kusterer ___ 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: WindowID to front
Uli, I apologize for my silly comment. Of course you are absolutely right. I totally overlooked you were refering to a User Session window ID, which is totally different from an application specific window ID. Cheers, Peter Am 28.02.2011 um 11:19 schrieb Peter Lübke: There's no problem accessing a window by its (application specific!) ID by AppleEvents / AppleScript. (Must have been decades since you last opened Script Editor, Uli :-) ). Of course this depends on the application supporting AppleEvents... Just run this script in Script Editor: tell application otherApplication properties of every window end tell Look at the result to see whether there´s an ID property. Since I guess Benedict is working in the sphere of Accessibility anyway, it might indeed be more appropriate to just call AXRaise on the AXWindow element. The reason I proposed AppleEvents was because he was asking for adressing the window by its ID. Am 28.02.2011 um 10:33 schrieb Uli Kusterer: On 27.02.2011, at 13:55, Benedikt Iltisberger wrote: But how can I now set the selected window ID to front? (Note: It is a window of a foreign application which I want to set to front. My own app wouldn't be a problem.) Not sure you can use that information for anything (I don't think AppleScript deals in Window IDs, but that may have changed since I last had to put up with it). You may have more luck using the accessibility APIs to both list the windows and then bringing one to front. Cheers, -- Uli Kusterer ___ 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: WindowID to front
Am 28.02.2011 um 15:10 schrieb Benedikt Iltisberger: Hey Peter, I did it exactly like you proposed. Works perfect :-) I am using following calls to make a selected window front most: AXUIElementPerformAction(windowElement, kAXRaiseAction); This should be sufficient to bring the window to front. AXUIElementPerformAction(windowElement, kAXIncrementAction); Are you sure this has any effect? As far as I can see, AXWindow doesn't have a settable AXValue attribute, so why increment a non- existing value? I simply used the fact that and kAXWindowsAttribute arrange their arrays in the same order. I did some testing and its working fine :-) Fine it works for you like this - but I still see a problem: The fact that two different APIs return the items in the same order on your configuration doesn't at all prove this is going to be true for other users' configuration, other OS versions... Maybe we can find a cleaner solution before I have my Weissbier, so I keep asking for the key / value you inquire in CGWindowListCopyWindowInfo() to decide which is the desired window? Thank you very much and I hope you are going to have a decent bavarian Weissbier tonight. I am going to have one for sure :-) Kind regards, Benedikt ___ 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: WindowID to front
Am 28.02.2011 um 16:55 schrieb Benedikt Iltisberger: Hey Peter, you are right. AXUIElementPerformAction(windowElement, kAXIncrementAction); Has no effect. I also recognized that the AXRaise seems to be not exactly what i wanted. If I raise a window for the first time it works fine. If I raise other windows after that and try to raise the first window again it sometimes doesn't become the frontMost window. I guess I have an error in my understanding of AXRaise. I was not able to reproduce this behaviour. Are you sure the AXWindow element is still valid when you call it again? You are right. This is not a suitable solution. I was just happy to see that it could work. The keys I inquire in CGWindowListCopyWindowInfo() are: kCGWindowOwnerPID and kCGWindowNumber (but kCGWindowNumber is totally pointless here because i cannot use it for accessibility api). I try to gather all windows which belong to the same ProcessID so the user can select one and set it front most (using AXRaise). Cheers Benedikt Important to know you let the user select the window, maybe from a popup button? In this case, simply gather the AXTitle attributes for the application's kAXWindowsAttribute elements. Populate the popup button (or whatever you present to the user) with these. The selection will tell you which AXWindow to raise. Representing AXTitle attributes to the user is presumably a lot more transparent than everthing CGWindowListCopyWindowInfo() is guaranteed to provide, since kCGWindowName is only an *Optional* Window List Key, and, as the docs say: ...(Note that few applications set the Quartz window name.) Cheers, Peter ___ 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: NSWindowController
BTW, is there a particular reason why you retain m_designViewerController ? A newly allocated object *is* a retained object. It will need one extra entire line of code to send a -release message to the object for it not to leak :-) -Peter Am 26.02.2011 um 09:08 schrieb koko: 1 m_designViewerController = [[[NSWindowController alloc] initWithWindowNibName:@DesignViewer] retain]; ___ 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: Getting NSScrollView to ignore scrolling
HI All, I have a NSTableView/NSScrollView setup that I've configured automatically to resize to contain the content of the table. This may sound silly, but I don't want scrolling behavior, but NSTableView seems to be designed to be inside a NSScrollView. My question is this: how do I get the scroll view to ignore scrolling messages? The tables/scrollviews are sitting on views that are part of a homebrew collection view, and the scrolling catches on them, even though there's no scrolling to be done. The scroll view is taking the events, but there is nothing for them to do. I want to be able to scroll past the table using a scrollwheel or the trackpad without the scrolling action catching. What do you mean with scroll past the table? Did you try to call setHasHorizontalScroller:NO, setHasVerticalScroller: NO, setHasHorizontalRuler:NO, setHasVerticalRuler:NO and setLineScroll:0.0 on the enclosing scroll view? You can create your own table view without an enclosing scroll view; there's some more work to do than simply dragging an NSTableView into a window in IB. Create an NSTableView subclass, add your table columns, override -calcSize and -sizeToFit to fit your resizing behaviour, and add it wherever it is supposed to be in your view hierarchy. Start creating instances with [[myTableView alloc] - initWithFrame:...]. Cheers, Peter ___ 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: NSComboxBox alternative
What about NSTableView? Just one column with a pretty large width... - Peter Am 17.02.2011 um 20:41 schrieb FirstName LastName: I have a selectable non-editable NSComboBox for choosing paths. However some of these paths are larger than the NSComboBox's width causing the following problems: 1. The list does not show the path's file names and extensions and there's no way to add a horizontal scroller. 2. The textfield is scrolled programmatically to show the file name and extension but the scroll goes away when another view becomes first responder. What do you suggest for being able to show file names and extensions in a list of paths? And keeping the currently selected one scrolled? (Unless changed by the user). Any help. ___ 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: Get ProcessSerialNumber of last front application
GetNextProcess() doesn't reflect the order in which processes were made front, as the Process Manager doc says: Note that the order of the list of processes is internal to the Process Manager which *seems* to be the order in which processes register with Process Manager; if this is true (I don't know whether you can rely on it), you could at least use GetNextProcess() to track the (backwards) order in which processes registered with process manager. An easy way to look at this is an AppleScript: tell application System Events name of every process end tell I don't quite understand the scenario though: are you looking for the process that was front before the user launched your application? Cheers -Peter Am 09.02.2011 um 16:23 schrieb Mr. Gecko: Hello, I am wondering how I can get the last front application ProcessSerialNumber so I can use SetFrontProcess to bring it back to front after they close the window to my application. My application is a UIAgent so it doesn't have a dock icon and I am thinking that the user would like it more if when they close the window to my application it will make the previous application so it's front. The way they open my window is by opening the application via the finder or dock (if they have it in the dock). My application runs in the background to keep track of things and I know my customers would not want a menubar icon as I don't want one as well. I know there is GetFrontProcess, but that is useless when the application becomes front before I call it due to them opening it in the finder and GetNextProcess gets Quick Look Helper. I hope I explained things well, thanks for any help. Mr. Gecko___ ___ 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: worker thread iterating over array - SLOW
Ken, you really made the whole issue clear to me. I ran my app in the debugger with breakpoints inside the methods of the objects in the array, and as you say, every single method is executed in the main thread! I'll have a look at YAMessageQueue. Thanks again for your great input, Peter Am 01.02.2011 um 05:45 schrieb Ken Thomases: On Jan 31, 2011, at 8:48 PM, Peter Lübke wrote: Thanks Ken, You're welcome. Am 01.02.2011 um 02:07 schrieb Ken Thomases: So, you have effectively failed to shift the work from the main thread to the worker thread. The main thread is a server doing all of the work on the behalf of its client, the worker thread. Not quite... In this case, the worker thread is the server. If the main thread owns the real array and the worker thread receives a proxy of the array (and thus its elements), then the main thread is the server, serving the services of the array and its elements to the worker thread. It doesn't matter how you intended/designed things to work. I guess that's why the main thread is all the way responsive. This probably has to do with the granularity of the messages that the worker thread is sending to the array and its elements. If it's invoking many quick methods, then the main thread will remain responsive, even if it's doing all the work. That's because there are frequent opportunities for it to respond to GUI events between messages from the worker thread. Also, you want to design a fairly coarse-grained protocol of requests that a client can make of the server -- few requests to do some big chunks of work, not many requests for small chunks of work. This is what I thought I was doing, the bad thing - if I get it right - is that I pass the array to the server? Basically, yes. It's not a hard and fast rule that doing so is always wrong or bad. Just remember that every method invoked on the proxy is delivered to the original object over the D.O. connection, the provider of that original object does the work, and then results are passed back -- and if the results are non-value objects, they are passed by reference, meaning as proxies. So, the proxiness can cascade. There's a bunch of these arrays around, all containing objects of one class. There's another bunch of objects of various classes that access these objects. I didn't like the idea of implementing the creation of threads that always kind of do the same sort of work in each of these different classes. So I thought it might be a good idea to have a singleton thread manager create worker threads as needed and coordinate those different object's requests. That's a thread pool. You can use any number of synchronization techniques to give work to the threads in a pool. NSConditionLock is nice and straightforward. See http://developer.apple.com/ library/mac/documentation/Cocoa/Conceptual/Multithreading/ ThreadSafety/ThreadSafety.html. There are also message queue implementations to do something a bit like D.O., except without the proxying. I've used YAMessageQueue in the past. It's also not too hard to roll your own. Cheers, 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
worker thread iterating over array - SLOW
Hi list, I use a worker thread in my app that invokes the same method(s) on all objects in an array sent from the main thread. The array may contain thousands of objects. The main thread communicates with the worker thread via distributed objects. Everything works fine except performance is too slow. Seems to me that my NSConnection asks for the method signature each time the method is invoked on an object in the array, thus adding massive overhead. The shared objects approach - call NSThread's - detachNewThreadSelector:toTarget:withObject: with the array as argument 3, have the secondary thread do the job and exit - is way faster! I just started using DO and probably missed more than one thing, so any help is very much appreciated. - Peter ___ 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: worker thread iterating over array - SLOW
Am 01.02.2011 um 00:20 schrieb A.M.: On Jan 31, 2011, at 6:13 PM, Peter Lübke wrote: Hi list, I use a worker thread in my app that invokes the same method(s) on all objects in an array sent from the main thread. The array may contain thousands of objects. The main thread communicates with the worker thread via distributed objects. Everything works fine except performance is too slow. Seems to me that my NSConnection asks for the method signature each time the method is invoked on an object in the array, thus adding massive overhead. The shared objects approach - call NSThread's - detachNewThreadSelector:toTarget:withObject: with the array as argument 3, have the secondary thread do the job and exit - is way faster! I just started using DO and probably missed more than one thing, so any help is very much appreciated. Did you set the root proxy protocol? -[NSDistantObject setProtocolForProxy:] I can -setProtocolForProxy: for the proxy for the array, but I can't do it for the objects in the array, right? Perhaps you could also look at -[NSRunLoop performSelector:onThread:withObject:waitUntilDone:]. You probably meant -[NSObject performSelector:onThread:withObject:waitUntilDone:]. The -performSelector:... methods don't offer the flexibility I need here, so I'll rather have to go for NSInvocation. Besides from this, I'd like my app to continue running in Tiger, and unfortunately, in Tiger there's only - performSelectorOnMainThread:... . methods. Cheers, Peter ___ 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: worker thread iterating over array - SLOW
Thanks Ken, I was afraid to get an answer like this:-) Am 01.02.2011 um 02:07 schrieb Ken Thomases: On Jan 31, 2011, at 5:13 PM, Peter Lübke wrote: I use a worker thread in my app that invokes the same method(s) on all objects in an array sent from the main thread. The array may contain thousands of objects. The main thread communicates with the worker thread via distributed objects. Everything works fine except performance is too slow. Seems to me that my NSConnection asks for the method signature each time the method is invoked on an object in the array, thus adding massive overhead. Well, that's part of it, but probably not the biggest part. The way you're using D.O. defeats the purpose of having a worker thread. Sending the array from the main thread to the worker thread causes the worker thread to receive a proxy for the array. Then, as you request each element of the array, that's a message to the main thread and back, and what you get is... a proxy for the element (not the element itself). Then, every operation you perform on the element is a message to the main thread _and the main thread performs the work on behalf of its client_. So, you have effectively failed to shift the work from the main thread to the worker thread. The main thread is a server doing all of the work on the behalf of its client, the worker thread. Not quite... In this case, the worker thread is the server. I guess that's why the main thread is all the way responsive. The worker thread also sends messages to the main thread updating a progress indicator which all works nice. If you're going to use D.O., ideally you want the messages to either carry no data or to carry data values (bycopy), not references to objects. Thanks for clarifying this. This explains a point I totally overlooked. Also, you want to design a fairly coarse-grained protocol of requests that a client can make of the server -- few requests to do some big chunks of work, not many requests for small chunks of work. This is what I thought I was doing, the bad thing - if I get it right - is that I pass the array to the server? The shared objects approach - call NSThread's - detachNewThreadSelector:toTarget:withObject: with the array as argument 3, have the secondary thread do the job and exit - is way faster! Is there a reason that's not sufficient? Why are you trying to use D.O.? There's a bunch of these arrays around, all containing objects of one class. There's another bunch of objects of various classes that access these objects. I didn't like the idea of implementing the creation of threads that always kind of do the same sort of work in each of these different classes. So I thought it might be a good idea to have a singleton thread manager create worker threads as needed and coordinate those different object's requests. Reading your statements, I will have to spent some thoughts on the basic concept... Thanks, Peter 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: copyItemAtPath takes double time than the Finder
Why not have the Finder do the job? You can use AppleEvents to send a duplicate message to the Finder; you can do it sync (kAEWaitReply) or async (kAENoReply). Behaviour and performance will be the same as using the Finder, including proper update of .DS_Store files. Am 20.01.2011 um 00:49 schrieb Gary L. Wade: Both FSCopyObjectAsync and FSCopyObjectSync leak memory in Mac OS X 10.6.x, even up to 10.6.6; the async form leaks even more than the sync form. Apple has verified this both in my bug, rdar://8734968 (opened against 10.6.5) and another unspecified one opened earlier in 2010. I've verified both still leak memory in 10.6.6. If you are only doing one or two copies per execution of your application, the leak is not significant. If you are doing many copies per execution of your application (as I must), these leaks are horrible. Apple has verified there is nothing a developer can do to work around this other than to use the Cocoa method. On 01/19/2011 3:15 PM, Mike Abdullah cocoa...@mikeabdullah.net wrote: Well you shouldn't be using this synchronous API for long-running copy operations, since it can't be cancelled or give progress. Instead use FSCopyObjectAsync(). On 19 Jan 2011, at 21:42, Leonardo wrote: Hi, I have checked, the Finder, takes only 7 seconds to copy a 500MB dmg file. The copyItemAtPath API takes 18 seconds to copy the same file. Why? Is a way to make copyItemAtPath run at the same Finder speed? If not, which API should I use to get the same performance? I use: [[NSFileManager defaultManager] copyItemAtPath:src toPath:dst error:err]; Architectures: ppc, i386 Base SDK: Mac OS X 10.5 Valid Architectures: i386 ppc ppc64 ppc7400 ppc970 x86_64 C/C++ Compiler Version: GCC 4.2 Optimization Level: Fastest [-O3] Regards -- Leonardo ___ 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: Odd Crash when adding table columns manually
Table columns are retained by the table view they are added to. So you can safely release or autorelease the table column right after invoking -addTableColumn: . The table view owns its columns and will release them when it itself is released. This is the normal behaviour when adding subviews to an NSView or its subclasses. Peter Am 11.01.2011 um 18:06 schrieb Eric Gorr: I've got a sample test project at: http://ericgorr.net/cocoadev/TableColumnTest.zip which reproduces the strange crash. I have a NSTableView to which I need to add NSTableColumns manually using the addTableColumn: method. The problem is that for some reason when I release the window and everything is being deallocated, someone has an extra retain on the table column and it sticks around. This causes a crash because the OS tries to redraw the table which really isn't there. Note: With the code as written, it will only cause a crash sometimes...if you comment back in the call to the EventAvail function in WindowTestAppDelegate.m, it will crash every time...this is how I ended up finding the odd behavior to begin with - I am working with a cocoa/carbon app and EventAvail is still being called. I can avoid the crash if, in my TableController class, I manually remove the table column from the table first. Is this what I am expected to do if I manually add the column? I would not have thought so, but perhaps I am wrong...? In TableController.m, I have the function GetNewColumn which creates a new table column. After I alloc and init the column, I can log the retain count of the column and see that it is 1. After I call setWidth: on the table column, I can see that the retain count is 2. Can anyone shed some light on what might be going on here and why it is crashing? (if it matters, I am still running on 10.6.5) ___ 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: Change the NSPreferencePane window size programmatically
Whatever you do to an app that isn't yours:
use the APIs supplied for Interapplication Communication, as there
are (among others):
AppleEvents, AppleScript, Accessibility...
These ensure sufficient isolation between the objects involved, and
they are (to a certain extend) likely to survive the next OS version.
These APIs DO give you objects you're allowed to message, and they
implement messages you're allowed to send to these objects.
Look at this simple AppleScript:
tell application System Preferences
set bounds of window 1 to {342, 125, 937, 585}
end tell
It's very easy to send this via NSAppleScript. So what makes you look
for dirty hacks?
Peter
Am 07.01.2011 um 19:51 schrieb Kyle Sluder:
On Fri, Jan 7, 2011 at 10:42 AM, eveningnick eveningnick
eveningn...@gmail.com wrote:
Kyle,
thanks for the warning, i understand the problems it may cause.
but what if i was doing that, how should have i sent a message to an
object of the host application?
Quite simple: you don't. Ever. If your host object doesn't explicitly
give you an object you're allowed to message, you don't message any of
its objects.
--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: Close System Preferences programmatically
Though almost everybody seems to disagree you should do something like this here some ideas: - If you want to press the Show All- or Back- button, you could do this using the Accessibility API; take a look at Apple's Accessibility Inspector app. - If you really want System Preferences to quit, you could use NSAppleScript and do something like: tell application System Preferences to quit You can do the same using AppleEvents. If your app didn't open System Preferences programmatically before, I'd strongly suggest you ask the user if quitting is ok. Peter Am 04.01.2011 um 22:20 schrieb eveningnick eveningnick: Hi Nick Thank you I've an unusual application that is mainly located in System Preferences (its gui part), and which can be uninstalled by clicking a button Uninstall in that prefpane better solution would be to programmatically press Show All button (back in System Preferences), but that seems impossible because PrefPane reference doesnt mention have to do that. if someone knows there is a way to click Show All from a preference pane programmatically, i'd be thankful ___ 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: Close System Preferences programmatically
Am 04.01.2011 um 23:38 schrieb eveningnick eveningnick:
- If you really want System Preferences to quit, you could use
NSAppleScript
and do something like:
tell application System Preferences to quit
You can do the same using AppleEvents.
Peter, could you hint me on how to do it using AppleEvents?
Googling, i have found some references to OmniAppKit:
There's a working example of using Apple Events to do this in the
published Omni frameworks --- let's see, it's OAOpenSystemPreferences
(), in OAPreferenceController.m, in OmniAppKit.
I havent found this kit though, it is quite outdated.
Here are two very simple code samples that terminate an application
friendly by sending it an apple event.
They do exactly the same as pressing an app's Quit - menu item.
(Use at your own risk!)
// Terminate an application specified by a bundle identifier.
// Returns a BOOL value indicating the success of the operation.
- (BOOL)quitApplicationWithBundleIdentifier:(const char *)
bundleIdentifier
{
OSErr err;
AppleEvent quitEvent;
AEInitializeDesc(quitEvent);
err = AEBuildAppleEvent( kCoreEventClass, kAEQuitApplication,
typeApplicationBundleID, bundleIdentifier, strlen
(bundleIdentifier),
kAutoGenerateReturnID, kAnyTransactionID,
quitEvent, NULL,
from:null());
if ( err == noErr )
err = AESendMessage(quitEvent, NULL, kAENoReply,
kAEDefaultTimeout);
AEDisposeDesc(quitEvent);
return ( err == noErr );
}
// Terminate an application specified by a Process Serial Number.
// Returns a BOOL value indicating the success of the operation.
- (BOOL)quitApplicationWithProcessSerialNumber:(ProcessSerialNumber)PSN
{
OSErr err;
AppleEvent quitEvent;
AEInitializeDesc(quitEvent);
err = AEBuildAppleEvent( kCoreEventClass, kAEQuitApplication,
typeProcessSerialNumber, PSN, sizeof(PSN),
kAutoGenerateReturnID, kAnyTransactionID,
quitEvent, NULL,
from:null());
if ( err == noErr )
err = AESendMessage(quitEvent, NULL, kAENoReply,
kAEDefaultTimeout);
AEDisposeDesc(quitEvent);
return ( err == noErr );
}
___
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: Event to trigger writeSelectionToPasteboard
You can copy a selection using the Accessibility API: First get the UIElement for the application's Copy menu item. Then invoke AXPress on it. Drawback is that you will have to ask the user to enable Accessibility if it is not enabled. To get an idea about Accessibility, look at Apple's Accessibility Inspector app, which also contains a bunch of interesting code samples. Peter Am 01.01.2011 um 10:32 schrieb Graham Cox: On 01/01/2011, at 6:43 AM, Peter Watkins wrote: I know that each Cocoa app implements writeSelectionToPasteboard (), and I'm guessing this is how services interact with running apps. Each service is a separate short-running process. Sothere must be some sort of IPC to get the selection from the running app into the service's pasteboard. If I can figure out what that IPC is, I can send a message to a running application, and this would avoid flashing the menu bar. Any ideas on getting another app to run its writeSelectionToPasteboard() method? Read the Services Implementation Guide: http://developer.apple.com/library/mac/#documentation/Cocoa/ Conceptual/SysServices/introduction.html The app needs to be written to be services aware, and implement the protocols specified in the guide. If not, you can't do what you're doing for any arbitrary app. Between the Cut or Copy menu command and data being put on the pasteboard, the app can do whatever it wants, there is no 'standard' method that gets called and the method names are arbitrary (even the action method that responds to the Copy command might not be called -copy:) There's no 'Copy' or 'Paste' event. Some apps might expose these through applescript - again, there's no guarantee. What are you really trying to achieve? If you implement your service in a standard way, apps that are services aware will be able to use it. If not, they won't, and you have to live with it. You can't force an app to become services aware if it wasn't written to be. --Graham ___ 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: XML to Plist
Hi Sandro,
just to mention it (this has nothing to do with your original question):
Why don't you create your NSMutableDictionary with
[NSMutableDictionary dictionary] ?
This produces exactly the same result as [[[NSMutableDictionary
alloc] init] autorelease] -
practically all Cocoa CLASS methods that create objects return newly
allocated, inited and autoreleased objects unless otherwise stated in
the docs.
Best regards,
Peter
Am 28.12.2010 um 19:34 schrieb Sandro Noël:
- (NSDictionary *) plist{
NSMutableDictionary *resultDict = [[[NSMutableDictionary alloc]
init] autorelease];
if ([self hasChildren]){
NSMutableDictionary *child = [[[NSMutableDictionary alloc]init]
autorelease];
for (OSXMLElement *element in _children){
[child addEntriesFromDictionary:[element plist]];
}
[resultDict setValue:child forKey:_elementName];
}
else {
[resultDict setValue:_elementText forKey:_elementName];
}
return resultDict;
}
___
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
