Wolfgang writes: > > My assertion only applies to AWs that are not Menu SubWindows: MSWs > > respond exactly as you say. > > > > If the pointer happens to be in an AW and it is being read by a Wman call > > (eg wm.rptr or MCALL) it wont return. Naturally: 'cause there aint no > > Wman-recognised menu there! (PI calls, of course, always return on a > > keypress if told to do so.) > > Yup, there is a difference between a WMAN call and a PI call but > even rptr should return...
iop.rptr does if you set the appropriate bits in the return vector. But Wman calls (wm.rptr) only respond to "events" (see the Qptr manual, pages 89 ff "Window Manager Access Routines") > > So, the problem I was trying to solve, namely How to make the program > > respond to keystrokes available to the main menu when the pointer is in an > > AW remains unanswered by the explanation I gave. If the AW happens to be a > > MSW (as in the case of the Qpac2 Files utility) then there is no problem! > > (Unless a LI and a menu item have the same keystroke, just as you say). > > I'mnot sure about the rest - it should be pretty simple to have an > action routine for the AW even if it isn't an MSB, that just returns > on any keystroke - IIRC, that's how QPTR does it from basic. I > haven't got the documentation to hand right now. AW events are entirely up to the programmer. My point is they are not processed by wm.rptr but by iop.rptr. This explains why there is no reaction to keystrokes defined in the main menu unless the AW happens to be a MSW. > I personally, actually see the problem the other way round: how do > you make an MSW respond to a keystroke if the pointer is NOT in > the msw... The simplest solution here is to use Dummy LIs in your main menu, as described earlier, and then use wm.rptr. However, this may not always be appropriate as MSWs can display a variable amount of data whilst the number of LIs must be pre-determined. However, if the pointer happens to be in an AW then youd have to trap the relevant keystrokes and funnel them into your Wman action routines or duplicate those routines specifically for that purpose (either method could involve having to access the menu structures, ie the Working Definition). A compromise solution Ive used is to trap a single keystroke in the AW that causes the pointer to be positioned somewhere in the main menu (with iop.sptr). A subsequent keystroke will then act on the main menu structure. Eg: If you use <tab> as the selection key for your AW then you could write a routine that positions the pointer in the middle of the main menu when you press <tab> again from inside your AW. This means that a main menu command is one additional keystroke away - but at least you dont have to yank the mouse or fiddle with cursor keys. > > The solution to the problem of using an AW instead of a button is to make it > > into a MSW containing one column and one row. It may still take a bit of > > extra footwork to make such a button behave identically to a LI (at least in > > EasyPTR). > > I'm sorry, I don'y use that. I've always found QPTR far easier - but > it's a matter of taste! Having tried both, I definitely find EasyPTR easier to use - at least once I got to grips with it. If you really prefer Qptr, you could still benefit from using the interactive design tools from EasyPTR - especially EasyMenu - if you could write a program to convert window definitions into Qptr-compatible SB statements. This might not be too difficult to do. IHATMS* Per * I hope all this makes sense ;)
