Some years ago, I wrestled with full_mouse_input in a %gr region. At the time I was much less adept in dealing with Clearwin than I am now, and indeed, I was inter alia attempting to do things that Paul didn’t actually fix until a later version of FTN95 than I was at that time using (notably popup menus in v5.50). I recall some helpful advice given on the forum (by John Campbell among others) about fmi. I swore (a lot!) at the time that I would never use ***fmi ***ever again, but like an alcoholic returning to the bottle, I have attempted a couple of times subsequently to use it, as there is a limit to what one can do with simple clicks and key modifiers. Indeed, the fact that one gets single mouse clicks along with double mouse clicks means that the usefulness of the single click is limited because if one ever wants to respond to a double click the single click can only be associated with something that you don’t mind being invoked en route to the double click. This makes a program idiosyncratic compared to other windows applications as a single left click is then effectively neutered. However, without fmi, the system is very reliable, and single clicks are detected and responded to very accurately. In my most recent excursion into the minefield of fmi, I discover that code that works well without it, such as:
CBR = CLEARWIN_STRING@('CALLBACK_REASON')
IF (CBR .EQ. 'MOUSE_LEFT_CLICK') THEN
Do something
ELSE IF (CBR .EQ. 'MOUSE_RIGHT_CLICK') THEN
Do something else
ENDIF
occasionally misses a click with fmi enabled. This leads the user to a set of activities, such as removing fluff from the mouse or clearing other filth from its working parts, peering at the red light etc., never suspecting the true problem.
On deep reflection, it occurs to me that the original advice from John Campbell, which in effect was to quickly inspect the state of the mouse buttons and mouse coordinates at every invocation of the callback probably means handling the mouse as one did in DOS, interrupt at a time, and not relying on the above ‘callback reason’ approach. In the course of program development, that means abandoning (or at least further complicating) code that one had working satisfactorily. For me, it created a ‘slough of despond’ as I was under the impression for some reason that SET_GRAPHICS_SELECTION@ only worked with fmi. However, I find that this is not actually the case, and I wonder if something changed while I was not looking! I live in hope that eventually popup menus and scroll wheel handling will also not require fmi.
In my graphics callback routine, it would greatly simplify matters if the callback reason was set to something like ‘area_selected’ or ‘elastic_line_drawn’ as presumably one would never get a single or double click callback if SET_GRAPHICS_SELECTION@ was set to mode 1 or 2. (There appears not to be an ‘ENQUIRE_IF_GRAPHICS_AREA_SELECTION_IS_ENABLED@’ option, and at present I am keeping track of whether or not these modes are enabled using an inelegant approach with a COMMON block). Or have I missed something in the depths of FTN95.CHM?
Eddie