Selecting record from a Grid for use in another form

[SitesMasstec]

Hello collegues!
I have a Form with a Grid populated with just some data from file RESERVAS.DBF:
When I locate the record I need, I want the form above to desappear and open another Form which has all data from that selected record:



The field "Localizador" is a unique key for each record in the table.
I tried to put in the Grid (first picture), Column1, Text1, Click event, the commands:

YLOCALIZA=this.Value
thisform.Release
DO FORM RELRESERVAS

But it presented error...

Isn't this the correct approach to achieve what I want to do?

 

[Joe Crescenzi]

It looks like you are trying to execute the form after you've released it. As far as I know, any lines after releasing the form will not execute.

The cleanest way to handle this is to keep the first form active, but potentially invisible.

For example:

thisform.visible = .f.
do form RELRESERVAS
thisform.visible = .t.
thisform.refresh() && optional, if you think the value of the second form will change things on the first form.

When the RELRESERVAS form ends, it will take you back to the original form with the grid. If that's not what you wanted, I would use another approach.

 

[igorsandler]

It seems to me that you are over complicating this process. We have a similar behavior on pretty much every maintenance form we have, whcih is a lot but we are using PageFrame with 2 pages(actually, we have more than 2 pages but , anyway). You select the record on the first page that has a grid, then Activate Page 2 that has all those controls and that's all there is to it.
Theoretically, you can call another form using click on the grid record and pass the target value as a parameter to DoForm(), on INIT() assigned it to a form property or public variable , then use a dataset similar to the first form and then use passed parameter to locate a target record. Something like that without a lot of details

 

[Doug Lindauer]

Another way to do this is to just create a container on the same form. The container has all the controls for the details of the grid row. When you design, just have it down below the grid and invisible. When you click a row in the grid, the code makes the grid invisible (or move it down out of view) and makes the container with the detailed view visible and at the top of the form.

To get back to the grid I just put a command button labeled Exit which does this in reverse: make the container invisible and the grid visible.

I often use this approach but have also used the page frame approach which works very well too.

 

[SitesMasstec]

Joe: the form has in the ControlSource for the columns, reservas.localiza, reservas.emissão, etc (RESERVAS.DBF is the Data Environment).
When this form call the 2nd form, it shows error (File already open).
I'm trying to get around this problem.

Igorsandler and Doug: the 2nd form that is called is too big, takes all screen area, has lots of data from 2 tables (RESERVAS.DBF, also used in the 1st form, and PASSAGEIROS.DBF). In fact the second form already uses what you have suggested, Pageframe with 6 pages, in just half part of the form.

 

[Joe Crescenzi]

Joe: the form has in the ControlSource for the columns, reservas.localiza, reservas.emissão, etc (RESERVAS.DBF is the Data Environment).
When this form call the 2nd form, it shows error (File already open).
I'm trying to get around this problem.

Igorsandler and Doug: the 2nd form that is called is too big, takes all screen area, has lots of data from 2 tables (RESERVAS.DBF, also used in the 1st form, and PASSAGEIROS.DBF). In fact the second form already uses what you have suggested, Pageframe with 6 pages, in just half part of the form.

I'm not a fan of data environments because I like the freedom of letting my customers switch directory paths and manage data for entirely different companies, so I open dbf files programmatically before loading forms or in the load event. This gives me freedom of which dbf files to open and when.

That said, I would've assumed that if the files were already open it would ignore it.

Anyhow, I know there are options to either autoopentables on loading or autoclosetables when closing a form, giving you at least some control when you use data environments.

Without a data environment in the form, you would just need to open each table manually in the load event. In my programs, I handle that through a simple PRG that checks to see if the file is already opened, and opens it only if it's not already USED.

 

[SitesMasstec]

I agree totally with you, Joe. I also prefer to have the files in a program (PRG), select the records and fields I will use in a form or report, and save then in a Cursor, as I did in the form I am working now:

SELECT LOCALIZA, EMISSAO, CODAGENTE, NOMAGENTE, NOMECIA, NOMENAV, DATASAIDA, DOCUMENTO ;
  FROM RESERVAS WHERE (EMISSAO>=XQualPDEmissao AND EMISSAO<=XQualUDEmissao) INTO CURSOR curReservas

Then, in the form, Grid, for each field I used the fields in the Cursor: curreservas.localiza, curreservas.emissão, etc (instead of my previous reservas.localiza, reservas.emissão, etc).

 

[SitesMasstec]

A problem has arisen:
I have these commands in the colums, headers, for each time the user click on a header, the records are sorted in ascending order.
For example, in the column for the header of LOCALIZA field, I have the comands, in the Click event:

SET ORDER TO LOCALIZA
thisform.Refresh
GOTO TOP

Well, this was when I was using the table.field (Data Environment), now I am using a Cursor to generate data in the Grid.
How to have the same effect for a Cursor? (to have the records sorted according to the chosen column/field)