Re: tracking EXC_BAD_ACCESS error in applescript command
That was a copy of the original call stack before I subclass NSScriptCommand. If I subclass NSScriptCommand and call executeCommand from this subclass, then the crash occurs as before, but of course the call stack changes accordingly. Anyway I put breakpoints in my subclass' methods to make sure I get through them. I've found a workaround which anyway is the way I originally wanted scripting to work. I have the document return an object of (say) FooClass through the property foo. Then I declare an object-first command (say check) and implement the command handler in the FooClass class. Then the applescript statement : check foo of front document does work fine. So I can't find a way of doing check front document using NSScriptCommand's executeCommand but I can do so on an object contained by the document... Le 21 déc. 2009 à 03:19, Jerry Krinock a écrit : On 2009 Dec 20, at 13:50, François Guillet wrote: EXC_BAD_ACCESS error : #0 0x7fff86951466 in -[NSScriptCommand _sendToRemainingReceivers] () #1 0x7fff86951fe5 in -[NSScriptCommand executeCommand] () #2 0x7fff8696902e in -[NSScriptingAppleEventHandler handleCommandEvent:withReplyEvent:] () I implemented a subclass of NSScriptCommand used both for verb first or object first command : everything works fine, I can call [[self evaluatedReceivers] handleCommmand:self] from executeCommand without any problem. The EXC_BAD_ACCESS error, though, always happens if I try to call NSScriptCommand's executeCommand. Not sure about the crash, but if you've subclassed NSScriptCommand, should not your subclass name appear in the call stack shown above, instead of NSScriptCommand? In your sdef, have you specified your subclass to be the Cocoa Class of this command? ___ 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/francois.guillet%40wanadoo.fr This email sent to francois.guil...@wanadoo.fr François ___ 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: Localization strategies?
Just my 2c gained from translating UIs in french. Localized strings can show a great variation in length even among close languages such as english and french. Moreover, english allows for short sentence/syntax whereas french does not, at least not easily. From what I've seen, there are two strategies to adapt to different strings lengths : -a managed layout (not too bad but not perfect) -designing as many UI elements as locales (perfect but tedious). AFAIK Apple chose the second solution, so that's about the only way to go on this platform I suppose. Substitution of localized strings in english UI elements (eg dialogs) will result in either text being clipped out of labels, label frames too wide in english because they have to make way for other localized strings or localized strings too short to make sense because they have to fit. And sometimes, the syntax has to change anyway and the dialog has to be rethought somewhat. So all in all, specifically designing UI elements for each locale make sense if you want the best results. It is also time consuming and thus (probably) expensive. It's weird to see big companies fall into localization blunders. Pixar's Wall.E, for example, shows at some point in the movie the axiom ship Operation Manual which in french is translated as Manuel d'Opération, an easy translation except we never refer to operation manuals using this term (although it's grammatically correct). Le 21 déc. 2009 à 10:27, Symadept a écrit : Hi Ricky, Even in my one of the project I am doing the same. Localizable.strings (english) version shall have all the strings in Key-Value pair format, Hello = Hello; And you can keep the comment on top of the string /* Welcome text */. And you can have many IBOutlets to set the string at runtime, as you mentioned, with NSLocalizedString(@Hello, nil). Now you generate various language localizable.strings by Add Localization (mail me if you think you need more info) from XCode and change the file format to UTF16. Now these files shall still show you english. Now pass these files to Localization team and they shall simply copy paste the other version of the string in RHS of the corresponding files. If you go with multiple nib files for various locale, UI maintainance will become hectic. Hence you are in right track. All the best. Regards Mustafa Shaik On Mon, Dec 21, 2009 at 4:30 AM, Ricky Sharp rsh...@mac.com wrote: In getting quotes from many localization companies, I've found that some have different processes. For example, one company would prefer if I just provide .string files. During their QA process, they'll then run the app and look at everything in context. While generating .strings from nibs is easy to do, there's a problem in that there seems to be no method of putting contextual comments into a nib. And there's no way I would hand-edit comments in the generated .strings files. Thus, I'm wondering if it would ultimately be worth it to externalize all strings from my nibs and just put everything in my single .strings file. This will clearly involve me adding tons of IBOutlet ivars just so that at runtime I can set their text with NSLocalizedString APIs. I still plan on having separate nibs though for each language (to account for text bounds, font sizes, etc.) How have others tackled localization? ___ 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/symadept%40gmail.com This email sent to symad...@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: http://lists.apple.com/mailman/options/cocoa-dev/francois.guillet%40wanadoo.fr This email sent to francois.guil...@wanadoo.fr François ___ 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
tracking EXC_BAD_ACCESS error in applescript command
Hi All, I'm trying to implement an object-first command targeted at the document of a document based app. Doing so always results in the same EXC_BAD_ACCESS error : #0 0x7fff86951466 in -[NSScriptCommand _sendToRemainingReceivers] () #1 0x7fff86951fe5 in -[NSScriptCommand executeCommand] () #2 0x7fff8696902e in -[NSScriptingAppleEventHandler handleCommandEvent:withReplyEvent:] () #3 0x7fff86861156 in -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] () #4 0x7fff86860f86 in _NSAppleEventManagerGenericHandler () #5 0x7fff868b941e in _NSAppleEventManagerPreDispatchHandler () #6 0x7fff806fe292 in aeDispatchAppleEvent () #7 0x7fff806fe18b in dispatchEventAndSendReply () #8 0x7fff806fe095 in aeProcessAppleEvent () #9 0x7fff821f8879 in AEProcessAppleEvent () #10 0x7fff87e303d5 in _DPSNextEvent () #11 0x7fff87e2fb41 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #12 0x7fff87df5747 in -[NSApplication run] () #13 0x7fff87dee468 in NSApplicationMain () I posted at applescript-implement...@lists.apple.com and was replied that the error was likely due to over-releasing an object and wasn't a problem with applescript implementation per se. The problem is that the object first command calls a very simple method with no other object implied than the document which is properly retained. I implemented a subclass of NSScriptCommand used both for verb first or object first command : everything works fine, I can call [[self evaluatedReceivers] handleCommmand:self] from executeCommand without any problem. The EXC_BAD_ACCESS error, though, always happens if I try to call NSScriptCommand's executeCommand. Any idea on how can I further investigate this problem ? (10.6.2, XCode 3.2.1, NSZombie enabled) Thanks, François ___ 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
