Unexpected behaviour in grid 2

[JackTheC]

I was programming a little today and I stumbled upon an unexpected problem:

I have a form with a grid. In the grid there is a click event. Doesn't matter if its grid.click or grid1.column1.text1.click.
The table of the grid is in workarea 1, but the currently selected workarea = 2 (with select 2 selected)

Then I click in the grid and the click event is executed:

* to be sure I select the workarea of the grid table
select 1
do form dummyfrm  && this is a dummy form, does nothing, is modal and desktop=.t. and it can confirm that workarea = 1 !!!
* but for some mysterious reason it changes the workarea back to 2 after releasing dummyfrm
messagebox(str(select()))  && 2, why 2?

select 1
messagebox('hello')  && no change in workarea
messagebox(str(select()))  && still 1

This behaviour does not occur if this code is placed in a cmdButton.click event on the form. If area 2 has no table open it also does not occur.
It only occurs in a grid when doing an other form and both areas have tables open.

Any replace command following the do form will be performed in the wrong and unexpeced workarea/table.

Why is that? Is there any logic behind this? The code above is simplified to isolate and demonstrate the problem.

 

[Olaf Doschke]

It's the same behaviour causing reports to work in unexpected workareas and it has the same solution:

Before you SELECT 1 in the grid1.column1.text1.click, set focus to any control of frmMain outside of the grid. That makes workarea 2 active, as the grid loses focus, then SELECT 1 and the memory of the grid is already lost and won't reeffect the current workares, the grid already has lost focus, though the click event still runs.

To read about the behaviour see Mike Lewis article:

http://hexcentral.blogspot.co.uk/2012/04/vfp-reports-not-showing-same-data-as.html

Unlike how Dan Macleod ends this article it is known for quite some time and we have to live with this.

Bye, Olaf.

 

[JackTheC]

Thanks for the research. It may be a known problem for some of us, but it is still unexpected and error prone.

 

[Olaf Doschke]

Well, even if you don't know this grid behaviour you see it. Your false assumption is the init state of frmDummy is the final state, but forms are getting visible only after init. You should know LISA (Load/Init/Show/Activate), forms are getting visible in Show. And that then causes all kind of deactivate/activate/valld/lostfocus events and there is naive behaviour there, so you'd need to check for a state in a forms Activate or in it's initial control gotfocus, whatever is the last event in the event order.

You have event tracking to find out event order, if you don't know LISA. And if you don't know that, what you know is the workarea that was active before the grid textbox click ran was 2, so you know frmDummy is the wrong suspect. From investigating at init of it you already know frmDummys init sees workarea 1 then you know the culprit has to be in frmMain, not in frmDummy.

There are many signs and indicators you throw away and didn't follow up.

Have you ever used DynamicBackColor or other Dynamic properties? Ever wondered why you can address grid recordsource fields just by field names always? It's because the grid activates its recordsource. And it moves back current workarea when losing focus, which doessn't only happens inside a form, but also because another form gets activated.

Bye, Olaf.

 

[JackTheC]

OK, when a grid gets the focus it changes its workarea automatic to that of the grids table. 1 in this case.
My Select 1 in the grid click event is superfluous.

"It's working in workarea two from the moment on the grid of frmMain lost focus."

But not always. Indeed when a form is evoked from within a grid it changes the area back to what it was before the grid got focus. 2 in this case. It also does that when a inputbox() is evoked in the click event. But when a messagebox() is called instead of a form or inputbox, the workarea stays 1 while the messagebox got focus. And a messagebox has clearly the focus: You can choose between multiple buttons on it.
And after the form or inputbox are closed the focus returns back to the grid in area 1, but that area is this time not automatically selected.

 

[Olaf Doschke]

Yes, the observation with the mesagebox is against all the odd rules. It surely comes from the messageebox being a system dialog and no VFP form, it doesn't influence VFPs focus and active form/control system.
A timer showing _screen.activeform in _screen.caption or via SET MESSAGE TO could show that a messagebox never becomes the active form.

Bye, Olaf.

 

[JackTheC]

Well a inputbox() is also a system dialog.

Further:
in the grids click event:

select 1 <== Is not needed because 1 is automatic selected. This Select 1 is not respected. VFP disregards this one?
x=inputbox('Name')
select 1 <== is needed for following replace commands. AND this Select 1 is respected for clicks to come.

The first click changes the area to 2 as we know now.
BUT a second or third a.s.o. click in the grid, respects the Second Select 1, Area stays 1 all the time.

I don't know how you call this. I call this strange and unexpected and illogic.

 

[Olaf Doschke]

Well, the grid sets back to workarea 2, but since you select 1 by the time the grid gets focus again workarea 1 is selected. So it stays there. It's not strange. The grid does not go back to what it first remembered, it goes back to what it remembers each time it gets focus. So compare select() in grid.When() to Select() in the grid.valid() event, it should be the same (I havent tested, workarea might already be recordsource in the When() event and it might only be set back after valid).

Also messagebox is a windows system dialog, inputbox is a vfp system dialog, still both don't count as _screen.activeform, that's only addressing anything based on VFP form. The focus issue still also "works" with inputbox, being a vfp system dialog it lets the grid loses is focus.

Bye, Olaf.