Selecting one row from a grid

[SitesMasstec]

I have looked in many VFP books for days, and have found lots of complex Grid matters, but not about this simple one:

I want to select a row from a grid, but I have not been able to do this, WHEN the form with the grid is called from another form, through the F2 key (figure 1) . But the form with the grid alone works! (figure 3)

I want also to take the value of the first column from the select row.
Figure 1

Figure 2
Properties from the above FORM WITH GRID, which is called from the other larger form:

Bellow ("alone it works"):
Figure 3

Thank you,
SitesMasstec

 

[Mike Lewis]

To select a row in a grid, you must first move the record pointer to the corresponding record in the underlying cursor or table. Then call the grid's SetFocus method (you do not need to refresh the grid).

You also need to set the grid's HighlightStyle to 2, but I see you have already done that.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

I don't know what you mean, SitesMasstec. I only see you have contradicting property settings of the called form, you have a top level form and set it to modal, that won't work, the modal definition will be disregarded unless the form is not really started as top level form. A form can't be top level form and modal at the same time.

What about the major form? If that is modal, it would explain why you can't work in the child form.

When you want the user to be able to work with multiple forms, all of them should be non-modal forms. That disables you to use things like DO FORM ... TO variable, as that depends on the called form being modal, but that whole concept is limiting the kind of interactions you can do because of form modalities.

An ideal application has no modal forms, besides occasional Message boxes. One easy way to have child forms influence parent forms is passing on THISFORM, have a form handler moderating between forms, forwarding dependencies and one strong instrument for forms involved with each other is, to let child forms work in the same data session, which simplifies setting values you would normally only set after the child form returns. You don't need to pass back anything, in that case, thus need no TO variable clause and no modality.

Bye, Olaf.

 

[SitesMasstec]

Hello colleagues:

Nothing of the above worked, but I can move through the rows in the grid with the down and arrow keys. But not with the mouse.




Thank you,
SitesMasstec

 

[Mike Lewis]

You have got AllowCellSelection set to .F. That would explain why you can't select a row with the mouse. Set AllowCellSelection to .T.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Well, this doesn't fit the earlier description, as you said the form works when run alone. I still think this is about modal/non modal.

Bye, Olaf.

 

[SitesMasstec]

AllowCellSelection set to .T. just hightlights the first colum in the first row. The mouse is not able to move to another row.

Also, I tried to change Modal/Modeless without sucess. As you can see in figure 1 above, the child window appears, and allows moving through the rows with Up and Down keys typed in my keybord, but not the mouse...

I think the child window HAS focus, or it wouldn't allow the moving through rows from keyboard. (Indeed I am not 100% sure about this...)


Thank you,
SitesMasstec

 

[Olaf Doschke]

What do you do to let F" call that secondary form?

Bye, Olaf.

 

[SitesMasstec]

Olaf:

When the major form is active, I press F2 to call the secondary form.

Note: In the main program I have the command:
ON KEY LABEL F2 DO FORM ITENSEST2
(ITENSEST2.SCX is the secondary form)


Thank you,
SitesMasstec

 

[Olaf Doschke]

OK, you still should keep your form being modeless, as any top level form will not be modal anyway. And you also don't need this, as there is no TO voriable clause of your DO FORM. I know this does not help here, but at least this rules out some thoughts.

I can imagine why you have all forms as top level form. If you have _screen.visible = .F. or SCREEN=OFF no normal form will appear, as they appear within the invisible _SCREEN and thus are invisible. Also, when you start forms from no context, as ON KEY LABEL does, in top level forms also don't appear, as your forms are no child forms. All your forms are main forms. That could play a role, but by itself is no reason you couldn't switch active form or use control with the mouse.

Do you have any ON KEY MOUSE or LEFTMOUSE or RIGHTMOUSE?

Bye, Olaf.

 

[SitesMasstec]

No, I don't have any ON KEY MOUSE or LEFTMOUSE or RIGHTMOUSE.

In my application major window (figure 1) I have the properties:
Show Window: In Screen
Window Type: Modal
If I change the above Window Type to Modeless, some errors appears when executing @...GET in the main program (which calls the major window: "Property Backstyle is read-only").

Interesting to note that in the Figure 3 above it works fine with:
Show Window: In Top Level Form
Window Type: Modeless


Thank you,
SitesMasstec

 

[Olaf Doschke]

Aha, that's news. You're working with @...GETs. You can't mix Winforms and legacy @GETs, this won't work. You're locking focus/events.

In a VFP application, you should only use visual forms/controls and READ EVENTS for the generic idle place in code waiting for and reading any events coming to any form.

Bye, Olaf.

 

[SitesMasstec]

But that @GET... is in the main .PRG program, neither in the major nor secondary forms.

And in the other example - Figure 3 - also has a .PRG program with @GET..., and it works.



Thank you,
SitesMasstec

 

[SitesMasstec]

Ah, sorry Olaf, this @GET in the main form is in a loop!

DO WHILE...

@GET...​

READ​

DO FORM...​

ENDDO

I am going to change this now.


Thank you,
SitesMasstec

 

[Olaf Doschke]

READ EVENTS also has to be applied in main, it is what you do in a VFP application instead of any @GET and READ.

To end the opposite is a CLEAR EVENTS or you QUIT, but put away any READ and @GET, that won't work with Windows events and messages.

I never programmed legacy Foxpro, but you can't mix legacy screens and forms, this is bound to fail, the model of how to cope with events differs.

The help topic about @...GET mentions the Listbox as alternative control, I rather have the feeling any visual control enabling the user to enter something or make a choice is your replacement for @...GET. The controls themselves are already enabling the user to input something, there is no extra statement needed to wait for any input. What the user inputs becomes the controls .VALUE property value most of the time and more important is forwarded to dbf table fields by binding via controlsource or recordsource or rowsource (depends on which control), so it makes any SCATTER/GATHER code completely unneccessary and you don't need to instruct VFP to wait for input. Contrary to this, the InteractiveChange happens, when a user enters something, and Valid happens right before the focus will be moved elswhere and this event is called Valid is you put your code in there to check the validity of input.

Bye, Olaf.

 

[SitesMasstec]

Hi Olaf! Now I have the application running correctly;

I changed the properties in all forms:
Show Window: 0-In Screen
Window Type: 1-Modal

And instead of using F2 key to invoke the child form (from which the user should select a row) now I created a button ("Select an item") in the major form. So, when the user press this button (which has a SetFocus in its Click property) the child window opens, and the user can select any row from it.

And when the user double click, selecting a row, it desappears (in the Grid: DblClick property, I put thisform.Release). Now I am going to work to pass the selected row to a field in the major form.

Note: I restored the loop with the @GET in the mais .PRG, without problem.

Thank you for your valuable help.


Thank you,
SitesMasstec