Re: Moving controls interactively

Ken Ferry <[email protected]>
Newsgroups gmane.comp.macosx.devel
Message-ID <[email protected]>
On Sep 27, 2009, at 1:00 AM, Andrea D'Amore <[email protected]>  
wrote:

>
> On 26/set/09, at 23:37, Andy Lee wrote:
>
>> might be the very point of the exercise, or might not.  I think it  
>> depends on what the real requirements are.
>
> Overriding mouseDown and mouseDragged as Scott suggests was my first  
> idea, I though about subclassing all the elements but then I  
> wondered if going a little down the events chain would have allowed  
> me to have the logic controlling normal/rearrange mode just in one  
> place rather than in every subclass.

Yes, I agree that subclassing every view seems non-optimal. I would  
suggest implementing -[NSView hitTestForEvent:] on a canvas view in  
which all of your controls sit. This allows you to handle the event in  
your canvas rather than letting it propagate to the controls. Check  
out the docs.

-Ken, abbreviated due to iPhone.

>
>> 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.
>
> It's just a concept for now and probably I'll end being the only one  
> using it, so HIG is not a big concern. It's not too much freedom for  
> the user, but I understand your point, preset layouts is not what I  
> want now.
>
>> 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.
>
> It's like this one, tho' nothing big as IB.
> Actually I'm not sure how to instantiate controls programmatically  
> but iirc this is better documented, maybe it's in Hillegass too.
>
>> 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?
>
> Create a window to, say, interface with a sqlite database. Not only  
> you want to specify your elements like field, labels and image, but  
> you want to arrange those on screen too. And later on you could  
> decide that you want to rearrange those elements again, thus a  
> button in the panel or a menu item will let you to switch between  
> "use" and "arrange" mode.
>
> What did you mean by suggesting to add a category on control classes?
>
> --
> Andrea
>
> _______________________________________________
> MacOSX-dev mailing list
> [email protected]
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.