8.71 Change in %ps responses

I am still investigating, but there seems to be a problem with %ps. I use this a lot. I have not tested every window.

In one window where one %ps tab (the second one) has a listview, if I sort the listview and re-display, the first tab of the %ps gains focus. The sort works fine, but focus does not stay on the tab. I have this occurring on more than one window. While annoying, I can still select each tab to perform the functions needed.

On another window, I cannot select any tab but the first one to have focus. Selecting the second or subsequent tabs will cause that tab to be displayed as a flash, then focus returns to the first tab. This renders the functionality unusable.

Note that these two examples do not respond to tab selections or update events in the same way.

I am posting this as a 'heads-up' for those using %ps.

In my second case (re: cannot select any but the first tab), the following change was required.

The %ps had a call back. Because the tab with the listview (the first tab) needs to have the control refreshed, the %ps callback returned a value of 1. Changing this to a value of 2 allows all the tabs to now be individually selected. The %ps does not have a sheet number variable. I have provided the winio@() call for reference.

i = winio@('%^5ps[hot_track]&',window_sheet(5),window_sheet(1),window_sheet(2),window_sheet(3),window_sheet(4),handle_lithology_initial_display_callback)

I am suspicious that other %ps with a callback will require the same fix.

As a point to note, I do have individual controls inside of the tab that have callbacks attached. These control callbacks do not appear to cause any of the behavior as described, just the callback associated with a %ps.

In looking at the code for my first example (re: performing an operation on the %lv in the second tab causes the first tab to be selected), the %ps does not have a callback attached. However, the callback for the %lv control (on the second tab) involved does have a callback and returns a 1 if and only if a specific action is taken. For example selecting a line of lines of the listview does not return a 1, but sorting on a column of data does. If I perform the sort, the first tab is then displayed, not the second. Stated another way, returning a value of 1 for a %lv control inside a %ps will force the first tab to be selected.

I have a button inside this second tab that, when selected, performs an action on the listview and returns a value of 1. Selecting this button does not cause the first tab to be selected.

N.B. I was finding that calling window_update@() specifically for my listview's was causing unnecessary processing to occur when also returning a 1 from the callback. Just bad form. So, I have gone through all the %lv callbacks making sure that only if the listview table is needing change with value of 1 be returned, thus allowing the system to update the display of the listview table.

Bill

If you conclude that there is a regression in ClearWin+ can you send me a sample program to look at.

I'll give it a shot. Nothing I have is small enough.....

The following will cause it to occur.

There are two tabs. The second tab has the listview.

Select the tab labelled 'lv only'. If you single click on a line on the left hand listview, only the selection occurs. I have verified (separately) that the callback returning a value of 1 does occur.

If you double click on that line, it will take you back to the first tab.

Clicking on the button whose callback returns 1 will also cause no ill effects.

Anything you do on the right hand listview has no ill effects.

	winapp
	PROGRAM MAIN
        use mswin
        integer:: i,j,k
	integer:: child_1(2)=0
        integer,external:: lv_callback_1,lv_callback_2
        character*32:: lv1(3),lv2(3)
        integer:: sel1(2)=0,sel2(2)=0
        data lv1/
     $	'|col1|col2|col3|',
     $	'!data1|||',
     $	'|data2|||'/
        data lv2/
     $	'|col1|col2|col3|',
     $	'!data1|||',
     $	'|data2|||'/

	i = winio@('%sh&',child_1(2))
        i = winio@('%ca[buttons only]&')
        i = winio@('%^bt[Button callback 1] &',lv_callback_1)
        i = winio@('%^bt[Button callback 2] &',lv_callback_2)
        i = winio@('')

	i = winio@('%sh&',child_1(1))
        i = winio@('%ca[lv only]&')
        i = winio@('%^lv&',100,100,lv1,3,sel1,3,lv_callback_1)
        i = winio@('%^lv&',100,100,lv2,3,sel2,3,lv_callback_2)
        i = winio@('%ff%2nl&')
        i = winio@('%^bt[Button callback 1] &',lv_callback_1)
        i = winio@('%^bt[Button callback 2] &',lv_callback_2)
        i = winio@('')

        i = winio@('%2ps[hot_track]',child_1(2),child_1(1))
        end
	integer function lv_callback_1()
        lv_callback_1 = 1
        return
        end
        integer function lv_callback_2()
        lv_callback_2 = 2
        return
        end

Bill

I can see that the response in this context has changed recently.

I can't give you a quick fix but if you are happy with a work-around then you could use the following idea.

The problem relates to the return value of 1 in lv_callback_1 when double clicking on a listview item. The resulting refresh somehow changes the tab.

The work-around is to avoid the refresh for a double click...

        integer function lv_callback_1()
        use clrwin
        character(80) reason
        reason = clearwin_string@('CALLBACK_REASON')
        lv_callback_1 = 1
        if(reason == 'MOUSE_DOUBLE_CLICK') lv_callback_1 = 2
        end

Paul, thanks. I had implemented that fix in one window (one callback) to verify the symptoms as I created the sample.

Long ago I went through all my %lv callbacks to make sure they did not perform the auto-refresh unless it was actually needed or a specific window_update@() was needed. I removed any window_update@() that were duplicating the auto-refresh. That made the use of %lv faster (by a lot) and prevented some other undesirable behaviors.

The prospect of having to redo all that work to insert the window_update@() in the proper places is daunting. I'll just wait a bit.

Bill

Bill

Is it not possible to just amend the callback in order to filter out the double click?

Paul, you are absolutely correct! But it is also the column sorting that many of my callbacks implement. As well as associated variables to the listview that require a refresh (like deleting an item, then redrawing the listview AND updating a counter that is displayed to the user [%`rd]). So it is not quite as straight forward.

It is not just one callback; it is many (I use listview a lot for tabular-style data). So, rather than modify multiple occurrences, then (possibly) turn around and modify them back, I'll just hold off any changes.

That said, if I find a flaw and am compelled to release another version to my users, I will make the appropriate changes. I know where they are. I'll expend the time/effort when it is absolutely needed.

No worries from my standpoint on waiting!

Bill

Bill

This has now been fixed for the next release of ClearWin+.

It turned out to be a bug in the ClearWin+ code that was exposed by an unrelated change on 21 March 2021.

I may wait a few days before uploading new DLLs. In the meantime, a temporary fix is to remove [hot_track].

Paul, thanks for the update! I agree now that a known fix is available (stop-gap), best to wait on the effort of a complete delivery. I run into the same conundrum myself when I find a problem/issue.

In a related question, can one put the %ps options in a text string and use the @ 'operator' to apply these changes?

Bill

Bill

I am not sure what you mean but it doesn't sound right.

You can do a internal WRITE to a CHARACTER variable and then use it as the first argument of winio@.

What I was hinting at (sorry for not being clear) was something like:

i=winio@('%2ps@','hot_track',a,b)

I should have included this example.

I get from your response that it does not work that way, which is absolutely fine. Curiosity more than anything else.

Bill

I am pretty sure that won't work but you could give it a try.

Had a few minutes to try. Nope, doesn't work that way. No big deal.

I just discovered that if a menu selection returns a value of 1, the same behavior is observed. I have updated my example and have included it here.

	winapp
	PROGRAM MAIN
        use mswin
        integer:: i,j,k
	integer:: child_1(2)=0
        integer,external:: lv_callback_1,lv_callback_2
        character*32:: lv1(3),lv2(3)
        integer:: sel1(2)=0,sel2(2)=0
        data lv1/
     $	'|col1|col2|col3|',
     $	'!data1|||',
     $	'|data2|||'/
        data lv2/
     $	'|col1|col2|col3|',
     $	'!data1|||',
     $	'|data2|||'/

	i = winio@('%sh&',child_1(2))
        i = winio@('%ca[buttons only]&')
        i = winio@('%^bt[Button callback 1] &',lv_callback_1)
        i = winio@('%^bt[Button callback 2] &',lv_callback_2)
        i = winio@('')

	i = winio@('%sh&',child_1(1))
        i = winio@('%ca[lv only]&')
        i = winio@('%^lv&',100,100,lv1,3,sel1,3,lv_callback_1)
        i = winio@('%^lv&',100,100,lv2,3,sel2,3,lv_callback_2)
        i = winio@('%ff%2nl&')
        i = winio@('%^bt[Button callback 1] &',lv_callback_1)
        i = winio@('%^bt[Button callback 2] &',lv_callback_2)
        i = winio@('')

	i = winio@('%mn[Return 1]&',lv_callback_1)
        i = winio@('%mn[Return 2]&',lv_callback_2)
        i = winio@('%2ps[hot_track]',child_1(2),child_1(1))
        end
	integer function lv_callback_1()
        lv_callback_1 = 1
        return
        end
        integer function lv_callback_2()
        lv_callback_2 = 2
        return
        end

Bill

The reported fix also resolves this situation.

Thanks for the confirmation, Paul!