Re: Confused about NSPrintInfo margins
More Info. If I do this:
- (void)setPrintInfo:(NSPrintInfo*) printInfo
{
[super setPrintInfo:printInfo];
PMPageFormatpmf = (PMPageFormat)[printInfo PMPageFormat];
PMPaper paper;
OSStatuserr = PMGetPageFormatPaper( pmf, paper );
if( err == noErr )
{
PMPaperMargins margins;
err = PMPaperGetMargins( paper, margins );
NSLog(@paper margins = {%f, %f} - {%f, %f}, margins.top,
margins.left, margins.bottom, margins.right );
}
}
I get the expected values logged. This suggests to me that the -
xxxMargin methods of NSPrintInfo are in fact, broken. If that's the
case I'll gladly report it, but I'd like to hear from anybody who
knows this stuff if my expectations are correct here.
--Graham
On 09/07/2009, at 2:48 PM, Graham Cox wrote:
I'm trying to get information about printing margins so my app can
show where the edges of the paper are correctly as well as the
content area.
I thought that's what NSPrintInfo methods such as -topMargin gave me
- the margins set by the Page Setup... dialog. But they never change
no matter what I do in the Page Setup dialog. The value of
NSPaperSize is also the same. I read the Printing Guide but it
doesn't mention margins at all.
Here are two examples, logged from the -setPrintInfo: method of
NSDocument. The first paper is a custom size based on A4 with
margins set to 0, the second set to 3 cm. As can be seen, apart from
the paper name, the info is identical.
2009-07-09 14:31:45.310 Ortelius[16094:10b] set print info: {
NSBottomMargin = 90;
NSCopies = 1;
NSDetailedErrorReporting = 0;
NSFaxNumber = ;
NSFirstPage = 1;
NSHorizonalPagination = 2;
NSHorizontallyCentered = 1;
NSJobDisposition = NSPrintSpoolJob;
NSLastPage = 2147483647;
NSLeftMargin = 72;
NSMustCollate = 1;
NSOrientation = 0;
NSPagesAcross = 1;
NSPagesDown = 1;
NSPaperName = A4 Minimal Margins 1;
NSPaperSize = NSSize: {651.969, 935.433};
NSPrintAllPages = 1;
NSPrintProtected = 0;
NSPrintTime = 0001-01-01 10:00:00 +1000;
NSPrinter = {
Device Description = {
NSDeviceIsPrinter = YES;
};
Language Level = 3;
Name = Canon i550;
Type = Canon i550;
};
NSPrinterName = Canon i550;
NSRightMargin = 72;
NSSavePath = ;
NSScalingFactor = 1;
NSTopMargin = 90;
NSVerticalPagination = 0;
NSVerticallyCentered = 1;
}
2009-07-09 14:32:01.407 Ortelius[16094:10b] set print info: {
NSBottomMargin = 90;
NSCopies = 1;
NSDetailedErrorReporting = 0;
NSFaxNumber = ;
NSFirstPage = 1;
NSHorizonalPagination = 2;
NSHorizontallyCentered = 1;
NSJobDisposition = NSPrintSpoolJob;
NSLastPage = 2147483647;
NSLeftMargin = 72;
NSMustCollate = 1;
NSOrientation = 0;
NSPagesAcross = 1;
NSPagesDown = 1;
NSPaperName = A4 Big Margins;
NSPaperSize = NSSize: {651.969, 935.433};
NSPrintAllPages = 1;
NSPrintProtected = 0;
NSPrintTime = 0001-01-01 10:00:00 +1000;
NSPrinter = {
Device Description = {
NSDeviceIsPrinter = YES;
};
Language Level = 3;
Name = Canon i550;
Type = Canon i550;
};
NSPrinterName = Canon i550;
NSRightMargin = 72;
NSSavePath = ;
NSScalingFactor = 1;
NSTopMargin = 90;
NSVerticalPagination = 0;
NSVerticallyCentered = 1;
}
So how can I get the information I need - the size of each margin?
And if that's not what -topMargin et. al. are for, what *are* they
for?
--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: bypass NSApp
Hi, Thx for the reply. First I think you did not understood my questions. In other platform, it's possible to run the GUI main loop in any thread. On macosx, there is a difference between the main run loop and the other NSRunLoop. I am trying to isolate this difference in order to avoid to run the main loop in the main thread. Because I have no access to the main thread. I read this : What especially distinguishes the main event loop is an input source called the event source, which is constructed when the global NSApplicationhttp://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSApplication_Class/Reference/Reference.html#//apple_ref/occ/cl/NSApplicationobject ( NSApphttp://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSApplication_Class/Reference/Reference.html#//apple_ref/c/data/NSApp) is initialized. The event source consists of a port for receiving events from the window server and a FIFO queue—the event queue—for holding those events until the application can process them from apple doc, so I want to use addport on a NSRunLoop to attach the input source described beside. I am still suprising of a such limiation of Cocoa on MacOSX while it works perfectly with GNUstep. Well, my first mail was very big and maybe not clear so I understand why you reply those things. I am free for any suggestion. (I say again: no access to the main thread) Sincerey Julien 2009/7/8 lbland lbl...@vvi.com On Jul 8, 2009, at 4:34 AM, Julien Isorce wrote: Any kind of comment or suggestion would be appreciated. I can see you are just beginning to discover multi-threading. You need to break in gdb and backtrace all of the thread stacks. That will tell you exactly what is going on. And it has it's own main loop. That is probably starving the main thread. All you need to do is get that code to execute in a sub-thread. The right way to do it is to get the 3rd party library to play nice with the main run loop. thanks!- -lance VVI ___ 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
NSStream, parsing NSData to struct
hello, i have NSData
...
NSData *d = [NSData dataWithBytes:(char*)buffer length:len];
NSLog(@%@, d); // efbeadde 14000100 0210 0400
00185918 b08259d8 1e00
and I have structure
typedef struct mrim_header
{
u_long magic;
u_long proto;
u_long seq;
u_long msg;
u_long dlen;
u_longIP;
u_longPort;
u_charReserved[16];
}mrim_header;
how can i parse this data to this structure? In general, i should catch some
unsigned long variable, i guess it's 1e00 and it must be equal 30 so,
before it i sent some packet and server returned to me these bytes, now i
should parse it
Please, let me know how to do it!
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSStream, parsing NSData to struct
On 09/07/2009, at 8:28 PM, Carlo Gulliani wrote:
hello, i have NSData
...
NSData *d = [NSData dataWithBytes:(char*)buffer length:len];
NSLog(@%@, d); // efbeadde 14000100 0210 0400
00185918 b08259d8 1e00
and I have structure
typedef struct mrim_header
{
u_long magic;
u_long proto;
u_long seq;
u_long msg;
u_long dlen;
u_longIP;
u_longPort;
u_charReserved[16];
}mrim_header;
how can i parse this data to this structure? In general, i should
catch some unsigned long variable, i guess it's 1e00 and it must
be equal 30 so, before it i sent some packet and server returned to
me these bytes, now i should parse it
Please, let me know how to do it!
The simplest approach is this:
mrim_header* header = (mrim_header*)[d bytes];
(or cut out the middle man: mrim_header* header = (mrim_header*)buffer;)
!BUT!
This will only work reliably if the same compiler was used to to
generate the code handling both the receiver and transmitter of the
data stream, and the platforms at each end have the same byte ordering
and word lengths and so forth. Different compilers could pack the
structure slightly differently, or a field might be 32 bits at one end
and 64 at the other, or the platforms may have different padding
conventions. If there's any chance that you can't guarantee all of
this, you will need to be more careful and be certain about any
padding that could have been added to the stream at source. Also, you
*will* need to byte-swap each field if the byte ordering differs.
Since you mention a server it sounds like the data is coming across a
network. In that case I would be very careful about simply casting to
the header structure without being absolutely certain about the size
of the fields, and all the rest.
This general article is a good introduction to this:
http://en.wikipedia.org/wiki/Data_structure_alignment
--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: bypass NSApp
On Jul 9, 2009, at 2:46 AM, Julien Isorce wrote: I am trying to isolate this difference in order to avoid to run the main loop in the main thread. Don't bother. Cocoa is quite explicitly designed to not support event processing on any thread other than the main thread. No amount of trying to isolate Cocoa functionality into a thread will make it work. Because I have no access to the main thread. The only way you can't have access to the main thread is if you are using a piece of software for which you have either no source or don't have the ability -- the rights, most typically -- to modify said source. If you have the source, modify it so that whatever it is that is consuming the main thread is no longer on the main thread. You'll need to give some more information on exactly what it is you are trying to do -- what you are trying to integrate with -- to gain more help. I am still suprising of a such limiation of Cocoa on MacOSX while it works perfectly with GNUstep. Think it through; why would Apple or NeXT waste engineering resources making this work? Making anything thread safe -- especially complex things -- is extremely difficult and there is always a performance hit for doing so. Always. And doing so offers what feature or advantage to the developer? Event processing is an inherently linear process. You generally cannot respond to the next event until the current event is fully processed. Efficiency is generally obtained by coalescing related events -- sequences of key events while typing -- or by ignoring events like mouse moves when they aren't relevant. b.bum ___ 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: unarchiving a font collection
hello to anyone that took notice of this issue appology to fontDescriptorsInCollection: on further investigation i discovered, deficient descriptor-count return from fontDescriptorsInCollection may be remedied by recreating the problem collection(s) (in Font Book); it appears the problem lies elsewhere. thanks, edward m taffel On Jul 7, 2009, at 3:50 PM, edward m taffel wrote: hello list, as NSFontManager -fontDescriptorsInCollection is apparently unreliable, i would like to unarchive collections directly (it seems apple does not provide support for this): anyone had success with unarchiving a font collection? thanks to all in advance, edward m taffel ___ 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/etaffel%40operamail.com This email sent to etaf...@operamail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Wake computer from sleep
Hello, I'm working on an alarm and I'm wondering what would be the best way to make it wake up the computer. I've heard of IOPMSchedulePowerEvent and I think it's the best way, but I'll need root privileges and I'm guessing the best way to do that without making a security hole is to have a helper application that just tells the computer what time to wake up and have my alarm application launch it. But there is one thing there, the only way I can find to do it requires the user to type in a password each time my alarm starts up and that's not user friendly, so is it possible maybe to save the user password in the keychain and use that to authenticate it to schedule an wake up time? Or save the AuthorizationRef and get that at start up? Thanks for any tips/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
Using private APIs
From time to time someone posts a question about using non-public Apple APIs -- you know, the ones that let you do something really cool or fast but causes your app to break on a future OS release. :) Anyways, I saw this purported private API for OS X, and I thought I'd share it. Pretty funny. :) From: http://ericasadun.com/iPhoneDocs300/_u_i_view_controller-_u_i_view_controller_class_dump_warning_8h-source.html @interface UIViewController (UIViewControllerClassDumpWarning) - (void)attentionClassDumpUser:(id)fp8 yesItsUsAgain:(id)fp12 althoughSwizzlingAndOverridingPrivateMethodsIsFun:(id)fp16 itWasntMuchFunWhenYourAppStoppedWorking:(id)fp20 pleaseRefrainFromDoingSoInTheFutureOkayThanksBye:(i))fp24; @end 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: Using private APIs
I think the far more interesting question beyond this superbly-named method (and kudos to the engineer who put it in) is Does this actually do anything? Dave On Jul 9, 2009, at 11:08 AM, Todd Heberlein wrote: From time to time someone posts a question about using non-public Apple APIs -- you know, the ones that let you do something really cool or fast but causes your app to break on a future OS release. :) Anyways, I saw this purported private API for OS X, and I thought I'd share it. Pretty funny. :) From: http://ericasadun.com/iPhoneDocs300/_u_i_view_controller-_u_i_view_controller_class_dump_warning_8h-source.html @interface UIViewController (UIViewControllerClassDumpWarning) - (void)attentionClassDumpUser:(id)fp8 yesItsUsAgain:(id)fp12 althoughSwizzlingAndOverridingPrivateMethodsIsFun:(id)fp16 itWasntMuchFunWhenYourAppStoppedWorking:(id)fp20 pleaseRefrainFromDoingSoInTheFutureOkayThanksBye:(i))fp24; @end ___ 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
[MEETING] Toronto Area Cocoa WebObjects Developer Group - July 14
The next meeting of tacow/Toronto CocoaHeads will be held on Tuesday, July 14 at 6:30 PM at Ryerson University. Up-to-date info and directions are available at http://groups.google.com/group/tacow and http://tacow.org/. Karl Moskowski kolpa...@voodooergonomics.com Voodoo Ergonomics Inc. http://voodooergonomics.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSDocument's -close method calls itself?
On 7/2/09 11:52 AM, Quincey Morris said:
On Jul 2, 2009, at 10:34, Sean McBride wrote:
I'm trying to find somewhere to undo what was done in my NSDocument
subclass' initializer. Specifically, to start/stop KVO
observation. It
seemed like 'close' would be a good place.
'close' isn't a good place, because it isn't necessarily called. If
you look at the Leopard Developer Release Notes:
http://developer.apple.com/releasenotes/Cocoa/AppKit.html
in the section entitled Advice for Overriders of Methods that Follow
the delegate:didSomethingSelector:contextInfo: Pattern, you'll find a
nice little code snippet that happens to show you where to place code
that should execute just before a document closes:
if (shouldClose) {
// Here we can do all sorts of things with this document that's
about to be closed.
}
Does that help?
Yes, thanks! However, just as 'close' is not always called, neither is
canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo. It's not
called if the document is explicitly closed (i.e. if someone sends the
document the 'close' message).
Again, my goal is to find a place to stop KVO started in my
initializer. Were I not a GC app, I guess I could use dealloc. I can't
use finalize, as removeObserver: is not documented to be thread safe.
I guess I'll do this:
- (void)close
{
if (!_didDoSpecialCloseStuffExactlyOnce)
{
[controller removeObserver:];
_didDoSpecialCloseStuffExactlyOnce = YES;
}
[super close];
}
The bool should protect me from super calling into 'close' again (see
subject).
Thanks,
--
Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
___
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: Confused about NSPrintInfo margins
Graham,
I'm not sure if this is exactly what you were talking about, but I did a test
in the printShowingPrintPanel of a program I'd written.
The NSPrintInfo methods setLeftMargin, setBottomMargin, setRightMargin and
setTopMargin all affect the margin values within the NSPrintInfo instance.
Here's the test code with the before and after values I saw.
- (void)printShowingPrintPanel:(BOOL)flag
{
NSPrintInfo *printInfo = [NSPrintInfo sharedPrintInfo];
float testLeft = [printInfo leftMargin];
float testBottom = [printInfo bottomMargin];
float testRight = [printInfo rightMargin];
float testTop= [printInfo topMargin];
// L, T, R, B IS NOW 72, 90, 72, 90
[printInfo setLeftMargin: 0];
[printInfo setBottomMargin: 0];
[printInfo setRightMargin: 0];
[printInfo setTopMargin:0];
testLeft = [printInfo leftMargin];
testBottom = [printInfo bottomMargin];
testRight = [printInfo rightMargin];
testTop= [printInfo topMargin];
// L, T, R, B IS NOW 0, 0, 0, 0
...
}
This was done using Xcode 3.1.3.
HTH,
Joel
___
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: Clarification on accessors? (was: Yet another memory management question)
On Jul 8, 2009, at 10:16 PM, Jeff Laing wrote: No, it doesn't. It would in fact violate the encapsulation principle if your -dealloc method required your accessors to not rely on certain state. The ability to override accessors violates encapsulation because it adds additional restrictions to the accessor that the superclass is not aware of. If you can't write your override of an accessor in such a way that you don't place additional restrictions on the superclass, you shouldn't do it. Because its not possible for you to make the assumption that the superclass will never care - without making (unjustifiable) assumptions about the superclasses implementation. My response was to someone presumably writing about Design Patterns, I believe who wanted to know what was the best approach to take. My opinion is that you should *not* assume that subclassers are idiots, because it doesn't matter how much bullet-proofing you put in, there's always going to be a worse idiot come along. Better to make them all have to work carefully, than to avoid using things *they* might screw up. I'll agree with Jeff on his points here. In my personal situation, I'm the only person working on code at my on- the-side home business. But, although I'm the only author, I have never had the need to subclass any accessors. And, I've always called accessors from within init and dealloc (as well as copyWithZone: and encodeWithCoder:). Such code is in shipping apps (Mac OS X and later iPhone OS) starting in 2004. The benefits of bottlenecking code through accessors like this is it can really help in debugging. I know for a fact that every access to a property does so via one line of code; easy to instrument and only one breakpoint needed. However, I also know that subclassing accessors may be needed. And in those cases, I'm going to assume that the coder(s) will understand the pitfalls. In my opinion, this is one of those all depends situations. ___ Ricky A. Sharp mailto:rsh...@instantinteractive.com Instant Interactive(tm) http://www.instantinteractive.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
[Moderator] Re: Using private APIs
This is not for discussion here. The guidelines are very clear that private API isn't to be be discussed here. On 2009-07-09, at 1:08 PM, Todd Heberlein wrote: From time to time someone posts a question about using non-public Apple APIs -- you know, the ones that let you do something really cool or fast but causes your app to break on a future OS release. :) Anyways, I saw this purported private API for OS X, and I thought I'd share it. Pretty funny. :) From: http://ericasadun.com/iPhoneDocs300/_u_i_view_controller-_u_i_view_controller_class_dump_warning_8h-source.html @interface UIViewController (UIViewControllerClassDumpWarning) - (void)attentionClassDumpUser:(id)fp8 yesItsUsAgain:(id)fp12 althoughSwizzlingAndOverridingPrivateMethodsIsFun:(id)fp16 itWasntMuchFunWhenYourAppStoppedWorking:(id)fp20 pleaseRefrainFromDoingSoInTheFutureOkayThanksBye:(i))fp24; @end 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/scott%40cocoadoc.com This email sent to sc...@cocoadoc.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Cocoa / Objective-C developers wanted
Want to work with the latest tools and a 30 inch screen? Want to work for a company where innovation and software development is taken seriously? Want flexible working hours and no silly dress code? Want a career where what you achieve really matters? Are you a clever problem solver with an enthusiastic and positive attitude? Are you a self starter and still able to work in a team? Can you get things done? NovaMind is based in sunny Queensland, located in Shailer Park midway between Brisbane and the Gold Coast, Australia. We are currently expanding our product development group to develop the worlds most advanced Mind Mapping software for Apple and Microsoft systems. We are looking for a software engineer who has a passion for creating innovative high quality software using the latest tools and technologies. You must be a self starter who loves solving problems in a logical self-disciplined manner. We are looking for someone who will fit well with our development team and remain courteous and friendly with both staff and customers at all times. If this doesn't describe who you are, your values and nature, please don't apply for this position. We are looking for people with the following skills: Essential skills: • Strong Objective-C skills • Strong AppKit development experience • Experience in meeting tight deadlines in a small development team • Experience with developing high quality software using object oriented methodologies • Experience interacting with customers on resolving defect reports Other highly desirable skills: • CoreData skills • Applescript / automator development experience • Experience with developing frameworks • XML and XSLT programming skills • Experience with loadable bundles and plugin architectures • Rendezvous/bonjour development experience • Experience with distributed objects • Experience with internationalization • Knowledge and understanding of Mind Mapping • Knowledge and understanding of screenplay script writing • Experience using MacOS X 10.5 Leopard Other desirable skills: • Experience with subversion • C# programming skills The tasks required for the position will vary over time, but include: • Designing and building new releases of the Mac version of NovaMind. • Assistance with setting product direction and feature sets for the Mac and Windows versions of NovaMind. • Documentation of the software at code/program level • Testing of the software • Preparing releases of the software, including installation mechanisms • Assisting as required with technical support • Fixing defects in the software • Working with beta testers to resolve any pre-release bugs • Improving systems • Setting and meeting key performance indicators To Apply To apply for this position, please email your resume in NovaMind Mind Map format, and cover letter to j...@novamind.com (we currently have two open Mac developer positions) Thanks Gideon King NovaMind Software www.novamind.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
[MEET] Reminder : LA CocoaHeads meeting tonight at 7:30pm
Greetings LA CocoaHeads. Tonight will be seeing a demo of the iPhone app TapStar and discussing what went into making it. You can read about TapStar here: http://toucharcade.com/2009/07/03/tapstar-sony-music-licensed-rhythm-game/ We will also be discussing the public announcements from WWDC from those who were able to attend in person. We meet at the offices of E! Entertainment at 7:30pm. Our meeting location is 5750 Wilshire Blvd Los Angeles, CA 90036. Here's a google map of the location: http://www.google.com/maps?f=qhl=enq=5750+Wilshire+Blvd,+Los+Angeles+CA+90036ie=UTF8z=15om=1iwloc=addr Free street parking is available after 8pm - FEED THE METER UP TO 8PM OR YOU MIGHT GET A TICKET! I'd suggest trying Masselin Ave, which is one block East of Courtyard Place. We meet near the lobby of the West building at 5750 Wilshire Blvd, on the West side of Courtyard Place. There are picknick tables in front of the lobby and we'll gather there starting at 7:20pm. From there we go inside and up to conference room 3A at around 7:45pm . If you arrive late, please ask the building security personnel in the lobby to direct you to the E! Security office, and they will be able to contact the group in conference room 3A and send someone down to meet you. Rob ___ 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: Clarification on accessors? (was: Yet another memory management question)
-init and -dealloc are special in that the object is not in a consistent state during those methods (it either hasn't yet entered it's initial state or is transitioning out of its final state). If your accessors rely on the internal state of the object being normal, they could blow up when called in these methods. As Graham Chris note, -init and -dealloc are special. The problem is really larger than that, though. In Cocoa, most setters are called upon the receiver by another object as public API to change the receiver. The setters may have complex behaviors associated with them, either directly or via KVO. Change tracking, document dirtying, undo registration, recomputing derived values, etc. But the receiver may also wish to express the notion of a private change in state that does not do any of that. In this case, while an ivar may change state in a literal sense, the class is not changing state as defined by its public API. Perhaps the document remains clean, perhaps there is no undo, or perhaps derived values are left unchanged (typically because all the private state is being rolled back together, so recomputing them is pointless) You may need to distinguish between privately restoring state and publicly changing state Conflating the public accessors with setting an ivar during init or dealloc is troublesome and inflexible. As with privately restoring state, constructing state and destructing state are just not the same as publicly changing state. While it will work for many simple projects, as behavior is added to classes, it tends to scale poorly. Considering init dealloc blessed (or cursed) allows for maximum flexibility for accessors and subclasses while minimizing bizarre bugs due to objects being in a partially constructed state. It's not a law, but it is the most pragmatic rule of thumb. There are a great many kinds of bugs that can sprout from partially constructed objects. Subclasses may access uninitialized state, setters may register the object in a global table before init is finished creating a multi-threading bug, setters may allocate more memory during dealloc, etc It may be that under certain circumstances (dictionary storage, synthesized properties on 10.5, etc) that you must use an accessor method even in init dealloc. That requires more care, is more error prone, and less flexible. In particular, additional behavior should not be adorned to the accessor, and the accessor must never leak knowledge of the receiver to a third party during init or dealloc. Basically, these accessors must be very very boring. - Ben ___ 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: NSPopupButton to display fonts in the fonts themselves
On Jul 8, 2009, at 6:15 PM, I. Savant wrote: On Jul 8, 2009, at 9:06 PM, Peter Ammon wrote: So for menus that may take a while to build, consider appending the items as they come in (like the Airport status item), or showing a Building... item until you're ready to add the complete set of items. What of menus that already have a selection well down the list? In this case, it sounds like my original idea of immediately building the list of font names on nibloading/creation/whenever first, then rendering the attributed titles in the background (and updating the popup on the main thread) might still be the better option. Or have I misunderstood? If your menu has a selection, like a popup menu, then your idea is definitely the way to go. However, getting the list of available fonts can take a noticeable amount of time, so you may find it too expensive to build the list up-front. ___ 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
Cocoa developers in Victoria BC
If you're in Victoria BC or its environs, and would like to join an informal group of fellow sufferers, please contact me off-list. (iPhone OS developers are also welcome, of course.) dkj ___ 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: NSPopupButton to display fonts in the fonts themselves
On Jul 8, 2009, at 8:02 PM, Graham Cox wrote: On 09/07/2009, at 11:06 AM, Peter Ammon wrote: - (BOOL)menu:(NSMenu *)menu updateItem:(NSMenuItem *)item atIndex: (NSInteger)index shouldCancel:(BOOL)shouldCancel is actually invoked on some sort of background thread/queue, so implementing these methods (the above + numberOfItemsInMenu:) in your menu delegate would allow you to update each item with the attributed title fairly simply and it wouldn't drag your main thread's performance down. --Graham What this method does is check at regular intervals for events that would cancel tracking. If one is detected, it passes YES for shouldCancel. So if your design is if the user clicks on the menu, sit and spin until it's built, then you could use this API to detect cancellation, to stop spinning. However, sit and spin isn't a very good user experience, and Leopard allows you to append items to a menu in the menu bar while it is open. So for menus that may take a while to build, consider appending the items as they come in (like the Airport status item), or showing a Building... item until you're ready to add the complete set of items. OK... this clarification has confused me a little though. Can this delegate method be used as suggested or not? In other words, if I use it to change each item's plain title to a more complex attributed title, will that cause a performance problem? What I expect to see is that I pop open the menu and see plain titles, gradually being replaced one by one with the attributed titles but menu tracking proceeds normally. No, the menu:updateItem:atIndex:shouldCancel: API does not support that. Every item gets updated before the menu is shown. It is entirely synchronous. If you want to set the attributed titles while the menu is opened, you can do it by installing a timer from the delegate callbacks, like menuWillOpen:, or NSMenuWillBeginTrackingNotification. But if my code inside this method takes significant time, will that make tracking sluggish? Also, if menu tracking ends, are the remainder of the items passed to this method or does it stop there? Every item gets passed to the callback, until the items are exhausted or the callback returns NO. If so, I. Savant's original plan would probably be better so that the titles can be processed in the background even if the menu isn't shown (though in that case it could be wasted work if the user *never* opens the menu). menuWillOpen: is probably the best place to create a timer to start installing the attributed titles. This will ensure that they only get installed if the menu is going to be displayed. Hope this helps, -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
[MEET] BYU CocoaHeads meeting tonight at 7:00pm
Hi everyone, This is a reminder that BYU CocoaHeads will be meeting tonight at 7:00pm MDT in W210 TNRB on BYU Campus. (http://map.byu.edu/?building=tnrb ) We'll be having a presentation on Core Data and might even have cookies (the edible kind). See you there! Dave DeLong President, BYU CocoaHeads ___ 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: bypass NSApp
Sent from my iPhone On Jul 9, 2009, at 10:04 AM, Bill Bumgarner b...@mac.com wrote: On Jul 9, 2009, at 2:46 AM, Julien Isorce wrote: I am trying to isolate this difference in order to avoid to run the main loop in the main thread. Don't bother. Cocoa is quite explicitly designed to not support event processing on any thread other than the main thread. No amount of trying to isolate Cocoa functionality into a thread will make it work. To empasize this point. Consider, for example, the method performSelectorOnMainThread:. We use this API in several place to ensure that functionality is performed on the same thread that is processing user events. If code were able to change the thread responsible for handling events willy-nilly, that kind of functionality would break badly. ___ 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
CFBundleTypeName
http://devworld.apple.com/ReleaseNotes/Cocoa/AppKit.html Use of these keys becomes optional: CFBundleTypeName http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html This key is required What is the truth? I'm trying to create a document by passing a type into makeDocumentWithContentsOfURL, but it doesn't seem to call the appropriate document handling class to create the document. Access Yahoo!7 Mail on your mobile. Anytime. Anywhere. Show me how: http://au.mobile.yahoo.com/mail ___ 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
disguising method and variable names in binary
is there a way to replace all method and variable names with something meaningless at build time? obviously these things need meaningful names for my sake but I don't care what they're called in the binary. I've tried setting the strip build settings for my target but still see method names in plain text in the executable. ___ 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: disguising method and variable names in binary
On Thu, Jul 9, 2009 at 5:15 PM, justin websterm...@justinwebster.com wrote: is there a way to replace all method and variable names with something meaningless at build time? No, there isn't. Why would you want to do this? obviously these things need meaningful names for my sake but I don't care what they're called in the binary. They need meaningful names at runtime, too. --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: disguising method and variable names in binary
On Jul 9, 2009, at 5:15 PM, justin webster wrote: is there a way to replace all method and variable names with something meaningless at build time? obviously these things need meaningful names for my sake but I don't care what they're called in the binary. Not really; KVO, KVC, Bindings, CoreData, delegation and many other mechanisms rely upon the selector and class names. Sometimes, even the ivar names. I've tried setting the strip build settings for my target but still see method names in plain text in the executable. You can't strip a dynamic application because there is no way for the compiler and linker to know what code paths might actually be used. Ultimately, though, stripping and obfuscating is largely just going to frustrate your efforts to figure out why your app crashes at a customer site more than it would ever prevent someone from hacking it. b.bum ___ 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: Confused about NSPrintInfo margins
Thanks Joel, certainly setting the margins directly does work. What
I'm left wondering is what they are actually for - they are never set
by he Page Setup panel and never change with changes to paper size,
printer, etc.
My conclusion is that these fields are merely a convenience for
specifying arbitrary user margins, and if you want to use them you
have to a) add UI to set them and b) make use of them in your code
somewhere. By default they do nothing, are ignored and have no effect
whatsoever on printing unless your code decides not to ignore them.
Unfortunately this is all guesswork as the docs do not discuss it
anywhere I can find. At the very least I will file a bug asking for
better documentation on this.
However I would love to hear from someone in the print group whether
I'm right about this, since I am writing stuff into my app to handle
page layout/printing and proceeding on this assumption could prove to
be a mistake.
--Graham
On 10/07/2009, at 5:22 AM, Joel Norvell wrote:
Graham,
I'm not sure if this is exactly what you were talking about, but I
did a test in the printShowingPrintPanel of a program I'd written.
The NSPrintInfo methods setLeftMargin, setBottomMargin,
setRightMargin and setTopMargin all affect the margin values within
the NSPrintInfo instance.
Here's the test code with the before and after values I saw.
- (void)printShowingPrintPanel:(BOOL)flag
{
NSPrintInfo *printInfo = [NSPrintInfo sharedPrintInfo];
float testLeft = [printInfo leftMargin];
float testBottom = [printInfo bottomMargin];
float testRight = [printInfo rightMargin];
float testTop= [printInfo topMargin];
// L, T, R, B IS NOW 72, 90, 72, 90
[printInfo setLeftMargin: 0];
[printInfo setBottomMargin: 0];
[printInfo setRightMargin: 0];
[printInfo setTopMargin:0];
testLeft = [printInfo leftMargin];
testBottom = [printInfo bottomMargin];
testRight = [printInfo rightMargin];
testTop= [printInfo topMargin];
// L, T, R, B IS NOW 0, 0, 0, 0
...
}
This was done using Xcode 3.1.3.
HTH,
Joel
___
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: NSPopupButton to display fonts in the fonts themselves
On 10/07/2009, at 8:11 AM, Peter Ammon wrote: No, the menu:updateItem:atIndex:shouldCancel: API does not support that. Every item gets updated before the menu is shown. It is entirely synchronous. Thanks for the clarification Peter - looks like my suggestion was off base then. Very useful to know. As you were, everyone... --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: TableView displaying a zillion empty rows Problem Solved!
I really appreciate all the help, it kept me searching for an answer. Ron Fleckner was the closest to diagnosing the problem. I had plugged the unit into the wall socket but I forgot to turn the breaker back on. I had failed to call reloadData. Sorry Andy, I didn't find the answer in the beer bottle. Dumb, Dumb, Dumb. Brian _ Hotmail® has ever-growing storage! Don’t worry about storage limits. http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009___ 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: TableView displaying a zillion empty rows Problem Solved!
Argh, when I think of all the times reloadData has been the *first* suggestion from the list in response to an NSTableView problem! Thanks for keeping us posted. :) --Andy On Jul 9, 2009, at 10:43 PM, Brian Hughes wrote: I really appreciate all the help, it kept me searching for an answer. Ron Fleckner was the closest to diagnosing the problem. I had plugged the unit into the wall socket but I forgot to turn the breaker back on. I had failed to call reloadData. Sorry Andy, I didn't find the answer in the beer bottle. Dumb, Dumb, Dumb. Brian ___ 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: bypass NSApp
On Thu, Jul 9, 2009 at 6:09 PM, Scott Thompsonea...@mac.com wrote: To empasize this point. Consider, for example, the method performSelectorOnMainThread:. We use this API in several place to ensure that functionality is performed on the same thread that is processing user events. If code were able to change the thread responsible for handling events willy-nilly, that kind of functionality would break badly. ... or two plugins both trying this hack, and claiming their thread as the main thread. I sympathize with what you're trying to do, Julien, but it's simply not going to work. Personally, I'd write a full fledged helper app in Cocoa, maybe marking it as a background app (so it doesn't appear in the Dock), and then communicate with it in my plugin. There are many ways to do this: unix sockets, mach ports, distributed objects, shared memory, etc, etc. ___ 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
NSConnection Proxy Crash
Hello, I'm having a problem after I send a message to a proxy
application through NSConnection.
my code is
daemonServer = [[NSConnection
connectionWithRegisteredName:@MGMDaemon host:nil] retain];
if (daemonServer==nil) {
NSLog(@Couldn't connect to daemon server.);
return;
}
MGMDaemon = [[daemonServer rootProxy] retain];
if (MGMDaemon==nil) {
NSLog(@Couldn't set proxy with daemon server.);
[daemonServer release];
daemonServer = nil;
return;
}
[MGMDaemon setProtocolForProxy:@protocol(MGMDaemonProtocol)];
[MGMDaemon runTest:@Test];
and my crash report says
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xc023
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x94738688 objc_msgSend + 24
1 com.apple.Foundation 0x95b9ac1a -[NSConnection
handlePortCoder:] + 1178
2 com.apple.Foundation 0x95b9a72e -[NSConcretePortCoder
dispatch] + 142
3 com.apple.Foundation0x95b99e93 __NSFireMachPort + 339
4 com.apple.CoreFoundation0x94f331c5 __CFMachPortPerform + 117
5 com.apple.CoreFoundation 0x94f57888 CFRunLoopRunSpecific +
3896
6 com.apple.CoreFoundation0x94f57c78 CFRunLoopRunInMode + 88
7 com.apple.Foundation 0x95b943e5 -[NSRunLoop(NSRunLoop)
runMode:beforeDate:] + 213
8 com.apple.Foundation 0x95ba0504 -[NSRunLoop(NSRunLoop)
run] + 84
9 itunesmenudaemon0x22e7 main + 320 (daemon.m:61)
10 itunesmenudaemon0x2056 start + 54
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x00104370 ebx: 0x95b5b2bb ecx: 0x947d4334 edx: 0xc003
edi: 0x0004 esi: 0x95d46874 ebp: 0xb508 esp: 0xb398
ss: 0x001f efl: 0x00010202 eip: 0x94738688 cs: 0x0017
ds: 0x001f es: 0x001f fs: 0x gs: 0x0037
cr2: 0xc023
I can't seem to find the problem, the command gets executed and then
it crashes.
Help please?
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
Toolbar Example
Can anybody recommend a toolbar example using Interface Builder? All the ones I've seen manage toolbars through code. I'm just trying to get my toolbar items to enable. I'm sure it's dead simple but I'm still trying to wrap my head around bindings and key/value coding. Thanks. Anthony smime.p7s Description: S/MIME cryptographic signature ___ 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
NSSavePanel delegate Methods called by NSOpenPanel
Hi all,
I'm a little confused by the following situation:
I have an NSPathControl (PopUp-Style) that should only
allow certain paths to be selected.
Therefore I have a controller-object that I set as the
delegate of the NSPathControl and the NSOpenPanel that
will be presented if a user clicks on the Choose...
item in the path-popup.
This is working fine except for the delegate method
- (NSString *)panel:(id)sender
userEnteredFilename:(NSString *)filename
confirmed:(BOOL)okFlag
which somehow doesn't seem to be called.
More curiously:
If I trick the panel in selecting an invalid path
through creation of a new directory, I cannot open
that path - which at least is half of what I wanted
to accomplish in the first place...
I guess I'm doing something terribly and obviously
stupid here, but I just don't see it...
So any pointers will be much appreciated!
Thanks in advance,
Daniel
PS:
Below are the interesting methods from my controller-
class's implementation.
#pragma mark NSPathControlDelegate methods:
- (void)pathControl:(NSPathControl *)pathControl willDisplayOpenPanel:
(NSOpenPanel *)openPanel
{
[openPanel setAccessoryView:mAccessoryView];
[openPanel setCanChooseFiles:NO];
[openPanel setCanChooseDirectories:YES];
[openPanel setCanCreateDirectories:YES];
[openPanel setDelegate:self];
[openPanel setDirectory:mValidBasePath];
}
#pragma mark NSSavePanelDelegate methods:
- (BOOL)panel:(id)sender
isValidFilename:(NSString *)filename
{
return [self isValidPath:filename shouldPresentError:NO];
}
- (NSString *)panel:(id)sender
userEnteredFilename:(NSString *)filename
confirmed:(BOOL)okFlag
{
// not called at all!
NSLog(filename);
if (![self isValidPath:filename shouldPresentError:YES]) {
NSLog (@invalid path: %...@\nreturning nil..., filename);
return nil;
}
NSLog (@valid path!);
return filename;
}
___
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: Clarification on accessors? (was: Yet another memory management question)
On Jul 9, 2009, at 4:29 PM, Ben Trumbull wrote: It may be that under certain circumstances (dictionary storage, synthesized properties on 10.5, etc) that you must use an accessor method even in init dealloc. That requires more care, is more error prone, and less flexible. In particular, additional behavior should not be adorned to the accessor, and the accessor must never leak knowledge of the receiver to a third party during init or dealloc. Basically, these accessors must be very very boring. But if it's a synthesized accessor, wouldn't it be pretty much a given that that would be the case? Charles ___ 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
how to hide/display titlebar?
Dear all, how to hide/display titlebar of cocoa window? i hope the window can be show full size when playing vedio! _ Messenger安全保护中心，免费修复系统漏洞，保护Messenger安全！ http://im.live.cn/safe/ ___ 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: Toolbar Example
On 10/07/2009, at 3:20 PM, Anthony Smith wrote: Can anybody recommend a toolbar example using Interface Builder? All the ones I've seen manage toolbars through code. I'm just trying to get my toolbar items to enable. I'm sure it's dead simple but I'm still trying to wrap my head around bindings and key/value coding. Thanks. You don't really need to write any code for toolbars. Just hook up the targets and actions of the toolbar items to the relevant places and it should work. Like menu items, by default a toolbar item is enabled if its target responds to the action method selector, or you can override -validateUserInterfaceItem: to provide more control. If your items are shown disabled, have you actually connected the action and target? n.b. KVC and/or bindings are not required. --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: Toolbar Example
Thanks. I messed around with selector and didn't think I was heading down the right path. The direction helps. I think I'll be able to handle it from here. On Jul 10, 2009, at 1:28 AM, Graham Cox wrote: On 10/07/2009, at 3:20 PM, Anthony Smith wrote: Can anybody recommend a toolbar example using Interface Builder? All the ones I've seen manage toolbars through code. I'm just trying to get my toolbar items to enable. I'm sure it's dead simple but I'm still trying to wrap my head around bindings and key/value coding. Thanks. You don't really need to write any code for toolbars. Just hook up the targets and actions of the toolbar items to the relevant places and it should work. Like menu items, by default a toolbar item is enabled if its target responds to the action method selector, or you can override -validateUserInterfaceItem: to provide more control. If your items are shown disabled, have you actually connected the action and target? n.b. KVC and/or bindings are not required. --Graham smime.p7s Description: S/MIME cryptographic signature ___ 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
