SitesMasstec said:
This will always be true, as THIS is the grid and the code is in the grid DblClick. So simplify your code:
Code:
EsteCodigo = itensest.wecodi
ThisForm.Release()
In comparison your code is much ado about nothing.
I see why this happened, you completely disregarded Tamar's solution in thread184-1777630 to address the existence of a control, not just THIS. You should get more grip on what things mean. You donwgraded her code to something proving you haven't understood the most important bit of it.
To react to <ENTER> use the form.KeyPress event and don't forget to set form.KeyPreview = .T.
As you only have that grid on the form, an ENTER you receive will mean the selection of a row by keyboard.
To check for the <ENTER> key, check the parameters with [tt]IF nKeyCode=13 AND nShiftAltCtrl=0[/tt] and then again assign [tt]EsteCodigo = itensest.wecodi[/tt]
You seem to have created a public variable EsteCodigo, which is a bad choice. In the main form create a cursor as a copy of itensest with just one record in it:
Code:
SELECT * FROM itensest WHERE .F. INTO CURSOR crsMainform READWRITE
APPEND BLANK IN crsMainform
This could go into the main form Init(), so you have this record for the whole lifetime scope of the form.
Set the textbox controlsource in the main form to crsMainform.wecodi. From this moment on changing the value of wecodi in the crsMainfrom cursor will change the display. You may also bind other controls to other fields of crsMainform, create it just as needed, I make the assumption all fields of the itensest are of interest, but you might also add other fields or only pick some fields of itensest, in the most generalized case you can use CREATE CURSOR crsMainform and define any fields you need. You can use the one record in crsMainform to hold all the values you need for controls.
The way it is now you're using controls as variables with form scope, where you need a bigger scope for the two forms. For that bigger scope, a DBF or cursor is ideal when you share a datasession, your controls now become slaves of this cursor, not master variables. But don't ever go for public variables. So don't declare the public variable EsteCodigo in your main.prg
In your grid from above, use the same datasession as in the main form, then instead of assigning the selected itensest.wecodi to EsteCodigo use [tt]REPLACE wecodi WITH itensest.wecodi IN crsMainform[/tt] This is saving you some code, even though it is longer than the assignment to EsteCodigo. You a) don't declare EsteCodigo and b) don't need to set the main form.TextX.Value = EsteCodigo, the grid child form already has updated the crsMainForm data displayed. All you need to after the DO FORM is Thisform.Refresh() and the new value shows.
To be detailed, the grid forms Keypress code will be:
Code:
LPARAMETERS nKeyCode, nShiftAltCtrl
IF nKeyCode=13 AND nShiftAltCtrl=0
REPLACE wecodi WITH itensest.wecodi IN crsMainform
Thisform.Release()
ENDIF
So notice: Sharing a datasession is giving you a way to let forms interact through shared data, the ideal way to interact in such cases. This way you have the least entanglement of code and form structures, you may later change the control on the main form, put it in a page frame or whatever. If you keep it bound to crsMainform.wecodi, the code to set it needs no change, your grid form does not need to know how your main form is structured, you separate the concerns, which is one of the major goals of OOP programming, aim for the least entanglement and dependency of code.
On the other side, it is totally okay to entangle the grid form with the main form by sharing the datasession. Your popup form really just compares to a complex dropdown of a combo box on the main form, it really belongs to the main form. Since you need a whole new form anyway, it's just fair you at least share the datasession. The only dependency your grid form has with the main form is, the main form must create a cursor crsMainform having a field wecodi. This can still be reused for picking a wecodi anywhere else you need to just like now only depending on the public variable EsteCodigo it just depends on crsMainForm.wecodi to exist in the shared datasession.
One maybe not very big but noticeable difference of the smaller scope of sharing data is this: Assume you have two main forms open at the same time (assume that's possible), assume the user does something opening up the grid forms for both main forms for whatever reason, instead of picking one by one. Each selection of the child forms only influences the shared datasession of the corresponding main form and nothing bleeds over. Admitted, it would not happen with the public variable, too, as its value only is of importance in the short moment of the choice, the main form receives its value and since you can't click on two grids at the same time and only one grid will have focus to get the KeyPress event, the public variable will just have the current choice in that moment and after the main form then copies that into its control, the public variable can be overwritten again. But this nature of the public variable already shows its scope is much too big, you really only need a transfer of data. It's no excuse to use that public variable, you use a shared datasession for that matter.
Bye, Olaf.
