NSTreeController -moveNode:toIndexPath doesn't work correctly
Hi all,
I'm having a problem with the -moveNode:toIndexPath: method of
NSTreeController, which is new to 10.5.
I'm not using Core Data, I have a very simple model object like so:
@interface Item : NSObject {
NSMutableArray* children;
Item* parent;
NSString* text;
BOOL isRootItem;
}
@property(assign) NSMutableArray* children;
@property Item* parent;
@property (copy) NSString* text;
@property BOOL isRootItem;
-(id) initWithParent:(Item*) theParent;
@end
I am using the children property as the children key of the
NSTreeController.
When I set up a hierarchy of these objects and call -
moveNode:toIndexPath:, the object is moved correctly in the
NSOutlineView but the model is not updated correctly.
Say I have a hierarchy like this:
Top Level Object 1
Top Level Object 2
Sub Level Object 1
Sub Level Object 2
Sub Level Object 3
Sub Level Object 4
Top Level Object 3
Top Level Object 4
If I move Top Level Object 1 to the index path [1][0], it should be
inserted as a child of Top Level Object 2, before the existing Sub
Level Object 1.
What happens, however, is that it is always added as the last object
in the Sub Level Object list:
Top Level Object 2
Sub Level Object 1
Sub Level Object 2
Sub Level Object 3
Sub Level Object 4
Top Level Object 1
Top Level Object 3
Top Level Object 4
Note that this is only occurring in the real object hierarchy, the
NSTreeNodes reflect the correct hierarchy.
When I had a look at the backtraces it seems that NSTreeController
eventually calls -addObject: on the children array, which of course
adds the item to the end of the children.
Does anyone know why this is occurring? Is there a workaround, or am I
doing something wrong?
--
Rob Keniger
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: sending email with attachement from cocoa
On Sep 26, 2008, at 20:11, has wrote: Alexander Cohen wrote: Is there a way to use a url request to open mail with all its fields completed but most importantly, contain an image attachement? Nope. If you want to send an email in the background, you'll need to look into a third-party framework option: http://www.collaboration-world.com/pantomime http://www.theronge.com/mailcore http://www.mulle-kybernetik.com/software/EDFrameworks http://vafer.org/blog/20080604120118 HTH 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 [EMAIL PROTECTED]
Re: Use other key than tab to cycle through text fields
On Sep 26, 2008, at 10:16 AM, Gerd Knops wrote:
On Sep 25, 2008, at 10:37 PM, Ken Thomases wrote:
On Sep 25, 2008, at 9:18 PM, Graham Cox wrote:
On 26 Sep 2008, at 10:24 am, Gerd Knops wrote:
I would like to use a key other than tab to advance to the next
text field, so that users can use a numeric keypad to enter
something like 11-22-33 and have 11, 22 and 33 end up in
different text fields.
I'd suggest not using a different key from 'Tab', since that's
very much hardwired into every Mac user.
Alternative, why not just detect when the field has the required
number of characters and move to the next field automatically? For
numeric entry this is much more user-friendly.
For implementing such a thing, see -[NSWindow selectNextKeyView:].
I know how to do that part. The tricky part is intercepting and
filtering the '-' key. given field editors etc.
One approach I tried was to implement -validateValue:forKey:error:
and intercept the key values of the fields I am interested in,
testing for a '-' as last character, removing it and advancing to
the next key field. That works (after setting the involved bindings
to 'Continuously updates value' and 'Verify immediately'), but for
some odd reason when the '-' character is entered that method is
called twice, causing it to skip a field. I hoped to avoid having to
also add connections for the individual views so that I can find the
next key view for the key field in question, but it seems to be the
least bothersome approach at that point.
Thanks
Gerd
I played around and found a solution. However I'm not sure if this
would be considered an abuse of the formatter/validation
architecture :-)
1) Write a custom subclass of NSNumberFormatter and implement
isPartialStringValid:proposedSelectedRange:originalString:originalSelectedRange:errorDescription
:. In it test for the '-' and set the errorDescription to some custom
string and return NO. (you could also subclass NSFormatter but you
will need to implement three more methods http://developer.apple.com/documentation/Cocoa/Conceptual/DataFormatting/Articles/CreatingACustomFormatter.html
)
2) In your controller:
a) Implement control:didFailToValidatePartialString:errorDescription:
and test the errorDescription against your custom string. If it
matches, call selectKeyViewFollowingView: on your window with the
passed in control.
b) Implement control:didFailToFormatString:errorDescription: and if
you have an empty string set the control to 0
3) In IB (in any order):
a) Add the NSNumberFormatter to your text fields then change the
class to your custom class.
b) Set your controller as the delegate of the text fields.
c) Set the nextKeyView for each of the text fields.
d) Bind the values to your model.
e) You don't need Validates Immediately or Continuous.
//
// NumberTabForwardFormatter.h
//
#import Cocoa/Cocoa.h
@interface NumberTabForwardFormatter : NSNumberFormatter {
}
@end
//
// NumberTabForwardFormatter.m
//
#import NumberTabForwardFormatter.h
@implementation NumberTabForwardFormatter
- (BOOL)isPartialStringValid:(NSString **)partialStringPtr
proposedSelectedRange:(NSRangePointer)proposedSelRangePtr
originalString:(NSString *)origString originalSelectedRange:
(NSRange)origSelRange errorDescription:(NSString **)error
{
// the user has just deleted the last number and we have an empty
string
if (proposedSelRangePtr-location == 0)
return YES;
// the user can type '-' anywhere in the string, not just at the end
if ([[*partialStringPtr
substringWithRange:NSMakeRange(proposedSelRangePtr-location - 1, 1)]
isEqualToString:@-]) {
*error = @Number Tab Forward Formatter Event;
return NO;
}
// I added this to only allow numbers, you may not need/want it, for
example you may want to allow '.' and ','
if (![[NSCharacterSet decimalDigitCharacterSet] characterIsMember:
[*partialStringPtr characterAtIndex:proposedSelRangePtr-location -
1]]) {
*error = nil;
return NO;
}
return YES;
}
@end
//
// AppController.h
//
@interface AppController : NSObject {
IBOutlet NSWindow *window;
int num1, num2, num3;
}
@property (assign) int num1, num2, num3;
@end
//
// AppController.m
//
#import AppController.h
@implementation AppController
@synthesize num1, num2, num3;
- (void)control:(NSControl *)control didFailToValidatePartialString:
(NSString *)string errorDescription:(NSString *)error
{
if ([error isEqualToString:@Number Tab Forward Formatter Event])
[window selectKeyViewFollowingView:control];
}
- (BOOL)control:(NSControl *)control didFailToFormatString:(NSString
*)string errorDescription:(NSString *)error
{
if ([string isEqualToString:@]) {
[control
Re: Autostart item in user profile.
Two solutions have been suggested, launchd and Login Item. (Indeed, LoginItemsAE is unreliable and depracated.) I've never seen an explanation of which one to use. Here are my conclusions: • If you do not want the user to be able to see and control your item in System Preferences, or if you have more complicated instructions than simply always launch at login, use launchd. This is probably appropriate for background agents/daemons/whatever. • If you want the user to be able to see and control en/disable your item in System Preferences, make it a Login Item. This is probably more appropriate for apps. You can set/unset Login Items programmatically using the new LSSharedFileList API... On 2008 Sep, 25, at 20:25, Ken Thomases wrote: Actually, Leopard introduced the LSSharedFileList API, which is the new preferred solution. Unfortunately, this API is undocumented. The only documentation (other than a brief mention in the release notes) is the header file: /System/Library/Frameworks/CoreServices.framework/Frameworks/ LaunchServices.framework/Headers/LSSharedFileList.h Yes, this is more reliable than LoginItemsAE and should be used in any project that requires 10.5. But, yes it's undocumented, not very nice to use (Carbon-style C API) and also there is a bug. To make it nicer to use, I wrote a Cocoa wrapper a few months ago, but forgot to make it available. I had been waiting for Apple to fix a bug, but apparently my bug report didn't ring the bell on the priority list. Oh, well. Here is the project... http://sheepsystems.com/files/SSYLoginItems.zip Click in the Documentation subfolder on index.html to see HeaderDoc documentation. Jerry Here's the text of the bug: Apple Bug Reporter. Problem ID 5901742 30-Apr-2008 01:48 PM Jerry Krinock: * SUMMARY The 'hidden' attribute for Login Items in the LSSharedList API has a disconnect with the reality. In more detail, when reading a Login Item, the 'hidden' attribute is read as 0, even if it is in fact '1', unless the 'hidden' attribute has been set by the LSSharedList API. In that case, it doesn't really set, but when you read it back with the API, it says that it is set, even though in fact it is not. * STEPS TO REPRODUCE Build and run the attached project. Follow the prompts shown in the the console. * EXPECTED RESULTS In all tests, the values read and written using the LSSharedList API and shown in the log should agree with what is shown in the System Preferences application. * ACTUAL RESULTS In Test #1, items which have the Hide box checked in System Preferences read from the API hidden=0. In Test #5, although the API set Safari to Hide and the API read it back as hidden=1, if you look in System Preferences you see that the Hide box is not checked. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
design pattern for data acquisition in background thread?
I have an application that acts as a GUI front end for a network device. The device has a telnet server, so I'm using a ASyncSocket to open a connection and talk telnet commands to it. That's all working fine. The problem is that the UI is totally unresponsive while it's doing an update, and it's 25 or so round trips to the server (telnet command/responses) for each update. Right now, the app controller object sends a message to the device controller, requesting the value of a specified variable. The device controller does the telnet command to get it, returns it to the app controller, and the app controller sends it to the text field. Repeat 25 times for a full update. Slow, and there's no return to the run loop in there to allow for keyboard or UI events. I'm looking for suggestions on how to deconstruct this to get the object talking to the device into another thread so the main window can take UI events. I'm thinking I can package up the variable requests into a dictionary so that the device controller can do a bunch at once. Then the main thread can do all the updates from the dictionary, which should be quick. joe ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Subviews in flipped layer-backed views
This used to work in 10.5.4 not in 10.5.5. However, there have been other changes in my code, so the cause could be elsewhere. I have a view that is flipped. My draw objects can contain text which is flowed into the shape of the object. The reason the view is flipped is that that is the only way I have found works for text layout. For editing the text, I install a NSTextView as a subview, a la the Sketch example. This works great in a non-layer-backed view. It used to work properly in a layer-backed view, but now it inverts both the text layout and the container location when editing. So when I edit text in an object near the top of the view, the edited textview text draws inverted near the bottom of the view. Why? When editing is complete, the text draws correctly within the object. BTW, just for experimentation, a button added to the view also draws its text inverted when the view is layer-backed. I need the same basic code to work in both layer-backed and non-layer-backed views. In fact, I simultaneously display the same objects in several different views. The only one I currently want layer-backed is the main presentation view. After many weeks of haggling with layers to get them to work properly in a scalable scrolling window, I now use an inverted content layer that is a sublayer of the view¹s layer in order to get an inverted coordinated system in the layer I draw into, so it will match what is done in the non-layer-backed views. I suppose that adding the NSTextView to a layer-backed view also makes the textview layer-backed. However, this doesn¹t seem to explain anything. Why is the textview (and controls) getting inverted just because its superview is layer-backed? Shouldn¹t the subview get its coordinates from the superview and not the superview¹s main layer? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Creating an NSForm programmatically tabbing
When I use interface builder to create a NSForm and hook up it's action, I see the action being executed when I tab between the fields as I am running the application. However, when I create a NSForm programmatically and hook up it's action, I only see the action being executed when I press return or enter. How can I have the NSForm send it's action when I tab between the fields when it is created programmatically? Thank you. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Accepting file promise drags
For completeness, I'd like to be able to accept file promise drags in my Cocoa application. What I want to do is to load an image file into the application after the drag source has written the file to the destination URL. Is there any way for my application to receive a notification after the file has been completely written? I looked at kqueues and FSEvents and Workspace notifications but in each case I don't see a notification that the drag-source application has closed the file. Do I just have to keep attempting to load the image file each time I get notification of a change? Also, it seems to me that applications are free to write files in ways that don't generate Workspace notifications. Am I missing something? Does NSWorkspace actually use one of the other mechanisms in the background? Any suggestions? Thanks, John ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: window controllers and managed object contexts
Hmm, well that seems to be the catch. I can't get the bindings to work for the MOC. First off, to set up the table displayed in the window loaded with a separate nib file, I simply dragged in an entity object from the Librarian. That doesn't set up an MOC binding, but, following an on- line tutorial, I told it to bind the MOC parameter to File'sOwner, and immediately the setting is managedObjectContext. (Looked promising.) Now, when I init the window, I do pass in a copy of the App's own MOC (I don't have multiple MOCs). But now I get the message: not key-value coding-compliant for the value: managedObjectContext. Which makes me wonder, just how much code needs to go into setting up a separate window controller, and is it worth it (speed-wise) if your app only has four or five windows. From a tidiness standpoint, it's nice of course to separate the control portion of MVC for each window, but is all that copying and key-value coding going to be faster than simply loading one big nib? And, given that Xcode is supposed to automatically set up bindings correctly for things like Entity, why does it not work in this case? The error message seems to suggest I need to be doing something like: [myWindow setObject: theMOC forKey: @managedObjectContext but the tutorial online uses plain accessors (with the local copy of MOC as an ivar, not a property) ... and works. One difference is that their's is a doc-based CoreData app, and mine is not. But I don't see why that should matter So I'm forced to use a property to express MOC in the window controller??? On Sep 26, 2008, at 3:29 PM, Kyle Sluder wrote: Erm, NSWindowController shouldn't be asking for a MOC. Perhaps whatever NSControllers you have in your nibs haven't had their managedObjectContext bindings fixed? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
No. But I'm still wondering. How would you set up a reference again if you chose to have the window released on close...without reloading the entire nib, which is probably counterproductive. On Sep 26, 2008, at 3:30 PM, Charles Steinman wrote: If it's accessed via an outlet in your app controller, you probably don't have multiple instances of it floating around like Scott was talking about, do you? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: window controllers and managed object contexts
On Sep 27, 2008, at 10:01 AM, Daniel Child wrote: but the tutorial online uses plain accessors (with the local copy of MOC as an ivar, not a property) ... and works. One difference is that their's is a doc-based CoreData app, and mine is not. But I don't see why that should matter It matters because NSPersistentDocument has a managed object context instance variable. See the note at http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdBeforeYouStart.html Core Data is not an entry-level technology. It leverages many other Cocoa technologies, including memory management, key-value coding, and key-value observing. You must understand these technologies to use Core Data effectively. You also need a solid understanding of data modeling and the model-view-controller design pattern as it pertains to Cocoa. If you don't understand this basic point, you should not yet be using Core Data. mmalc ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: CALayers inside NSSplitView (clipping issue) [SOLVED]
For posterity. To solve this clipping problem, I wrapped all of the views that I have in a superview instance of NSView. I.e. 'IB - Layout - Embed Objects In - Custom View'. That stops the clipping weirdness from occurring. Don't ask me why, because I don't know - but I made this change as a part of another thing I was doing and noticed that the problem no longer occurs. John why me? Clayton On 24/09/2008, at 4:50 PM, John Clayton wrote: Hi All, Someone kindly suggested that I post the question again, but that this time I make some sense :-) Good idea I say... So - step by step, first a series of facts to set the scene: 1. i have an NSSplitView 2. both of the views that this split view contains use CALayer instances 3. in the lower view is a track-view style control, it allows one to drag tracks up and down 4. the track view in the lower part of the NSSplitView is contained in an NSScrollView instance (which is usual for splitters of course - nothing abnormal so far). next: here's a screen shot of the app working properly - in this screenshot, I've started the app but not resized anything or moved anything yet. http://skitch.com/johnclayton/s5fr/picture-1 now, imagine that I take the mouse, and I use it to drag that horribly purple coloured track straight down. the desired effects are: - the layer is moved downwards - the view expands in the vertical direction (gets larger, but thats ok right - cos its in a scrollview) - the vertical scrollbar should appear in the NSScrollView - the NSScrollView / NSClipView should clip the contents view now, here's a screenshot of the bug: http://skitch.com/johnclayton/s5fa/picture-3 so I wonder what is causing the calayer instance to NOT be clipped in this case. The NSClipView inside the scrollview should be clipping, right? Thanks -- John Clayton Skype: johncclayton On 24/09/2008, at 5:58 AM, John Clayton wrote: Hi All, I have a vertically laid out NSSplitView which is hosting two NSViews, both of which contain CALayer instances. In the bottom view, there's a scroll view - and I can drag stuff within the view - which in turn causes the view to grow. Sometimes, the splitview doesn't clip the CALayer *at all*, and I see this: http://skitch.com/johnclayton/s4gc/picture-2 I resize the contents of the split-view during mouseDragged: (along with its layers), does anyone know of issues with this or perhaps has an idea of whats going wrong? Thanks -- John Clayton Skype: johncclayton ___ 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/john_clayton%40mac.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
On Sat, Sep 27, 2008 at 1:06 PM, Daniel Child [EMAIL PROTECTED] wrote: No. But I'm still wondering. How would you set up a reference again if you chose to have the window released on close...without reloading the entire nib, which is probably counterproductive. Released does not mean Dealloced. --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 [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
On 27.09.2008, at 19:06, Daniel Child wrote: No. But I'm still wondering. How would you set up a reference again if you chose to have the window released on close...without reloading the entire nib, which is probably counterproductive. Well, for some windows, you might not need another reference. Imagine you have a window of which you can open several, like the Get Info panel in some apps. Your window controller would listen for the window closed notification and commit suicide upon receiving it, and the window would go away. Though I agree that it's a better design to just not use this flag, and just have the window controller destroy itself when the window is closed, and take down the window the regular way. Also, there are cases where someone else is going to retain a window anyway. Closing a window will simply call -release, if someone else retained it, the object won't go away. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Creating an NSForm programmatically tabbing
Here's some sample code demonstrating this two cases: http://ericgorr.net/nsform.zip Contacts-FormManual is where I am creating the NSForm programmatically. When I tab between the fields, I would like the formChanged: selection to be called. Contacts-Form is where I am creating the NSForm via IB. When I tab between the fields, the updateContact: selector is called. On Sep 27, 2008, at 12:29 PM, Eric Gorr wrote: When I use interface builder to create a NSForm and hook up it's action, I see the action being executed when I tab between the fields as I am running the application. However, when I create a NSForm programmatically and hook up it's action, I only see the action being executed when I press return or enter. How can I have the NSForm send it's action when I tab between the fields when it is created programmatically? Thank you. ___ 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/mailist %40ericgorr.net This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: problems in runModal in NSOpenPanel used with defaults
On Sat, Sep 27, 2008 at 1:34 AM, spartan g [EMAIL PROTECTED] wrote: Thanks Corbin, I have used your tips in the updated code. Besides, my aim is to save the filename selected through the panel to a pList file timely whenever it is changed, so I am using synchronization of defaults. I checked and found that there is no resetStandardUserDefaults used anywhere in the entire project. I tried implementing dictionary insted of defaults and updating the pList contents accordingly. But to my surprise, in either cases(dictionary/defaults), whenever I click browse and click cancel/open the junk values are appended automatically in the pList file!!! For the time being I am deleting and recreating the file, but it doesn't seem a good alternative!!! How can a 'Panel runModal' add such junk in the pList!!! I believe you attempted to show the junk values you were getting in your first e-mail, however they did not appear to me. So this is just a guess I suspect that you're seeing entirely normal autosave information being generated by NSOpenPanel. That plist is not exclusively yours. It holds all user defaults for your program. Any library in your program, such as AppKit, is free to use that plist to store its own values as well. This is normal, harmless, and expected. NSOpenPanel will store values in user defaults to remember its position, size, selection, and other such values. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
On Sat, Sep 27, 2008 at 2:39 PM, Uli Kusterer [EMAIL PROTECTED] wrote: Also, there are cases where someone else is going to retain a window anyway. Closing a window will simply call -release, if someone else retained it, the object won't go away. But suddenly you're back to having to think about the global picture of who owns objects, which is what Cocoa's memory management system is supposed to avoid. Retains and releases should be balanced. This doesn't just means that they should ultimately be equal in number, it also means that the same entity should be doing both. Release when closed breaks the fundamental memory management rules and, as a consequence, makes it much more complicated to think about how the program works. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: design pattern for data acquisition in background thread?
On Sep 26, 2008, at 3:37 PM, Joe Keenan wrote: Right now, the app controller object sends a message to the device controller, requesting the value of a specified variable. The device controller does the telnet command to get it, returns it to the app controller, and the app controller sends it to the text field. Repeat 25 times for a full update. Slow, and there's no return to the run loop in there to allow for keyboard or UI events. I'm looking for suggestions on how to deconstruct this to get the object talking to the device into another thread so the main window can take UI events. I'm thinking I can package up the variable requests into a dictionary so that the device controller can do a bunch at once. Then the main thread can do all the updates from the dictionary, which should be quick. It doesn't even need to be that complicated. You can follow a delegate model in your device controller's design to make it asynchronous, rather than have it provide a synchronous API. Instead of an API like this, which is synchronous: @interface DeviceController : NSObject - (NSString *)valueForVariable:(NSString *)variable; @end You might instead implement this, which is asynchronous: @protocol DeviceControllerDelegate; // forward declaration @interface DeviceControlelr : NSObject @property (readwrite, assign) id DeviceControllerDelegate delegate; - (void)requestValueForVariable:(NSString *)name; @end @protocol DeviceControllerDelegate NSObject - (void)deviceController:(DeviceController *)controller receivedValue:(NSString *)value forVariable:(NSString *)variable; @end If you want to use a thread to actually do the request, you can use - performSelectorOnMainThread:withObject:waitUntilDone: to pass the value back to the main thread for sending through the delegate message. You don't have to use a thread though. You could also use NSStream and its delegate messages to run the state machine that manages your protocol straight from the main run loop. Your API would look the same, but you wouldn't have to manage a thread yourself. (NSStream can use one if it wants to.) -- Chris ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Creating an NSForm programmatically tabbing
On Sep 27, 2008, at 12:03 PM, Eric Gorr wrote: Contacts-FormManual is where I am creating the NSForm programmatically. When I tab between the fields, I would like the formChanged: selection to be called. [theFormCell setSendsActionOnEndEditing:YES]; mmalc ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
On 27.09.2008, at 22:13, Michael Ash wrote: But suddenly you're back to having to think about the global picture of who owns objects, which is what Cocoa's memory management system is supposed to avoid. Retains and releases should be balanced. This doesn't just means that they should ultimately be equal in number, it also means that the same entity should be doing both. Release when closed breaks the fundamental memory management rules and, as a consequence, makes it much more complicated to think about how the program works. You're misunderstanding the purpose of Cocoa's memory management system: It's not about not having to care who owns what, it's about not having to worry about shared ownership. There are many cases (threading and creation of objects come to mind) where ownership is handed from one object to the other. In this case, you specify in the NIB that you want your window to release itself, and you haven't written your outlet in a way that it retains the window. If you expect your window to not go away when closed, you're expecting too much. That said, I fully agree on one partial point you raised: 'Release when closed' is dangerous and complicates matters. It should be off by default, and it's very likely that nobody would miss it. That said, I don't know what it was originally introduced for. Any old NeXTies here who know? Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
sizeof(unsigned long long)
Hello, I have a piece of C code that generates an unsigned long long from an sequence of unsigned char's. When I do sizeof(unsigned long long) i get 8. Afterwards I try to shift each unsigned char into its position along the destination unsigned long long variable, but I get a warning from the compiler that I am shifting beyond the type's capacity. That is not surprising since I am targeting 32 bit. Then I don't understand why the size of returns 8. Shouldn't it return 4 ? I'm running Xcode 3.0 on Leopard. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: setPrimitiveValue:forKey: and to-many relationships
On Sep 24, 2008, at 3:56 PM, Quincey Morris wrote:
IAC, it's not clear why you need to use setPrimitiveValue: at all.
Why not something like:
- (void)setChildren:(NSSet*)value_
{
[[self mutableSetValueForKey:@children] removeAllObjects];
[[self mutableSetValueForKey:@children] unionSet: value_];
}
In addition to what Ben has said, the above code is incorrect and
should not be used. It's not just incorrect as a Core Data accessor/
mutator method -- it doesn't post KVO will/did notifications around
the property mutation -- but it's also incorrect from a general Cocoa/
KVC perspective.
The reason is that it's using -mutableSetValueForKey: in the
implementation of one of the mutators that -mutableSetValueForKey: may
call, giving the potential for infinite recursion. In other words,
sending -setChildren:, which as part of -unionSet: could potentially
send -setChildren:, which as part of -unionSet:...
The -mutable{Array,Set}ValueForKey{Path}: methods are covers for your
properties, not implementation helpers for your properties.
-- Chris
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: sizeof(unsigned long long)
On Sep 27, 2008, at 3:49 PM, Daniel Luis dos Santos wrote: When I do sizeof(unsigned long long) i get 8. Afterwards I try to shift each unsigned char into its position along the destination unsigned long long variable, but I get a warning from the compiler that I am shifting beyond the type's capacity. That is not surprising since I am targeting 32 bit. Then I don't understand why the size of returns 8. Shouldn't it return 4 ? No; long longs are always 8 bytes (64 bits). Ints are 4 bytes (32 bits) on both 32-bit and 64-bit architectures. Nick Zitzmann http://www.chronosnet.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 [EMAIL PROTECTED]
Re: sizeof(unsigned long long)
On Sat, Sep 27, 2008 at 2:49 PM, Daniel Luis dos Santos [EMAIL PROTECTED] wrote: Hello, I have a piece of C code that generates an unsigned long long from an sequence of unsigned char's. When I do sizeof(unsigned long long) i get 8. Afterwards I try to shift each unsigned char into its position along the destination unsigned long long variable, but I get a warning from the compiler that I am shifting beyond the type's capacity. That is not surprising since I am targeting 32 bit. This has nothing to do with 32-bit vs. 64-bit. In C, when you shift an unsigned char, the result is an int (or unsinged int on some platforms). GCC is warning you that you are shifting beyond the capacity of an int. To avoid this, cast your unsigned char's to unsigned long longs *before* you shift. Then I don't understand why the size of returns 8. Shouldn't it return 4 ? unsigned long long is *always* at least 64-bits. This is guaranteed by the C standard. -- Clark S. Cox III [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
PubSub not automatically downloading enclosures
I'm having some problems with PubSub not downloading enclosures. I'm
running 10.5.5 and using Xcode 3.1.1. If this is the wrong list, my
apologies.
Here's a codesample that seems to not be working.
---
- (void)awakeFromNib
{
PSClient *client = [PSClient applicationClient];
PSFeedSettings *settings = client.settings;
settings.downloadsEnclosures = YES;
settings.enclosureTypes = [NSArray arrayWithObject:@image/jpeg];
settings.maxEnclosureSize = PSFeedSettingsUnlimitedSize;
settings.refreshesInBackground = NO;
client.settings = settings;
client.delegate = self;
PSFeed *feed = [client addFeedWithURL:[NSURL
URLWithString:@http://api.flickr.com/services/feeds/[EMAIL
PROTECTED]lang=en-usformat=atom]];
[feed refresh:NULL];
}
- (void)feed:(PSFeed *)feed didAddEntries:(NSArray *)entries
{
NSLog(@%@ added entries %@, feed, entries);
}
- (void)enclosure:(PSEnclosure *)enclosure
downloadStateDidChange:(PSEnclosureDownloadState)state
{
NSLog(@%@ %d, enclosure, state);
}
--
When I run the code, I get the following output:
--
2008-09-27 15:42:26.434 PhotoRSS[92602:10b]
PSFeed[http://api.flickr.com/services/feeds/[EMAIL
PROTECTED]lang=en-usformat=atom
2/8] added entries (
PSEntry['Happy Birthday' 3166],
PSEntry['OpenDoc ftw' 3157],
PSEntry['Loot from Portland' 3159],
PSEntry['Nerd mode engage!' 3158],
PSEntry['Anne' 3170],
PSEntry['Ready for Action' 3171],
PSEntry['Hotel Monaco' 3155],
PSEntry['Palin hates polar bears' 3172],
PSEntry['Nice Hawaii license plate!' 3165],
PSEntry['photo.jpg' 3163],
PSEntry['KILL' 3164],
PSEntry['WALL·E Rides ... Muni?' 3169],
PSEntry['My new pixel rig' 3162],
PSEntry['Aloha Shoyu is the best, don't pose' 3161],
PSEntry['New glasses have arrived!' 3160],
PSEntry['New Digs' 3168],
PSEntry['LLs Loco Moco and Spam musubi' 3153],
PSEntry['WTF hot sauce?' 3154],
PSEntry['Inside Macintosh' 3156],
PSEntry['CA$H' 3167]
)
-
As you can see, it does not appear that the enclosures are not
downloading automatically. I even checked in the PubSub sqlite db, and
the downloadedPath column is empty for all enclosures.
Any suggestions? Or is PubSub just broken, and I should just file a
radar and write my own RSS parsing code...
-Colin
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: design pattern for data acquisition in background thread?
I believe the Design Pattern you're looking for is the Asynchronous Callback. Basically you send a command over the network and some point in the future it tells you when the data is available. This leaves the rest of the application to continue on until your data request shows up. I'm still learning the Cocoa APIs, but I'd be surprised if CFNetwork didn't support this functionality since non- blocking network communication is generally the norm. -Michael On Sep 26, 2008, at 6:37 PM, Joe Keenan wrote: I have an application that acts as a GUI front end for a network device. The device has a telnet server, so I'm using a ASyncSocket to open a connection and talk telnet commands to it. That's all working fine. The problem is that the UI is totally unresponsive while it's doing an update, and it's 25 or so round trips to the server (telnet command/responses) for each update. Right now, the app controller object sends a message to the device controller, requesting the value of a specified variable. The device controller does the telnet command to get it, returns it to the app controller, and the app controller sends it to the text field. Repeat 25 times for a full update. Slow, and there's no return to the run loop in there to allow for keyboard or UI events. I'm looking for suggestions on how to deconstruct this to get the object talking to the device into another thread so the main window can take UI events. I'm thinking I can package up the variable requests into a dictionary so that the device controller can do a bunch at once. Then the main thread can do all the updates from the dictionary, which should be quick. joe ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
How to count composed characters in NSString?
Hi, I have been trying to find this in the documentation and list archives but without success so far. What is the best way to count the number of characters in an NSString taking account of the fact that some characters may take up multiple 16 bit slots. Using - (NSUInteger)length is thus not the right way. Using a series of calls to rangeOfComposedCharacterSequenceAtIndex: seems like a possibility, but I am not sure this would be the most efficient way. Is there a simple and straightforward solution? I would like to be able to display the number of characters in a string and not report the wrong results for foreign languages (which I would get if I simply took the length of the string). I need a solution that does not only work in Leopard (i.e. CFStringTokenizer is not an option) and that does not require using the lower level UCFindTextBreak. Thanks, david. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
How to get the current screen resolution on Mac
Hi, All,I am a newcomer, I write a simple program on mac, and want to display the main window at the center of screen, i mean the window's position should depends on the screen's width and height, so i need to get the screen resolution, who can tell me how to get it? which api is available? Thanks James _ 一点即聊，MSN推出新功能“点我！” http://im.live.cn/click/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
On Sep 27, 2008, at 4:44 PM, Uli Kusterer wrote: That said, I fully agree on one partial point you raised: 'Release when closed' is dangerous and complicates matters. It should be off by default, and it's very likely that nobody would miss it. That said, I don't know what it was originally introduced for. Any old NeXTies here who know? Well, I'm not an old NeXTie, but I use this when I make a throw away window programmatically. Something like the About panel, say. Instead of setting up a delegate and have it autorelease the window on the -windowShouldClose: method, I just set it up with release when closed and I know when the window is closed it gets released. I have no idea why it's an option in a nib file, though. Perhaps someone just wanted to be thorough in giving you the window's options? Does the window really get deallocated when using this option? I haven't really looked, but wouldn't the nib's owner still have a reference to it as part of its top level objects? -- Darkshadow (aka Michael Nickerson) http://www.nightproductions.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Need to override +(Class) class?
Hi everyone,
I'm building an app, and I've got a bunch of interface object
definitions called InputElements. There are a couple subclasses,
such as InputElementButton and InputElementSlider.
I'm building the interface via an InputMode object, that contains an
array of InputElement objects. As I build the interface, I loop
through the InputElement objects in the InputModes array, and am doing
the following:
for (InputElement * element in [inputMode elements]) {
if ([element isKindOfClass:[InputElementButton class]]) {
//build an InputViewButton
} else if ([element isKindOfClass:[InputElementSlider class]]) {
//build an InputViewSlider
}
}
When I try to compile, I'm getting two errors:
_OBJC_CLASS_$_InputViewSlider, referenced from:
[EMAIL PROTECTED] in CosMouseViewController.o
_OBJC_CLASS_$_InputViewButton, referenced from:
[EMAIL PROTECTED] in CosMouseViewController.o
My question is, do I need to override the +(Class) class method for
each InputElement subclass, and if so how do I make a Class object?
Thanks,
Dave
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: How to get the current screen resolution on Mac
On 27 Sep 08, at 18:00, 熊佳 wrote: Hi, All,I am a newcomer, I write a simple program on mac, and want to display the main window at the center of screen, i mean the window's position should depends on the screen's width and height, so i need to get the screen resolution, who can tell me how to get it? which api is available? NSScreen gives you this functionality, but it's even easier to just have [NSWindow center] do the job for you.___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Need to override +(Class) class?
Not sure exactly what your problem is, have you tried isMemberOfClass: instead of isKindOfClass:? the is*OfClass: methods have certain... dangers. You might try testing the given object to see if they respond to slider selectors versus button selectors, and discriminate in that way. On Sep 27, 2008, at 7:38 PM, Dave DeLong wrote: When I try to compile, I'm getting two errors: _OBJC_CLASS_$_InputViewSlider, referenced from: [EMAIL PROTECTED] in CosMouseViewController.o _OBJC_CLASS_$_InputViewButton, referenced from: [EMAIL PROTECTED] in CosMouseViewController.o My question is, do I need to override the +(Class) class method for each InputElement subclass, and if so how do I make a Class object? Jamie Hardt The Sound Department http://www.soundepartment.com/ http://www.imdb.com/name/nm0362504/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Need to override +(Class) class?
It's always the simple errors that get me. I had dragged the InputView* class files into my project, but they weren't successfully added. Removing them and adding them again got rid of the errors. I feel a little silly now, but that's ok. Thanks for the point in the right direction, and the advice on +(Class) class; Cheers, Dave On 27 Sep, 2008, at 8:59 PM, Andrew Farmer wrote: On 27 Sep 08, at 19:38, Dave DeLong wrote: I'm building an app, and I've got a bunch of interface object definitions called InputElements. There are a couple subclasses, such as InputElementButton and InputElementSlider. snip When I try to compile, I'm getting two errors: _OBJC_CLASS_$_InputViewSlider, referenced from: [EMAIL PROTECTED] in CosMouseViewController.o _OBJC_CLASS_$_InputViewButton, referenced from: [EMAIL PROTECTED] in CosMouseViewController.o This error appears to indicate that the InputViewSlider and InputViewButton classes are not defined in your application. If you haven't written them yet, you may need to stub them out for your code to work. My question is, do I need to override the +(Class) class method for each InputElement subclass, and if so how do I make a Class object? Leave -[NSObject class] alone. Overriding it will probably lead to all sorts of crazy misbehavior. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: design pattern for data acquisition in background thread?
On Sep 27, 2008, at 4:25 PM, Chris Hanson wrote:
On Sep 26, 2008, at 3:37 PM, Joe Keenan wrote:
Right now, the app controller object sends a message to the device
controller, requesting the value of a specified variable. The
device controller does the telnet command to get it, returns it to
the app controller, and the app controller sends it to the text
field. Repeat 25 times for a full update. Slow, and there's no
return to the run loop in there to allow for keyboard or UI events.
I'm looking for suggestions on how to deconstruct this to get the
object talking to the device into another thread so the main window
can take UI events. I'm thinking I can package up the variable
requests into a dictionary so that the device controller can do a
bunch at once. Then the main thread can do all the updates from
the dictionary, which should be quick.
It doesn't even need to be that complicated.
You can follow a delegate model in your device controller's design
to make it asynchronous, rather than have it provide a synchronous
API.
Thanks for that pseudo-code. I think you're right about doing it that
way. I was also thinking I could add a request queue and a response
queue so that there can always be a request in the works, instead of
waiting to start the next one after the UI is updated.
The problem with any async method is that I haven't figured an elegant
way to know which update code to use for each return value. They're
not all the same. Different data elements need different processing
to update the UI. When I get a response back asynchronously, I have
the variable name and the value, and I have to figure out which UI
element it belongs to. The brute force method is a long if/else chain
that tests the name of the variable to do it, like:
if ([key isEqualToString: @lnbcolor])
{
[lnbLight setTextColor:[NSColor colorFromHexidecimalValue:
keyValue]];
}
else if ([key isEqualToString: @lancolor])
{
[lanLight setTextColor:[NSColor colorFromHexidecimalValue:
keyValue]];
}
With lots (25 or so) more possible key values, and a half-dozen or
more different ways to update the UI element.
joe
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: How to get the current screen resolution on Mac
On 28.09.2008, at 03:00, 熊佳 wrote: Hi, All,I am a newcomer, I write a simple program on mac, and want to display the main window at the center of screen, i mean the window's position should depends on the screen's width and height, so i need to get the screen resolution, who can tell me how to get it? which api is available? Thanks James What do you need, the resolution, or its size? Someone else has already mentioned NSWindow's center call if you really just want to center a window. If you need the size of each screen (there may be several, which make up one huge, irregularly-shaped surface!) for something else, check out NSScreen, which was also mentioned. As to the screen resolution, I believe there is some CGDirectDisplay API for that, or maybe there's even a Cocoa method in NSScreen, don't remember right now. However, all of these seem to rely on the screen to provide the actual resolution information in dpi, and many screens don't do this in a suitable way, it seems. One generally just gets 72 dpi back, even if the actual resolution these days is often closer to 100dpi. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Need to override +(Class) class?
On 28.09.2008, at 05:05, Dave DeLong wrote: I had dragged the InputView* class files into my project, but they weren't successfully added. Removing them and adding them again got rid of the errors. You probably just forgot to associate them with your target. Next time this happens, just do a Get Info on each file and, in the inspector window that comes up, check the checkbox for whatever target you want these files to be part of. No need to remove and re-add, most things can be set there, there's even a popup indicating what type you want the files compiled as. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: design pattern for data acquisition in background thread?
On 28.09.2008, at 05:10, Joe Keenan wrote: The problem with any async method is that I haven't figured an elegant way to know which update code to use for each return value. They're not all the same. Different data elements need different processing to update the UI. When I get a response back asynchronously, I have the variable name and the value, and I have to figure out which UI element it belongs to. The brute force method is a long if/else chain that tests the name of the variable to do it, like: You could take advantage of the dynamism in the ObjC runtime and build a class or method name from whatever key you have that indicates what to do, then use NSClassFromString() or NSSelectorFromString() (or whatever) and then call that to do the work. I did that for my template engine once: NSString* className = [NSString stringWithFormat: @UK [EMAIL PROTECTED], fieldType]; Class theClass = NSClassFromString(className); UKTemplateController* theObj = [[theClass alloc] init]; // From now on I can use all the template controller // subclasses like the base class, and only they know they're different. Works like a charm, and the same can be done for selectors on a single object if that's more appropriate. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
On Sat, Sep 27, 2008 at 4:44 PM, Uli Kusterer [EMAIL PROTECTED] wrote: On 27.09.2008, at 22:13, Michael Ash wrote: But suddenly you're back to having to think about the global picture of who owns objects, which is what Cocoa's memory management system is supposed to avoid. Retains and releases should be balanced. This doesn't just means that they should ultimately be equal in number, it also means that the same entity should be doing both. Release when closed breaks the fundamental memory management rules and, as a consequence, makes it much more complicated to think about how the program works. You're misunderstanding the purpose of Cocoa's memory management system: It's not about not having to care who owns what, it's about not having to worry about shared ownership. There are many cases (threading and creation of objects come to mind) where ownership is handed from one object to the other. It's just two different sides of the same coin. Why is it useful to be able to ignore shared ownership? Because it turns memory management from a global problem into a local problem. How does Cocoa make memory management a local problem? By allowing us to easily deal with shared ownership. I did not mean to imply that ownership never gets passed from one object to another. Only that when you balance a retain with a release, the entity doing the release should be the same one doing the retain. Anything other approach turns the problem back into a global one, and makes life much more difficult. In this case, you specify in the NIB that you want your window to release itself, and you haven't written your outlet in a way that it retains the window. If you expect your window to not go away when closed, you're expecting too much. Except that in every case I've seen of people getting bit by this, the window was still being implicitly retained by the nib's File's Owner. You should definitely *not* expect a top-level nib object to go away until File's Owner releases it. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: design pattern for data acquisition in background thread?
On Sep 27, 2008, at 10:10 PM, Joe Keenan wrote:
The problem with any async method is that I haven't figured an
elegant way to know which update code to use for each return value.
They're not all the same. Different data elements need different
processing to update the UI. When I get a response back
asynchronously, I have the variable name and the value, and I have
to figure out which UI element it belongs to. The brute force
method is a long if/else chain that tests the name of the variable
to do it, like:
if ([key isEqualToString: @lnbcolor])
{
[lnbLight setTextColor:[NSColor colorFromHexidecimalValue:
keyValue]];
}
else if ([key isEqualToString: @lancolor])
{
[lanLight setTextColor:[NSColor colorFromHexidecimalValue:
keyValue]];
}
With lots (25 or so) more possible key values, and a half-dozen or
more different ways to update the UI element.
If I understand you correctly, then I had a similar problem in a Perl
web application: there were dozens of different run modes, each
corresponding to a different handler method (with the method names
themselves having essentially no relation to the run mode strings...
sigh). I eliminated the cascade of if-statements by mapping the run
modes to the methods directly with a hash map. You might be able to do
the same thing by e.g. using selectors as values in an NSDictionary.
Of course, it all depends on how your app's behavior needs to vary
with the responses you get from the networked device.
-Michael
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: design pattern for data acquisition in background thread?
On 28 Sep 2008, at 1:10 pm, Joe Keenan wrote:
if ([key isEqualToString: @lnbcolor])
{
[lnbLight setTextColor:[NSColor colorFromHexidecimalValue:
keyValue]];
}
else if ([key isEqualToString: @lancolor])
{
[lanLight setTextColor:[NSColor colorFromHexidecimalValue:
keyValue]];
}
With lots (25 or so) more possible key values, and a half-dozen or
more different ways to update the UI element.
An idea.
NSInvocation allows you to turn any method call on any object into an
object itself. That could then be stored in a dictionary keyed off the
received string, so your long if/else statement reduces to a single
line something like:
[[dict objectForKey:key] invoke];
Of course you still need to set up this dictionary in the first place,
but if the methods are typically the same but with different targets
you can copy and reuse the invocation objects to make this fairly
simple.
hth,
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 [EMAIL PROTECTED]
