Hyperion Entertainment Message Boards

I've created a window object in which I restrict the IDCMP message range to the closewindow event only, by passing "WA_IDCMP, IDCMP_CLOSEWINDOW, /.../". This is just for the sake of testing something; the window has gadgets and menu and all. When I do WM_HANDLEINPUT for this particular window, I receive not only WMHI_CLOSEWINDOW but also other events (such as WMHI_MENUPICK). Is this normal or is something broken? Should I do anything else to restrict the event range for WM_HANDLEINPUT?

There is nothing broken. Just consider the WA_IDCMP flags independent of the WMHI events. Always explicitly handle the WMHI events you are interested in and ignore the rest.

My experience shows that flags from WA_IDCMP when specified on NewObject() are added to the default flags set by window.class internally. Some flags must be set by WA_IDCMP, for example IDCMP_RAWKEY, otherwise no WMHI_RAWKEY event will occur. You cannot unset flags by removing them from WA_IDCMP.

I have not yet tried what happens when you change flags by SetAttr(window_object,WA_IDCMP,...) and whether you can unset flags set by window.class internally.

If you set both WA_IDCMP and WINDOW_IDCMPHookBits on NewObject(), the IDCMPHookBits are not added to those in WA_IDCMP. You have to specify them explicitely in both tags.

@ssolie

ssolie wrote:Just consider the WA_IDCMP flags independent of the WMHI events. Always explicitly handle the WMHI events you are interested in and ignore the rest.

Why I'm asking: in connection with this thread, I'm working on a program that uses multiple windows generating Intuition input. I've decided to use a shared port for all windows to handle all incoming events in a single loop. As one of the windows is a drawing window that sends loads of INTUITION_MOUSEMOVE events, I'm trying to limit the amount of events other windows could possibly send to the shared port. I want the event handling to be as efficient as possible.

Any tips?

Depending on how different the windows are in their behaviour and purpose and on what the application does between the input events, it might be an idea to create a seperate process for each window. This surely will result in the highest possible responsiveness of your application and it might give the user the option to save his work in case one of the processes crashed. And it might be much easier to program and thus have less bugs.

trixie wrote:Any tips?

Yes, test it before worrying about it. If you notice there is a real problem then we can get into more complex solutions such as multiple message ports and so on.

@thomasrapp

My experience shows that flags from WA_IDCMP when specified on NewObject() are added to the default flags set by window.class internally. Some flags must be set by WA_IDCMP, for example IDCMP_RAWKEY, otherwise no WMHI_RAWKEY event will occur.

Are you sure? I use no WA_IDCMP tag for the program window in WordNet and yet I receive WMHI_RAWKEY events just all right.

Depending on how different the windows are in their behaviour and purpose and on what the application does between the input events, it might be an idea to create a seperate process for each window. This surely will result in the highest possible responsiveness of your application

Thanks, I'll keep this solution in mind.

@ssolie

test it before worrying about it. If you notice there is a real problem then we can get into more complex solutions such as multiple message ports and so on.

Point taken. I thought I'd ask before I actually start implementing something because re-implementation usually takes longer than a question