Bug(s) in Clearwin associated with full_mouse_input

I have been turning a %gr region from a static “repository” for graphics into an interactive system.

In this region, I have a need for various types of mouse clicks, and for popup menus. Eventually, I found what I wanted in “enhanced popup menus”. Firstly, what I think is a bug. When defining the format string for an enhanced popup menu, if the first item is greyed out, Clearwin complains if the –gr is followed by a comma, e.g. as in:

FMT = ‘[-gr,Delete, …

and will only accept

FMT = ‘[-grDelete …

Anywhere else, and the comma IS needed.

Secondly, to make the enhanced popup menus work in a %gr region, full_mouse_input is required. Now I have discovered that full-mouse_input isn’t a nice thing to switch on. On my fairly high-spec system, it makes the detection of ordinary simple clicks seem sluggish and ragged. Not every click is detected, and this leads to mistakes being made. Everything I programmed – except enhanced popup menus – works much more smoothly with full_mouse_input switched off, i.e. not specified. Unfortunately, it seems that this cannot be switched on / off at will. I consider full_mouse_input to be my bête noir.

Consider the range of problems I have had, and the workarounds I have found, and the nature of the underlying problem becomes clear - eventually.

1. Parameters passed to a subroutine become undefined. Workaround – send them through COMMON.
2. MAX and MIN intrinsic functions stop working. Workaround – of the type IF (A .LT. B) B=A
3. Mouse clicks appear not always to be detected. I have a facility where clicking on the edges of my %gr where I have drawn rulers causes the plot to be scaled differently. Without full_mouse_input – perfect. With full_mouse_input about 1 in 5 of the clicks is missed.
4. The fourth clue lies in how I struggled to implement click’n’drag (I have actually given up). I couldn’t reliably detect mouse button release. I am, of course, using the recommended route of

CLEARWIN_STRING@('CALLBACK_REASON') and CLEARWIN_INFO@ (‘whatever’)

Interestingly, I found when trying to work with a code that Paul sent, that he uses call get_mouse_info@ (x1,y1,nstat), and definitely, this wouldn’t work reliably when mixed with the approach I am using.

5. I have also found that when full_mouse_input is enabled, the behaviour of the full width/height crosshair cursor (as produced by set_graphics_selection@(3)) is noticeably different and erratic. For example, it leaves a “ghost” set of crosshairs at the initial position – but not always. At one stage I managed to get the cross point of the cross hairs to show an XOR circle with a dot in the middle, although that seems to have disappeared now. Bizarre.

I have tried to implement enhanced popup menus. This is where I found the –gr comma bug described above. I found the idea of an enhanced popup menu with a single callback function not particularly well described in the online help file. More to the point, I found it difficult to know what happened after CALL DISPLAY_POPUP_MENU@ (). I eventually concluded that program control transferred to the callback routine associated with the enhanced popup menu, or to the start of the original callback for %gr, but unless I followed CALL DISPLAY_POPUP_MENU@ with

GR_CALLBACK = 1 ! where this is the name of the callback function RETURN

I got erratic behaviour, and I certainly can’t account for that.

Also not described in the help file is what is supposed to happen if one ignores the popup menu and clicks elsewhere on the screen. In this situation, one gets a visit to the %gr region callback, and not the callback that services the popup menu. Obvious in retrospect, but not at first (and not while puzzling out whether –gr should be followed by a comma or not!).

After a period where the enhanced popup menu system worked – now it doesn’t. The intervening modifications to my program were unconnected to the graphics. What I now find is that after I have changed the enhanced popup menu once (with REPLACE_ENHANCED_POPUP_MENU@), a click on any menu item provokes the correct response. After I changed it a second time, a click on a menu item does nothing. A “write (,) ‘ entered callback’” as the first statement in the callback function is not executed.

Of course, I was dismayed and perplexed when it stopped working - and set about trying to work out what I had done, whereas a day earlier, when it had equally mysteriously STARTED working, I had put that down to 'finally getting it right'.

On reflection, the problems above with subroutine parameters and MIN and MAX not working all happened in the callback function to service %gr - they worked with the reliability one has become used to from FTN95 everywhere else in the program.

Eventually, the penny dropped. This isn’t my mistake or ignorance (and I confess to both mistakes and a certain inability to understand some of the finer points) – it is a bug in Clearwin. I can also tell you precisely what it is. When full_mouse_input is enabled, Clearwin mishandles the stack. Sometimes it matters, sometimes it doesn’t. When it doesn’t, then all is sweetness and light. When it does, it messes up subroutine parameters and calls to intrinsic functions, and finally, it messes up messaging about mouse activity - all things that are passing data a little way from the current top of the stack, and only when one is detecting mouse activity in a graphics area. QED.

Perhaps marking 75 exam scripts will clear my mind ....

Regards

Eddie

I don't think that ClearWin+ has the capacity to 'mess up the stack' but if you can send me a sample program that demonstrates the problem I will do what I can to advise or sort out the problem.

ClearWin+ does pass on messages to the user from the main message loop and the ordering of these messages may vary.

The source code for the latest incarnation of my program is 800 k. I'll work on seeing if I can do a demonstration that is smaller.

Maybe the stack corruption is due to an inadequate automatic allocation of stack. I'll try specifying it explicitly - I saw a thread on that recently.

Regards

Eddie

Eddie,

Sorry for the delay, I have just read your post.

With %gr and full_mouse_input I have certainly seen some of the problems you are describing. As the mouse can provide many move interupts, to overcome the problem, I test for how far the mouse has moved since the last time I reacted and ignore the interrupt if abs(dx)+abs(dy) is less than a minimum value. I also change the cross hair to long and sometimes have to drag the mouse to a corner before going to the menu, so that the cross hairs do not in linger on the screen. There can be a delay between the menu and the computation phases of the program that cause this problem. The most likely cause of this is that your program is responding to the mouse move interrupt.

Write an efficient test to see if the move is not sufficient to justify any response and most of the problems will go away.

regards John