Re: Moving controls interactively

On Sep 26, 2009, at 11:58 AM, Scott Stevenson wrote:
> On Sep 26, 2009, at 5:22 AM, Andrea D'Amore wrote:
>
>> I'd like to let an user move controls around the window, i.e. he  
>> should be able to both rearrange buttons, text fields, labels and  
>> images and to use them.
>>
>> I'm using a non NSDocument based project in XCode, I created a  
>> MyWindow subclass of NSWindow and I overrode sendEvent.
>> In sendEvent I check if a flag in controller is set and then either  
>> pass along sendEvent by running [super sendEvent:event]; or I set  
>> the control position using setFrame.
>
>
> Overriding sendEvent is NSWindow is almost always too low level –  
> you end up subverting the Cocoa event system and losing a lot of  
> conveniences.
>
> Instead, you can just override mouseDown or mouseDragged in your  
> controls. If your special "rearrange mode" flag is set as you  
> describe, then you can adjust the frame as the mouse is moved. If  
> the flag isn't set, you can just call [super mouseDown:] or [super  
> mouseDragged:]. The advantage of this is Cocoa will send events to  
> the right control automatically.
>
> I'm not sure how many apps do this, but I can't see any reason it  
> wouldn't work and certainly isn't a hack. The only downside to this  
> is that the controls probably need to be subclasses. I'm not sure if  
> that works for your app.
>
> I don't know of an example that does this offhand, but I hope that  
> description helps.

Subverting the normal dispatch of mouse events when the drag flag is  
set -- and only when the drag flag is set -- might be the very point  
of the exercise, or might not.  I think it depends on what the real  
requirements are.

Is the purpose to give the user the power to decide on their UI  
layout?  If so, I wonder if arbitrary dragging of controls is *too*  
much control.  Maybe it would be better to offer a few canned layouts,  
all conforming to the HIG, that the user can choose in the application  
preferences.

If there's one particular kind of control this behavior is intended  
for -- say it's a Scrabble game and NSButtons are used for the tiles  
-- then I agree subclassing NSButton makes sense.

On the other hand, if the application is some sort of IB-like tool for  
laying out user interfaces, then I would have reservations about  
subclassing every possible control class that might go into the  
window.  Overriding the window's sendEvent: (and maybe adding a  
category on one or more control classes) is just one alternative.   
Another approach would be to wrap each control instance in a special  
class that implements the desired behavior, similar to what IB does  
(or used to do) IIRC.

So I guess I would ask -- what is the ultimate purpose for the  
draggable controls?

--Andy