Re: Using fake properties
On Aug 16, 2013, at 22:51 , Ken Thomases k...@codeweavers.com wrote: Dot syntax is just syntactic sugar for accessing properties through the accessors. I agree with everything you said in your reply, except for a quibble about this one sentence. Dot notation is *not* syntactically equivalent to method notation, not in all cases. Specifically, for dot notation to be syntactically legal, the class of the object to the left of the dot must have a visible declaration of the property name to the right of the dot (using either of the 2 ways of declaring properties). Method notation is additionally legal when the receiver is of type 'id' and the named method is declared in any class that's visible at that point in the compilation. Another way of saying this is that method notation can represent full polymorphism, but dot notation cannot. ___ 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: After popping view controller, table view scrolls sideways
On 17 Aug, 2013, at 1:18 PM, Kyle Sluder k...@ksluder.com wrote: Cargo cults are insidious because they often start out as legitimate solutions to real problems, but become community wisdom by way of similarity. I don't doubt your solution to your problem (but would love the opportunity to verify it for myself). I'm just concerned about Roland adopting it because it smells enough like your problem. --Kyle Sluder That's fair enough. One thing Rick could try is breakpointing in his override of setContentSize:, if the stack trace at the point it sets the size incorrectly is called something like _resetToOriginalContentSize .. that is at least the same method which has been resetting mine incorrectly after it earlier set it correctly. I don't have any push/pop on mine either, it's a one-screen app. I never got further with it, just could not find anything unusual I was doing which caused it. I've tested one of them with iOS7 this morning, don't see the issue, rechecked it on 6, still did. I'm holding out a little hope this is fixed, or the edge case I got myself into has been sorted out. Other two projects will take a bit more work to iOS7-ify but I should get on with it anyway. ___ 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: After popping view controller, table view scrolls sideways
On Aug 16, 2013, at 23:30 , Roland King r...@rols.org wrote: That's fair enough. One thing Rick could try is breakpointing in his override of setContentSize:, if the stack trace at the point it sets the size incorrectly is called something like _resetToOriginalContentSize .. that is at least the same method which has been resetting mine incorrectly after it earlier set it correctly. I don't have any push/pop on mine either, it's a one-screen app. I never got further with it, just could not find anything unusual I was doing which caused it. I did put a breakpoint there. It gets called with a bad size in two places: during my call to -selectRowAtIndex path on the first table view, and again when popping the pushed view controller. The second of these two calls is in _resizeWithOldSuperviewSize. I've tested one of them with iOS7 this morning, don't see the issue, rechecked it on 6, still did. I'm holding out a little hope this is fixed, or the edge case I got myself into has been sorted out. Other two projects will take a bit more work to iOS7-ify but I should get on with it anyway. Bah. I'm getting so fed up with Apple not fixing bugs in dot releases. -- Rick ___ 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: GNUstep Kickstarter Project
I am in. Paul Franz On Aug 15, 2013, at 8:02 PM, Reaves, Timothy trea...@silverfieldstech.com wrote: No, not really. On Thu, Aug 15, 2013 at 5:02 PM, Lars Sonchocky-Helldorf lars.sonchocky-helld...@hamburg.de wrote: Hi list, I've got this from the lead developer of GNUstep, maybe some of you are interested in this. cheers, Lars Anfang der weitergeleiteten E-Mail: Von: Gregory Casamento greg.casame...@gmail.com Datum: 12. August 2013 22:13:54 MESZ An: Discuss-gnustep Discuss discuss-gnus...@gnu.org Betreff: GNUstep Kickstarter Project Hey guys, I've launched a kickstarter project in the hopes of getting some time to work exclusively on GNUstep in order to try to address some of the issues we have surrounding API completeness, documentation issues, etc..., here it is: http://www.kickstarter.com/projects/203272607/gnustep-project Thanks, GC -- Gregory Casamento Open Logic Corporation, Principal Consultant yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) http://www.gnustep.org http://heronsperch.blogspot.com ___ Discuss-gnustep mailing list discuss-gnus...@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ 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/treaves%40silverfieldstech.com This email sent to trea...@silverfieldstech.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/paul.p.franz%40gmail.com This email sent to paul.p.fr...@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: predefined macro iOS vs OS X
On Aug 16, 2013, at 19:04 , Kyle Sluder k...@ksluder.com wrote: On Aug 16, 2013, at 12:41 PM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: On 16 Aug 2013, at 22:59, Kyle Sluder k...@ksluder.com wrote: Xcode does know this. But if you're building for 32-bit OS X, it will correctly complain. When I build for Mac OS X CGRect is accepted. But when I build for iOS then NSRect creates Use of undeclared identifier NSRect did you mean NSSet Stop using NSRect in your method prototypes and just use CGRect. This is certainly pragmatic, effective advice. PetPeeve However…if you care as much about dependency management as I do (and chances are you don’t), and don’t have a direct dependency on CoreGraphics in that code (and chances are you do), then this is slightly stomach-churning, in addition to pragmatic and effective. Pulling in a dependency on CoreGraphics just to get those types is awful, in addition it makes it harder to make code that works on both Mac OS X and iOS. After going back and forth on this for quite some time, I decided to standardize on the Foundation types and have a tiny compatibility layer, which you can find on github: https://github.com/mpw/MPWFoundation/blob/master/Classes/PhoneGeometry.h /PetPeeve ___ 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: predefined macro iOS vs OS X
On Aug 16, 2013, at 19:04 , Kyle Sluder k...@ksluder.com wrote: On Aug 16, 2013, at 12:41 PM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: On 16 Aug 2013, at 22:59, Kyle Sluder k...@ksluder.com wrote: Xcode does know this. But if you're building for 32-bit OS X, it will correctly complain. When I build for Mac OS X CGRect is accepted. But when I build for iOS then NSRect creates Use of undeclared identifier NSRect did you mean NSSet Stop using NSRect in your method prototypes and just use CGRect. This is certainly pragmatic, effective advice. PetPeeve However…if you care as much about dependency management as I do (and chances are you don’t), and don’t have a direct dependency on CoreGraphics in that code (and chances are you do), then this is slightly stomach-churning, in addition to pragmatic and effective. Pulling in a dependency on CoreGraphics just to get those types is awful, in addition it makes it harder to make code that works on both Mac OS X and iOS. After going back and forth on this for quite some time, I decided to standardize on the Foundation types and have a tiny compatibility layer, which you can find on github: https://github.com/mpw/MPWFoundation/blob/master/Classes/PhoneGeometry.h /PetPeeve ___ 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: predefined macro iOS vs OS X
I actually got one step (sorry for the pun) ahead as limited to what Cocoa’s Foundation and GNUstep’s Base have in common. That allows me to create code-compatible programs that builds and runs under both OS X (or iOS) and Linux. (In my company everything starts off in Objective-C and now with this limitation the porting cost is dropping drastically.) Example: CGIKit: https://github.com/xcvista/CGIKit (a FastCGI library for Objective-C, CGIKit.xcodeproj will build on OS X with embedded libfcgi and GNUmakefile will build on Linux with GNUstep with external libfcgi.) On Aug 17, 2013, at 23:52, Marcel Weiher marcel.wei...@gmail.com wrote: On Aug 16, 2013, at 19:04 , Kyle Sluder k...@ksluder.com wrote: On Aug 16, 2013, at 12:41 PM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: On 16 Aug 2013, at 22:59, Kyle Sluder k...@ksluder.com wrote: Xcode does know this. But if you're building for 32-bit OS X, it will correctly complain. When I build for Mac OS X CGRect is accepted. But when I build for iOS then NSRect creates Use of undeclared identifier NSRect did you mean NSSet Stop using NSRect in your method prototypes and just use CGRect. This is certainly pragmatic, effective advice. PetPeeve However…if you care as much about dependency management as I do (and chances are you don’t), and don’t have a direct dependency on CoreGraphics in that code (and chances are you do), then this is slightly stomach-churning, in addition to pragmatic and effective. Pulling in a dependency on CoreGraphics just to get those types is awful, in addition it makes it harder to make code that works on both Mac OS X and iOS. After going back and forth on this for quite some time, I decided to standardize on the Foundation types and have a tiny compatibility layer, which you can find on github: https://github.com/mpw/MPWFoundation/blob/master/Classes/PhoneGeometry.h /PetPeeve ___ 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/xcvista%40me.com This email sent to xcvi...@me.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
editing text part in a custom NSTextFieldCell (of a NSTableView)
Hi,
I have a NSTableView and I'm setting a particular column to have a custom
NSTextFieldCell subclass object as its cell.
For this I'm doing in awakeFromNib:
TableViewListCell *aTableViewListCell3 = [[[TableViewListCell alloc] init]
autorelease];
[[tableViewPresetsMainList tableColumnWithIdentifier:COLUMN_ID_DESC]
setDataCell:aTableViewListCell3];
[[[tableViewPresetsMainList tableColumnWithIdentifier:COLUMN_ID_DESC]
dataCell] setEditable:YES];
The object value returned for this cell in method, - (id)tableView:(NSTableView
*)aTableView objectValueForTableColumn:(NSTableColumn *)aTableColumn
row:(NSInteger)rowIndex, is a NSMutableDictionary containing the text to
display in the cell as well an NSImage object to display in the cell.
Then in NSTextFieldCell subclass TableViewListCell, in method, -
(void)drawInteriorWithFrame:(NSRect)theCellFrame inView:(NSView
*)theControlView, I'm drawing the image (32x32 pixels) and then text to the
right side of image, after obtaining these image and text from the cell's
objectValue, which is the NSMutableDictionary.
Now the problem is that when I click on the cell for editing the text
displayed, the field that pops up shows the value same as description of the
mutable dictionary.
e.g.
{
Description = Preset #0;
Icon = NSImage 0x1001a3ab0 Name=Presets Size={32, 32} Reps=(\n
\NSBitmapImageRep 0x1001f75e0 Size={32, 32} ColorSpace=Device RGB colorspace
BPS=8 BPP=32 Pixels=32x32 Alpha=YES Planar=NO Format=2
CurrentBacking=CGImageRef: 0x1001f76f0 CGImageSource=0x1005a48e0\\n);
}
Whereas I want to show and edit only the drawn name Preset #0,.
Also I want to set the editing field's rect to a smaller one, which I guess I
can do by over-riding the method, - (void)editWithFrame:(NSRect)aRect
inView:(NSView*)controlView editor:(NSText*)textObj delegate:(id)anObject
event:(NSEvent*)theEvent
Any suggestions?
Wishes,
Nick
___
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: predefined macro iOS vs OS X
Le 17 août 2013 à 17:55, Marcel Weiher marcel.wei...@gmail.com a écrit : On Aug 16, 2013, at 19:04 , Kyle Sluder k...@ksluder.com wrote: On Aug 16, 2013, at 12:41 PM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: On 16 Aug 2013, at 22:59, Kyle Sluder k...@ksluder.com wrote: Xcode does know this. But if you're building for 32-bit OS X, it will correctly complain. When I build for Mac OS X CGRect is accepted. But when I build for iOS then NSRect creates Use of undeclared identifier NSRect did you mean NSSet Stop using NSRect in your method prototypes and just use CGRect. This is certainly pragmatic, effective advice. PetPeeve However…if you care as much about dependency management as I do (and chances are you don’t), and don’t have a direct dependency on CoreGraphics in that code (and chances are you do), then this is slightly stomach-churning, in addition to pragmatic and effective. You don't have to add explicit dependency to anything as NSGeometry.h already does that for you. Importing Foundation.h is enough to use CGRect on both OS X and iOS. -- Jean-Daniel ___ 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: predefined macro iOS vs OS X
On Aug 17, 2013, at 18:03 , Maxthon Chan xcvi...@me.com wrote: On Aug 17, 2013, at 23:52, Marcel Weiher marcel.wei...@gmail.com wrote: On Aug 16, 2013, at 19:04 , Kyle Sluder k...@ksluder.com wrote: Stop using NSRect in your method prototypes and just use CGRect. This is certainly pragmatic, effective advice. PetPeeve However…if you care as much about dependency management as I do (and chances are you don’t), and don’t have a direct dependency on CoreGraphics in that code (and chances are you do), then this is slightly stomach-churning, in addition to pragmatic and effective. Pulling in a dependency on CoreGraphics just to get those types is awful, in addition it makes it harder to make code that works on both Mac OS X and iOS. After going back and forth on this for quite some time, I decided to standardize on the Foundation types and have a tiny compatibility layer, which you can find on github: https://github.com/mpw/MPWFoundation/blob/master/Classes/PhoneGeometry.h I actually got one step (sorry for the pun) ahead as limited to what Cocoa’s Foundation and GNUstep’s Base have in common. That allows me to create code-compatible programs that builds and runs under both OS X (or iOS) and Linux. (In my company everything starts off in Objective-C and now with this limitation the porting cost is dropping drastically.) Example: CGIKit: https://github.com/xcvista/CGIKit (a FastCGI library for Objective-C, CGIKit.xcodeproj will build on OS X with embedded libfcgi and GNUmakefile will build on Linux with GNUstep with external libfcgi.) Very cool, and I am definitely with you, though I have to admit I haven’t really kept in sync with GNUStep ( https://github.com/mpw/MPWFoundation/blob/master/GNUmakefile is a bit out of date), working more with Cocotron to get Linux compatibility. Cheers, Marcel ___ 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: predefined macro iOS vs OS X
Well I chose GNUstep for its longer history (it predates Cocoa, even OpenStep - in fact it is the second implementation of Application Kit, what would later become the libraries we now know as Foundation and AppKit, after NeXT.) and better ARC support. They have an impressive libobjc that combined what Apple and LLVM folks called libobjc4 (Objectve-C 2 runtime with ARC support) and libBlocksRuntime into one unit, and supports GCD very well. Also, LLVM folks ported what Apple contributed in LLDB debugger to support their runtime too. Also, they have rewrites of Core Foundation, Core Data, Core Graphics, WebObjects (in Objective-C) and more. On Aug 18, 2013, at 1:15, Marcel Weiher marcel.wei...@gmail.com wrote: On Aug 17, 2013, at 18:03 , Maxthon Chan xcvi...@me.com wrote: On Aug 17, 2013, at 23:52, Marcel Weiher marcel.wei...@gmail.com wrote: On Aug 16, 2013, at 19:04 , Kyle Sluder k...@ksluder.com wrote: Stop using NSRect in your method prototypes and just use CGRect. This is certainly pragmatic, effective advice. PetPeeve However…if you care as much about dependency management as I do (and chances are you don’t), and don’t have a direct dependency on CoreGraphics in that code (and chances are you do), then this is slightly stomach-churning, in addition to pragmatic and effective. Pulling in a dependency on CoreGraphics just to get those types is awful, in addition it makes it harder to make code that works on both Mac OS X and iOS. After going back and forth on this for quite some time, I decided to standardize on the Foundation types and have a tiny compatibility layer, which you can find on github: https://github.com/mpw/MPWFoundation/blob/master/Classes/PhoneGeometry.h I actually got one step (sorry for the pun) ahead as limited to what Cocoa’s Foundation and GNUstep’s Base have in common. That allows me to create code-compatible programs that builds and runs under both OS X (or iOS) and Linux. (In my company everything starts off in Objective-C and now with this limitation the porting cost is dropping drastically.) Example: CGIKit: https://github.com/xcvista/CGIKit (a FastCGI library for Objective-C, CGIKit.xcodeproj will build on OS X with embedded libfcgi and GNUmakefile will build on Linux with GNUstep with external libfcgi.) Very cool, and I am definitely with you, though I have to admit I haven’t really kept in sync with GNUStep ( https://github.com/mpw/MPWFoundation/blob/master/GNUmakefile is a bit out of date), working more with Cocotron to get Linux compatibility. Cheers, Marcel ___ 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: predefined macro iOS vs OS X
On Aug 16, 2013, at 10:04, Kyle Sluder k...@ksluder.com wrote: On Aug 16, 2013, at 12:41 PM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: On 16 Aug 2013, at 22:59, Kyle Sluder k...@ksluder.com wrote: Xcode does know this. But if you're building for 32-bit OS X, it will correctly complain. When I build for Mac OS X CGRect is accepted. But when I build for iOS then NSRect creates Use of undeclared identifier NSRect did you mean NSSet Stop using NSRect in your method prototypes and just use CGRect. Or just define NS_BUILD_32_LIKE_64. Doing so will cause NSRect to be defined as a typedef for CGRect. -- Clark Smith Cox III clark@apple.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: predefined macro iOS vs OS X
On Aug 17, 2013, at 4:52 PM, Clark Smith Cox III clark@apple.com wrote: On Aug 16, 2013, at 10:04, Kyle Sluder k...@ksluder.com wrote: Stop using NSRect in your method prototypes and just use CGRect. Or just define NS_BUILD_32_LIKE_64. Doing so will cause NSRect to be defined as a typedef for CGRect. Gerriet still needs to use CGRect in his APIs because he's compiling them for both iOS and Mac. And as the name implies, NS_BUILD_32_LIKE_64 is unnecessary if you're not targeting 32-bit OS X. --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
-[NSBundle URLForResource:withExtension:subdirectory] is case-sensitive
I just filed the following radar and I thought I'd share it. (Of course, if this is one of those things that everybody knows, please be kind.) rdar://14766402 -[NSBundle URLForResource:withExtension:subdirectory] is case sensitive Create a file named Index.html (notice the leading 'I' is capitalized). Place the file somewhere inside the application bundle. Examine the result of the following statement (where self.helpFolderName describes the folder containing the file). NSURL * indexURL = [[NSBundle mainBundle] URLForResource:@index withExtension:@html subdirectory:self.helpFolderName]; I expect indexURL to be non-null (and to contain the appropriate URL). However, in actual devices, this function returns nil; on the IOS Simulator it returns a valid URL. If I change the resource name to exactly match the actual file name (i.e., change either the filename or the argument to exactly match) I get a correct result on both the actual and simulated devices. Cheers, Rick Aurbach Aurbach Associates, Inc. ___ 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: -[NSBundle URLForResource:withExtension:subdirectory] is case-sensitive
On Sat, Aug 17, 2013 at 6:03 PM, Rick Aurbach r...@aurbach.com wrote: I expect indexURL to be non-null (and to contain the appropriate URL). However, in actual devices, this function returns nil; on the IOS Simulator it returns a valid URL. If I change the resource name to exactly match the actual file name (i.e., change either the filename or the argument to exactly match) I get a correct result on both the actual and simulated devices This is a known limitation of the Simulator. On OS X the filesystem is case preserving, but not case sensitive. Since the Simulator runs on top of OS X it inherits this behavior. However, on iOS the filesystem is case sensitive. It's been this way since the beginning; you just have to watch out for 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: editing text part in a custom NSTextFieldCell (of a NSTableView)
On Aug 17, 2013, at 10:31 AM, Nick Rogers wrote:
I have a NSTableView and I'm setting a particular column to have a custom
NSTextFieldCell subclass object as its cell.
For this I'm doing in awakeFromNib:
TableViewListCell *aTableViewListCell3 = [[[TableViewListCell alloc] init]
autorelease];
[[tableViewPresetsMainList tableColumnWithIdentifier:COLUMN_ID_DESC]
setDataCell:aTableViewListCell3];
[[[tableViewPresetsMainList tableColumnWithIdentifier:COLUMN_ID_DESC]
dataCell] setEditable:YES];
The object value returned for this cell in method, -
(id)tableView:(NSTableView *)aTableView
objectValueForTableColumn:(NSTableColumn *)aTableColumn
row:(NSInteger)rowIndex, is a NSMutableDictionary containing the text to
display in the cell as well an NSImage object to display in the cell.
Then in NSTextFieldCell subclass TableViewListCell, in method, -
(void)drawInteriorWithFrame:(NSRect)theCellFrame inView:(NSView
*)theControlView, I'm drawing the image (32x32 pixels) and then text to the
right side of image, after obtaining these image and text from the cell's
objectValue, which is the NSMutableDictionary.
Now the problem is that when I click on the cell for editing the text
displayed, the field that pops up shows the value same as description of the
mutable dictionary.
e.g.
{
Description = Preset #0;
Icon = NSImage 0x1001a3ab0 Name=Presets Size={32, 32} Reps=(\n
\NSBitmapImageRep 0x1001f75e0 Size={32, 32} ColorSpace=Device RGB colorspace
BPS=8 BPP=32 Pixels=32x32 Alpha=YES Planar=NO Format=2
CurrentBacking=CGImageRef: 0x1001f76f0 CGImageSource=0x1005a48e0\\n);
}
Whereas I want to show and edit only the drawn name Preset #0,.
Also I want to set the editing field's rect to a smaller one, which I guess I
can do by over-riding the method, - (void)editWithFrame:(NSRect)aRect
inView:(NSView*)controlView editor:(NSText*)textObj delegate:(id)anObject
event:(NSEvent*)theEvent
Use a view-baed NSTableView instead. You won't even have to have an
NSTextFieldCell subclass, and you might even be able to use a vanilla
NSTableCellView. It's actually a better approach to your overall table issue,
IMHO.
HTH,
Keary Suska
Esoteritech, Inc.
Demystifying technology for your home or business
___
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: -[NSBundle URLForResource:withExtension:subdirectory] is case-sensitive
On Aug 17, 2013, at 7:29 PM, Stephen J. Butler stephen.but...@gmail.com wrote: This is a known limitation of the Simulator. On OS X the filesystem is case preserving, but not case sensitive. Since the Simulator runs on top of OS X it inherits this behavior. However, on iOS the filesystem is case sensitive. It's been this way since the beginning; you just have to watch out for it. You also need to be aware of this behavior if you're doing iCloud document syncing. --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: -[NSBundle URLForResource:withExtension:subdirectory] is case-sensitive
On Aug 17, 2013, at 6:29 PM, Stephen J. Butler wrote: On Sat, Aug 17, 2013 at 6:03 PM, Rick Aurbach r...@aurbach.com wrote: I expect indexURL to be non-null (and to contain the appropriate URL). However, in actual devices, this function returns nil; on the IOS Simulator it returns a valid URL. If I change the resource name to exactly match the actual file name (i.e., change either the filename or the argument to exactly match) I get a correct result on both the actual and simulated devices This is a known limitation of the Simulator. On OS X the filesystem is case preserving, but not case sensitive. Since the Simulator runs on top of OS X it inherits this behavior. It's worth noting that OS X can be configured to use a case-sensitive file system. That can be useful for testing. It's also something that you have to keep in mind as a Mac application developer. Your end users may be using a case-sensitive file system, so your app has to behave correctly. You have to watch out for inadvertent reliance on case-insensitivity sneaking into your code. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
