Re: Returning a nil float?
On Jan 29, 2010, at 6:44 PM, Chunk 1978 wrote:
i'm almost 100% sure it's not possible to return a nil on basic data
types, but just incase i'll post the question.
--
- (float)panForSoundWithName:(NSString *)soundName
{
OpenALSound *sound = [soundDictionary objectForKey:soundName];
if (!sound) return 0.0f;
return sound.pan;
}
--
so above i'd like to write if (!sound) return nil;. my reasoning is
because some attributes to a sound object (like pan) are created only
when the sound is initialized. if there is no sound object than there
should also be no pan value to return. unfortunately, the float
default 0.0f is also the default value for pan (range from -1.0 to
1.0).
Another option besides those already mentioned is to use exceptions. Whether
they're appropriate depends on whether calling -panForSoundWithName: on
non-existent sounds is part of your normal control flow, I guess.
-Michael
___
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: Returning a nil float?
On Feb 1, 2010, at 12:58 PM, Jean-Daniel Dupas wrote:
Le 1 févr. 2010 à 19:17, Michael Gardner a écrit :
On Jan 29, 2010, at 6:44 PM, Chunk 1978 wrote:
i'm almost 100% sure it's not possible to return a nil on basic data
types, but just incase i'll post the question.
--
- (float)panForSoundWithName:(NSString *)soundName
{
OpenALSound *sound = [soundDictionary objectForKey:soundName];
if (!sound) return 0.0f;
return sound.pan;
}
--
so above i'd like to write if (!sound) return nil;. my reasoning is
because some attributes to a sound object (like pan) are created only
when the sound is initialized. if there is no sound object than there
should also be no pan value to return. unfortunately, the float
default 0.0f is also the default value for pan (range from -1.0 to
1.0).
Another option besides those already mentioned is to use exceptions. Whether
they're appropriate depends on whether calling -panForSoundWithName: on
non-existent sounds is part of your normal control flow, I guess.
This solution is not suitable in Cocoa. Exceptions are slow and should be
used only when a critical error occurs. They should not be part of the normal
flow and should not be used in this kind of situation.
Did you miss the part where I said it depends on whether this is part of the
program's normal control flow? I don't think we have enough information from
Chunk's description to make a judgment on this one way or the other.
As to exceptions being slow: assuming that's true, so what? Unless one plans to
use them in an inner loop, what does it matter? That advice stinks of premature
optimization.
-Michael___
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: Snapshotting hidden UIViews
On Jan 13, 2010, at 10:30 PM, glenn andreas wrote: On Jan 13, 2010, at 9:46 PM, Michael Gardner gardne...@gmail.com wrote: On Jan 13, 2010, at 5:07 PM, glenn andreas wrote: On Jan 13, 2010, at 4:48 PM, Michael Gardner wrote: I also tried calling -drawRect: on my hidden view (after setting the context with UIGraphicsBeginImageContext()), but it doesn't seem to do anything. Many built in views do not draw anything at all (and have no useful drawRect:) - all of their rendering is handled by the view's layer. Ah, that explains that. But I'd still very much like to know why the layer's -renderInContext: doesn't work consistently when the view is hidden. Pure speculation, but a hidden view may not have a layer associated with it, and things like subview layout aren't done for hidden views (why waste cycle laying out the subviews if nobody will see it?). There are probably other undocumented optimizations as well on hidden views, such as animations not running, pending refreshes postponed, etc... UIWebView is going to be especially problematic, since it does a whole lot of things in the background (such as loading needed images and other resources) That still leaves the question of how to capture the contents of a UIView in an image when the view isn't visible. By the way, I tried the trick Matt suggested earlier in the thread, by obscuring my view behind another one instead of making it hidden. It didn't work. Is UIKit smart enough to know that a view behind another (opaque) view is effectively hidden? -Michael___ 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: Snapshotting hidden UIViews
On Jan 13, 2010, at 11:24 AM, Matt Neuburg wrote: On Tue, 12 Jan 2010 14:18:05 -0600, Michael Gardner gardne...@gmail.com said: I'm trying to create a snapshot UIImage from a UITextView that's inside a larger, hidden UIView. renderInContext: works fine for visible UIView layers, but I can't get consistent results for hidden views. I read somewhere (can't recall the source, but it wasn't authoritative) that this is expected behavior, and that -renderInContext: is only guaranteed to work for visible UIViews' layers. Is this true? If so, how else can I replicate *exactly* what my UITextView would look like when visible? In my JACTVocab app I have a similar problem: I need to make a snapshot of a situation in my window that doesn't exist yet. In other words, my window is in situation A, but I need a snapshot of situation B. I will eventually show the user situation B, but I need the snapshot first. So what I do is: I take a snapshot of situation A, and cover the window with a borderless window containing that snapshot. This hides what I am about to do in the real window. Now I change the situation in the window to situation B. The user cannot see this happening because snapshot of situation A is covering the window. Now I take the snapshot of situation B (this works perfectly well even though the second window is covering it). The hand is quicker than the eye, and the user never notices (I hope). Also, I use cacheDisplayInRect, not renderInContext. But it may be that there are reasons why you don't have that option... Hope this helps some - m. Thanks for this useful tip, but I hope I don't have to resort to your method. It just feels... dirty, you know? I'm not using -cacheDisplayInRect: because it doesn't exist in UIView, as far as I know. I also tried calling -drawRect: on my hidden view (after setting the context with UIGraphicsBeginImageContext()), but it doesn't seem to do anything. -Michael___ 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: Snapshotting hidden UIViews
On Jan 13, 2010, at 5:07 PM, glenn andreas wrote: On Jan 13, 2010, at 4:48 PM, Michael Gardner wrote: I also tried calling -drawRect: on my hidden view (after setting the context with UIGraphicsBeginImageContext()), but it doesn't seem to do anything. Many built in views do not draw anything at all (and have no useful drawRect:) - all of their rendering is handled by the view's layer. Ah, that explains that. But I'd still very much like to know why the layer's -renderInContext: doesn't work consistently when the view is hidden. -Michael___ 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
Snapshotting hidden UIViews
I'm trying to create a snapshot UIImage from a UITextView that's inside a larger, hidden UIView. renderInContext: works fine for visible UIView layers, but I can't get consistent results for hidden views. I read somewhere (can't recall the source, but it wasn't authoritative) that this is expected behavior, and that -renderInContext: is only guaranteed to work for visible UIViews' layers. Is this true? If so, how else can I replicate *exactly* what my UITextView would look like when visible? -Michael ___ 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
Deleting entire sections in UITableView edit mode
I'm creating a UITableView in which users should be able to (among other things) delete not only single rows, but entire sections. When the table is put into edit mode, I would like to show a control in each section header that will allow deletion of the associated section. How hard is this going to be (in particular, getting the custom edit controls' appearance and animations to match those of the existing edit controls)? Has anyone done anything similar before? If it turns out to be too hard, I may just give up and put an always-visible delete this section button in the header or footer of each section. -Michael___ 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: [OT] How do people use and contribute to this list?
On Oct 19, 2008, at 10:18 PM, Scott Ribe wrote: The view unread only option is the reason I haven't switched to Mail and still use Entourage. You know you can sort by unread status by clicking on the 'unread' column in Mail, right? It's not exactly the same, but it works well for me. -Michael ___ 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: How to count composed characters in NSString?
On Sep 28, 2008, at 5:53 AM, Gerriet M. Denkmann wrote: On Sun, 28 Sep 2008 03:27:48 -0500, Michael Gardner [EMAIL PROTECTED] wrote: On Sep 27, 2008, at 2:23 PM, David Niemeijer wrote: Hi, I have been trying to find this in the documentation and list archives but without success so far. What is the best way to count the number of characters in an NSString taking account of the fact that some characters may take up multiple 16 bit slots. Using - (NSUInteger)length is thus not the right way. If I am reading you right, you are saying that -length will give you the wrong results because some characters in Unicode are represented by multibyte sequences. This is incorrect: -length will give you the number of Unicode characters in a string [...]. This surprises me. I always thought that length gives you the number of shorts in the Utf-16 encoding of the string, which - as I used to think - is not the same as the number of Unicode code points in this string. But maybe you are right and I am confused. Upon further investigation, I may be wrong. I based my assertion upon Apple's NSString documentation (Returns the number of Unicode characters in the receiver), and upon some quick tests I ran. But this reply made me look into the issue in greater depth. I re-did my tests more throughly, and it does appear that -length returns the number of 16-bit words (code units), not the number of Unicode characters (code points), in the string. If this is true, I would call it a bug either in the code or in the documentation, which David should submit to Apple. I apologize for the apparent misinformation in my previous, hasty reply. In the meanwhile, David, perhaps you can find a library that can work with UTF-8 strings. What are you using the length values for? -Michael ___ 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: How to count composed characters in NSString?
On Sep 28, 2008, at 1:17 PM, David Niemeijer wrote: Michael, On 28 sep 2008, at 14:41, Michael Gardner wrote: Upon further investigation, I may be wrong. I based my assertion upon Apple's NSString documentation (Returns the number of Unicode characters in the receiver), and upon some quick tests I ran. But this reply made me look into the issue in greater depth. I re-did my tests more throughly, and it does appear that -length returns the number of 16-bit words (code units), not the number of Unicode characters (code points), in the string. If this is true, I would call it a bug either in the code or in the documentation, which David should submit to Apple. i think the docs are clear. In the discussion section for length it says: The number returned includes the individual characters of composed character sequences, so you cannot use this method to determine if a string will be visible when printed or how long it will appear. But composed character sequences aren't the problem; surrogate pairs are. Composed character sequences can be taken care of by using either -precomposedStringWithCanonicalMapping or - precomposedStringWithCompatibilityMapping. In my opinion, -length should take surrogate pairs into account, which is what the docs seem to imply. -Michael ___ 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: design pattern for data acquisition in background thread?
On Sep 27, 2008, at 10:10 PM, Joe Keenan wrote:
The problem with any async method is that I haven't figured an
elegant way to know which update code to use for each return value.
They're not all the same. Different data elements need different
processing to update the UI. When I get a response back
asynchronously, I have the variable name and the value, and I have
to figure out which UI element it belongs to. The brute force
method is a long if/else chain that tests the name of the variable
to do it, like:
if ([key isEqualToString: @lnbcolor])
{
[lnbLight setTextColor:[NSColor colorFromHexidecimalValue:
keyValue]];
}
else if ([key isEqualToString: @lancolor])
{
[lanLight setTextColor:[NSColor colorFromHexidecimalValue:
keyValue]];
}
With lots (25 or so) more possible key values, and a half-dozen or
more different ways to update the UI element.
If I understand you correctly, then I had a similar problem in a Perl
web application: there were dozens of different run modes, each
corresponding to a different handler method (with the method names
themselves having essentially no relation to the run mode strings...
sigh). I eliminated the cascade of if-statements by mapping the run
modes to the methods directly with a hash map. You might be able to do
the same thing by e.g. using selectors as values in an NSDictionary.
Of course, it all depends on how your app's behavior needs to vary
with the responses you get from the networked device.
-Michael
___
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: Grand Central Details
On Jun 17, 2008, at 7:17 PM, Pierce T. Wetter III wrote: If you've ever used CoreNetwork you might get the idea, because CFNetwork is event-driven, rather then the shitty thread-per-socket style that CS students are taught. So you can easily handle a zillion connections with CoreNetwork. Too bad you can't avoid blocking at least occasionally with the event- driven APIs, meaning you still have to use threads to avoid it completely. And I fail to see what's so bad about having one thread per socket. Is it because Threads Are Hard? -Michael ___ 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: Writing a notifier app
Have you looked at Growl? -Michael Abhiram Dwivedi wrote: Hi, I need to build a functionality similar to gmail notifier. Any pointers if Cocoa would be the right approach or if some other technology (python?) can be used to create such an app? Also, if you know of a similar open source project, it would be great. Can you please suggest where to begin with / what to use. Thanks, Abhiram Send instant messages to your online friends http://uk.messenger.yahoo.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/gardnermj%40gmail.com This email sent to [EMAIL PROTECTED] ___ 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: Application support for Time Machine
What are you looking to accomplish with Time Machine? -Michael Ralf Edmund Stranzenbach wrote: Hi. I'm still wondering if there is any plug-in or extension type architecture that enables applications to cooperate with the TimeMachine backups much like Apples Mail or AddressBook application. Does anyone know, how those things might be accomplished ? regards Ralf Edmund Stranzenbach [EMAIL PROTECTED] ___ 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/gardnermj%40gmail.com This email sent to [EMAIL PROTECTED] ___ 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: Anyone used btlsocket framework?
I've used SmallSockets (http://smallsockets.sourceforge.net/) in a small project, with good results. It doesn't do run loop events, but in my opinion it's better to just use threads with blocking I/O anyway. -Michael On May 10, 2008, at 2:11 PM, Jens Alfke wrote: On 10 May '08, at 11:59 AM, Wade Tregaskis wrote: I haven't used it directly, but I did notice when looking at it that it seems to rely on you polling it... that's terrible, given you can setup a socket as a runloop source very easily and it operates very efficiently. By Jove, you're right! From BTLSocketManager: //! \brief Updates the sockets. //! //! This method should be called often. Managed sockets will not recieve data or //! finish pending connections until this method is called. NSTimer can be used //! to call this method on a regular basis. - (void)select That is just absurd. It might have been excusable ten years ago in the classic OS, when threading and asynchrony were so difficult, but as you point out, you pretty much have to go out of your way to be this badly-behaved on Mac OS X. Let us never speak of it again :-/ Anyone got a good socket framework to recommend? (I realize it's not that hard to roll your own with NSStreams, as shown in CocoaSockets, but a framework with a few more bells whistles would be nice.) —Jens___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/gardnermj%40gmail.com This email sent to [EMAIL PROTECTED] ___ 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: NSStream blocking behavior?
Responding to my own message here, but from looking at the
CFWriteStreamWrite documentation, that function does have the
semantics I was looking for (blocks until at least one byte has been
written). I would assume that NSOutputStream's -write:maxLength: has
the same behavior, though the docs don't specify this. Can anyone
confirm?
Is anyone else doing networking the same way I'm planning to? Is there
anything wrong with the following strategy?
-Put the reader and writer in their own threads
-Ignore events from the NSOutputStream and just do blocking writes
-Use -performSelector:onThread:withObject:waitUntilDone: to pass data
to/from the main thread
-Michael
On May 8, 2008, at 12:00 PM, Michael Gardner wrote:
Okay, then next question: what will happen if I call -
write:maxLength: on an NSOutputStream without having received a
NSStreamEventHasSpaceAvailable event? Is is guaranteed to block
until it has written at least one byte (assuming we're not dealing
with a fixed-length stream that has reached its capacity)?
I ask because, given that run-loop scheduling is not a guarantee
against blocking, I plan to put my NSOutputStream writing code in a
separate thread. It would be nice if I can ignore the stream events
entirely and just call -write:maxLength: whenever the thread
receives data to write, with something like:
- (void)sendLine: (NSString*)line {
NSUInteger bytesWritten = 0;
NSUInteger bytesToWrite = [line lengthOfBytesUsingEncoding:
NSUTF8StringEncoding];
char const * bytes = [line UTF8String];
while (bytesWritten bytesToWrite) {
NSInteger result = [outputStream write: bytes + bytesWritten
maxLength: bytesToWrite - bytesWritten];
if (result = 0)
@throw [NSException exceptionWithName: @WriterThreadException
reason: @Error writing to output stream userInfo: nil];
bytesWritten += result;
}
}
I would then use -performSelector:onThread:withObject:waitUntilDone:
from my main thread to queue data for sendLine to write. Is this a
viable approach?
-Michael
On May 8, 2008, at 2:58 AM, Stefan Haller wrote:
Michael Ash [EMAIL PROTECTED] wrote:
NSStream matches the semantics of the UNIX read/write calls. In both
cases, if you are informed that data or space is available, you can
issue a read or write for an arbitrary amount of data and be
guaranteed that it will not block.
I would have thought so too, but the NSStream documentation seems to
disagree (this is from the Stream Programming Guide for Cocoa
document):
: It should be pointed out that neither the polling nor run-loop
: scheduling approaches are airtight defenses against blocking. If
the
: NSInputStream hasBytesAvailable method or the NSOutputStream
: hasSpaceAvailable method returns NO, it means in both cases that
the
: stream definitely has no available bytes or space. However, if
either
: of these methods returns YES, it can mean that there is available
: bytes or space or that the only way to find out is to attempt a
read
: or a write operation (which could lead to a momentary block). The
: NSStreamEventHasBytesAvailable and NSStreamEventHasSpaceAvailable
: stream events have identical semantics.
I'm not sure exactly what momentary block means here.
--
Stefan Haller
Ableton
http://www.ableton.com/
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/gardnermj
%40gmail.com
This email sent to [EMAIL PROTECTED]
___
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: -draggingEntered: never gets called [SOLVED]
It turns out that this was caused by manipulating the GUI outside the main thread. Once I realized that and refactored accordingly, the issue went away. No wonder I was having trouble duplicating the symptoms! Thanks to everybody who helped me figure this out. -Michael On May 5, 2008, at 4:02 PM, Michael Gardner wrote: I'm trying to implement drag drop in an NSView subclass. I made sure that the source returns NSDragOperationMove in - draggingSourceOperationMaskForLocal:, and that the destination calls -registerForDraggedTypes: with the same (custom) type that the source uses for the drag operation. The drag operation starts properly, but the destination's - draggingEntered: method never gets called, no matter what I do. What could cause this? Does it matter if the source and destination are the same object? -Michael ___ 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]
NSStream blocking behavior?
Are there any guarantees about blocking behavior for NSInputStream and NSOutputStream? For example, if I receive an NSStreamEventHasSpaceAvailable for an NSOutputStream, how many bytes can I write without blocking? It doesn't seem safe to do I/O in the main thread if there are no such guarantees, but the documentation on Cocoa streams is unsettlingly vague on this point. -Michael ___ 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: -draggingEntered: never gets called [solved?]
With help from Stéphane Sudre, I found that calling - registerForDraggedTypes: somewhere outside the destination's -init: method solves the issue. Can anyone shed light on why this would be? My views are created programatically rather than loaded from a .nib, so there shouldn't be any interference from that side of things. As far as I can tell, this looks to be a bug in Cocoa's DnD code, or at least a caveat that should be mentioned in the documentation... -Michael On May 5, 2008, at 4:02 PM, Michael Gardner wrote: I'm trying to implement drag drop in an NSView subclass. I made sure that the source returns NSDragOperationMove in - draggingSourceOperationMaskForLocal:, and that the destination calls -registerForDraggedTypes: with the same (custom) type that the source uses for the drag operation. The drag operation starts properly, but the destination's - draggingEntered: method never gets called, no matter what I do. What could cause this? Does it matter if the source and destination are the same object? -Michael ___ 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: -draggingEntered: never gets called [solved?]
My actual init method has a different signature, and calls - initWithFrame: on its superclass. I was trying to abstract away extra details, but I shouldn't have made it look like an actual method signature. Sorry about that. -Michael On May 6, 2008, at 9:34 AM, I. Savant wrote: With help from Stéphane Sudre, I found that calling -registerForDraggedTypes: somewhere outside the destination's - init: method solves the issue. Can anyone shed light on why this would be? I've never personally experienced the problem you're describing, but if you're literally calling this from an init method with this signature: - (id)init ... then You're Doing It Wrong. Views and their subclasses use -initWithFrame: as their designated initializer. If your call to -registerForDraggedTypes: is in an -init method, it won't get called unless you're creating your view with that method ... which you shouldn't do because it's a view and strange things will happen. -- I.S. ___ 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: -draggingEntered: never gets called [solved?]
Upon further investigation, I've found that if I call - registerForDraggedTypes: before adding the view to its parent window with -setContentView:, I never get the -draggingEntered: messages. If I do so afterwards, everything works properly. Is this expected behavior? As for posting the code, I'm trying to put together a minimal test case, but so far I haven't been able to duplicate the problem. There must be some relevant difference between the test case and my actual code, but I haven't been able to figure out what that is yet. -Michael On May 6, 2008, at 10:14 AM, I. Savant wrote: On Tue, May 6, 2008 at 10:44 AM, Michael Gardner [EMAIL PROTECTED] wrote: My actual init method has a different signature, and calls - initWithFrame: on its superclass. I was trying to abstract away extra details, but I shouldn't have made it look like an actual method signature. Sorry about that. At this point, I think it's time to post your relevant code. Again, I have never run across the problem you've described -- it should work as far as I know. I'll assume you've verified that your own init method (and the associated call to is -registerForDraggedTypes:) is actually called as expected (ie, you've stepped through it with the debugger and it is in fact called). -- I.S. ___ 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: -draggingEntered: never gets called [solved?]
Which is irrelevant, since I'm constructing my views programatically. Anyway, I've long since verified that my methods are all getting called as expected (except for -draggingEntered:, of course). -Michael On May 6, 2008, at 6:24 PM, Kyle Sluder wrote: On Tue, May 6, 2008 at 10:44 AM, Michael Gardner [EMAIL PROTECTED] wrote: My actual init method has a different signature, and calls - initWithFrame: on its superclass. I was trying to abstract away extra details, but I shouldn't have made it look like an actual method signature. Sorry about that. IB will never call this method. It will always call -initWithFrame:, as it has no way of knowing that you have designated a different initializer. --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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: -draggingEntered: never gets called [solved?]
If so, it should be documented. As soon as I can get together a working test case, I'll submit a bug report. It would be nice to get some confirmation from an Apple engineer, though, since I'm having trouble duplicating the issue. -Michael On May 6, 2008, at 6:30 PM, Graham Cox wrote: I'm not sure if it's documented as such, but I *think* this is expected behaviour. The reality is that the dragging is really implemented by the underlying window (ultimately using Carbon) so if the view has no reference to its window when the drag types are registered, they probably just get lost. A nib-instantiated window won't have this problem as it's most likely built top down. Generally it's probably wise to build structures completely (in this case window+views) before trying to set up high-level behaviours on them which probably do assume that things are fully constructed. G. On 7 May 2008, at 1:34 am, Michael Gardner wrote: Upon further investigation, I've found that if I call - registerForDraggedTypes: before adding the view to its parent window with -setContentView:, I never get the -draggingEntered: messages. If I do so afterwards, everything works properly. Is this expected behavior? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
-draggingEntered: never gets called
I'm trying to implement drag drop in an NSView subclass. I made sure that the source returns NSDragOperationMove in - draggingSourceOperationMaskForLocal:, and that the destination calls - registerForDraggedTypes: with the same (custom) type that the source uses for the drag operation. The drag operation starts properly, but the destination's - draggingEntered: method never gets called, no matter what I do. What could cause this? Does it matter if the source and destination are the same object? -Michael ___ 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: -draggingEntered: never gets called
The source implements -draggingSourceOperationMaskForLocal: and - mouseDown: (for initiating the drag). The destination implements -draggingEntered:, - prepareForDragOperation:, and -performDragOperation:. I checked the pasteboard's types list, and the result is as expected. For reference, here's how I start the drag: NSPasteboard * pboard = [NSPasteboard pasteboardWithName: NSDragPboard]; [pboard declareTypes: [NSArray arrayWithObject: MyPasteboardType] owner: nil]; if ([pboard setData: dragData forType: MyPasteboardType]) [self dragImage: dragImage at: dragLoc offset: NSZeroSize event: event pasteboard: pboard source: self slideBack: YES]; -Michael On May 5, 2008, at 4:25 PM, Stéphane Sudre wrote: On May 5, 2008, at 11:02 PM, Michael Gardner wrote: I'm trying to implement drag drop in an NSView subclass. I made sure that the source returns NSDragOperationMove in - draggingSourceOperationMaskForLocal:, and that the destination calls -registerForDraggedTypes: with the same (custom) type that the source uses for the drag operation. The drag operation starts properly, but the destination's - draggingEntered: method never gets called, no matter what I do. What could cause this? Does it matter if the source and destination are the same object? What methods did you implement in your view for drag drop? Did you log the content of the pasteboard after the drag is initiated? ___ 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/gardnermj%40gmail.com This email sent to [EMAIL PROTECTED] ___ 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]
