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.

 

[Scott24x7]

Jack,
It's been a while, but in your "dummyfrm" there are a lot of events that fire natively. I'm wondering if there is anything that on the unload or otherwise, might be attempting to get an unused workarea.
Also, remember there are some weirdnesses that go back to FoxPlus. SELECT 1, SELECT A are both the same thing. SELECT 0 gives you the next unused work area.
Oh, I also just thought.... You "SELECT 1", the do a form, but don't open any table in work araa 1, then you return from the form, and MESAGEBOX (not sure why you STR it, it will still display 2 as a number), SELECT() shows 2.

Then in your second example, everything is on SELECT 1
But MESSAGEBOX doesn't have a dozen other events that fire in between it. So I would suspect it's something in the release of your dummyfrm that VFP does natively...
Which is why I ALWAYS execute a SELECT <TableAlias> before performing ANY function that affects that table (REPLACE, INSERT, TABLEUPDATE(), etc.) because there are several VFP anomalies that can affect expected results on table executions. Not sure if this is made better/worse by a particular buffering strategy.

Oh, one other though.. in your dummfrm if this is a class, look at what code you have in the Data Environment. This can inherit code as well. I know in mine I have in "BEFORE OPEN TABLES" the values SET TALK OFF and SET DELETED ON which is inherited then by every new form I create.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

Are you sure the grid wrks in workarea 1? A grid always activates the workarea of it's recordsource, when activated. OT: This also is a reson a report may fail, when started from a grid method, if it should not printg the grid recordsource and if it does not have its own private datasession.

Does your dummyform have a private datasession? If so it by default is in workarea 1, but that's its datasession workarea 1, not your current form workarea 1, anything you do outside of the dummyform with active workarea or recordpointers will not influence the dummyform, as its datasession is created when it starts. So it's never confirming what you do outside, it's its own bubble outside your datasession. And if dummyform works i the same datasession don't expect it to end in workarea 1 just because you started it with that activated. All kind of things happen only because of datsession automatically opening and closing tables. It might even cose the workareas of your current form, if in the same datasession.

It's good practice to work with alias names instead of workarea numbers, the age of only 15 workareas is over and you don't specify workarea numbers anymore, you use sommetable IN 0 and don't care about which workare it gets you put a table in a dataenvironment and also don't care about which workarea number its opened in, the alias is what matters. It's also good practice to let each form have its private datasession unless it really is a stellite form working with the already opened data.

Bye, Olaf.

 

[JackTheC]

I originally made this example in VFP6 but the strange behaviour also occurs in VFP9.
That is the reason I use STR() in the Messagebox. VFP6 doesn't convert automaticaly to strings in Messagebox.

It doesn't matter if you perform Select 1 or Select A or Select TablenameA.
The table of the grid is in Area 1. If there is no table open in Area 2 than there is no problem on releasing the dummyfrm.

The dummyfrm is really a dummyform that does nothing. No events:
Create dummyfrm
Set propertie desktop = .t.
Set propertie Windowtype = 1 modal
If you wish you can confirm the selected workarea (which is 1) in the Init event: thisform.caption=str(select())
Save it

The behaviour occurs with any called form from within a grid. Even a dummyform with no events. You can test it yourself.
And there is no Activate event or something like that in the calling form.

Again the click event in the grid: The selected workarea at that moment can be 1 (no problem) or 2 (problem)

Select 1
do Dummyfrm   && changes the workarea on release. There is no command anywhere that instructs to do so.
messagebox(select())  && confirms workarea changed to 2

By the way: Desktop and Windowstyle properties have no influence on this problem: You may set them to default.

 

[JackTheC]

How I came to this problem: I have a form with 2 grids with each a table. There are several buttons that perform actions in select 1 or in select 2. That reflects in grid1 or in grid2.

When I click (or right click or doublel click) in grid1 an edit form appears:
Click event:

select 1
do editform
replace fields with newvalues

But when testing I noticed that sometimes the wrong table (the one in 2, the other grid) was edited. I found out that this happens when a previous action has left workarea 2 the selected area.

Of course if you know this you can do what Scott suggests. But who expects this if there is no command or function in editform to change the areas?

select 1
do editform
select 1   && again
replace fields with newvalues

 

[Olaf Doschke]

>By the way: Desktop and Windowstyle properties have no influence on this problem
Sure, the problem is about the selected workarea, only controls and datasession influence this.
You ddn't react on all of my talk anbd questions about datasession and didn't tell what session your dummyform is in.

If you say dummyform is no special form I think you use the base native form class. But you create an SCX, which unlike the form class itself has a dataenvironment. And that dataenvironment has AutoCloseTables = .T. as default, it'll itereate all open tables and at least try to close them, it'll influence the workarea number that way. As simple as that.

Please take the advice and work with forms with private datasessions and they won't influence each other anymore. Only work in the same datasession, if you wish influences, eg as the simplest way to work on the currently seletect record of the currently selected workarea without the need to pass this and id or recno as parameters of a form needing to open and poisiotn in a new datasession, that saves some code. But know you're adding a close event to the datasession via the additional form, even though only the final form closeing the datasession really releases it, some behaviours are per form closing and that's why having all forms in default datasession is a nightmare.

And also make it a habit to remember selected workarea and put it back or even set it each time you do something without IN clause or use commands not having an IN clause, like LOCATE or SEEK command (in case of SEEK there is the alternative SEEK() function). You'll never be surprised then about changes due to grid activation or timers or anything else influencing current workarea, like the AutoCloseTables behavour of a DE.

Bye, Olaf.

 

[JackTheC]

Olaf,
There is no table, there is no data environment, there is no class, there is absolutely nothing.

Create form dummyfrm
Set propertie desktop = .t.
Set propertie Windowtype = 1 modal
If you wish you can confirm the selected workarea (which is 1) in the Init event: thisform.caption=str(select())
Save it

or if you like it
Create form dummyfrm
Save it

 

[Olaf Doschke]

There always is a dataenvironment in a form you create by CREATE FORM.
By the way the command CREATE dummyform opens the table designer, a table/dbf is the default object CREATE creates.

Bye, Olaf.

 

[JackTheC]

Sorry typo; create form
(I always use modi form in fact)

OK there is a default dataenvironment, but no tables

 

[Olaf Doschke]

Yes, no tables, but the native form has Datasession = 1 default datasession, so the datasession of dummyform has the same two tables open. You confuse datasession with dataenvironment. The environment is having behaviour definitions so to say, if you put in tables there your are actually designing visually USE commands acting on the datasession at runtime, not at designtime. Having no tables in there doesn't mean dummyform datasession will be empty, it simply doesn't open further tables. BUT its AutoCloseTables=.T. comes into action, for example. Many things act on the current datasession even without putting code or controls in there, a base form already is quite a complex object. Simply try setting the dummyform.datasession=2 (private) and see that it won't influence your current form anymore.

Bye, Olaf.

 

[Olaf Doschke]

Besides CREATE FORM does not need to create the native form class, look into Extras->Options-> Form tabs for Template Form. Only if nothing is set there you create a base form. As you modi form, are you sure you started off from scratch? SET PATH can mean you fetched any dummyform.scx of previous experiments in any path vfp looks by default.

Between the two lines DO FORM and MESSAGEBOX many things and events run. Current form control valid and lostfocus, current form deactivate, all dummyform events, then current form activate and current controls when and gotfocus and only after all this messagebox(). You forget you are in an oop world and there is no such thing as a single command seqence running, there are branch offs even just by creating an object, not only with control flow commands.

Bye, Olaf.

 

[JackTheC]

Olaf,

There is no template there is no class other than default. I tested this in VFP6 and VFP9. Please test it your self with 2 dummy forms

Simply try setting the dummyform.datasession=2 (private) and see that it won't influence your current form anymore.

No that did NOT influence the strange behaviour. I set the datasession in the dummyform=>no effect. I set it on both forms =>no effect.
I set it on the calling form only => no effect. Changing autocloseTables=>no effect

There is only one conclusion: this is a bug in VFP.
Anything that comes up with a unexplainable and unexpected error is a bug. In short: select 1, select 1, do form, stays 1. But select 2, select 1, do form, is changed into 2.

 

[Olaf Doschke]

You keep dding new info but still don't answer questions or follow suggestions. At least don't report back on that. You rather seem to be in a mode reporting what your doing, but not listening.

At least you found it has to do with VFP6 imported forms. Fine, then forget about that, do your stuff in VFP9 and everything should work.

Bye, Olaf.

 

[JackTheC]

Sorry Olaf, I deleted that finding. It also occurs in freshly created forms in VFP9.
I just want a confirmation that this is a bug. I know how to handle it (not prevent it), but nobody expects this result. So this may be a warning to you all when you are doing a form from within a grid. And private datasessions does not effect the result with this behaviour.
Have you tried to reproduce this error on your computer?

 

[Olaf Doschke]

I still don't see this bug. So your instructions to reproduce the bug are incomplete!?
I'm still at the point of guessing what happens to you. It's not happening to me. It must be somewhere outside of what you already described and specified.

Bye, Olaf.

 

[JackTheC]

Steps to reproduce:

A. You have to have 2 (free) tables or you have to create 2 (free) tables.
like tableA.dbf and tableB.dbf
there has to be at least one record in TableA

B. Make a main.prg

close all
select 2
use tableB
select 1
use tableA
do form frmmain

C. Make a main form
Modi form frmMain (or Create form frmMain)
Desktop=.t.
WindowType=1 Modal

put a grid1 on it and use the builder with tableA
in Grid1.Column1.text1.click

	select 1
do form frmDummy
messagebox(select())

put 2 commandbuttons on the form
in Command1.click

select 1

in Command2.click

	select 2

D. Make a frmDummy
Desktop=.t.
Windowtype=1 Modal

in the init event:

thisform.caption=str(select())

*this proves the workarea is always 1


Now you do main.prg
if you click button 1, area 1 is selected. You click in the grid and frmDummy is fired. The caption shows 1
You close the frmDummy and the messagebox shows 1. That's good.

Now you click button 2, area 2 is selected. You click in the grid and frmDummy is fired. The caption shows 1
You close the frmDummy and the messagebox shows 2. Nobody instructed to select workarea 2 when closing the form.
We are still in the click event which started with Select 1, so we think we are still in 1.

I tested this in VFP6 and VFP9 on 3 different PC's (XP, 8 and 10) All have this bug. And Olaf, you do need to have a table open in area 2.

 

[Olaf Doschke]

I had a table open in workarea 2, of course.

Anyway, you never mentioned a buutton with SELECT 2 outside of the grid.

I can't explain full why you see this, I also have to test the reproduction, but I can already now explain why workare1 is selected when the dummyform starts, even beforehand. I point you back to what I already said: The grid does autoselect it's recordsource. Since you click nto the grid and call dummyform from there workarea 1 is selected in that moment.

Now let me see what reactivates workarea 2. Anyway, the grid behaviour is by design and no bug.

Bye, Olaf.

 

[JackTheC]

Olaf, read the first question

The table of the grid is in workarea 1, but the currently selected workarea = 2

Of course te problem is only when area 2 is current before I click in the grid. I mentioned that several times.
The buttons are only there to be able to show the problem when 2 is selected before the click.

And anything that comes up with a unexplainable and unexpected error is a bug.
yeah, yeah, this is not a bug it's a feature. That's what they always say....

 

[Olaf Doschke]

Jack, I did not say your overall behaviour is by design, but the grid selcting it's workarea is.

You initially said "The table of the grid is in workarea 1, but the currently selected workarea = 2 (with select 2 selected)"
I thought it would be in the grid code before doing do form dummyform, where your demo code now explicitly sets workarea 1 via SELECT 1.

Im at creating the sample now...

Bye, Olaf.

 

[Olaf Doschke]

OK, now we're talking. I can reproduce and the same thing happens, if you don't select 1.
If you also messagebox(select()) before you do form fmrDummy you'll see that. It's not cause by frmDummy but by the grid.
So that part of changing the workarea is clear.

Now put a command button on your empty frmDummy calling thisform.init(), or repeat the line of code: thisform.caption=str(select())
In any case if you click the button fmrDummy will show 2 in it's caption.

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

And indeed, that's by design. It happens, no matter if you explicitly select 1 in the grid1.column1.text1.click or not, it happens, because workarea 2 was selected when the grid got focus and it happens to form2, not in it's init, but when it gets visible and the whole series of frmDummy.show, formDummy.activate, formMain.Grid1.column1.text1.valid, formMain.Grid1.column1.text1.lostfocus, formMain.Grid1.lostfocus, formMain.deactivate happen.

So most of what I already said holds true.

There is a bug: The debugger does not break, even if you add a breakpoint acting on the expression select()=2 it only gets active, when you return from frmDummy, while select() already was 2 for all the time the frmDummy form is active. That's a bug of the debugger.

Bye, Olaf.