Using a List View (%lv) with other windows

I have discovered some interactions between windows and thought I'd put down some of my observations and fixes here for others.

I make extensive usage of the %lv (List View) to present data in the report view (tabular, a lot like Excel). I don't allow any editing of the data (that's done elsewhere), but I do use the callback to allow sorting of individual columns, selection of items for processing , etc.

I also use the Text Array (%tx) for a number of human interactions. It is this combination (%lv and %tx) that caused me no end of 'trouble'. But, there is an easy fix.

What I discovered was an interaction between independently created windows. The %tx window appeared to interfere with the %lv callbacks. Specifically, the following behaviors were observed:

Moving the cursor from the %tx window into the %lv window would cause the %lv data to flash as if being refreshed.

Moving the cursor could SOMETIMES cause the number of displayed items to show only up through the last selected item, making the remaining data appear to have disappeared. Moving the cursor back and forth from the underlying window into the %lv window would cause this condition to occur or restore itself.

The %lv callback function would get double 'SET_SELECTION' messages on occasion, as well as the '?', meaning the callback was performed but not with a valid CLEARWIN_INFO@ message.

There are other windows in my program that do not exhibit this behavior, so I looked at the similarities/differences in how the windows were created.

It turns out that if the window is created as if it is a dialog (modal), then the problem did not manifest itself.

So, what to do when I really need to have a window (not a dialog) created? I can 'disable' the %tx main window. There are three ways of doing this.

First, if one minimises the %tx window, then there is no interaction since the window is not displayed and cannot gain focus (nor see the cursor move across it.

The second way is to disable (%de) the %tx window so that it does not process cursor movements (or anything else).

The third (and probably only applicable in my case) is to close the %tx window, recreating it only AFTER the %lv window has been processed and the %tx window is needed.

This may or may not help others, but if you are seeing odd behaviors and/or lots of sporadic and odd callbacks, this might help.

Without making any promises, if you are able to illustrate the bad behaviour in a small program, then I might be able to get to the root of the problem within ClearWin+.

Paul, thanks for the offer. I've pulled out what I think are all the code segments and have put them together, but cannot get the same behavior.

I will continue to look at the code to see what could be causing this, and will attempt to replicate the issue, but for now, no joy!

Bill

Paul (et. al.),

I have trimmed the code, but not been able to duplicate the specific problems outlined originally. Obviously, the code that displays the problem is much larger, and there's likely another layer/control/option that causes the behavior seen to occur; that said, the code I have linked to below does show some of the characteristics.

When the program starts the %lv window is placed in front of the ClearWin window (standard output). Moving the cursor across the control produces no callbacks, selecting a row does generate the appropriate SET_SELECTION callback, etc. The problem begins when the %tx window (behind all this) has focus or appears behind the %lv window.

Using the mouse to just move across the %tx window itself now causes the %lv window to have generated callbacks. Also, pressing a key when the %tx window is in focus also causes the %lv window to generate callbacks (SET_SELECTION).

Now, with the %lv window up front and in focus, on top of the %tx window, there is a callback initiated while moving the mouse across just the %lv control. There is also a 'flash' of the %lv control, like it is being refreshed.

If the %tx control is placed 'behind ' the ClearWin window (i.e. %tx covered by ClearWin covered by %lv), then the %lv control works as one might expect.

I have included the Project file along with the F95 source in the folder. Perhaps this will lend an insight.

Bill

https://drive.google.com/drive/folders/0B5fbkRqVCqoMM2RMQ3BOMWFrWVk?usp=sharing

I was able to find and fix the problem. It has to do with the return value from the callback.

When the callback return is 1, the screen updates. Well, for LV controls with LOTS of data, it causes the flicker. Even holding down the shift or ctrl key causes the callback to be invoked, so those will cause the flicker also.

I've updated all the %lv callbacks to return a 1 if and only if the control needs an update.

And, no more flickering.

BTW, the reference in the on-line help references that 4 is a special value for %lv and %bv controls, but not what that does. A hint, perhaps?

Here is a quote from ftn95.chm about %lv. There are other references to a return value of 4.

With BEGIN_EDIT you can get the index of the selected item by the call clearwin_info@('ROW_NUMBER'). If your call-back function returns the value 4 then editing of this item is prevented.

Thanks, Paul. Sorry I missed that!