How to display NSStrokeColorAttributeName on the NSColorPanel
When my 1st NSColorWell is active and I change the selection in my
NSTextView, both NSColorWell and NSColorPanel display the foreColor of the
selected tex. That's fine.
Now I have a second NSColorWell that should display the strokeColor (or any
other color) of the selected text. But I can't yet succeed. I my NSTextView
subclass I have coded, unsuccessfully:
- (void)textViewDidChangeSelection:(NSNotification*)aNotification
{
NSRange selRange = [self selectedRange], effRange;
NSDictionary*attributes = [self.textStorage
attributesAtIndex:selRange.location effectiveRange:&effRange];
if(attributes){
NSColor *strokeColor = [attributes
objectForKey:NSStrokeColorAttributeName];
if(strokeColor){
[oStrokeColorWell setColor:strokeColor];
}
}
}
Even if the strokeColor exists and gets set to the oStrokeColorWell, the
oStrokeColorWell still displays the foreColor. Any idea?
Regards
-- Leonardo
___
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: Legal Opinion on GCUndoManager
On 01 Feb 2014, at 01:02, Graham Cox wrote: > On 1 Feb 2014, at 4:32 am, Fritz Anderson wrote: >> If I were implementing the review process, my automated checker would run >> strings(1) on the binary, and flag the collision with private API. Under my >> notional process, the reviewer would have to reject, because he has no way >> of knowing how the selector is used; or, even if your use is innocent, >> whether it propagates down into the framework so the collision with private >> API happens anyway. > >> but if I’m right, the app would not simply sail through to acceptance. > > > Except that it does (so far, over several years), so the process must be > different from your notional one. > > To be on the safe side, I would prefer a cleaner way to handle this, but so > far Quincey's suggestions haven't borne fruit, though I don't properly > understand why. The problem seems clear enough: how to benignly swallow a > method invocation to a private method without actually defining the method on > the receiver. Implement one of the unhandledSelector methods and just have it return instead of erroring? But really, you’re fixing the letter of the law, not the intent: Apple’s point of prohibiting use of private API is to give them flexibility to refactor, rename and generally do unspeakable things with them without our code breaking. If Apple ever renamed that method, your interception would stop happening, and your class would break. It sounds like a safer solution would be to get Apple to either make this method public and make a promise of sorts that they’ll keep it working, or to get them to not even call it on your class (I didn't quite get the details, but I suppose they could check via respondsToSelector: before calling it?). Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to display NSStrokeColorAttributeName on the NSColorPanel
Hi Mike,
sure, the value of oStrokeColorWell is different than the forecolor.
Let's say I have the string "ocean" within the NSTextView. Its forecolor is
black, while the stroke color is red. I click between the "c" and the "e".
The oForeColorWell properly displays the black color and the
oStrokeColorWell properly displays the red color. Then I press the right
arrow key and go between "e" and "a". Now both the colorWells display the
black color. And more than what I see with my eyes, my log still displays
the stoke color is rgba(1, 0, 0, 1);
It seems that, since the oStrokeColorWell is active, it automatically gets
its color value from the selected text. I would like to override the method
from which it takes the color value, but I cannot guess which one it is.
I unsuccessfully tried - (NSColor*)textColor; And I even tried to not to
override the method below textViewDidChangeSelection. Same trouble.
Any idea?
Regards
-- Leonardo
> Da: Michael Babin
> Data: Sat, 01 Feb 2014 09:19:08 -0600
> A: Leonardo
> Oggetto: Re: How to display NSStrokeColorAttributeName on the NSColorPanel
>
> On Feb 1, 2014, at 3:37 AM, Leonardo wrote:
>
>> When my 1st NSColorWell is active and I change the selection in my
>> NSTextView, both NSColorWell and NSColorPanel display the foreColor of the
>> selected tex. That's fine.
>>
>> Now I have a second NSColorWell that should display the strokeColor (or any
>> other color) of the selected text. But I can't yet succeed. I my NSTextView
>> subclass I have coded, unsuccessfully:
>>
>> - (void)textViewDidChangeSelection:(NSNotification*)aNotification
>> {
>>NSRange selRange = [self selectedRange], effRange;
>>NSDictionary*attributes = [self.textStorage
>> attributesAtIndex:selRange.location effectiveRange:&effRange];
>>if(attributes){
>>NSColor *strokeColor = [attributes
>> objectForKey:NSStrokeColorAttributeName];
>>if(strokeColor){
>>[oStrokeColorWell setColor:strokeColor];
>>}
>>}
>> }
>>
>> Even if the strokeColor exists and gets set to the oStrokeColorWell, the
>> oStrokeColorWell still displays the foreColor. Any idea?
>
> What's the value of oStrokeColorWell when you're setting it? That is, check to
> make sure it isn't nil (outlet is connected).
>
> What's the value of strokeColor? Are you sure it is different than the
> foreColor?
>
> - Mike
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
NSArrayController - Remove and immediately deallocate objects
Hi, I have created an NSArrayController on IB. During the runtime, I remove all the objects from this NSArrayController. The objects get properly removed but they don't get deallocated immediately. Not even if I use a pool like that: NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; NSArray *boxes = [mBoxesArrayController arrangedObjects]; [mBoxesArrayController removeObjects:boxes]; [pool release]; At this point the boxes should receive the dealloc message, but they do not receive that immediately, as I expected. I have been looking for a solution and found something like [managedObjectContext processPendingChanges]; But I can't get the managedObjectContext for that NSArrayCOntroller that I have created on IB. Since I am pretty new at managing NSArrayController, I would like to know how to do that. Thank you. Regards -- Leonardo ___ 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: NSArrayController - Remove and immediately deallocate objects
On 2014 Feb 01, at 10:50, Leonardo wrote: > The objects get properly removed but they don't get deallocated immediately. This is not an issue with the array controller. It is an issue with memory management in general. First of all, I presume that you have a good reason (such as that the objects are using huge memory that you want to free up) for requiring that these objects be deallocated immediately. Otherwise, you shouldn’t be worried about them because forcing objects to dealloc can be tedious and difficult. The problem is that something else other than the array controller controller has retained your boxes. > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; > NSArray *boxes = [mBoxesArrayController arrangedObjects]; > [mBoxesArrayController removeObjects:boxes]; > [pool release]; Scratch that. In order for a local autorelease pool to be effective, it must enclose the target objects’ entire life cycle, beginning with their creation. You’ve missed their creation. > I have been looking for a solution and found something like > > [managedObjectContext processPendingChanges]; That might help, if indeed the objects have been deleted from the managed object context. At some point, you might need to verify that. > But I can't get the managedObjectContext for that NSArrayCOntroller that I > have created on IB. To access objects instantiated in nibs, use an outlet. * * * Getting back to the tedious and difficult, you need to track everything that might ever have retained your boxes from their creation. Since your boxes are apparently “managed” (Core Data) objects, read this… https://developer.apple.com/library/ios/documentation/cocoa/conceptual/CoreData/Articles/cdMemory.html One thing for sure is that, if this managed object context has an Undo Manager, deleted objects are being retained in case there is an Undo or Redo. ___ 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
Quartz problem (glext bug)
I've got a problem when I include the Quartz framework. Doing so, without altering a single line of my code, causes the following error to be raised when I attempt to compile: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/OpenGL.framework/Headers/glext.h:3382:45: Expected ')' I've done some digging around, and I understand that the problem is caused by a bug in glext - namely that 'it has a bunch of definitions that useGLenum, but GLenum isn't defined anywhere in that file. So, before you include glext.h, you need to include a file that defines GLenum.' Given that I'm not directly including this file, it is being included from the Quartz framework, how can I fix this problem? Interestingly, the QuickLookDownloader demo doesn't seem to have this problem. Once again, to reiterate, I haven't written any extra code other than "#import ", and added the framework to the build library. Without, all is fine. With, this odd error. ___ 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: Quartz problem (glext bug)
On Feb 1, 2014, at 11:56 AM, Pax <45rpmli...@googlemail.com> wrote: > I've got a problem when I include the Quartz framework. Doing so, without > altering a single line of my code, causes the following error to be raised > when I attempt to compile: > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/OpenGL.framework/Headers/glext.h:3382:45: > Expected ')' > > I've done some digging around, and I understand that the problem is caused by > a bug in glext - namely that 'it has a bunch of definitions that useGLenum, > but GLenum isn't defined anywhere in that file. So, before you include > glext.h, you need to include a file that defines GLenum.' Given that I'm not > directly including this file, it is being included from the Quartz framework, > how can I fix this problem? That doesn't sound right. glext.h includes gltypes.h, which defines GLenum. My guess is that you have a #define elsewhere in your code that interferes with the declarations in glext.h. If you have a #define that happens to have the same name as one of glext's parameter names then the #define could introduce a syntax error into glext's code. You can use Xcode's Preprocess command to look at the code after #defines have been applied. If the problem is a wayward #define then you may be able to see it there. (Find the code on line 3382 of glext.h. Product > Perform Action > Preprocess File with one of your files that causes the error. Find that same code in the preprocessor output; it'll be on a different line. Look at that line and the lines around it for syntax errors.) In my copy of glext.h, line 3382 is the declaration of function glObjectPurgeableAPPLE, and column 45 is the 'o' in parameter 'GLenum objectType'. If your code has something like `#define objectType 42` before you include that file then you'll get the error described. Some versions of clang will tell you that there's a macro involved: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/OpenGL.framework/Headers/glext.h:3382:45: error: expected ')' extern GLenum glObjectPurgeableAPPLE(GLenum objectType, GLuint name, GLe... ^ test.c:1:20: note: expanded from macro 'objectType' #define objectType 42 ^ -- 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: Quartz problem (glext bug)
Damn Google! Always with the wrong answer ;-) Thanks for this. With your sage advice, I've located the problem. On 1 Feb 2014, at 20:30, Greg Parker wrote: > On Feb 1, 2014, at 11:56 AM, Pax <45rpmli...@googlemail.com> wrote: >> I've got a problem when I include the Quartz framework. Doing so, without >> altering a single line of my code, causes the following error to be raised >> when I attempt to compile: >> >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/OpenGL.framework/Headers/glext.h:3382:45: >> Expected ')' >> >> I've done some digging around, and I understand that the problem is caused >> by a bug in glext - namely that 'it has a bunch of definitions that >> useGLenum, but GLenum isn't defined anywhere in that file. So, before you >> include glext.h, you need to include a file that defines GLenum.' Given >> that I'm not directly including this file, it is being included from the >> Quartz framework, how can I fix this problem? > > That doesn't sound right. glext.h includes gltypes.h, which defines GLenum. > > My guess is that you have a #define elsewhere in your code that interferes > with the declarations in glext.h. If you have a #define that happens to have > the same name as one of glext's parameter names then the #define could > introduce a syntax error into glext's code. > > You can use Xcode's Preprocess command to look at the code after #defines > have been applied. If the problem is a wayward #define then you may be able > to see it there. (Find the code on line 3382 of glext.h. Product > Perform > Action > Preprocess File with one of your files that causes the error. Find > that same code in the preprocessor output; it'll be on a different line. Look > at that line and the lines around it for syntax errors.) > > In my copy of glext.h, line 3382 is the declaration of function > glObjectPurgeableAPPLE, and column 45 is the 'o' in parameter 'GLenum > objectType'. If your code has something like `#define objectType 42` before > you include that file then you'll get the error described. Some versions of > clang will tell you that there's a macro involved: > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/OpenGL.framework/Headers/glext.h:3382:45: > error: > expected ')' > extern GLenum glObjectPurgeableAPPLE(GLenum objectType, GLuint name, GLe... >^ > test.c:1:20: note: expanded from macro 'objectType' > #define objectType 42 > ^ > > > -- > 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
