Re: Objective-C Question
On 12 Mar 2013, at 21:34, Graham Cox wrote: On 13/03/2013, at 6:53 AM, Dave d...@looktowindward.com wrote: If that is the case, then how do you signal to the compiler/ analyzer that you are returning a retained object? In general you shouldn't return a retained object (unless it's temporarily retained and will be autoreleased of course) Why? Where does it say this? And Autorelease is evil and should never be used if it can be avoided! . If you are routinely doing this then your design is flawed. The reason it's hard to signal to the compiler that you're returning a retained object is that you shouldn't be doing it. When you have to do it, use the word 'new' in the method. How many years experience do you have writing applications and OS level software? I've been doing it since that late 70's. And, in all that time, I have never (well rarely it's a long time!) heard a more silly statement then If you are routinely doing this then your design is flawed. (this meaning returning a retained object). In that case Unix, MacOS X and most software on the market has a flawed design according to this logic! I've never seen anything about this written down in any Apple document. In fact see below - Apple seems to disagree with you! The reason it's hard to signal to the compiler that you're returning a retained object is that you shouldn't be doing it. When you have to do it, use the word 'new' in the method. So, the design is flawed because it's hard to signal to the compiler that you are retuning a retain object? Do you realize how silly that sounds? How can a compiler option/feature affect a design? Also, are you saying that ARC is a flawed design? With ARC you do nothing BUT return retained objects! So lets say we have a number of fairly complex (non ARC) iPad Applications that work wonderfully with no memory leaks. The code is well written, commented and easy to understand and maintain, but these Apps contained methods that routinely return retained objects. Would you then say these apps have a Flawed Design simply for this reason? The fact of the matter is that this *is* routinely done in many commercial applications that I have worked on and by many developers, both on the Mac and iOS. Originally, I don't think there was a new prefix, so older code has lots of methods beginning with alloc. The new was added later to make it easier to signal to the compiler the the method is returning a retained object. Most developers I worked with think that using new as a prefix when returning a retained object. Besides all this, it isn't hard to signal to the compiler you are returning a retained object, you just prefix the name with new, alloc, retain etc. As per: http://clang.llvm.org/docs/LanguageExtensions.html#related-result-types Unless there is another prefix to use, they I am going to continue ignore it too! Again, no offence intended but when a person doesn't follow a rule because they think it doesn't apply to them, it's just a sign of inexperience and/or lack of understanding. Sorry, but there it is. I don't think the rule doesn't apply to just me, I think it's doesn't apply to *anyone* and that it either isn't a rule and you are mistaken or if it is a rule, it's a stupid one and I don't follow stupid rules. The only reason you have given me is that this is bad is that hard to signal to the compiler that you're returning a retained object but it isn't hard, you just prefix with new. If there are other reasons, then please do let me know and I will consider what you say, but so far you've not given one reference to an Apple doc that categorically states this and no real reason why its bad apart from it's hard to signal the compiler what you are doing, which is isn't! So, pardon me if I take no notice of what you say! There are loads of rules in life that no one pays any attention to! There are load of rules that Apple have made that are routinely broken. A few that spring to mind are, using _ in iVar names, have getters/setters with non-standard names, For instance, there is a law in England that dates back hundreds of year that states that a Male may urinate on the public highway as long as he alerts people to this fact uses the offside of his cab to shield passers by from this unsightly spectacle! How many men do you hear announcing in Oxford street that that are going to Urinate and then doing it against the offside of their car! Not Many! There is another that says perambulated baby carriages much be wheeled off the pavement and on the road! How many people do you see wheeling their offspring along the slow lane side of the A40? Not many. However, according to you, these rules must be obeyed! So next time you need to relieve yourself while wheeling your baby buggy along a public highway, just announce the fact that you are about to urinate and
Re: Another Gnarly Objective-C Question!
Le 13 mars 2013 à 01:55, Wim Lewis w...@omnigroup.com a écrit : On 12 Mar 2013, at 2:08 AM, Graham Cox wrote: in a + method, [self class] === self. Once you've got that, you've got it. You're overthinking this. A class method is just an instance method of the class object. No magic at all. So all this confusion you've caused yourself about [super class] and so on is wholly unnecessary to correctly use class methods. To be very slightly pedantic, the only magic here is 'super' --- sending a message to super (which you can only do from a method implementation) is special syntax that searches for the method starting with the implementation's class's superclass, rather than at the receiver's actual class. Everything else is non-magic. (In general, that's been one of the strengths of ObjC: very little magic.) To be ever more pedantic, there is other magic involved when sending a message to a class. If there is no class method that matches the selector, the runtime will then search for instance methods of the root class. So you can use NSObject instance (like performSelector:) method on all NSObject subclasses. http://www.sealiesoftware.com/blog/archive/2009/04/14/objc_explain_Classes_and_metaclasses.html -- Jean-Daniel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Objective-C Question
On 3/13/13 9:36 AM, Dave wrote: On 12 Mar 2013, at 21:34, Graham Cox wrote: On 13/03/2013, at 6:53 AM, Dave d...@looktowindward.com wrote: If that is the case, then how do you signal to the compiler/analyzer that you are returning a retained object? In general you shouldn't return a retained object (unless it's temporarily retained and will be autoreleased of course) Why? Where does it say this? https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html And Autorelease is evil and should never be used if it can be avoided! Nonsense. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Objective-C Question
On 12 Mar 2013, at 21:25, Graham Cox wrote:
On 13/03/2013, at 2:41 AM, Dave d...@looktowindward.com wrote:
So, what is it? Wind up merchant or Moron?
I don't think there's any need for this. If I caused offence, it
was unintended (I sometimes have trouble anticipating how others
might receive statements I make, that's just something I have to
live with).
The further discussion doesn't really convince me that you've
really understood it, but if you have, great. Personally I have no
stake in whether you succeed or not, so if you choose to ignore
advice or insult the adviser, it makes no difference to me.
Look, you made a number of silly and wild comments, all I did was to
ask you do back them up. Perhaps I could have been kinder, but to be
honest, from your comments it showed you didn't even bother to read
the original post and the code contained therein, so again:
@interface BaseClass
+(NSMutableDictionary*) newDict;
@end
@implementation BaseClass
+(NSMutableDictionary*) newDict
{
return [[NSMutableDictionary alloc] init];
}
@class NewClass;
@interface NewClass : BaseClass
+(NSMutableDictionary*) newDict;
@end
#import BaseClass.h
@implementation NewClass
+(NSMutableDictionary*) newDict
{
NSMutableDictionary*myDict;
myDict = [[super class] newDict];
//** bug
[myDict setObject:@Some Data forKey:@someKey];
return myDict;
}
You said of this code:
Why not state you goals instead of give us a lump of incoherent code?
How is the above code incoherent? The text from that email:
I had assumed (and I thought I'd done something like this before)
that the:
myDict = [[super class] newDict];
statement would call newDict in BaseClass Instead it calls the
version in NewClass and goes into an infinite loop!!
How is this not stating my goals?
The attempts you made show a clear lack of understanding about
inheritance, which is what others were trying to tell you.
In what way does the above code show a clear lack of understanding
about inheritance ? To me and many others on this list, it just
showed a typeo/bug in one line of newly added code.
Then you post some other code, that was slower and didn't even do the
same job! Then you argued that it did do the same job and made light
of the fact that is was slower and even questioned the fact that it
might be slower. From that I could have said the attempts you made,
showed a clear lack of understanding abut memory management and how
container objects work in Cocoa.
The fact of the matter is that allocating a read-only array and then
copying it's contents into a mutable array is slower, but worse than
this, doesn't do the same thing at all. When I pointed out how it's
different, you went quiet and then had a go about something else!
The latest post really takes the cake though:
In general you shouldn't return a retained object (unless it's
temporarily retained and will be autoreleased of course). If you
are routinely doing this then your design is flawed. The reason
it's hard to signal to the compiler that you're returning a
retained object is that you shouldn't be doing it. When you have to
do it, use the word 'new' in the method.
According to you, many, many Apps have design flaws because they
contain methods that return retained objects! What a croc! rofl!
So, lets explore this stupidity a little! This is the Non-ARC case,
obviously. I need to create an Object that has a different class type
than the class I am working in. I want to retain the object locally
in the current method. Normally I would write
-(Obj*) newObject
{
Obj*myObj;
myObj = [[Obj alloc] init];
// setup some fields in myObj
return myObj;
}
// Calling method:
Obj*myObj;
myObj = [self newObj];
// use myObj
[myObj release];
You are saying that this is a flawed design? Worse than that, you
seem to be saying that:
-(Obj*) getObject
{
Obj*myObj;
myObj = [[Obj alloc] init];
// setup some fields in myObj
return [myOb autorelease]j;
}
// Calling method:
Obj*myObj;
myObj = [self getObject];
[myObj retain];
// use myObj
[myObj release];
Is a better design? Is this really what you are saying? Because if it
is, I don't care about what any rule says. the second example is
Flawed over the first for obvious reasons. If you really do think
this, then justify it and I don't mean point me to some Apple Doc of
rules that was written years ago and has no real relevance to the
real world. Tell me in technical terms why example 2 is better than
example 1 or come up with a better way altogether.
So far AFAIAC you have been wrong on most of what you have said. I've
pointed out the reasons why I think you are wrong but you just ignore
them and pick on something else to be wrong about.
If you don' justify your reasoning, then regardless of
Moderator - Re: Objective-C Question
Moderator I've had a number of complaints about this thread. This thread has gone beyond all reasonable value and the behavior is not acceptable. Nobody has a requirement to read and answer questions. The questions have been answered politely by posters who have a long history on the list of helping people. Do not respond to this on the list. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
how to implement iphoto like animation while doing drag and drop on custom listview
Hi Friends,
i had developed the custom list view which is having NSView as a cell with
variable sizes to represent the video clips in the timeline.
and i had implemented the drag and drop for reordering functionality...
that is working as per the expectation...
but i wanted to add the animation while doing the drag and drop like in
iPhoto...
(when user drag the item if the mouse co-ords enters the in between region
then the corresponding elements will animate... and animation will end and
it comeback its original position once the mouse left the coords)
here i am including the drag and drop code please help me how i can
implement the above mentioned animation while doing drag and drop...
Thanks Regards,
Muthu
- (NSDragOperation)draggingEntered:(id NSDraggingInfo)sender
{
NSDragOperation theOperation = NSDragOperationNone;
self.highlightForDragAcceptance = YES;
BOOL dropHighlight = _highlightForDragAcceptance;
downLocation = [self convertPoint: [sender draggingLocation] fromView:
[self superview]];
dropindex = [self indexOfCellAtPoint:downLocation];
theOperation = [timelineViewController validateDrop:sender proposedCell:
dropindex
proposedDropHighlight: dropHighlight];
return theOperation;
}
- (NSDragOperation)draggingUpdated:(id NSDraggingInfo)sender
{
NSDragOperation theOperation = NSDragOperationNone;
self.highlightForDragAcceptance = YES;
BOOL dropHighlight = _highlightForDragAcceptance;
currentLocation = [self convertPoint: [sender draggingLocation] fromView:
[self superview]];
NSUInteger _numberOfCells = [[timelineViewController collection] count];
NSArray * sprites = [timelineViewController collection];
dropindex = [self indexOfCellAtPoint:currentLocation];
theOperation = [timelineViewController validateDrop:sender proposedCell:
dropindex
proposedDropHighlight: dropHighlight];
return theOperation;
}
- (void)draggingExited:(id NSDraggingInfo)sender
{
#pragma unused(sender)
self.highlightForDragAcceptance = NO;
}
- (BOOL)prepareForDragOperation:(idNSDraggingInfo)sender
{
sender.animatesToDestination = YES;
return YES;
}
- (BOOL)performDragOperation:(id NSDraggingInfo)sender
{
BOOL highlight = _highlightForDragAcceptance;
BOOL accepted = [timelineViewController acceptDrop:sender cellindex:
dropindex dropHighlight:highlight];
self.highlightForDragAcceptance = NO;
return accepted;
}
- (void)concludeDragOperation:(id NSDraggingInfo)sender
{
#pragma unused(sender)
}
- (void)draggingEnded:(id NSDraggingInfo)sender
{
#pragma unused(sender)
self.highlightForDragAcceptance = NO;
[self deselectSelectedObjects];
}
- (BOOL)wantsPeriodicDraggingUpdates
{
return YES;
}
- (BOOL)writeCellsWithIndexes:(NSIndexSet*)indexes toPasteboard:(
NSPasteboard *)dragPasteboard
{
[dragPasteboard declareTypes: [NSArray arrayWithObjects:
NSStringPboardType, nil] owner: self];
[dragPasteboard setString: @Just Testing forType: NSStringPboardType];
return YES;
}
- (NSDragOperation)validateDrop:(id NSDraggingInfo)info proposedCell:(
NSUInteger)index
proposedDropHighlight:(BOOL)dropHighlight;
{
return NSDragOperationCopy;
}
- (BOOL)acceptDrop:(id NSDraggingInfo)info cellindex:(NSUInteger)index
dropHighlight:(BOOL)dropHighlight
{
NSLog(@Accept Drop);
NSLog(@selection index:%i,[spritesController selectionIndex]);
NSLog(@drop index:%i,index);
MVSprite *temp = [collection objectAtIndex: [spritesController
selectionIndex]];
[spritesController removeObjectAtArrangedObjectIndex:[spritesController
selectionIndex]];
[spritesController insertObject:temp atArrangedObjectIndex:index];
NSArray * sprites = [self collection];
int count = [sprites count];
//layout the subviews
for (int i=0; icount; i++)
{
MVSprite * current = [sprites objectAtIndex:i];
if(i == 0)
{
current.start = 0;
current.end = current.start + current.duration;
[current setAnimate:YES];
[current.spriteView setSpriteViewFrame];
}else{
MVSprite * previous = [sprites objectAtIndex:i-1];
current.start = previous.end;
current.end = current.start + current.duration;
[current setAnimate:YES];
[current.spriteView setSpriteViewFrame];
}
}
}
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Snapping windows while moving
I'm using this:
//http://www.cocoadev.com/index.pl?MagneticWindows
- (void)windowDidMove:(NSNotification *)notification
{
NSEnumerator *e;
NSWindow *theWindow;
id edgeObject;
NSArray *frames = NSApp windows] copy] autorelease]
arrayByAddingObjectsFromArray:[NSScreen screens]];
//Edit 7 October 2004: this prefers window edges. change the above line to:
//NSArray *frames = [[NSScreen screens]
arrayByAddingObjectsFromArray:[NSApp windows]];
//to give snapping priority to screen edges.
NSRect frame, myFrame;
BOOL hDidChange = NO, vDidChange = NO;
float gravity = 3;
theWindow = [notification object];
myFrame = [theWindow frame];
e = [frames objectEnumerator];
if ([[NSApp currentEvent] modifierFlags] NSAlternateKeyMask) return;
while ((edgeObject = [e nextObject]))
{
if ( (edgeObject != theWindow
([edgeObject
respondsToSelector:@selector(isVisible)] [edgeObject isVisible]))
|| [edgeObject isKindOfClass:[NSScreen class]] )
{
// leave out the following if clause and just set frame
to [edgeObject frame]
//if you want windows to snap behind the dock
if ([edgeObject isKindOfClass:[NSScreen class]])
{
frame = [edgeObject visibleFrame];
}
else
{
frame = [edgeObject frame];
}
/* code continues here with */ /* horizontal magnet */
//NSLog(@%f %f, NSMinX(frame) - NSMinX(myFrame),
NSMinY(frame) - NSMinY(myFrame));
if (!hDidChange fabs(NSMinX(frame) -
NSMinX(myFrame)) = gravity)
{
//NSLog(@NSMinX(frame) - NSMinX(myFrame));
myFrame.origin.x = frame.origin.x;
hDidChange = YES;
}
if (!hDidChange fabs(NSMinX(frame) -
NSMaxX(myFrame)) = gravity)
{
//NSLog(@NSMinX(frame) - NSMaxX(myFrame));
myFrame.origin.x += NSMinX(frame) -
NSMaxX(myFrame);
hDidChange = YES;
}
if (!hDidChange fabs(NSMaxX(frame) -
NSMinX(myFrame)) = gravity)
{
//NSLog(@NSMaxX(frame) - NSMinX(myFrame));
myFrame.origin.x = NSMaxX(frame);
hDidChange = YES;
}
if (!hDidChange fabs(NSMaxX(frame) -
NSMaxX(myFrame)) = gravity)
{
//NSLog(@NSMaxX(frame) - NSMaxX(myFrame));
myFrame.origin.x += NSMaxX(frame) -
NSMaxX(myFrame);
hDidChange = YES;
}
/* vertical magnet */
if (!vDidChange fabs(NSMinY(frame) -
NSMinY(myFrame)) = gravity)
{
//NSLog(@NSMinY(frame) - NSMinY(myFrame));
myFrame.origin.y = frame.origin.y;
vDidChange = YES;
}
if (!vDidChange fabs(NSMinY(frame) -
NSMaxY(myFrame)) = gravity)
{
//NSLog(@NSMinY(frame) - NSMaxY(myFrame));
myFrame.origin.y += NSMinY(frame) -
NSMaxY(myFrame);
vDidChange = YES;
}
if (!vDidChange fabs(NSMaxY(frame) -
NSMinY(myFrame)) = gravity)
{
//NSLog(@NSMaxY(frame) - NSMinY(myFrame));
myFrame.origin.y = NSMaxY(frame);
vDidChange = YES;
}
if (!vDidChange fabs(NSMaxY(frame) -
NSMaxY(myFrame)) = gravity)
{
//NSLog(@(NSMaxY(frame) - NSMaxY(myFrame));
myFrame.origin.y += NSMaxY(frame) -
NSMaxY(myFrame);
vDidChange = YES;
}
}
//if (v_isChanged h_isChanged) break;
}
if ([[theWindow screen] isEqualTo:[NSScreen mainScreen]]) {
if ((myFrame.size.height+myFrame.origin.y)([[NSScreen mainScreen]
frame].size.height-20)) {
myFrame.origin.y = [[NSScreen mainScreen]
frame].size.height-myFrame.size.height-20;
Re: Objective-C Question
On 13 Mar 2013, at 09:24, Markus Spoettl wrote:
On 3/13/13 9:36 AM, Dave wrote:
On 12 Mar 2013, at 21:34, Graham Cox wrote:
On 13/03/2013, at 6:53 AM, Dave d...@looktowindward.com wrote:
If that is the case, then how do you signal to the compiler/
analyzer that you
are returning a retained object?
In general you shouldn't return a retained object (unless it's
temporarily
retained and will be autoreleased of course)
Why? Where does it say this?
https://developer.apple.com/library/mac/#documentation/Cocoa/
Conceptual/MemoryMgmt/Articles/mmRules.html
And Autorelease is evil and should never be used if it can be
avoided!
Nonsense.
Obviously, it isn't evil, but from experience of working on 5 or more
major iOS applications, I've found most bugs were caused as a
consequence of autorelease, that's why I avoid it if possible. I
don't have a problem with memory management, it's simple as long as
you follow the rules.
Avoiding autorelease makes it run faster anyway and makes the whole
app more robust in general. Autorelease in the wrong hands can cause
massive inefficiencies that you'd never code otherwise, here are some
examples of what I mean:
-(NSString*) processString:(NSString*) theString
{
NSString* myWorkString;
myWorkString = [theString stringByReplacingOccurencesOfSting:@/b
with:@BOLD]; //1
myWorkString = [theString stringByReplacingOccurencesOfSting:@/i
with:@ITALICS]; //2
myWorkString = [theString stringByReplacingOccurencesOfSting:@/u
with:@UNDERLINE]; //3
myWorkString = [theString stringByReplacingOccurencesOfSting:@*
with:@ASTERISK];//4
myWorkString = [theString stringByReplacingOccurencesOfSting:@
with:@AMPERSAND]; //5
myWorkString = [theString stringByReplacingOccurencesOfSting:@$
with:@DOLLAR];//6
and so on
return myWorkString;
}
This code creates 5 strings that are not needed and will clog up
memory until the runloop is called or the pool is drained. Imagine
there were 30 such replacements going on and the initial theString is
large ( 100K) and there are 100's of these strings.
You don't need a degree in applied meta physics to see where this is
going. It's not the fault of autorelease I know, it's the fault on
inexperienced developers or people that blindly follow rules.
The underlying problem is that it makes the above method data
dependent without really drawing much attention to this fact. I
actually had a bug that was caused by this. I worked on an iPad app
for an International Newspaper. The App was working ok, until one day
it crashed a 5 AM when the new edition was published and the iPad
client software downloaded and processed it. When it got to the
sports section a method similar to the above (although a lot more
complex with a LOT more autorealsed objects) crashed. I got in a 6 AM
and it took me a good while to figure out what was wrong. On that
particular day, the paper published the football (soccer) league
tables for the whole of the UK. Apart from there being a loads of
data, it was also heavily attrubuted, bold, italics, colours etc.
Well it was too much for the method and when it had built up around
80 to 100 MB of useless autoreleased strings, it crashed!!
There are loads of other problems I come across as a side effect of
junior (and sometimes senior) developers using autorelease, but I
think the above described above was the worst.
That's why I say it's evil and I avoid it with a vengeance. So why
do you think it's a force for good?
Besides all this, is it really so hard to add:
[ release];
It's less typing than autorelease anyway!!!
All the Best
Dave
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Snapping windows while moving
And you're seeing that getting called for every single movement of the mouse? -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 On Mar 13, 2013, at 00:11:50, Tamas Nagy tamas.lov.n...@gmail.com wrote: - (void)windowDidMove:(NSNotification *)notification ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Snapping windows while moving
Exactly. On Mar 13, 2013, at 1:56 PM, Steve Mills smi...@makemusic.com wrote: And you're seeing that getting called for every single movement of the mouse? -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 On Mar 13, 2013, at 00:11:50, Tamas Nagy tamas.lov.n...@gmail.com wrote: - (void)windowDidMove:(NSNotification *)notification ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/tamas.lov.nagy%40gmail.com This email sent to tamas.lov.n...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Snapping windows while moving
On Mar 12, 2013, at 3:11 PM, Steve Mills wrote: What's the best way to go about snapping windows to screens and other windows while dragging the window? I've tried catching it in windowDidMove (only when the mouse is down), but that isn't called for every single movement of the mouse. I haven't been able to find anything equivalent to the old kEventWindowBoundsChanging with kWindowBoundsChangeUserDrag, which was exactly what was needed to do this. It needs to be available in 10.7 on up. The Window Server moves most windows entirely without involving the app (until the move is completed). If you want to change how windows get moved, I think you have to take over the whole process. You do [window setMovable:NO] to make the Window Server not move your windows itself. Instead, you get the relevant mouse events and you write typical mouse drag code and change the window frame manually. See the docs for -[NSWindow isMovable]. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: how to implement iphoto like animation while doing drag and drop on custom listview
On Mar 6, 2013, at 10:28 PM, Muthulingam Ammaiappan muthulinga...@gmail.com wrote: here i am including the drag and drop code please help me how i can implement the above mentioned animation while doing drag and drop... This is too broad and vague. What you’re asking is something for a paid consultant, not mailing-list volunteers. —Jens smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: how to implement iphoto like animation while doing drag and drop on custom listview
Take a look at the MultiPhotoFrame sample source:
http://developer.apple.com/library/mac/#samplecode/MultiPhotoFrame/Introduc
tion/Intro.html
The dragged images are animated as they enter/exit views by tracking the
mouse using this NSDraggingSource Protocol method:
- (void)draggingSession:(NSDraggingSession *)session
movedToPoint:(NSPoint)screenPoint
Also, check out the following WWDC 2011 video. It explains how to change
drag images in flight.
https://developer.apple.com/videos/wwdc/2011/?id=115
I'm writing similar code at the moment.
Chuck
On 3/6/13 11:28 PM, Muthulingam Ammaiappan muthulinga...@gmail.com
wrote:
Hi Friends,
i had developed the custom list view which is having NSView as a cell with
variable sizes to represent the video clips in the timeline.
and i had implemented the drag and drop for reordering functionality...
that is working as per the expectation...
but i wanted to add the animation while doing the drag and drop like in
iPhoto...
(when user drag the item if the mouse co-ords enters the in between region
then the corresponding elements will animate... and animation will end and
it comeback its original position once the mouse left the coords)
here i am including the drag and drop code please help me how i can
implement the above mentioned animation while doing drag and drop...
Thanks Regards,
Muthu
- (NSDragOperation)draggingEntered:(id NSDraggingInfo)sender
{
NSDragOperation theOperation = NSDragOperationNone;
self.highlightForDragAcceptance = YES;
BOOL dropHighlight = _highlightForDragAcceptance;
downLocation = [self convertPoint: [sender draggingLocation]
fromView:
[self superview]];
dropindex = [self indexOfCellAtPoint:downLocation];
theOperation = [timelineViewController validateDrop:sender proposedCell:
dropindex
proposedDropHighlight: dropHighlight];
return theOperation;
}
- (NSDragOperation)draggingUpdated:(id NSDraggingInfo)sender
{
NSDragOperation theOperation = NSDragOperationNone;
self.highlightForDragAcceptance = YES;
BOOL dropHighlight = _highlightForDragAcceptance;
currentLocation = [self convertPoint: [sender draggingLocation]
fromView:
[self superview]];
NSUInteger _numberOfCells = [[timelineViewController collection]
count];
NSArray * sprites = [timelineViewController collection];
dropindex = [self indexOfCellAtPoint:currentLocation];
theOperation = [timelineViewController validateDrop:sender
proposedCell:
dropindex
proposedDropHighlight: dropHighlight];
return theOperation;
}
- (void)draggingExited:(id NSDraggingInfo)sender
{
#pragma unused(sender)
self.highlightForDragAcceptance = NO;
}
- (BOOL)prepareForDragOperation:(idNSDraggingInfo)sender
{
sender.animatesToDestination = YES;
return YES;
}
- (BOOL)performDragOperation:(id NSDraggingInfo)sender
{
BOOL highlight = _highlightForDragAcceptance;
BOOL accepted = [timelineViewController acceptDrop:sender cellindex:
dropindex dropHighlight:highlight];
self.highlightForDragAcceptance = NO;
return accepted;
}
- (void)concludeDragOperation:(id NSDraggingInfo)sender
{
#pragma unused(sender)
}
- (void)draggingEnded:(id NSDraggingInfo)sender
{
#pragma unused(sender)
self.highlightForDragAcceptance = NO;
[self deselectSelectedObjects];
}
- (BOOL)wantsPeriodicDraggingUpdates
{
return YES;
}
- (BOOL)writeCellsWithIndexes:(NSIndexSet*)indexes toPasteboard:(
NSPasteboard *)dragPasteboard
{
[dragPasteboard declareTypes: [NSArray arrayWithObjects:
NSStringPboardType, nil] owner: self];
[dragPasteboard setString: @Just Testing forType: NSStringPboardType];
return YES;
}
- (NSDragOperation)validateDrop:(id NSDraggingInfo)info proposedCell:(
NSUInteger)index
proposedDropHighlight:(BOOL)dropHighlight;
{
return NSDragOperationCopy;
}
- (BOOL)acceptDrop:(id NSDraggingInfo)info cellindex:(NSUInteger)index
dropHighlight:(BOOL)dropHighlight
{
NSLog(@Accept Drop);
NSLog(@selection index:%i,[spritesController selectionIndex]);
NSLog(@drop index:%i,index);
MVSprite *temp = [collection objectAtIndex: [spritesController
selectionIndex]];
[spritesController
removeObjectAtArrangedObjectIndex:[spritesController
selectionIndex]];
[spritesController insertObject:temp atArrangedObjectIndex:index];
NSArray * sprites = [self collection];
int count = [sprites count];
//layout the subviews
for (int i=0; icount; i++)
{
MVSprite * current = [sprites objectAtIndex:i];
if(i == 0)
{
current.start = 0;
current.end = current.start + current.duration;
[current setAnimate:YES];
[current.spriteView setSpriteViewFrame];
}else{
MVSprite * previous = [sprites objectAtIndex:i-1];
current.start =
Re: Another Gnarly Objective-C Question!
On Mar 13, 2013, at 2:13 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 13 mars 2013 à 01:55, Wim Lewis w...@omnigroup.com a écrit : On 12 Mar 2013, at 2:08 AM, Graham Cox wrote: in a + method, [self class] === self. Once you've got that, you've got it. You're overthinking this. A class method is just an instance method of the class object. No magic at all. So all this confusion you've caused yourself about [super class] and so on is wholly unnecessary to correctly use class methods. To be very slightly pedantic, the only magic here is 'super' --- sending a message to super (which you can only do from a method implementation) is special syntax that searches for the method starting with the implementation's class's superclass, rather than at the receiver's actual class. Everything else is non-magic. (In general, that's been one of the strengths of ObjC: very little magic.) To be ever more pedantic, there is other magic involved when sending a message to a class. If there is no class method that matches the selector, the runtime will then search for instance methods of the root class. Note that this isn't magic really; it's a quirk of the type system (both formal and dynamic). The root metaclass is a subclass of the root class. This can be problematic if you really want your root class to have a layout that's bigger than just an isa field, because the ABI and runtime just hardcode the layout of classes and there is no room for extra fields there — thus you need to be sure that anything using your extra fields is never invoked on a class object. John. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
KeyboardType for an iOS searchBar.
Hopefully, this will be a more constructive question for the list. On iOS in Xcode 4.2, I've put a storyboard scene together with a tableView and a searchBar. The searchBar searches the tableView just fine, but my problem is how and when the storyboard defaults are applied to the searchBar and the resulting keyboard? I ask, because it appears that it's only possible to override the storyboard defaults to set the keyboardType within the searchBar:textDidChange: method and this seems really clunky. I'm using the methods below and I've tried setting the keyboardType on the viewController's viewDidLoad, viewDidAppear, after notification from UIKeyboardDidShowNotification, nothing works to override the setting used in the storyboard except for searchBar:textDidChange:, which is not acceptable. [searchBar setKeyboardType:UIKeyboardTypeNumbersAndPunctuation]; [searchBar reloadInputViews]; I'm extending the interface to use the UISearchBarDelegate. Is there anything obvious here that I might be missing? TIA, - Zav ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Another Gnarly Objective-C Question!
Le 13 mars 2013 à 18:13, John McCall rjmcc...@apple.com a écrit : On Mar 13, 2013, at 2:13 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 13 mars 2013 à 01:55, Wim Lewis w...@omnigroup.com a écrit : On 12 Mar 2013, at 2:08 AM, Graham Cox wrote: in a + method, [self class] === self. Once you've got that, you've got it. You're overthinking this. A class method is just an instance method of the class object. No magic at all. So all this confusion you've caused yourself about [super class] and so on is wholly unnecessary to correctly use class methods. To be very slightly pedantic, the only magic here is 'super' --- sending a message to super (which you can only do from a method implementation) is special syntax that searches for the method starting with the implementation's class's superclass, rather than at the receiver's actual class. Everything else is non-magic. (In general, that's been one of the strengths of ObjC: very little magic.) To be ever more pedantic, there is other magic involved when sending a message to a class. If there is no class method that matches the selector, the runtime will then search for instance methods of the root class. Note that this isn't magic really; it's a quirk of the type system (both formal and dynamic). The root metaclass is a subclass of the root class. Yes, nothing is magic if the magician reveals its tricks, that's why he should not do that ;-) This can be problematic if you really want your root class to have a layout that's bigger than just an isa field, because the ABI and runtime just hardcode the layout of classes and there is no room for extra fields there — thus you need to be sure that anything using your extra fields is never invoked on a class object. I usually avoid this kind of issue by not writing root class. The extra fields issue is not the only one that a root class can have. Even methods that do not access ivars should take care of the Class case (retain/release/autorelease for instance). -- Jean-Daniel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
UIPopoverController
I have seen some popovers that have a wider frame with text information. I cannot find how to specify this style and text an am asking for a pointer to the documentation for this feature. -koko ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UIPopoverController
Do you have a sample so we can see what you mean?
I've been doing a few popovers recently that are completely independent from a
UISplitViewController. It can be a little challenging getting a grip on how
you should set things up. Generally, I'll programmatically set the popover's
viewController with initWithContentViewController like so:
PopoverContentViewController *popoverContent =
[[PopoverContentViewController alloc] init];
// Setup the popover for use from the navigation bar.
infoPopoverController = [[UIPopoverController alloc]
initWithContentViewController:popoverContent];
infoPopoverController.popoverContentSize = CGSizeMake(320.0, 244.0);
infoPopoverController.delegate = self;
So, you can make the content as wide as you want within the
PopoverContentViewController view controller.
Then when a button is tapped, I'll call this:
- (IBAction)InfoButtonPressed:(id)sender {
// Set the sender to a UIBarButtonItem.
UIBarButtonItem *tappedButton = (UIBarButtonItem *)sender;
// If the master list popover is showing, dismiss it before presenting
the popover from the bar button item.
if (infoPopoverController != nil) {
[infoPopoverController dismissPopoverAnimated:YES];
}
// If the popover is already showing from the bar button item, dismiss
it. Otherwise, present it.
if (infoPopoverController.popoverVisible == NO) {
[infoPopoverController
presentPopoverFromBarButtonItem:tappedButton
permittedArrowDirections:UIPopoverArrowDirectionAny animated:YES];
}
else {
[infoPopoverController dismissPopoverAnimated:YES];
}
}
Hope this helps.
On Mar 13, 2013, at 4:09 PM, koko wrote:
I have seen some popovers that have a wider frame with text information.
I cannot find how to specify this style and text an am asking for a pointer
to the documentation for this feature.
-koko
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
This email sent to z...@mac.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Setting the position of new windows
I've spent most of the day researching and coding this, but still don't have it perfect. I need to position our new document windows so they aren't covered by palettes that might be visible. I've done this in my window controller's windowDidLoad method, as was suggested somewhere. I'm able to calculate the new frame and set it with setFrame. This works on the first window. But if I create a 2nd window, it is going through what looks like the default cascading code, mostly ignoring the setFrame I just did (the size is right, but it moves it around). Am I going about this in the wrong place, or do I have to do a whole bunch more stuff to make this work, like subclassing NSWindow and overriding cascadeTopLeftFromPoint or some such thing? -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Setting the position of new windows
I think you want to use -setShouldCascadeWindows:NO. On Mar 13, 2013, at 2:20 PM, Steve Mills smi...@makemusic.com wrote: I've spent most of the day researching and coding this, but still don't have it perfect. I need to position our new document windows so they aren't covered by palettes that might be visible. I've done this in my window controller's windowDidLoad method, as was suggested somewhere. I'm able to calculate the new frame and set it with setFrame. This works on the first window. But if I create a 2nd window, it is going through what looks like the default cascading code, mostly ignoring the setFrame I just did (the size is right, but it moves it around). Am I going about this in the wrong place, or do I have to do a whole bunch more stuff to make this work, like subclassing NSWindow and overriding cascadeTopLeftFromPoint or some such thing? -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/kperry%40apple.com This email sent to kpe...@apple.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Setting the position of new windows
On Mar 13, 2013, at 2:20 PM, Steve Mills wrote: I've spent most of the day researching and coding this, but still don't have it perfect. I need to position our new document windows so they aren't covered by palettes that might be visible. I've done this in my window controller's windowDidLoad method, as was suggested somewhere. I'm able to calculate the new frame and set it with setFrame. This works on the first window. But if I create a 2nd window, it is going through what looks like the default cascading code, mostly ignoring the setFrame I just did (the size is right, but it moves it around). Am I going about this in the wrong place, or do I have to do a whole bunch more stuff to make this work, like subclassing NSWindow and overriding cascadeTopLeftFromPoint or some such thing? If you don't want the cascading, you can turn that off in the window controller (setShouldCascadeWindows:). -- Seth Willits ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Setting the position of new windows
On Mar 13, 2013, at 16:29:36, Kevin Perry kpe...@apple.com wrote: I think you want to use -setShouldCascadeWindows:NO. That's an idea. I was hoping there was some way to say this is the frame for the first new window, but all others should respect it AND then go ahead and cascade down from there, because I'd still like to cascade the windows from that calculated position but hopefully without having to write all the code that Apple already wrote to cascade windows and ensure that they's still 100% onscreen in the first place. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: KeyboardType for an iOS searchBar.
Maybe I'm missing the point, but you can set the keyboard type in the storyboard settings for it.. Or do you need to change it programmatically for some particular reason? Op Mar 13, 2013, om 6:51 PM heeft Alex Zavatone z...@mac.com het volgende geschreven: Hopefully, this will be a more constructive question for the list. On iOS in Xcode 4.2, I've put a storyboard scene together with a tableView and a searchBar. The searchBar searches the tableView just fine, but my problem is how and when the storyboard defaults are applied to the searchBar and the resulting keyboard? I ask, because it appears that it's only possible to override the storyboard defaults to set the keyboardType within the searchBar:textDidChange: method and this seems really clunky. I'm using the methods below and I've tried setting the keyboardType on the viewController's viewDidLoad, viewDidAppear, after notification from UIKeyboardDidShowNotification, nothing works to override the setting used in the storyboard except for searchBar:textDidChange:, which is not acceptable. [searchBar setKeyboardType:UIKeyboardTypeNumbersAndPunctuation]; [searchBar reloadInputViews]; I'm extending the interface to use the UISearchBarDelegate. Is there anything obvious here that I might be missing? TIA, - Zav ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/diederik%40tenhorses.com This email sent to diede...@tenhorses.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: KeyboardType for an iOS searchBar.
Yeah, that's the point. I know you can set it a la the storyboard, but once it is set (once it's on the scene, the default is what is set) it's really hard to change. I have cases where the data the searchBar will be searching will all start with numbers and other cases where it will all start with letters. Based on the data, I would like to display the default keyboard, or the UIKeyboardTypeNumbersAndPunctuation keyboard. In any case, it appears to be very difficult to change the keyboard of the searchBar when it is created by placing it in a scene in a storyboard. If you know how to do it, I'd sure like to know how. Also, why is it so hard to override these UISearchBar properties defined by a storyboard setting? I've run into other cases where it's really difficult to enable/disable the cancel button + other settings of a UISearchBar. Thanks Diederik. On Mar 13, 2013, at 5:42 PM, Diederik Meijer | Ten Horses wrote: Maybe I'm missing the point, but you can set the keyboard type in the storyboard settings for it.. Or do you need to change it programmatically for some particular reason? Op Mar 13, 2013, om 6:51 PM heeft Alex Zavatone z...@mac.com het volgende geschreven: Hopefully, this will be a more constructive question for the list. On iOS in Xcode 4.2, I've put a storyboard scene together with a tableView and a searchBar. The searchBar searches the tableView just fine, but my problem is how and when the storyboard defaults are applied to the searchBar and the resulting keyboard? I ask, because it appears that it's only possible to override the storyboard defaults to set the keyboardType within the searchBar:textDidChange: method and this seems really clunky. I'm using the methods below and I've tried setting the keyboardType on the viewController's viewDidLoad, viewDidAppear, after notification from UIKeyboardDidShowNotification, nothing works to override the setting used in the storyboard except for searchBar:textDidChange:, which is not acceptable. [searchBar setKeyboardType:UIKeyboardTypeNumbersAndPunctuation]; [searchBar reloadInputViews]; I'm extending the interface to use the UISearchBarDelegate. Is there anything obvious here that I might be missing? TIA, - Zav ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/diederik%40tenhorses.com This email sent to diede...@tenhorses.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Setting the position of new windows
On Mar 13, 2013, at 2:38 PM, Steve Mills wrote: I think you want to use -setShouldCascadeWindows:NO. That's an idea. I was hoping there was some way to say this is the frame for the first new window, but all others should respect it AND then go ahead and cascade down from there, because I'd still like to cascade the windows from that calculated position but hopefully without having to write all the code that Apple already wrote to cascade windows and ensure that they's still 100% onscreen in the first place. The exact behavior you describe is the behavior I see when simply setting the window frame in windowDidLoad. -- Seth Willits ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Snapping windows while moving
On Mar 12, 2013, at 1:54 PM, Steve Mills wrote: Pretty sure you want to subclass and override constrainFrameRect:toScreen: but I can't recall off the top of my head whether this is called live for every movement. I believe it is. Nope. It only seems to be called when the window is being created and *after* the mouse has been released during a move. Oh I see. I was thinking of the -windowWillResize:toSize: delegate method which is called live for resizes. On Mar 13, 2013, at 6:06 AM, Tamas Nagy wrote: And you're seeing that getting called for every single movement of the mouse? Exactly. I definitely do not. I suspect Tamas misinterpreted the question? On Mar 13, 2013, at 8:34 AM, Ken Thomases wrote: The Window Server moves most windows entirely without involving the app (until the move is completed). Minor detail… while the window is being moved the app has no idea it's happening, but after the movement stops for some brief time (the mouse button can *still be held down*) the window's frame is changed. That is, while the mouse button is held down, the window frame *does* update, but only after the mouse has stopped moving for some short amount of time. The frame change happens transparently though — no calls to any setFrame method is made (and no notifications happen etc). So it's still useless, but it's interesting. If you want to change how windows get moved, I think you have to take over the whole process. You do [window setMovable:NO] to make the Window Server not move your windows itself. Instead, you get the relevant mouse events and you write typical mouse drag code and change the window frame manually. See the docs for -[NSWindow isMovable]. I too think this the only option. -- Seth ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
