Re: Does Mac OS X support interior pointers?
Those who disagree with me implicitly acknowledge I do not think that those who disagree with you must acknowledge your two premises implicitly or explicitly. A) The compiler is generating code that violates the C standard. You put a lot of effort into claiming that it's a given that the compiler is generating bad code and that the point is "not up for debate". I agree that your claim is not open for debate, it is demonstrably false. It is not the compiler that is generating code that violates the C standard. It is the action of the garbage collector thread, and the semantics of associated library routines like NSAllocateCollectable, that are at odds with the the semantics of the C described by the standard (the standard that does nothing to take the actions of a garbage collector into account). If you were to do something evil like set up your running application to kill the Garbage Collector thread prior to executing the code that the compiler has generated, that would execute in accordance with the standard. The compiler cannot be held responsible for the actions of the Garbage Collector thread (whether it is an optimizing compiler or not). From the standpoint of the compiler and the standard, the garbage collector thread and its libraries are rogue agents that work outside the law. B) Because of this, it significantly complicates writing code that uses garbage collection. Well, having shot holes through premise A we could ignore premise B altogether. We could also devolve into pointless and petty arguments over subjective opinions like those expressed in the fragment "significantly complicates". I suppose you might argue that using the Garbage Collector with arbitrary C code, when using common C pointer idioms, is more complicated than using it in the context of those problems that it was designed to solve. Then again, what technology doesn't get more complicated to use once you apply it outside of the context of the problems it was designed to solve? .. there is no way for you to write code at the C source level that explicitly and intentionally ensures that lifetimes of the "base" pointers continue for as long as "derived" or "interior" pointers need to be valid. As Adam on Mythbusters might say "Well there's your problem, right there!" The Mac OS X garbage collector is not designed to simplify memory management at the "C source level". I've seen _hours_ of presentations at WWDC and the "Tech Talks" which focus on the esoteric way that the garbage collector behaves when you combine garbage collected Objective-C objects with lower-level C code. In those instances, the system provides some low level routines for solving very specific problems when Objective-C is interacting with C code. Those routines might be misconstrued as providing general support for low level memory management in C, but that would be an erroneous conclusion. Incidentally, you CAN write code at a low level that "explicitly and intentionally ensures the lifetime of the base pointer". Use the NSGarbageCollector routines disableCollectorForPointer: and enableCollectorForPointer: on that base pointer and you can control its lifetime almost as closely as you would like. (Admittedly, however, that's at the "Objective-C source level", and not the C level). If GC effort and difficultly is ever greater than manual memory management, what's the point? What's the point of driving a car if you have to get off the freeway and drive on residential streets? What's the point of using computers if the applications can crash? "The point" is that the majority of the time GC greatly simplifies memory management of Objective-C objects. In special cases if you have to interact with lower level C code you might have to accept the complexity afforded by the lower level routines, routines like NSAllocateCollectable (which is designed to allow you to allocate C structs in such a way that Objective-C pointers can be stored inside them without the objects being collected). I mean, seriously... when using Mac OS X GC, it's no longer enough to write source code that's correct - you also need to make sure the code that comes out of the optimizer reflects the intent of the source code and that crucial bits haven't been dead code eliminated. Seriously... If you make the decision to use of the garbage collector, then in _addition_ to making sure that you write source code that is correct according to the semantics defined by the language standard and the compiler, you must _also_ make sure that the source code you write is correct with respect to the semantics of the garbage collector and associated library routines. To mangle a popular movie quote, "If you opt in to Garbage Collection you are invoking great power and with greater power comes greater responsibility". When you drop down to t
Re: #pragma to suppress a warning message
Also, can anyone point me to a list of the #pragma’s for xcode? I'm not sure what you are referring to when you say that your pragam warnings would have worked "In gnu". Xcode is an IDE. The compiler most commonly used with Xcode is gcc which is the GNU C compiler. In Snow Leopard, you can optionally use the clang compiler. A list of pragmas for gcc can be found here: http://gcc.gnu.org/onlinedocs/gcc/Pragmas.html Nonetheless, on the 10.4 machine where I tested this, the method works. Does anybody know what the story is with this method and 10.4? Is this method actually supported by 10.4 or is it something that happens to be supported if certain other software has been installed on a 10.4 platform? If it is not in the headers, it is a private and unsupported method. It may appear to work, but you have no guarantees as to whether or not it is returning the correct information in all cases. As such, it should not be used. ___ 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: stringWithCString:length deprecation
But that doesn't look like a real replacement. Shouldn't there be a stringWithCString:length:encoding What am I missing? I think what you're missing is: - (id)initWithBytes:(const void *)bytes length:(NSUInteger)len encoding:(NSStringEncoding)encoding; Scott ___ 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: Vector images on Cocoa
> I would need some way of loading vectorized images from files and drawing > them to my custom NSView derived class, scaled up or down according to the > frame of the control. I was thinking of using SVG files but there seems not > to be any easy way of handling them in Cocoa and I feel that implementing my > own SVG parser would be of too much work. What would you recommend? EPS? > > Thank you. > > Regards, > Henri Häkkinen PDF is a vector graphics image format (the evolution of EPS) and is also the default metafile format for Mac OS X. Scott ___ 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: resizing PDF obtained from dataWithPDFInsideRect:
On Nov 19, 2009, at 4:37 PM, Chinh Nguyen wrote: > The conversion to screen coordinates is causing stair stepping in connected > lines and other oddities when exporting to PDF. As a temporary solution > until the code is rewritten, I've created a subclass of my view that's sized > at the large coordinate space's dimensions specifically for rendering the > image to PDF. However, I can't seem to resize the PDF data down to the more > manageable screen view's dimensions when saving to disk. I've tried creating > an NSPDFImageRep from the PDF data and resizing it but it has no effect on > the saved to disk image (I guess setSize: does not affect the original data). > What I end up with is a PDF file with large dimensions that overwhelms > whatever application I'm placing it into. > > What I ended up doing is creating an NSView subclass that simply draws the > PDF at the size I want and returns the PDF data from that. This works but is > there a better way of resizing the dimensions of PDF data or is the size the > size that it's generated at and there's no changing it? A PDF file has a number of rectangles that affect how and where it draws. I would recommend looking at CGPDFContext. It gives you the ability to specify the size of the PDF you are generating. You would basically use a combination of changing the size of the PDF and using a coordinate transformation to scale the PDF content to the size that you want. > Also, I allow the user to export the image as a bitmap and even override the > dimensions. I create an NSImage from the PDF data, resize the NSImage, then > save the TIFF representation to the bitmap format I want. This works in > Leopard but no longer works in Snow Leopard. I read the tech note about > changes to NSImage and caching but I had no luck with the different caching > methods. I ended up creating an NSImage at the desired size, locking the > focus, drawing the PDF data at the desired size, unlocking the focus, then > saving the TIFF representation. Is there a better way? Your solution sounds OK. I tend to work at the CG Layer a lot so personally, I would avoid NSImage altogether and drop down to the Core Graphics layer. I would create a block of memory, use CGBitmapContextCreate to create a CG context on that bitmap, draw the graphic into that context, construct a CGImage and use Image I/O to export the image. The end result would be similar, but I'd have to go through a lot more steps than you did. > And finally, is there a way to change the resolution of a bitmap from 72dpi > to say 300dpi? My users want to be able to specify the dimensions of the > exported bitmap in inches and the resolution. They want to be able to place > their 1800 pixel wide TIFF file into Word and it show up 6 inches wide (@ > 300dpi) instead of 25 inches wide (@ 72dpi). Not a huge deal because I still > recommend our users use PDF but some of them have legacy apps that don't > support PDF. The example I was able to find on this created a new > NSBitmapImageRep and copied the image data into it and then set the size. This is one feature that Image I/O allows you to have control over. As you export each image you can provide a dictionary of image attributes, one of which is the desired image resolution. Scott ___ 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: newbe view question
>> I had thought about subclassing the window's content view but, yuch, there >> must be a better way. I have perused the literature & if something is there >> I have missed it. Is there some way I can drop a folder onto a window or its >> content view & get the name of the folder? Please point me in the right >> direction. Instead of trying to subclass and replace the content view, just create your own NSView subclass and add it as a subview of the content view that already exists. ___ 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: Basic, but still confuses me (initWithFrame and drawRect)
On Jun 19, 2009, at 2:20 PM, Chunk 1978 wrote:
so i'm forced to subclass the rect...
Hmm... There's no such thing as "subclassing a rect". CGRect is a
structure, not a class.
my StrokeView:UIView class.m is this:
- (id)initWithFrame:(CGRect)frame {
if (self = [super initWithFrame:frame]) {
frame = CGRectMake(10, 10, 100, 100);
}
return self;
}
You've changed the value of the local variable "frame". If you want
to resize your view you will have to either change the frame before
calling super, or use self.frame = CGRectMake(10, 10, 100, 100) after
self has been initialized.
- (void)drawRect:(CGRect)rect
{
CGContextRef context = UIGraphicsGetCurrentContext();
CGContextSetLineWidth(context, 2.0);
CGContextSetStrokeColorWithColor(context, [UIColor
whiteColor].CGColor);
CGContextStrokePath(context);
}
You asked for the current path to be stroked, but you haven't told the
context what the current path is. Somewhere in there before the
StrokePath you probably want to do:
CGContextAddRect(context, CGRectMake( <... whatever rect you like
here...>));
now in my may app controller.h i have the following:
@class StrokeView;
@interface AppController : UIViewController
{
StrokeView *strokeViewClass;
}
@property (nonatomic, retain) StrokeView *strokeViewClass;
and in the implementation file, i'm calling for the class to be added
as a subview with this:
#import "StrokeView.h"
[self.view insertSubview:strokeViewClass atIndex:1];
totally doesn't work.
Do you ever allocate the strokeView? You've declared that your
UIViewController knows about a stroke view, but you've not actually
created one (at least not with this code example).
It would seem that there is a lot here you don't understand. I would
recommend going back and looking at some basic examples and perhaps
some of the sample code to see if you can learn a bit more.
Scott
___
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: Problem: how to get glyph descent and ascent
On Jun 23, 2009, at 1:02 PM, Anders Lassen wrote: The font descent is the maximum descent for all characters in that font, so it will not help me to position the character correct Unfortunately the documentation on the text system in Mac OS X can be very difficult to navigate (as you have no doubt learned). There is documentation on QuickDraw, ATSUI, Core Text, the Cocoa System etc... etc... some of it's legacy, some of it's deprecated, and it's really hard to know what you should use. I would recommend looking at the Cocoa Text system (if you are a Cocoa app) then drop down to the Core Text level if that is not sufficient. I would use ATSUI as a last resort. Speaking in very broad terms, the text systems on the OS are much happier if you start out at the character level and let them manage the conversion from characters to glyphs. You can then get at the glyph information, but the information you can learn about any particular glyph is usually given in the context of an entire line of text that has been arranged for you. To learn about an individual glyph you would have to either arrange for it to be put into it's own style run, or you would have to dig around in the font tables yourself (a practice I would recommend avoiding if at all possible). You started out asking about glyphs and now are talking about characters. What information are you starting with in your application? Do you have a set of characters that represents some sub- expression of your formula, or are you starting out with a set of glyph ids? Scott ___ 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: How do I draw a CGImage (30 sq px PNG) upon a host (larger) CGImage Image at a specific coordinate?
On Jun 26, 2009, at 2:25 PM, Frederick C. Lee wrote:
Environment: iPhone OS 3.0
Greetings:
I would like to place one or more reference icons (png) upon a
host image (png) {Like a street map with legends, landmarks, etc.}.
I'm working with Quartz so I'm using pre-loaded CGImages via
UIImage.CGImage, for both the map/layout and the icons.
Use UIGraphicsBeginImageContext to create a graphics context attached
to a third image. Draw the first (Background image) using UIImage's
drawAtPoint: or drawInRect: methods, then draw the second (reference
icon) image. UIGraphicsGetImageFromCurrentImageContext will give you
the final image after which you can close down the context using
UIGraphicsEndImageContext.
Here's some pseudo-code (typed into mail so it might not compile)
UIGraphicsBeginImageContext( hostImageSize )
[hostImage drawInRect: CGRectMake(0, 0, hostImageSize.width,
hostImageSize.height)]
[refIcon drawAtPoint: ]
UIImage *combinedImage = UIGraphicsGetImageFroCurrentImageContext();
UIGraphicsEndImageContex()
Questions:
1) Should destination context be the host-image context vs
UIGraphicsGetCurrentContext() ?
If so, how do you get a drawing context from a PNG image?
I would draw into an entirely new context, as above, preserving the
background image.
3) Should I make the source PNG image (the ref icon) a CGLayer object?
Only if you plan to draw the same icon over and over on the map. In
that case you would create the image context and grab the current
context as above, then create your CGLayer passing the new context to
CGLayer. Draw your reference icon into the layer, and draw the layer
as many times as you care to to draw the reference icon.
I would very carefully check the performance of such an operation,
however, the drawing environment on the phone is quite a bit simpler
than the drawing environment on a desktop machine. The speed
advantage of a CGLayer may not be as advantageous.
4) Can I work with a different scale (say, 4x) to more-accurately
place the icons upon the host?
Quartz 2D uses floating point coordinates. You have the full accuracy
of that type to place the image at sub-pixel resolutions. I can't see
why you would need to scale the host image to place the reference icon
accurately.
Scott
___
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: [Rubycocoa-talk] Alternative to NSGraphicsContext graphicsContextWithGraphicsPort:flipped:
On Wednesday, July 01, 2009, at 02:51PM, "Duncan McGregor" wrote: >Hi > >I'm writing PDF's with RubyCocoa, and want to set the current graphics >context to a PDF context from CGPDFContextCreateWithURL so that I can >draw on it. > >Essentially my code says (sorry, ObjC folks, Ruby follows) > >@pdf_context = CGPDFContextCreateWithURL(pdf_url, CGRectMake(0, 0, >100, 100), nil) >. >NSGraphicsContext.saveGraphicsState >nscontext = >NSGraphicsContext >.graphicsContextWithGraphicsPort_flipped(@pdf_context, true) >NSGraphicsContext.setCurrentContext(nscontext) > >My problem is that graphicsContextWithGraphicsPort:flipped: crashes >RubyCocoa. It's a known issue, and has been fixed, but not shipped in >10.5.7 > >Can anyone suggest any workarounds that could get the pdf_context >current? If I understand... you're going all the way to NSGraphicsContext just to flip the coordinate system? That's a long row to hoe :-). Try something like (typed into mail) CGContextTranslateCTM(pdf_context, 0, 100); # where 100 is the height of the context... CGContextScaleCTM(pdf_context, 1.0, -1.0); use that instead of trying to set the flipped bit. Scott ___ 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: Rendering a fixed-width text
On Jun 30, 2009, at 9:52 AM, Riccardo Canalicchio wrote: I'm developing an application for MacOSX, based on Core Animation. I would like to know the best way to render a fixed-width text paragraph inside a CALayer. I already tried with CATextLayer, which indeed gave me a fixed-width text but I wasn't able to make height automatically adjust accordingly to the number of lines in the paragraph. To some extent it depends on your application. I would recommend looking at the Cocoa text system and in particular how to assemble the text system "by hand": http://developer.apple.com/documentation/Cocoa/Conceptual/TextArchitecture/Tasks/AssembleSysByHand.html Using that you could determine the size and layout (line breaks) for a section of text (fixed-width or not). You could also use that system to draw the text onto the layer using the NSLayoutManager: - (void)drawBackgroundForGlyphRange:(NSRange)glyphsToShow atPoint: (NSPoint)origin; - (void)drawGlyphsForGlyphRange:(NSRange)glyphsToShow atPoint:(NSPoint) origin; If Cocoa is not to your liking, then you could also use the Core Text system, a C interface that the Cocoa Text (at least in part) is built upon: http://gemma.apple.com/documentation/Carbon/Conceptual/CoreText_Programming/Introduction/Introduction.html Scott ___ 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: setting a CGContextRef to the current Context
On Jul 8, 2009, at 6:03 PM, David Alter wrote: I have CGContextRef that I use for some quartz calls. It is a bitmap context. I would like to set it as the current context so that I can use NSString drawAtPoint: withAttributes:. I do not see how to do this. NSGraphicContext setCurrentContext: takes a NSGraphicContext and not an CGContextRef. I do not see a way to create a NSGraphicContext with a CGContextRef. Nor do I see anything in the C API. So I'm a little unclear how I can set my bitmap Context to the current context so I can draw my string. Anyone have any ideas. thanks for the help. In the world of NSGraphicsContext, a CGContextRef is known as a "graphicsPort". So the routine you are looking for is: + (NSGraphicsContext *)graphicsContextWithGraphicsPort:(void *) graphicsPort flipped:(BOOL)initialFlippedState; You should typecast your CGContext to (void *) and pass it as the graphicsPort argument. Ater doing that you can use setCurrentContext. The whole thing looks something like this [NSGraphicsContext saveGraphicsState]; [[NSGraphicsContext graphicsContextWithGraphicsPort: (void *) yourCGContextHere flipped: isFlipped] setCurrentContext]; ... draw here... [NSGraphicsContext restoreGraphicsState]; "Flipped" refers to the location of your origin and the orientation of your coordinate system. Set flipped to YES if you've moved the origin to the top left of the context and are using a left handed coordinate system (x axis to the right, y axis pointing down). You are likely going to want the flipped coordinate system to draw text. Scott ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: bypass NSApp
Sent from my iPhone On Jul 9, 2009, at 10:04 AM, Bill Bumgarner wrote: On Jul 9, 2009, at 2:46 AM, Julien Isorce wrote: I am trying to isolate this difference in order to avoid to run the main loop in the main thread. Don't bother. Cocoa is quite explicitly designed to not support event processing on any thread other than the main thread. No amount of "trying to isolate" Cocoa functionality into a thread will make it work. To empasize this point. Consider, for example, the method performSelectorOnMainThread:. We use this API in several place to ensure that functionality is performed on the same thread that is processing user events. If code were able to change the thread responsible for handling events willy-nilly, that kind of functionality would break badly. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to write ipeg image created with CGImageRef?
I'm trying to save an NSBitmapImageRep initialized with -
initWithCGImage: onto a disk.
But the image of the saved file is bad. This means only black and
white horizontal lines are drawn meaninglessly.
The _rep in the below code is the NSBitmapImageRep instance
allocated and initialized with -initWithCGImage: as I said at the
beginning,
and the image rep has alpha.
- (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError
{
NSDictionary* properties = [NSDictionary
dictionaryWithObjectsAndKeys:
[NSNumber
numberWithFloat:0.7], NSImageCompressionFactor,
[NSNumber
numberWithBool:YES], NSImageProgressive, nil];
NSData* result = [_rep representationUsingType:NSJPEGFileType
properties:properties];
return result;
}
The NSBitmapImageRep is logged like the following:
0x15ce70 Size={400, 264} ColorSpace=NSCalibratedRGBColorSpace BPS=8
BPP=32 Pixels=400x264 Alpha=YES Planar=NO Format=2
Would you tell me what I'm missing?
Thank you for reading this message.
Instead of taking the CGImage into NSImage and then exporting the
NSImage, you might just use ImageIO to save the CGImage directly.
Look up CGImageDestination in the documentation and see if you get
better results using it to export as JPEG.
Scott
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: bypass NSApp
On Jul 10, 2009, at 3:40 PM, Julien Isorce wrote: In GNUstep it's possible to decide which pthread is the "main thread". I mean the first pthread which call GSRegisterCurrentThread, is the main thread. And then the NSApp must be init and run in this main thread, as it's required on MacOSX. Is it possible to change the "main thread" as far as Cocoa is concerned, on MacOSX ? (something like GSRegisterCurrentThread) What is the point of such a routine? Suppose that the application starts and we give the main thread the label "Thread A". You spin up an new thread that we will give the label "Thread B. You then use your routine to make the thread with the label "Thread B" to be the main thread. Now the main thread has a "Thread B" sign and there is another thread with a "Thread A" sign hanging off of it. How is this different than if you had simply started the application gave the the main thread the label "Thread B", then started a new thread and gave it the label "Thread A"? In this way no performInMainThreads are borken, and it's a solution to my problem. It's still not clear what your problem is. What exactly is it that are you trying to do on Mac OS X? What is the environment in which your code is running and what effect are you trying to achieve? The only guess I can make is that you are trying to create a plugin for something like the GIMP and you want to use Cocoa from that plugin. There may be a way to solve your problem properly in Mac OS X, but we need to know what the problem is (not how you think you want to solve the problem). Scott ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: bypass NSApp
sure but in the previous mails I tried to explain that I am making a plugin (which consists of a dynamic library) of a program which I have not the source code. OK.. the application for which you are writing the plugin... is it a Cocoa application, a Carbon application, or something else... If it is a Cocoa or Carbon application then you shouldn't steal the event stream away from it. You should be able to simply create a window and expect that the standard event dispatching mechanism will do the right thing in distributing events to you. If it is not a Carbon or Cocoa application... then running a separate application environment in a separate thread within the application can only interfere with the behavior of the application itself. To twist a phrase from The Princess Bride (not sure how it translates to French): I do not think you need to do what you think you need to do. So the final question: is there a way to make [NSThread isMainThread] return YES in a thread different that the main thread of a process, on MacOSX ? No... nor is it likely to be something you want to do. You should not need to steal the main thread away from the application in order to receive events. Well... you could subclass NSThread and override isMainThread to return YES... but that's not productive at all. Scott ___ 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: getting directories created from a certain time
On Jul 10, 2009, at 1:46 PM, I. Savant wrote: On Jul 10, 2009, at 2:43 PM, Angelo Chen wrote: I have a lengthy process where it creates a few directories, I'd like to know how to get a list of directories created since the starting of the process, any hints? Thanks, If you're targeting Leopard, check out the FSEvents API. see also: http://developer.apple.com/documentation/performance/Conceptual/FileSystem/Articles/TrackingChanges.html ___ 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: UITextView Doesn't seem to function
On Jul 16, 2009, at 9:09 PM, Development wrote: Actually its a UITextView, it is linked in IB and when I NSLog (@"%@",about.text) it shows me that it has the string stored in the object, however it is not updating the onscreen view. Make sure that your text view is large enough to show the size of text that you are displaying in it. Otherwise the word wrap might be causing the text to seem to disappear. If necessary, make your text view too big just to make sure that the text is showing. Also make sure that the text color of the view is not white. Scott ___ 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: Why do CFType instances respond to NSObject messages?
On Jul 16, 2009, at 7:24 AM, Wilson Chen wrote:
Hi all,
I'm new to the Cocoa framework, and puzzled why the following code
would
work:
CGLayerRef layer = ...assume we have a layer created.
printf("Retain count after creation: %i\n", CFGetRetainCount(layer));
[(NSObject*)layer retain];
printf("Retain count after sending a retain message: %i\n",
CFGetRetainCount(layer));
[(NSObject*)layer release];
printf("Retain count after sending a release message: %i\n",
CFGetRetainCount(layer));
The code above gives the following output:
Retain count after creation: 1
Retain count after sending a retain message: 2
Retain count after sending a release message: 1
Since a CGLayer is not a subclass of NSObject, its instances shouldn't
respond to retain/release messages. Yet the code works.
This code works in a non-garbage collected environment. In a garbage
collected environment, the Objective-C retain and release calls would
be ignored while CFRetain and CFRelease would not. Your best bet is
to not mix the two paradigms.
___
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: [iPhone] Custom -sizeWithFont: and CGContextRef question
On Jul 16, 2009, at 1:30 PM, Michael Hoy wrote:
Hello all,
For various reasons I'd like to implement a method similar in
function to NSString's -sizeWithFont: (UIKit addition). The
difference is it takes a CGFontRef. Here's a rough idea of the code
(a slight adaptation of Timothy Ritchey's TTFontCell code, and I
apologize because I can't find a link to it right now):
- (CGSize)sizeWithFont:(CGFontRef)font ofSize:(CGFloat)size
withKerning:(CGFloat)kerning {
CGContextRef context = UIGraphicsGetCurrentContext();
CGContextSetFont(context, font);
CGContextSetFontSize(context, fontSize);
CGContextSetCharacterSpacing(context, kerning);
}
The code works — however, it can only be called within a UIView's
drawRect: method, for a valid context to be returned in
UIGraphicsGetCurrentContext();
This method is only useful really if it can be called *before* the
drawing code, for laying out views and such. I know that I need to
create a CGContextRef and push it on the UIGraphics stack. My
question is, what might be the best way to do this? I see I can use
CGPDFContextCreate or CGBitmapContextCreate... which makes sense
here? All I need to do is determine the size of a string w/
specified font, not actually draw it.
Working directly from a CGFontRef is often not the Right Thing(tm) to
do primarily because Quartz 2D is not the best way to draw text.
Quartz 2D is really good at drawing glyphs but there's a long road
from characters to glyphs. On the text system, there are public APIs
to Core Text that which handle things like line layout, glyph
substitution, bidi text adjustments etc... On the iPhone you're
largely limited to what you can find in UIKit.
Can you elaborate on why you are working from a CGFontRef instead of
from a UIFont?
If you absolutely MUST work from the CGFont level, you are likely to
have to use routines like CGFontGetGlyphBBoxes and
CGFontGetGlyphAdvances to compute the size yourself.
Scott___
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: Simple question
On Mar 17, 2008, at 7:53 AM, Luca Ciciriello wrote: Yes, you got it. .h stands for "header" and is the place where you make your declarations, .m stands for "module" and is where the definitions take place. You can encounter also .mm exetension. In these file you can mix Objective-C an C++ language. I would recommend that you find a nice book on C. I would recommend one, but it's been a while since I've surveyed the literature. The C derived languages (with those most relevant to Macintosh programming being, C, C++, Objective-C, and Objective-C++) tend to separate your code into two parts. The first is the active part of your program, that part which "does things". This code is placed into a file whose extension depends on the language you are using. As Luca points out ".c" is for C source code. ".m" is for Objective-C source code. C++ source is usually found in a file ending either in ".cp" or ".cpp". And Objective-C++ code uses ".mm". The header, or ".h" file doesn't typically contain active code. Instead, it usually contains some kind of description of the code that is found in the corresponding source code file. The description lets other part of your program know what functionality can be found in the source code file. To sum up, the source code file defines what your program can do, and how it can do it. The header file declares what's available and you you invoke it. Scott ___ 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 [EMAIL PROTECTED]
Re: Python/Ruby for Cocoa (was: Simple question)
I completely agree - and I wrote CamelBones, the Cocoa/Perl bridge. It is, and always has been, my opinion that language bridges are not an adequate substitute for learning Cocoa's native language, Objective-C. What they are *great* for is giving additional options to a skilled programmer who's already familiar with both Cocoa and a scripting language. Someone who tries to use them as a means to avoid Objective-C is just setting themselves up for a lot of frustration. I also find that (if you're already familiar with Cocoa, and if you're willing to put up with the corner cases) languages bridges like the Ruby, Python, and Perl bridges are really great tools for prototyping things quickly, and learning new APIs.For example, with Leopard I've used Ruby to learn more about the RSS handling of the Publish and Subscribe APIs, as well as to explore some of the functionality found in the scripting bridge. YMMV. Someday I should try using F-Script for that kind of thing too... Scott ___ 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 [EMAIL PROTECTED]
Re: Using C++ classes from Objective C
On Mar 20, 2008, at 2:34 PM, Jeremy wrote: Thanks everyone! Using a void* for the member variable of my wrapper class did the trick and I now have my Objective C code calling my C++ code! What is the best way to pass strings from my Objective C code to my C ++ code though? I started looking at the unichar definition and the methods on NSString, but would like to know if there is an obvious standard for dealing with the unicode issues. Are your C++ classes using CFStringRef, or std::string, or something else? Do you try and use wchar_t in your C++? Scott ___ 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 [EMAIL PROTECTED]
Re: Beginner with Cocoa
On Mar 24, 2008, at 7:12 AM, Jeff LaMarche wrote: I'g be rather surprised if the Cocoa books took out discussions of traditional objective-C memory managements in their next releases. It's still available for use, and as you mention, necessary for writing to earlier versions of the OS, not to mention for programming that thing that we're allowed to talk about programming for here. It would not surprise me. There are still a lot of cases where you cannot make use of the Garbage Collector. For example, I would hope that Cocoa development books might discuss the Ruby and Python Objective-C bridges. If you either bridge in your application (either to implement an embedded scripting language, or as the main implementation language), then you will not be able to use the garbage collector. There are also third party frameworks and libraries that may not yet be available in garbage collected versions. Applications linking to those libraries will have to use the traditional memory management scheme as well. Over time, there will be more code able to take advantage of the Garbage Collector, but I think it will be some time before it's ubiquitous enough to remove the retain/release memory management scheme from the literature. Scott ___ 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 [EMAIL PROTECTED]
Re: Garbage collection - was Beginner with Cocoa
On Mar 24, 2008, at 10:30 AM, colo wrote: In Ruby GC just works dandy without thought. Why is it so different in Cocoa Obj2.0? Conceptually, it's not much different. In implementation, however, they are two separate garbage collectors and they don't play well together. The problem crops up when you try to mix the two using RubyCococa in a single application. Right now RubyCocoa allows you to work with Objective-C objects through the Ruby interpreter and it uses retain/release mechanisms to manage the life-cycle of the Objective-C objects. To put it another way, if you are using Ruby as your development language, you don't have to worry about retain and release because the RubyCocoa library does it for you. However, that memory management is done in the RubyCocoa framework not at the level of the Ruby garbage collector. The Ruby garbage collector is not at all aware of the Objective-C garbage collector (and vice versa). As a result, it might be possible for one garbage collector to sweep away objects that the other garbage collector things should be "live". That's not good. To integrate the two, someone would have to rewrite the internals of the Ruby interpreter and add in special case code for Objective-C objects. That kind of a rewrite sounds Hard(tm) on many levels. Not the least of which is the fact that interpreter is shared across many platforms and environments and mucking with it's guts could have far- reaching and unexpected consequences. Regardless of the reasons, however, the fact remains that if you are going to write a Cocoa application that uses the RubyCocoa bridge to talk to some Ruby code in Leopard. The Cocoa application cannot use the Objective-C 2.0 garbage collector. What kinda of real headaches will I have jumping into osx programing compared to ruby ? It kinda depends on what you mean by "OS X Programming". Well, if you want to do "Pure" Ruby programming (including Rails) on Mac OS X, I doubt you are likely to run into many headaches. For everything I've tried, which I must admit is not much compared to what's possible, Ruby "just works" on Mac OS X. If "OS X Programming" means writing Coco applications, then, the RubyCocoa bridge will allow you write Cocoa applications in Ruby. However, be forewarned that there are some headaches in integrating the two. Those headaches might make learning Cocoa through Ruby unattractive for the Cocoa novice. My opinion (and apparently the opinions of others) is that you would be better off learning the Cocoa framework through the Objective-C APIs first, and then applying that knowledge to Ruby, than you would be trying to learn the Cocoa framework through Ruby from square one. YMMV If you are familiar with Cocoa and "familiar enough" with Ruby then I've found RubyCocoa particularly useful in two instances: 1. Quickly prototyping some object designs. If I'm trying to put together an object hierarchy or some object interactions, I will often prototype them in Ruby and play with their interfaces and such (I used to use Squeak/Smalltalk for that, but with ALL due respect to the Squeak folks, Ruby takes up less screen real estate). 2. Exploring new APIs and new parts of Cocoa. I used Ruby to learn some more about the Scripting Bridge and the "Publish and Subscribe" frameworks. Mostly because I was curious about them. Again, the ability to quickly throw together some... er... half-baked code in Ruby and then poke at it with irb was pretty handy. And to be fair, my understanding, though I have no experience with these other languages, is that you can do the same thing with other languages. Most notably, I've heard of support in FScript, Python, Perl (by using CamelBones). Does that answer your question? ___ 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 [EMAIL PROTECTED]
Re: Garbage collection - was Beginner with Cocoa
On Mar 24, 2008, at 3:03 PM, colo wrote: But I do not wish to use the bridge options yet I would rather do it right in one place than trying to glue it together and spend days not "getting it" I'll make a compromise with you. :-) I'll let you try one... just one... RubyCocoa application before you start looking at Objective-C. Start here: http://developer.apple.com/documentation/Cocoa/Conceptual/RubyPythonCocoa/Articles/BuildingRubyCocoaAppl.html#/ /apple_ref/doc/uid/TP40005425-SW1 That should walk you through some of the tools and basics but let you stick in Ruby just for a bit. Then, go directly to: http://developer.apple.com/referencelibrary/GettingStarted/GS_Cocoa/index.html#/ /apple_ref/doc/uid/TP30001088 and in particular: http://developer.apple.com/documentation/Cocoa/Conceptual/ObjCTutorial/01Introduction/chapter_1_section_1.html If/when you run into questions, let us know :-) Scott ___ 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 [EMAIL PROTECTED]
Re: Leopard on PPC
On Mar 27, 2008, at 10:29 AM, Clark Cox wrote:
On Wed, Mar 26, 2008 at 4:04 PM, Lorenzo <[EMAIL PROTECTED]> wrote:
Hi Laurent,
I am going to debug and let you know. Right now I have found these
lines.
Might they cause the trouble on Leopard && PPC?
No, but this line will cause problems when/if you build for 64-bit:
number = CFNumberCreate(NULL, kCFNumberFloatType,
&destSize.width);
Use kCFNumberCGFloatType instead of kCFNumberFloatType, and make sure
that you later CFRelease(number). Or just use NSNumber.
You could just use NSNumber, if it were not for the fact that NSNumber
doesn't have any API support for CGFloat. :-)
(rdar: //5812091)
You can add it with a category:
@implementation NSNumber (CGFloatSupport)
+ (NSNumber *) numberWithCGFloat: (CGFloat) cgFloatValue
{
CFNumberRef cfVersion = CFNumberCreate(NULL, kCFNumberCGFloatType,
&cgFloatValue);
return [NSMakeCollectable(cfVersion) autorelease];
}
- (CGFloat) cgFloatValue
{
CGFloat retVal = 0;
CFNumberGetValue((CFNumberRef) self, kCFNumberCGFloatType, &retVal);
return retVal;
}
@end
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: CGImage
On Apr 9, 2008, at 3:31 PM, Hugo Duncan wrote:
kCGImagePropertyMakerCanonFirmware
Looks like a bug in the frameworks to me. I would report it to Apple
at bugreport.apple.com.
If this constant follows the behavior of most constants of it's kind,
you could work around the problem by adding:
const CFStringRef kCGImagePropertyMakerCanonFirmware =
CFSTR("kCGImagePropertyMakerCanonFirmware");
as a global variable in your app.
Scott
___
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 [EMAIL PROTECTED]
Re: Drawing a 1 pixel-perfect wide bordered NSBezierPath
On Apr 17, 2008, at 4:28 AM, Heinrich Giesen wrote: Sorry, pressed the wrong button. And: if the bezier path shall always be drawn 1 pixel wide, independent of resolution and scaling the lineWidth should be set to 0 (zero) While this works for PostScript, it does not work for Quartz. Quartz 2D will not draw strokes with a zero width. Scott ___ 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 [EMAIL PROTECTED]
Re: Drawing a 1 pixel-perfect wide bordered NSBezierPath
Setting a line width of 0 draws a 1-pixel wide line at the
resolution of the device it draws to, so on screen, that's 1/72 of
an inch (approx) on a printer 1/600 inch, say. It's a useful way to
isolate drawing from any CTM scaling. This is handy for drawing a
selection rect outline on top of a zoomed image where you don't want
the selection itself to be scaled up (among many other uses). So
yes, I'd say it works - and Quartz most definitely does draw strokes
with a line width of 0.
No, Quartz 2D does not draw zero width strokes.
If you use NSBezierPath and supply a stroke width of 0 then Cocoa will
fudge the stroke width on your behalf and come up with something that
approximates a single pixel line, but Quartz 2D itself will not draw a
0 pixel wide line. You can try it yourself:
- (void) drawRect: (NSRect) rectToDraw
{
// This, of course, will draw
NSBezierPath *bezierPath = [NSBezierPath bezierPathWithRect:
NSMakeRect(20, 20, 150, 150)];
[bezierPath setLineWidth: 1];
[[NSColor blueColor] set];
[bezierPath stroke];
// This also will draw because Cocoa is nice and fudges the
underlying Quartz drawing for you
bezierPath = [NSBezierPath bezierPathWithRect: NSMakeRect(10, 10,
200, 200)];
[bezierPath setLineWidth: 0];
[[NSColor redColor] set];
[bezierPath stroke];
// This will not draw anything because Quartz does not draw zero
width lines.
CGContextRef cgContext = (CGContextRef) [[NSGraphicsContext
currentContext] graphicsPort];
CGContextSetLineWidth(cgContext, 0);
CGContextSetRGBStrokeColor(cgContext, 0.0, 1.0, 0.0, 1.0);
CGContextAddRect(cgContext, CGRectMake(5, 5, 150, 150));
CGContextStrokePath(cgContext);
}
___
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 [EMAIL PROTECTED]
Re: Drawing a 1 pixel-perfect wide bordered NSBezierPath
What function is drawing? I'm not sure this works with NSFrameRectWithWidth(), but it definitely does with NSBezierPath/ stroke. The NSFrameRect family of routines are odd ducks to begin with. In some ways, they tend to to be more pixel oriented than your typical drawing routines. For example, if you use NSFrameRectWithWidth, and supply a width of 1 (or 0) then you will see that your framed rectangle does not have to have the 0.5 pixel offset in order to align to the pixel grid. You will also note that when using wider widths, the stroke does not straddle the rectangle's path the way it would when using NSBezierPath. The entire width of the stroke (in pixels) will be contained within the rectangle. Finally, the pixel-oriented nature of these routines is clear when you consider that there is NSFrameRectWithWidthUsingOperation which draws the frame while applying a pixel operation. In a lot of ways, using NSFrameRect and friends is more like copying a bitmap onto the screen rather than drawing with the underlying Quartz mechanisms. As a result, the NSFrameRect routines are very handy for drawing on- screen or to bitmap contexts, but may, or may not, give you suitable results when drawing to other devices. Scott ___ 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 [EMAIL PROTECTED]
Re: Bitmap data from CGImageRef
On Apr 18, 2008, at 1:54 PM, Carter R. Harrison wrote: Thanks Adam.. For some reason I cannot seem to find CGDataProviderCopyData in the Apple docs. I can search for it at the ADC, and it returns the page for CGDataProvider as the first hit, but once you go to that page, there is absolutely no reference to CGDataProviderCopyData. Strange. There was another thread on quartz-dev that noted that. Someone at Apple said they would look into it. FWIW. Scott ___ 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 [EMAIL PROTECTED]
Re: drawRect: called twice for NSView subclass.
On Apr 19, 2008, at 7:15 PM, William Hunt wrote: Essentially I have a window with a custom view atop a button. What happens at each refresh, however, is that the custom view's drawRect: is called twice. First it is called with the whole window's NSRect, then it is called with the "proper" NSRect. The result is that if I draw a circle at (0,0), it gets drawn twice at different locations: +--+ |++| || Custom || ||o View || |++| |o == | +--+ What is going on here? Is this buggy behavior or correct behavior? My code is basically a new Cocoa application with a single NSView subclass. There is absolutely nothing funny (that I know of) going on here. That leads me to believe that the behavior is "correct," and that I'm just missing something. For the record, I only want the one call to drawRect:, the one with the "proper" NSRect. It sounds like you've somehow ended up with the content rect of the window as an instance of your custom view class. How do you create your view hierarchy (i.e. in Interface Builder) or "by hand"? Scott ___ 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 [EMAIL PROTECTED]
Objective-C variadic methods vs. NSArray et al.
Technical QA 1405 concerns the creation of Objective-C methods that take variable number of arguments... so called variadic methods. Happily the mechanisms just use the standard C mechanisms (va_start and friends). That being the case, why is it that methods like arrayWithObjects: require you to nil terminate the list of arguments? Is it simply tradition, or some kind of optimization? I don't need to know... I'm just curious. Scott ___ 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 [EMAIL PROTECTED]
Re: Objective-C variadic methods vs. NSArray et al.
On Nov 21, 2008, at 5:52 PM, Clark Cox wrote: On Fri, Nov 21, 2008 at 3:40 PM, Scott Thompson <[EMAIL PROTECTED]> wrote: Technical QA 1405 concerns the creation of Objective-C methods that take variable number of arguments... so called variadic methods. Happily the mechanisms just use the standard C mechanisms (va_start and friends). That being the case, why is it that methods like arrayWithObjects: require you to nil terminate the list of arguments? Is it simply tradition, or some kind of optimization? Without the nil, how would the method know when to stop fetching arguments with va_arg? This is true in C too, you have to have some way that tells you how many parameters are being passed and what types they are, and there are generally only two ways to do this: 1) Have the information encoded in the first parameter (like a printf format string) 2) Have some sentinel value marking the end of the list (like the nil passed to arrayWithObjects:) Ah... I see. ___ 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 [EMAIL PROTECTED]
