Re: Minimal document-based app
If nothing else, it would explain to me how things works, 20 lines of code would help me better than 20 documentation pages. There tutorials above certainly did the explaining very well. Also, I don't really want to argue whether there is merit or not - I would be more thankful for the eventual tutorial or code sample. On Tue, May 1, 2012 at 8:08 AM, Graham Cox wrote: > I see no merit in trying to make a "minimal" document based app, whatever > that is. It's usually misguided to try and build UI in code, it saves you > nothing and makes it much harder to get anywhere. > > Just start a new Cocoa app and use the project template for a document based > app. It gives you the necessary starting points, which though it adds a nib, > it's extremely small. There is nothing to be gained by going some other route. > > --Graham > > > On 30/04/2012, at 7:47 AM, ecir hana wrote: > >> Dear list, >> >> I'm trying to understand how the things in Cocoa works but I'm >> struggling with one thing. I saw >> http://cocoawithlove.com/2010/09/minimalist-cocoa-programming.html and >> http://casperbhansen.wordpress.com/2010/08/15/dev-tip-nibless-development/ >> and I think I somewhat understood. >> >> Now, I would like to do the same but for a "Document-based >> application". Please, does anyone know of a tutorial or example akin >> to the ones above? Alternatively, what do I need to do to make it >> work? I think I need to create NSDocumentController - but how does it >> relate to NSApplication? And I create NSDocument from there? Frankly, >> I'm bit lost... >> >> Thank you very much in advance! > ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Minimal document-based app
On 29 Apr 2012, at 22:47, ecir hana wrote: > Dear list, > > I'm trying to understand how the things in Cocoa works but I'm > struggling with one thing. I saw > http://cocoawithlove.com/2010/09/minimalist-cocoa-programming.html and > http://casperbhansen.wordpress.com/2010/08/15/dev-tip-nibless-development/ > and I think I somewhat understood. > > Now, I would like to do the same but for a "Document-based > application". Please, does anyone know of a tutorial or example akin > to the ones above? Alternatively, what do I need to do to make it > work? I think I need to create NSDocumentController - but how does it > relate to NSApplication? And I create NSDocument from there? Frankly, > I'm bit lost… I appreciate the intention here. I would start by creating a NSDocumentBased app using the Xcode template and examining it. This app is fully functional even though it contains just the document class and the nib. The reason it works can be found in info.plist under CFBundleDocumentTypes. This defines the NSDocument class to use. In MainMenu.xib you can see that File New sends newDocument: up the responder chain. This passes up the chain to NSApplication which (having loaded Info.plist) knows to create an instance of your document class. To create a document in code just send newDocument: up the responder chain with a nil targeted action [NSApplication sendAction:@selector(newDocument:) to:nil from:self] Regards Jonathan Mitchell ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Nil and nil Macro Conflict
I want to use a C++ software library which uses class names "nil" and "Nil" for a Cocoa application. Including the headers will fail due to name conflicts with the macros "Nil" and "nil". What are my options? Regards Andreas ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Nil and nil Macro Conflict
On May 1, 2012, at 5:44 AM, Andreas Grosam wrote: > What are my options? You might have to wrap that sucker, so that you can compile that class as straight C++ and never include its header from Objective-C++, but instead use your wrapper class from Objective-C++. Assuming you don't want to change those class names and then have to re-do that every time you update the library... -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Nil and nil Macro Conflict
On May 1, 2012, at 3:56 PM, Scott Ribe wrote:
> On May 1, 2012, at 5:44 AM, Andreas Grosam wrote:
>
>> What are my options?
>
> You might have to wrap that sucker, so that you can compile that class as
> straight C++ and never include its header from Objective-C++, but instead use
> your wrapper class from Objective-C++.
Hm, the library is a header only template library - namely its spirit (from
boost), so my chances to never include this library are zero ;)
Basically, I need something like the following to compile:
// file foo.m:
#include
namespace nm {
struct nil {};
struct Nil {};
}
NSObject* o = nil;
Andreas
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Minimal document-based app
On May 1, 2012, at 12:28 AM, ecir hana wrote: > If nothing else, it would explain to me how things works, 20 lines of > code would help me better than 20 documentation pages. There tutorials > above certainly did the explaining very well. But it won't teach you how document-based Cocoa apps are actually constructed. I would instead suggest understanding how nibs work, and how the document architecture is put together. Rather than focusing on finding an example that bucks convention, read the source to an example that adheres to it. > > Also, I don't really want to argue whether there is merit or not - I > would be more thankful for the eventual tutorial or code sample. Sorry, this isn't a reasonable demand. This is a discussion forum about Cocoa; you should anticipate that the participants will discuss your question from the perspective of Cocoa programmers. --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Minimal document-based app
On 1 May 2012, at 2:28 AM, ecir hana wrote: > If nothing else, it would explain to me how things works, 20 lines of > code would help me better than 20 documentation pages. There tutorials > above certainly did the explaining very well. Every few months, a beginner comes who wants to skip NIBs to "see how it works." Please understand why experienced developers advise against this, even though they understand the impulse. NIBs _are_ how it works. They don't contain or generate code. They don't contain or generate scripts. They don't exercise much of the API you're trying to use. They contain archived objects and their connections. Their effects can (often) be mimicked in code, but by the same token, Objective-C can be mimicked in assembly. It is useful to understand a bit of assembly when you use a high-level language, but except in special circumstances, nobody advocates writing programs in it. And in the case of compiling Objective-C, at least the translation passes (notionally) through assembly code. Similarly, it is useful to understand how NIBs are reconstituted into objects, but one must understand that the underlying mechanism is reconstitution, not executing code that simulates reconstitution. Unlike the translation of a high-level language, there is no executable layer through which reconstitution passes. (At least in the sense you mean.) NOTE: On iOS, it is frequently useful to build object hierarchies in code, but the Cocoa Touch API is designed to make that easy. Even there, most designs take the form of reconstituting objects from NIBs. — F ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Nil and nil Macro Conflict
On May 1, 2012, at 8:10 AM, Andreas Grosam wrote: > Hm, the library is a header only template library - namely its spirit (from > boost), so my chances to never include this library are zero ;) I didn't say never include it; I said never include it from Objective-C++. The fact that it is a header-only template library does not change the fact that you can create wrapper classes to use from Objective-C++. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Minimal document-based app
What Fritz said. Unlike other graphical UI layout tools, Interface Builder is central to Cocoa development, not simply a shortcut for newbies or a way to get started quickly. Anyone who thinks developing without Interface Builder is a purer path to understanding Cocoa has already missed the point. _murat On May 1, 2012, at 7:50 AM, Fritz Anderson wrote: > On 1 May 2012, at 2:28 AM, ecir hana wrote: > >> If nothing else, it would explain to me how things works, 20 lines of >> code would help me better than 20 documentation pages. There tutorials >> above certainly did the explaining very well. > > Every few months, a beginner comes who wants to skip NIBs to "see how it > works." Please understand why experienced developers advise against this, > even though they understand the impulse. > > NIBs _are_ how it works. They don't contain or generate code. They don't > contain or generate scripts. They don't exercise much of the API you're > trying to use. They contain archived objects and their connections. > > Their effects can (often) be mimicked in code, but by the same token, > Objective-C can be mimicked in assembly. It is useful to understand a bit of > assembly when you use a high-level language, but except in special > circumstances, nobody advocates writing programs in it. And in the case of > compiling Objective-C, at least the translation passes (notionally) through > assembly code. > > Similarly, it is useful to understand how NIBs are reconstituted into > objects, but one must understand that the underlying mechanism is > reconstitution, not executing code that simulates reconstitution. Unlike the > translation of a high-level language, there is no executable layer through > which reconstitution passes. (At least in the sense you mean.) > > NOTE: On iOS, it is frequently useful to build object hierarchies in code, > but the Cocoa Touch API is designed to make that easy. Even there, most > designs take the form of reconstituting objects from NIBs. > > — F > > > ___ > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/mlist0987%40gmail.com > > This email sent to mlist0...@gmail.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Nil and nil Macro Conflict
On May 1, 2012, at 7:10 AM, Andreas Grosam wrote:
> Hm, the library is a header only template library - namely its spirit (from
> boost), so my chances to never include this library are zero ;)
>
> Basically, I need something like the following to compile:
>
> // file foo.m:
>
> #include
>
> namespace nm {
>struct nil {};
>struct Nil {};
> }
>
> NSObject* o = nil;
If you never need to use boost's nil in your own code, you can carefully order
your includes so the boost headers are always first.
#include // uses nil
#include// #defines nil but doesn't affect the
boost header
NSObject *o = nil; // uses objc's nil
If you do need to use boost's nil in your own code, you can use macro tricks to
rename their nil.
#define nil boost_nil
#include
#undef nil
#include
// now you have objc's nil and boost::boost_nil
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Minimal document-based app
On May 1, 2012, at 8:50 AM, Fritz Anderson wrote: > NIBs _are_ how it works. They don't contain or generate code. They don't > contain or generate scripts. They don't exercise much of the API you're > trying to use. They contain archived objects and their connections. True, but the beginner may not have the slightest clue as to what those objects in Interface Builder are and what functionality they provide and how they should be properly connected. I have often found that once you understand a class and its methods by reading the documentation again and again and even doing some coding, then when you look at it in Interface Builder a light will go on and you will exclaim eureka, now I understand what this is trying to tell me! But for me it has NEVER been the other way around. I have NEVER learned a concept first Interface Builder and have it make sense. I have often thought that Interface Builder was created by very gifted programmers who knew the underlying objects and API and to them it all makes perfect sense but they are completely oblivious to the fact that it makes almost no sense to a beginner. Apple has done an incredible job with the Cocoa API, documentation, and developer tools but the learning curve can still be overwhelming. My advice to a beginner is start very small and work your way up. Read the documentation, get a good book like Cocoa Programming for Mac OS X Third Edition by Hillegass, and start working your way through the examples. There are no shortcuts. Hillegass covers the document architecture in Chapter 10 starting on page 157 which is almost half way through the book. Maybe it is just me, but that has been my experience. --Richard ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Modal-loop Event-handling question
Thanks Jens, for your enlightening comments. On 30/04/2012, at 20:55, Jens Alfke wrote: > > On Apr 30, 2012, at 1:24 AM, Motti Shneor wrote: > >> In our client-server app we sometimes present modal sheets on our main >> window. Following server notifications we sometimes have to dismiss these >> sheets (user is expelled, or otherwise status-changed). > > To me, dismissing a sheet without any user intervention sounds like a > problematic UI design. It could be confusing if the user was about to do > something with the sheet (or was halfway through) when it disappeared. In the > worst case the user might be about to click an item in the sheet, and end up > clicking through to whatever control was underneath it in the main window. > I agree this is not "nice" user experience, but ours is a "virtual meeting" system. Please compare: You talk to someone on the phone, then line is lost. Indeed some of your words will go down a dead line. This is the kind of situation I'm describing. In such situations, where the dialog (whether modal or modeless) has no meaning anymore, and whatever the user will do in it, makes no difference, because the context is gone (e.g. you want to send a little note to another participant. You open that dialog, and start typing Then the host expels you. Or the meeting is closed (scheduled) or... whatever. What good is to keep the dead UI, and thus mislead the user that he can complete the action he started? > I would suggest either making this UI modeless, or keeping the sheet up but > adding a banner or something to it alerting the user that she’s been logged > out. I'd rather replace the whole contents of the sheet with that banner you insinuate, but that's another discussion. Currently I need to overcome this crashing bug. > >> However, If we do this while the user holds one of the sheet buttons pressed >> --- within the mouse-tracking loop --- than endSheet happens, and then the >> mouseUp event reaches a released object (the sheet) which then crashes the >> application. > > Ouch. The best workaround to this that I can think of is to check the current > runloop mode, and if it’s NSEventTrackingRunloopMode give up without messing > with the sheet (or check again later.) > I can't just "give up" when I'm tracking the mouse. To avoid the crash, we tried to defer the "endSheet" via "performSelecor:@selector(closeAnyOpenSheet) afterDelay:0.0". This prevents the releasing of the dialog before the "mouseUp" event is received. However, when "mouseUp" event comes, the didEndSelector is called for the sheet-alert (before our deferred "endSheet" has a chance to happen), and then we face another problem --- we try to accomplish user command, in a dead context. No problem to patch a few "sheetDidEnd" methods, but we have dozens of them (all very different) and I would prefer general treatment for the problem. Do you know anything about the difference between "stopModal" and "abortModal" methods? Do you know which of these is being called by "endSheet" ? Is there a lower-level programmatic way to close the sheet and the modal session, giving up whatever event-loop is there? Thanks again@ Motti Shneor, Spectrum Reflections Ltd. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Minimal document-based app
> Unlike other graphical UI layout tools, Interface Builder is central to Cocoa > development, not simply a shortcut for newbies or a way to get started > quickly. Anyone who thinks developing without Interface Builder is a purer > path to understanding Cocoa has already missed the point. Actually, there are a lot of commercial developers who hard-code their entire UIs. I'm at something of a loss to see why myself, but they do it, and they swear it's the best way. Ironically, one of the reasons often given is "easier internationalisation" vs xibs. Though this does happen more often with iOS than Mac OS, from what I've seen. There may be some paradigms refusing to shift with ex- or co-Android developers. Nonetheless it's demonstrably possible. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
No validation with a bound NSTableView and custom NSFormatter
Hi all, I have an NSTableView whose data source is bound to an NSArrayController. To one of its columns (displaying a custom type) I have attached a custom NSFormatter subclass. The NSFormatter correctly returns NO from getObjectValue:forString:error: if the supplied string is not acceptable. Despite this, however, validation is not enforced; when tabbing out of the field, the table view carries on and just assigns a null value to the corresponding property. Even when I implement control:didFailToFormatString:errorDescription: in the NSTableView's delegate, an invalid null value is nevertheless accepted and focus moves to the next responder, despite returning NO. My current implementation has been using an in-memory (transient) CoreData stack, but I have pared that back to simply use NSArrayController in "class" mode and behaviour is the same. The modelled property in question is a custom class (not a plist-compliant primitive, hence in part the need for a custom NSFormatter); however, two-way behaviour in the NSTableView works fine except for the lack of validation. I must be missing something fundamentally obvious, but I can't figure out where to approach the fix. Enlightenment would be appreciated. thanks, -ben -- Ben Kennedy, chief magician Zygoat Creative Technical Services http://www.zygoat.ca ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Modal-loop Event-handling question
On May 1, 2012, at 12:30 PM, Motti Shneor wrote: > To avoid the crash, we tried to defer the "endSheet" via > "performSelecor:@selector(closeAnyOpenSheet) afterDelay:0.0". This prevents > the releasing of the dialog before the "mouseUp" event is received. However, > when "mouseUp" event comes, the didEndSelector is called for the sheet-alert > (before our deferred "endSheet" has a chance to happen), and then we face > another problem --- we try to accomplish user command, in a dead context. There are always going to be race conditions like this — the user can always press a button at exactly the same time something asynchronously makes the button meaningless. Your code just has to deal with it safely. Presumably something underneath will return a kSessionClosedError, and the UI code will just ignore it because the sheet’s gone already. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Minimal document-based app
On May 1, 2012, at 12:46 PM, Wade Tregaskis wrote: > Actually, there are a lot of commercial developers who hard-code their entire > UIs. I'm at something of a loss to see why myself, but they do it, and they > swear it's the best way. Ironically, one of the reasons often given is > "easier internationalisation" vs xibs. > Though this does happen more often with iOS than Mac OS, from what I've seen. > There may be some paradigms refusing to shift with ex- or co-Android > developers. Nonetheless it's demonstrably possible. I haven’t heard of it with any Mac apps, except for ugly Qt or Java apps. It’s kind of understandable on iOS because user interfaces tend to be simpler (especially since windows never have to resize) and a lot of apps use custom UI elements instead of sticking with the standard ones. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: No validation with a bound NSTableView and custom NSFormatter
On May 1, 2012, at 14:23 , Ben Kennedy wrote: > I have an NSTableView whose data source is bound to an NSArrayController. To > one of its columns (displaying a custom type) I have attached a custom > NSFormatter subclass. The NSFormatter correctly returns NO from > getObjectValue:forString:error: if the supplied string is not acceptable. > Despite this, however, validation is not enforced; when tabbing out of the > field, the table view carries on and just assigns a null value to the > corresponding property. Double-check that "Validates immediately" is checked for the binding. Counter-intuitively, this doesn't mean "immediately" in the sense of every keystroke, but "immediately" in the sense of when editing ends. If it's not checked, validation is presumably deferred until an entire view's worth of fields has been entered. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: No validation with a bound NSTableView and custom NSFormatter
On May 1, 2012, at 2:47 PM, Quincey Morris wrote: > On May 1, 2012, at 14:23 , Ben Kennedy wrote: > >> I have an NSTableView whose data source is bound to an NSArrayController. >> To one of its columns (displaying a custom type) I have attached a custom >> NSFormatter subclass. The NSFormatter correctly returns NO from >> getObjectValue:forString:error: if the supplied string is not acceptable. >> Despite this, however, validation is not enforced; when tabbing out of the >> field, the table view carries on and just assigns a null value to the >> corresponding property. > > Double-check that "Validates immediately" is checked for the binding. > Counter-intuitively, this doesn't mean "immediately" in the sense of every > keystroke, but "immediately" in the sense of when editing ends. If it's not > checked, validation is presumably deferred until an entire view's worth of > fields has been entered. That seems to be at odds with the Bindings documentation: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaBindings/Concepts/MessageFlow.html The validation should be triggered as soon as the text field tries to commit editing. --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: No validation with a bound NSTableView and custom NSFormatter
On May 1, 2012, at 14:55 , Kyle Sluder wrote: > That seems to be at odds with the Bindings documentation: > https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaBindings/Concepts/MessageFlow.html > > The validation should be triggered as soon as the text field tries to commit > editing. That's what I meant by "when editing ends". The point was that validation doesn't occur keystroke by keystroke when "Validates immediately" is checked, even though it would be a reasonable guess from the title of the checkbox. If "Validates immediately" is *not* checked, no automatic verification occurs at any time. In that case, I assume, you're expected to trigger validation of all relevant fields manually at some point. (In the flow chart you referred to, there's no mention of validation except at Step 3.) ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: No validation with a bound NSTableView and custom NSFormatter
On 01 May 2012, at 2:47 pm, Quincey Morris wrote: > Double-check that "Validates immediately" is checked for the binding. Thanks for the reply Quincey. I confess to have mis-described my situation somewhat: while most columns were bound, several instead used the classical NSTableViewDataSource style, including the one for which I'm having the validation trouble. Sure enough, when I connect a binding for that column, the formatter-imposed validation now works -- regardless of whether "validates immediately" is in force or not, contrary to your suggestion. (I was certain that I had tested that already, but apparently I didn't.) However, the reasons I'm serving data for this column programatically are a) to offset the displayed value according to a document-level property (when the data set is in a "read-only" mode), and b) to be able to calculate and apply a related change to other columns when the current value is modified. Before I started using NSArrayController or bindings, validation used to work. There must be something else I have overlooked here. Why is validation failing for the non-binding (NSTableViewDataSource-backed) columns? Additionally: for a bound column, my understanding is that validate:error: should be called against the object to check validity (at least in the absence of an attached formatter). However, it doesn't. Is there a prerequisite I am failing to satisfy? thanks, -ben -- Ben Kennedy, chief magician Zygoat Creative Technical Services http://www.zygoat.ca ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSTableview tooltip bug?
I have an NSTableview column where each cell contains a file name. I use tooltips (addToolTipRect and NSToolTipOwner protocol) to show the complete path to the file when the user hovers the mouse over the cell. This works fine unless the name of the file exceeds the column width - 3 pixels. i.e. if the width of the text for the cell is greater than (column width - 3) I get a strange behaviour: the correct tooltip flashes briefly in the usual place relative to the cell, then the cell itself becomes highlighted with a bright yellow background. If the text width is greater than the cell width the the highlighted rectangle extends over the column boundary, so I guess it is the enclosing rectangle of the cell's text that is highlighted. I created a category on NSString to define a truncated string method where I remove characters from the middle of the string to fit it into a specified width. My workaround to this problem was to specify the column width - 3 as the width I wanted for the truncated string. Has anyone else seen this? Is it a known bug? Thanks, Don Don Hall Apps & More Software Design, Inc. d...@appsandmore.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: No validation with a bound NSTableView and custom NSFormatter
On May 1, 2012, at 16:23 , Ben Kennedy wrote: > I confess to have mis-described my situation somewhat: while most columns > were bound, several instead used the classical NSTableViewDataSource style, > including the one for which I'm having the validation trouble. Sure enough, > when I connect a binding for that column, the formatter-imposed validation > now works -- regardless of whether "validates immediately" is in force or > not, contrary to your suggestion. (I was certain that I had tested that > already, but apparently I didn't.) > > However, the reasons I'm serving data for this column programatically are > > a) to offset the displayed value according to a document-level property (when > the data set is in a "read-only" mode), and > > b) to be able to calculate and apply a related change to other columns when > the current value is modified. > > Before I started using NSArrayController or bindings, validation used to > work. There must be something else I have overlooked here. Why is > validation failing for the non-binding (NSTableViewDataSource-backed) columns? > > Additionally: for a bound column, my understanding is that > validate:error: should be called against the object to check validity > (at least in the absence of an attached formatter). However, it doesn't. Is > there a prerequisite I am failing to satisfy? I'm not aware that KVC-style validation ever happens automatically *except* for bindings that have have "Validates immediately" checked. This idea is supported by the KVC documentation: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/Validation.html#//apple_ref/doc/uid/20002173-CJBDBHCB AFAIK, the validation performed by a number formatter is limited to its own internal understanding (modified by the properties you set) of what a valid number looks like. I don't see how it could know what validate: method to call. OTOH, if your bindings-based validation isn't working at all, then there's also some other factor at play here. It's worth triple-checking that you haven't misspelled a property name or a method name, causing the validation method to no longer match the property. The other factor with validation methods is that the presence of a formatter changes what class of object the validation receives. Without any formatter, it gets a NSString (from a text field UI element). With a number formatter, it gets a NSNumber. Depending on how the validation method is coded, it might be doing the wrong thing if it gets an object of the "wrong" class. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Concealing an app from DTrace
I found this old message: http://lists.apple.com/archives/cocoa-dev/2010/Mar/msg01042.html in which stated: If you think this is going to help you avoid piracy, it's not. OS X has a flag (PT_DENY_ATTACH) that the kernel checks for when a debugger asks to attach to a process. If that flag is set, the kernel refuses to allow the debugger to attach. iTunes famously does this to prevent people from inspecting the operations of the DRM system. It's a trivial matter to patch the kernel to not respect this flag, I was just wondering if this is still true or true in general...that it is not possible to conceal an application from DTrace. 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Concealing an app from DTrace
On May 1, 2012, at 6:04 PM, Eric Gorr wrote: > I found this old message: > >http://lists.apple.com/archives/cocoa-dev/2010/Mar/msg01042.html > > in which stated: > >If you think this is going to help you avoid piracy, it's not. OS X >has a flag (PT_DENY_ATTACH) that the kernel checks for when a debugger >asks to attach to a process. If that flag is set, the kernel refuses >to allow the debugger to attach. iTunes famously does this to prevent >people from inspecting the operations of the DRM system. It's a >trivial matter to patch the kernel to not respect this flag, > > I was just wondering if this is still true or true in general...that it is > not possible to conceal an application from DTrace. It is true and will be true as long as your are able to compile your own kernel. Think about it. --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Concealing an app from DTrace
Thanks Kyle. Is that the only way? Or is there something easier that would bypass the flag? In my case, I am not sure i would be concerned if a custom kernel was required. On May 1, 2012, at 9:28 PM, Kyle Sluder wrote: > On May 1, 2012, at 6:04 PM, Eric Gorr wrote: > >> I found this old message: >> >> http://lists.apple.com/archives/cocoa-dev/2010/Mar/msg01042.html >> >> in which stated: >> >> If you think this is going to help you avoid piracy, it's not. OS X >> has a flag (PT_DENY_ATTACH) that the kernel checks for when a debugger >> asks to attach to a process. If that flag is set, the kernel refuses >> to allow the debugger to attach. iTunes famously does this to prevent >> people from inspecting the operations of the DRM system. It's a >> trivial matter to patch the kernel to not respect this flag, >> >> I was just wondering if this is still true or true in general...that it is >> not possible to conceal an application from DTrace. > > It is true and will be true as long as your are able to compile your own > kernel. Think about it. > > --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: No validation with a bound NSTableView and custom NSFormatter
On 01 May 2012, at 5:25 pm, Quincey Morris wrote: > I'm not aware that KVC-style validation ever happens automatically *except* > for bindings that have have "Validates immediately" checked. Thanks for clarifying that -- I believe you're right. > AFAIK, the validation performed by a number formatter is limited to its own > internal understanding (modified by the properties you set) of what a valid > number looks like. I don't see how it could know what validate: method > to call. What I meant was that since the formatter's statement of invalidity seemed to be ignored by the table view, I was then expecting the NSTableView machinery to at least call validate: on its data source -- and indeed it does, if both a binding is configured and "validates immediately" is checked. (Of course in retrospect this only makes sense for bindings, since in a NSTableViewDataSource setup there is no knowledge of the data model except within the data source's tableView:objectValueForTableColumn:... and tableView:setObjectValue:... methods.) The issue I'm still having is that non-bound columns (i.e., those controlled by the latter two NSTableViewDataSource methods) are not enforcing validity when the attached formatter returns NO from getObjectValue:forString:errorDescription:. cheers, b -- Ben Kennedy, chief magician Zygoat Creative Technical Services http://www.zygoat.ca ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: No validation with a bound NSTableView and custom NSFormatter
On May 1, 2012, at 19:20 , Ben Kennedy wrote: > The issue I'm still having is that non-bound columns (i.e., those controlled > by the latter two NSTableViewDataSource methods) are not enforcing validity > when the attached formatter returns NO from > getObjectValue:forString:errorDescription:. I don't know that I've ever had to deal with this specific scenario, but examination of the documentation leads to the following observations: 1. You can implement a table view delegate that conforms to the NSTableViewDelegate protocol. 2. That's a sub-protocol of the NSControlTextEditingDelegate protocol. 3. That protocol has a method 'control:isValidObject:'. 4. The documentation of that method: > https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/NSControlTextEditingDelegate_Protocol/Reference/Reference.html#//apple_ref/occ/intf/NSControlTextEditingDelegate says this: > "This method gives the delegate the opportunity to validate the contents of > the control’s cell (or selected cell). In validating, the delegate should > check the value in the object parameter and determine if it falls within a > permissible range, has required attributes, accords with a given context, and > so on. Examples of objects subject to such evaluations are an NSDate object > that should not represent a future date or a monetary amount (represented by > an NSNumber object) that exceeds a predetermined limit." That seems like what you want, if you query the formatter directly from this delegate method. Whether NSTableView has an automated mechanism for querying the formatter itself, I don't know, and I can't find any documentation that suggests it might. I bet there's an easier answer staring us right in the face. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: No validation with a bound NSTableView and custom NSFormatter
On 01 May 2012, at 7:42 pm, Quincey Morris wrote: > 3. That protocol has a method 'control:isValidObject:'. > >> "This method gives the delegate the opportunity to validate the contents of >> the control’s cell (or selected cell). > > That seems like what you want, if you query the formatter directly from this > delegate method. I hadn't noticed that one before. However, for some reason, it does not get called on my delegate. > Whether NSTableView has an automated mechanism for querying the formatter > itself, I don't know, and I can't find any documentation that suggests it > might. Well, the NSControlTextEditingDelegate protocol also provides 'control:didFailToFormatString:errorDescription:', which seems to be to the point of what I want: > Invoked when the formatter for the cell belonging to the specified control > cannot convert a string to an underlying object. > > Return Value: YES if the value in the string parameter should be accepted as > is; otherwise, NO if the value in the parameter should be rejected. And unlike control:isValidObject:, it does get called on my delegate. Unfortunately, my return value of NO seems to be ignored. The thing about all this is that a few revs back, when I was using a dumb array with NSTableViewDataSource and no bindings, I was getting the validation behaviour for free. Now it's gone. I guess I should re-trace my steps and try to figure out what subtle critical difference I've introduced. cheers, b -- Ben Kennedy, chief magician Zygoat Creative Technical Services http://www.zygoat.ca ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: No validation with a bound NSTableView and custom NSFormatter
On May 1, 2012, at 20:09 , Ben Kennedy wrote: > The thing about all this is that a few revs back, when I was using a dumb > array with NSTableViewDataSource and no bindings, I was getting the > validation behaviour for free. Now it's gone. I guess I should re-trace my > steps and try to figure out what subtle critical difference I've introduced. When you bind one or more table columns to an array controller, the table view automatically binds its own content binding to the array controller (presumably with some heuristic for choosing one out of several, if you happened to bind different columns different ways). It doesn't seem impossible that the table view honors cell formatter errors only when its content binding isn't used (i.e. pure data source for all columns). That would explain the earlier behavior. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Concealing an app from DTrace
> Is that the only way? Or is there something easier that would bypass the flag? There are several that I know of. But my question first, to you, is why? I can tell you now that you can't reliably defend against all approaches. What you can do is make things really awkward for yourself for debugging, slightly awkward for profiling, and problematic for your users as they fail to get normal system behaviours like crash reporting. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Concealing an app from DTrace
On Tue, May 1, 2012 at 6:28 PM, Kyle Sluder wrote: >> I was just wondering if this is still true or true in general...that it is >> not possible to conceal an application from DTrace. > On May 1, 2012, at 6:04 PM, Eric Gorr wrote: > It is true and will be true as long as your are able to compile your own > kernel. Think about it. Even if you couldn't compiler your own kernel there are all kinds of ways to defeat this: - Hot-Patch the running kernel by editing its memory space with a kernel debugger or even just a hex editor. - Load a device driver (Kernel Extension in the case of iOS and OS X) that does the hot-patching. - Patch the executable binary of the program that you want to crack, by writing some No-Op instructions over the code that sets that flag. - Build from source any of the libraries that are in the call chain from the attempt to set the flag to the context switch into the kernel. - Replace any of those libraries at runtime, when they dynamic libraries are linked, in just the same way as Guard Malloc replaces the regular memory allocation library. - Rather than replace a library, insert a "shim", that is, what appears to the app to be a library, but is just a thin veneer that calls through to the regular library, but in certain routines it either alerts the input parameters, the output results, or it just returns immediately when called rather than calling down to lower levels. When I was at Working Software in the early nineties, most of our products were what the company founder describes as "Virus-Like Hacks", with the difference that our products' users wanted them on theirs Macs, paid good money for them, and they were packaged in full-color boxes with attractive, well-written manuals. -- Don Quixote de la Mancha Dulcinea Technologies Corporation Software of Elegance and Beauty http://www.dulcineatech.com quix...@dulcineatech.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Nil and nil Macro Conflict
Are not both Objective-C and C++, as well as Objective-C++ case-sensitive? If so, Nil and nil should be different symbols. If they should be, and really are different symbols, but still conflict somehow, then you've actually got a different problem than you think you do. Do Not Let The Sun Go Down Until You've Read John Lakos' excellent book "Large Scale C++ Software Design", published by Addison-Wesley. Much of what he proposes will contribute to the solution of your conflicting symbol problem. Even if one's project isn't written in C++, even if one does not have a clue about C++ it's quite likely there is something in Lakos' text that will help one out in a substantial way. Lakos' employer Mentor Graphics - a leading Electronic Design Automation (EDA) vendor - was one of the very first adopters of one of the very first releases of the C++ programming language. Their first attempts at writing EDA tools in C++ failed miserably, with their "finished" programs being huge, bug-laden, crashy and leaky rats' nests that they had no hope of ever debugging. EDA tools have a lot of source; the computers of the day would take days on end to do a single build! Rather than abandon C++, Lakos and his people figured out how to write C++ the way C++ wants to be written, with "Large Scale C++ Software Design" being the written report of what they figured out. That is, Bjarne Stroustrup and his people at AT&T figured out the Computer Science of C++. John Lakos and his people at AT&T figure out C++'s Software Engineering. It's important to understand that Software Engineering and Computer Science are COMPLETELY different things! Primary among Lakos recommendations is that one should not create just one single header file - allegedly "for convenience" - that client coders #include from everywhere. He states all manner of good reasons for not doing that. Long, long before I read his book, among my main practices at many of the coding shops where I worked was breaking up just such monolithic headers into much smaller headers, so that each source or intervening header could #include just what it needed. Note that Apple's SDK engineers are the worst offenders with this, with "#include ", "#include " and so on. Quite a long time ago I figured out how to get the ZooLib C++ Cross-Platform Application Framework to build _without_ using #include , only to be informed by some Apple engineer - who undoubtably spoke with authority - that Carbon was not at all guaranteed to even work if one #included individual framework headers, rather than just the top-level header. Another of Lakos' recommendations, which apply even for languages that use no header files, is to "levelize" your codebase. That is, a very poorly structured codebase will have most modules depending in some way on most other modules. You'll find that you'll never get the bugs out of that code. You'll also find that it's very difficult for newly-hired engineers to understand enough of your codebase to begin working productively at your company. The dependencies in a poorly levelized program will resemble the "string art" that was so popular in the late sixties and early seventies. We were heavily into string art during my elementary school days. One drives a bunch of finishing nails into a piece of wood, spaced evenly say in an elliptical shape. Then one ties some brightly colored string to one nail, stretches the string across the middle of the ellipse, around another nail, back across the middle and so on, finally tying it off after wrapping around a few other nails. Every nail is connected to at least a few other nails by several pieces of string. Close examination of most of your codebases is quite likely to find that the dependencies of your compilation units on each other is just like the connections between pairs of nails by strings! By "module" Lakos means a "compilation unit", that is, a source file and everything that source file depends on to build - its headers, their headers and so on. The first step in levelizing your codebase is to edit the source of each module just so that it is broken into several new smaller and simpler pieces. For object-oriented code, permit no more than one class per source file or header. Occasionally one has "helper" or C++ friend classes that are required for a particular class to work. If those classes will _never_ be used by other than the main class they contribute to, it would be permissible to place them in the SOURCE FILE but not in the header file for that class. One places them in the source rather than the header so they are totally invisible to any other source. Similarly the headers for templates should be split into multiple files so that unrelated templates are in separate header files. Start with the simplest of your classes, and get just those classes to build all by themselves, to generate object files but not a full executable. For templates, create some manner of test driver that
Re: Nil and nil Macro Conflict
On May 1, 2012, at 7:16 PM, Greg Parker wrote:
> On May 1, 2012, at 7:10 AM, Andreas Grosam wrote:
>> Hm, the library is a header only template library - namely its spirit (from
>> boost), so my chances to never include this library are zero ;)
>>
>> Basically, I need something like the following to compile:
>>
>> // file foo.m:
>>
>> #include
>>
>> namespace nm {
>> struct nil {};
>> struct Nil {};
>> }
>>
>> NSObject* o = nil;
>
> If you never need to use boost's nil in your own code, you can carefully
> order your includes so the boost headers are always first.
>
> #include // uses nil
> #include// #defines nil but doesn't affect
> the boost header
> NSObject *o = nil; // uses objc's nil
I thought about this, too. But Foundation.h is often in a Prefix header, as in
my case. So this would require to include the boost header(s) in the prefix
header as well. It's a viable solution, since I control the prefix header. It
makes the project setup a bit fragile, though (removing the prefix will cause
the project to not compile anymore).
But as you too would suggest it, and it seems this is still the least intrusive
solution to this issue, I'll give it a try.
>
> If you do need to use boost's nil in your own code, you can use macro tricks
> to rename their nil.
>
> #define nil boost_nil
> #include
> #undef nil
> #include
> // now you have objc's nil and boost::boost_nil
That's a handy trick - still I need to put the boost header in front of the
Foundation header within the prefix file.
Thank you Greg, and thank you all others for the tips!
Regards
Andreas
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
