forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Using a List View (%lv) with other windows

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
wahorger



Joined: 13 Oct 2014
Posts: 366
Location: Morrison, CO

PostPosted: Thu Sep 08, 2016 12:01 am    Post subject: Using a List View (%lv) with other windows Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 4920
Location: Salford, UK

PostPosted: Thu Sep 08, 2016 7:24 am    Post subject: Reply with quote

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+.
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 366
Location: Morrison, CO

PostPosted: Thu Sep 08, 2016 6:46 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 366
Location: Morrison, CO

PostPosted: Mon Sep 12, 2016 4:00 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 366
Location: Morrison, CO

PostPosted: Sat Mar 25, 2017 10:49 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 4920
Location: Salford, UK

PostPosted: Tue Mar 28, 2017 4:42 pm    Post subject: Reply with quote

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

Quote:
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.
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 366
Location: Morrison, CO

PostPosted: Tue Mar 28, 2017 8:16 pm    Post subject: Reply with quote

Thanks, Paul. Sorry I missed that!
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group