forums.silverfrost.com

[LitusSaxonicum]

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:

[JohnCampbell]

Eddie,

I probably do not have to much to add to your comments.

My latest approach to coding FMI is to set up a look up table of possible responses using " call call_back_statistics (reason, 1)". I inspect this at the end of a run to see the possible call back responses that occur. There are a few I didn't expect.

[LitusSaxonicum]

John,

There's a lot to think about here! My immediate problem is to zoom in on a not very sophisticated map. Without FMI, and just using left_click to zoom in a step, right-click to zoom out, a good choice of step sizes and a limit on both zooming in and out gives me a nice effect. As my graphic is always centred in the screen, I tried a SHIFT or CTRL combo with a click to choose a new centre point. Alas, that causes an ugly jump, and my experience of other windows programs makes me yearn to be able to pan the screen view.

At that point, I contemplated scroll bars - but I dislike them for the whole of a screen-filling %gr. Maybe I should have a click-and-drag panning - but that would seem to require FMI. The logical thing for me was to use box_select, and rescale and re-centre based on that - but until I tried it earlier, I was under the impression that it required FMI as well (I'm sure it used to). It doesn't, but what it does seem to need is a way to know whether box_select is enabled, and to be able to turn it off so that simple clicks can be detected. (A mechanism for this is to select an appropriate toolbar button to swtich the process on and off, but for me, the fewer the big mouse movements and clicking on this and that, the better).

I'm fascinated by the idea of unexpected callback reasons ("There are a few I didn't expect.") How many of them are undocumented callback reasons?

Eddie

[edit]PS to Paul: could the area selection outline be a different colour, and/or the area be filled with a light tint with transparency? E
[second edit]PPS ... and wouldn't it be great if there was a mode 4 for SET_GRAPHICS_SELECTION@ in which nothing was drawn, but the start and finish coordinates of a "click and drag" operation was reported, to facilitate panning of the sort usually done with a 'hand' cursor? E

[JohnCampbell]

Eddie,

My call_back_statistics is a recent work in progress.
Call_id can have a value
-1: echo statistics as end of run
1: mouse interrupt
2: mousewheel interrupt
I was thinking of storing a list of callbacks, using num_callback as the count and including cpu_clock@ as an indicator of spacing.

The main surprises I had was with resize and mouse wheel interrupts, where there were more interrupts than I expected. Also the few initial interrupts, before the program is "up and running" cause a few problems.

My blowup approach is also a work in progress (over many years), as I have a number of ideas but not the time to implement.
I do blowups with set_graphics_selection@ : mode=1. It has worked ok in the past.
I am wanting a better zoom and pan. I am thinking of using the mouse wheel to zoom in and out. To review the expanded image, I would create a virtual screen of the full object, then pan around by grabing the screen with the mouse down and draging the virtual screen over the real screen. (H:10,240xV:7,680x4colour_bytes = 300mb, hence the interest in large DIB images). Would work well for a 2D image, but needs more for rolling a 3D image.
I have a 3D roll by draging the mouse about the centre, updating with a wire diagram with the mouse down then a full rendered image when the mouse is released. I developed this over 10 years ago, so faster graphics might have meant that I could update with the rendered image, but the size of problem I have has also increased from about 50k polygons to about 20m.
With the latest problems, I don't select roll very often but do a lot of panning.
I also recently developed a lookup window; a small .1 x .1 screen in the bottom left with an edge line image. I click in this window to select a blow up view location. Works with large images and big zoom.

My call-back handler must know what viewing mode is in use: pan, blowup, rotate, porthole, wobble, lookup or other. Other is to inquire info about selected objects on the screen, so I need to know when all the other options are turned off.
Porthole is another interesting option, where I click on the full view and display a 10x blowup at that point in a .3 x .3 window in the top left. By dragging the mouse, the porthole updates in real time, with a much smaller active model.

As I'm the only user of the software, I don't have problems with tricky users who confuse the interrupt handler. I'd expect that coping with other users is another level of complexity.

I could send you my mouse.f95 if you would like to see some ideas that work for me. I'm sure there are many alternative approaches that work better. Always looking for advice on better ways to manage this. It's surprisingly easy to code some of these options, you just need to have a good idea and a way of managing the update.

John

[PaulLaidler]

I have noted this correspondence but the best I can do at the moment is to make and note to investigate when time allows.

[JohnCampbell]

I will update the callback log to include the list order and elapse times.
I will try to document the first few call-backs and identify what they relate to.
Once the program starts up, I find that recalling what I did to get the call backs is difficult, but I think the first few are of interest.

I recall that if resize is enabled, there is a resize interrupt issued as the program starts. Caused me some problems, as my status variables had not been initialised. I'll investigate and provide ore reliable advice.

John

[LitusSaxonicum]

John,

As always, thanks for the ideas. Fortran programming for me is far from being my main business, and I am often reluctant to dive in too deeply, especially to shark-infested waters (like fmi)! When I have digested this I've return to the topic with my thoughts.

In the meantime, perhaps Paul will consider my suggestion for a mode 4 as it looks to me as though it would be easy to derive from modes 1 and 2, and would be of considerable use when programming panning when not using fmi.

Regards

Eddie

[JohnCampbell]

Eddie,

I changed the log to store the interrupt reason and the elapse time when it occured. I also included some extra "interrupts", to log key events, as type 3.
the listing of the log, omitting repeated moves is:

[JohnCampbell]

The revised call back loging routine is:

[LitusSaxonicum]

John,

Taking 40 seconds to load the file! It is probably a good job you are your main user, or you would be programming something to keep them busy while the 40 seconds ticks by.

Thanks for your suggestions / code. When I get a spare hour or two I will revisit the hell of fmi ...

I've been drawing icons. As thumbs up and thumbs down have defeated my limited artistic abilities I've settled on smilies ...

Eddie

[JohnCampbell]

Paul,

This is the first time I have been able to clearly document the effect of multiple interrupts and probably why I am getting the "write over write error"

You will note that the first 5 interrupts I have identified are :

[JohnCampbell]

Not sure now, as Set_Widow_Size can be called from either RESIZE or %SC, although I had assumed that RESIZE response occurred after %SC.
The startup code I use is:

[PaulLaidler]

John

I am not able to respond to this in detail at the moment but here are a few random comments.

My understanding is that we have to think in terms of a single thread but this serves a message queue that is fed by SendMessage and PostMessage calls. The difference being that SendMessage waits for a return whilst PostMessage does not. In addition ClearWin+ can also peek a message before taking it out of the queue and processing it.

Messages can only be added to the end of the queue and processed one at a time. So the question in the end is what is the order in which the messages are sent.

Regarding %sc, I think that this is equivalent to the message WM_INITDIALOG and thus provides information whilst the window is being created by the API and before it is displayed.

[JohnCampbell]

Paul,

Thanks for your response.
Based on your single thread comment, am I wrong in thinking that the first RESIZE interrupt from
winio@ ('%`^gr[grey, user_resize, rgb_colours, full_mouse_input, user_surface]&', &
could conflict with %sc ?

IN the past I have had an error that a write event has occurred while another routine has itself performed I/O ( sorry I can't recall the exact message)
I assumed this was due to a seperate thread for the interrupts.
If it is not then I will have to look for another reason and a search as to how to clean it up.

John

[JohnCampbell]

Paul,

I have been thinking about the problem of the relative timing of the start-up events.
%gr initiates the window state and in the example I have provided, initiates the mouse response and also the resize response.
To initialise the program settings, I call some routines before any winio@ routines (eg crtstart) and also use %sc for some other routines (via my routine plot_setup_function).
It would appear that I should change the structure of this so that I initialise all data structures not related to the %gr window before the first winio@ call and include in plot_setup_function those data structures which depend on %gr.
Also as RESIZE is initiated before the %sc response, I should check that it can work at this time, although the RESIZE response does require some of the window dimensions to be initialised. (Not being aware that this could occur has caused problems recently.)

I think the answer to this problem is to be aware of the potential timing of these events, as I suspect there is not much that can (or should) be changed.

My understanding of the mouse, resize, mouse wheel or menu interrupts is that they are separate "threads" that act independently of each other. It is important to try and minimise the coded response time so that they do not conflict. My question before is can we queue these interrupts up so that they are processed one at a time. I have had the impression that especially with MOUSE_MOVE interrupts that they do not wait for the last interrupt to be completed, which is typically found with fmi.

I would welcome your comments on any of these thoughts.

John