Double click on a grid

Hi,

I use a Select SQL statement to create a cursor and then use the cursor to populate a grid.
The grid is on a form that also has "Select" and Cancel" Buttons.

I put the following code in the DblClick event of the grid:

THISFORM.cmdSelect.CLICK()​

In the cmdClick() event, I select the work area and appropriate record based on the grid's return value and run another form.

If I click the grid and then the Select button, it works fine.

If I double click on a column in the grid, the work area changes to the cursor and then the form is run, resulting in errors.

Thanks for any insight,
Sam

 

[Olaf Doschke]

>I select the work area and appropriate record based on the grid's return value
Would you please show this code?

Anyway, Selecting the grid already selects it's recordsource. Selecting a record already selects it.

If your other form accepts the ID of a record as init parameter, all your cmdSelect button has to do would be

if !EOF("cursoralias")
   DO FORM otherform WITH cursoralias.ID
Else
   MessageBox("please choose a record first")
Endif

You don't need to get any parameters from the grid to the button.

Bye, Olaf.

 

[Olaf Doschke]

Besides I'd suggest you don't call events, events happen, they don't get called.

So instead of calling THISOFRM.selectCmd.Click() both the Grid.DblClick() and the selectCmd.Click() should call a form method Thisform.dootherform() with the code to call the other form inside it.

Bye, Olaf.

 

[Dan Freeman]

What Olaf is saying is that grids don't return anything.

Grids also don't react to DblClick unless you do the Dblclick in an empty portion of the grid. Rather, the textbox (or other control) contained in the column contained in the grid is what gets the event.

 

[Olaf Doschke]

Dan,

you're right, but I wasn't even talking of that. If you set grid.AllowCellselection= .F. the grid events will occur, because column controls won't get focus.
Anyway, the douleclick does indeed start the other form, there only are problems and I'm not sure why. Not enough information.

Bye, Olaf.

 

[sdocker]

Hi Olaf,

This is the code to create the cursor:

SELECT ALL LOC_ID, Prop_LOC FROM S2DATA WHERE S2DATA.CODE = CLDATA.CODE ;
INTO CURSOR lfLocations READWRITE

This is the code to select the correct record.
SELECT S2DATA
SEEK(CLDATA.CODE + LEFT(lfLocations.Loc_ID,5))

The cursor does not contain all the fields of the table record. I use it to obtain the index info and seek the record in the table, as follows:

SELECT S2DATA
SEEK(CLDATA.CODE + LEFT(lfLocations.Loc_ID,5)) && S2DATA is indexed on CODE + Loc_ID
DO PDEASS

Sam

 

[Mike Lewis]

Sam,

My preferred solution would be to fix things so that the "other" form does not rely on a particular work area or record being selected. Better always to pass the record number or ID as a parameter to the form, and let the form worry about fetching the correct record.

So, in brief:

- Since your cursor is generated by a SQL statement, you presumably don't want to update it, so set the grid to read only and set its AllowCellSelection to .F. Then, as Olaf pointed out, you will get the grid's DblClick to fire, rather than the column's.

- In both the grid's DblClick and the click of the Select button, call the form, passing the ID of the current record in the cursor as a parameter. Never mind about which work area is selected. Just pass MyCursor.ID or whatever.

- In the Init of the called form, receive the parameter, then navigate to the relevant record within the cursor.

This assumes that the main form and the "other" form have the same data session.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Mike has a good overall solution, I was going in that direction with DO FORM otherform WITH cursoralias.ID.

Nevertheless, before you change in that direction, what is really the error and where do you get an error?

Does the SEEK not work? Check out if EOF("lfLocations"), otherwise you have no data to seek to, no record is selected.

Bye, Olaf.

 

[sdocker]

The seek works because I tested it with FOUND(). The error is "Variable Not Found", because I am referencing a field that is not in the table in the current work area.

The error occurs after the INIT and before the REFRESH of the called form.

FYI: If I close the cursor, it is deleted and everything works.

I'm still perplexed as to why my selecting a table is effective, then the current work area reverts to the cursor.

Sam

 

[Mike Lewis]

The error occurs after the INIT and before the REFRESH of the called form.

But that doesn't tell us what line of code is causing the error. The error can't occur between two methods. It must be inside a method.

I'm still perplexed as to why my selecting a table is effective, then the current work area reverts to the cursor.

Because - as Olaf pointed out -clicking in a grid causes the grid's underlying cursor or table to become selected.

Can we get this clear: Are you actually passing a parameter to the called form? If so, the error is probably caused by the parameter going out of scope when the Init finishes. If you are not, can you clarify exactly what you are doing in the called form?

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Yes, the grid is the main culprit, it select it's own recordsource.
And since you call the other form from the grid dblclick, lfLocations will be selected, when you arrive there.

Set focus to the button in the grid dblclick, that should solve it, for example:

THISFORM.cmdSelect.SetFocus()
SELECT S2DATA
SEEK(CLDATA.CODE + LEFT(lfLocations.Loc_ID,5))
DO PDEASS

Again the warning: If you're at EOF in lfLocations, lfLocations.Loc_ID will be the empty string, the SEEK will just seek CLDATA.CODE and will thereby seek to the first location with the code, eventually not what you'd want. You'll get no error, but jump to the wrong record. So:

IF EOF("lfLocations")
   MessageBox("please choose a location first")
ELSE
   THISFORM.cmdSelect.SetFocus()
   SELECT S2DATA
   SEEK(CLDATA.CODE + LEFT(lfLocations.Loc_ID,5))
   DO PDEASS
ENDIF

If you check FOUND() in PDEASS, you only check, whether SEEK arrives at some record, you don't check, whether a location in lfLocation was actually picked.

Bye, Olaf.

 

[Olaf Doschke]

By the way, Mike has written about this grid behaviour in regard to reports. A preview looks ok, and the print not.

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

if you launch the preview while a grid has focus, the grid changes the current work area to match its record source. For reasons that aren't completely clear, this doesn't immediately affect the preview window, but it does affect the selected alias as seen by the printed report

In the same way, your SEEK seeks in the s2data table, as you do it right after SELECT S2DATA, but when PDEASS has started the next form, the grid cursor has become the active workarea again.

What Christof Lange once told me is, that while VFP does not allow multiple threads (natively), grid controls run their own threads. A grid control depends on it's recordsource being the selected workarea and so the grid simply sets it, this happens sometime and always before the grid would otherwise access another workarea. So the only way around it is to move focus away from the grid, then the grid is inactive and does not play with the selected workarea.

Bye, Olaf.

 

[sdocker]

This line causes the error

.txtC_C_TAX.VALUE = ROUND(.txtC_C_TOT.VALUE * C_C_RATE,2)

because​

C_C_RATE is not a field in the Cursor

I know that at the end of the INIT the work area was correct. In REFRESH, it was not. There is no SELECT statement in the forms code.

I am not passing a parameter to the called form. i select the correct record and then run the form.

Because - as Olaf pointed out -clicking in a grid causes the grid's underlying cursor or table to become selected.

This makes sense, but I changed the work area before calling the form, and once the form is called, it starts out OK and then changes. Is it possibly something to do when it gets to a point where it's waiting for user input?

 

[Olaf Doschke]

You have the answer, the grid does that. Move focus away from it.

Bye, Olaf.