Carbon events help

[aarku]

I have been trying to get mouse dragged events working for a long time. I don't get it. Here is an 11kb download which is a slightly modified version of the "Carbon Application" template in XCode.

http://www.tc.umn.edu/~czec0035/files/DragTest.tar.gz

What am I doing wrong???

Thanks
-Jon

[aarku]

The window is using the standard event handler. If you uncheck it in IB, it works. (Thanks OSC) However, this really isn't a solution. When using the standard handler, it will work if another window is in the foreground and you click into the application window and drag.

This is wacko.

-Jon

[NCarter]

It works if you turn off Compositing in IB, too. I can't imagine why it would make a difference.

[aarku]

It works if you turn off Compositing in IB, too. I can't imagine why it would make a difference.

Interesting. What's compositing again. . ? I thought that had to do with how things were drawn in the window. Things seem to work the same without it -- besides dragged events working.

-Jon

update: here's a doc on compositing -- but this doesn't make any sense why it would make a difference

http://developer.apple.com/documentation/Carbon/Conceptual/Upgrading_HIToolbox/upgrading_hitoolbox_conc/chapter_2_section_4.html

[NCarter]

Thinking about it, compositing totally changes the way the controls in the window are represented internally, although the difference isn't apparent from the developer's point of view. You know, it might be that you're seeing a bug here. HIView is a fairly new technology, so maybe this just doesn't work properly yet.

Incidentally, why do you want to handle drag events in the window event handler? Would you be able to handle the drag events in a control instead? Maybe you could write a Control definition or HIView derivative to handle your drags (although it might not work any better!).

[aarku]

It's for a level editor -- drawing terrain and placing/moving sprites.

Someone on carbon-dev (finally!) responded and said that the content view is tracking and eating my kEventMouseDragged events. He recommended putting a view in front of the content view and doing my mouse tracking on the view rather than at the window level.

. . . .

Not completely sure I totally understand the solution, but I don't like it either way. Seems silly. I should just poll with Button() and GetMouse.

-Jon

[NCarter]

If your window is going to be completely covered by an OpenGL context or has only very simple controls, I'd just turn off compositing for that window. You won't be missing much if your OpenGL context isn't a custom HIView.

Even if you're not using OpenGL, if you're just drawing all over the window's port instead of making a custom HIView, the same applies.

Not completely sure I totally understand the solution, but I don't like it either way. Seems silly. I should just poll with Button() and GetMouse.
You could do this, but it could be a bit processor intensive and Apple recommend against it for that reason. If you plan to make your tool usable for other people, I think it would be better to try to use events.

[aarku]

Thanks again for the response. It sounds like turning off compositing is my best answer. It would be my understanding then that it would suffer no noticable ill effects. The window is indeed completely covered by an OpenGL context. I have a quick hack working with polling for the mouse, but it has some usability bugs so I will be switching to events like I wanted to be using in the first place :rolleyes:

Thanks again! I'm glad I finally got this cleared up.

-Jon