Several times now I have tried to use the tag WINDOW_AppMsgHook, but I still have some questions about it.
I've created a 'small' test program utilising this tag (and, yes I did specify WINDOW_AppPort, WINDOW_AppWindow and WINDOW_IconifyGadget tags too, with proper ti_Data values applied).
When after starting the program, the window opens, dropping an object on the window seems to indeed call the Hookfunction. However, when I have Iconified the program AppMsgPort's SigBit [AllSig |= (1 << AppMsgPort->mp_SigBit)] is added to all the SigBits IExec->Wait() is expected to react upon [AnySig = IExec->Wait(AllSig)]. After de-Iconified the program this AppMsgPort's SigBit is removed from AllSIg [AllSig &= ~(1 << AppMsgPort->mp_SigBit)], but the Hookfunction does no longer seem to work. All messages still seem to be relegated to the 'normal' IExec->Wait() functionality which does not react to the Messages due to the SigBit being removed (i.e. nothing happens).
I'm inclined to leave the whole AppMsgHook for what it was and have all AppMessages dealt with in the IExec->Wait()-cycle (like I have always done). But what is then the advantage of said tag?
Or needs the tag WINDOW_AppMsgHook to be re-applied after de-Iconification in order to take effect (again)?
Have you tried looking at Trixie's example in the blogs here? It's here with some example source code. I based my code on it a while back and it worked for me.
If you use RA_HandleInput() / WM_HANDLEINPUT then you are not allowed to access the window's AppPort/UserPort to obtain messages directly as they will be handled by "window.class". Instead you must use WINDOW_AppMsgHook / WINDOW_IDCMPHook if you need access to the messages or your program may have weird problems because it is stealing messages from window.class or vice versa (window.class uses the AppPort for WMHI_UNICONIFY notification f.e.).
Thanks again. My current view upon the matter is one of thinking it 'cumbersome': nothing is reactiing in anywhich way, that I may see some light.
Will revert again to the timehonoured old and venerable way of listening for messages coming down various ports and act upon that. Spent too much time reading documentation, reading between lines, trying to get the gist of the matter from examplecode, scratching my head, trying one approach after another, compiling, testrunning, etc., etc.
This example has been tested and works on 68k and PPC: http://thomas-rapp.homepage.t-online.de/examples/appwinra.c
There is at least one example in the SDK (can't remember which but when I get home I'll find out and post here) that accesses the window's AppPort and processes AppMessages BEFORE going into RA_HandleInput(). I would like to stress that such a technique is not allowed: it mixes up two different approaches, and only makes things more complicated. As Fredrik suggests, use WINDOW_AppMsgHook and/or WINDOW_IDCMPHook to process events that are not handled by RA_HandleInput(). The AppMessage hook is well described in my tutorial.
AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2