I have first form that has text1, text11 and text12, as textboxes. In text1 i have keypress(F3) that calls another form(form2) which has computations. My question is how would i pass a computed value from form2 back to text11 and text12 to form1? I hope i have explain it well.... thanks....
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
how to pass value to first form? 5
- Thread starter Mandy_crw
- Start date
Steve Meyerson
Programmer
Mandy said:
Me said:
See my first post in this thread for a step-by-step. Ok?
Steve
Chris Miller
Programmer
I had yet another idea: Form2 could just take _Screen.activeform a the form which called it.
I attach an example based on that idea.
Unzip, open the pjx file, confirm to set the new home directory of the project and then run the start.prg
Click on the button of form1 starting form2, click on on of the buttons of form2 to set form1 textboxes to some results, which are hardcded, but you can of course return whatever you want, you're also not limnited to char fields and values, it could also be numbers, datetimes, whatever.
The example works with a shareed formcommunication.dbf table that has two fields cResult1 and cResult2, which are set as controlsource of two textboxes of form1. Form2 changes these field values and refreshe form1 to display them in one button, in the other button it sets the tetbox values.
That's also why I asked my last question, if your textboxes text11 and text12 are already having controlsources, that wouldn't hinder you to use that mechanism, it just means you already have a dbf and are able to set the fields text11 and text12 are bound to to whatever you whish to display in them, you wouldn't need the CREATE TABLE formcommunication.dbf
Since the calling form is known to refresh it, the alternative now is also to actually set textbox values, no matter if they're bound to controlsources or not. That's done in the secoond button of form2. It may be something to use, if the textbox controlsources are a cursor only form1 can access and not a dbf form2 can also open - or - if the textboxes of form1 are unbound to data.
I'd still prefer and recommend to use a dbf as your mean to transfer back (and also forth) data between two forms, because form2 shoudn't really need to know how controls on another form are named to set them, there should be a defined way of communjication via a table record, in other cases you may even use many tables and records. Actually that's what you do al the time to communicate between any forms also between different users, you store data ito a shared databse or free tables, doesn't matter, the essnce is you share data in DBFs. That's a natural thing to do. So form2 shouldn't need to know where form1 shows some data, it just wshould know where to store that shared information and form1 then picks that up by refreshing.
If you comment the line Thisform.oCallerform.refresh() from the two buttons in form2, the communication still happens, it's just not shown immediately, when click into the textboxes of form1 the result values wil show, so the refresh() is just needed to show the change of values immediately, the data already is transferred by setting the field values.
Edit: This last thing means even if you don't have an active form when form2 is called or the active form is not the one, that should get the return values, the communication by sharing data also works, the only need is to refresh the form that has new data, that's not happening on its own. But form1 could also refresh itself when form2 closes as it's modal, so the form1 refresh could also be done as THISFORM.REFRESH() in the button on form1 after the DO FORM, form2 then just needs to be made modal or the refresh is done when form2 starts, not when it ends or sets the results. All in all form2 still would only need to know the dbf record to share the data and return results, doesn't need to know the callform or its controls at all, and that's how you should always program, self contained, without needs of knowing which other controls exist, even on the same form. Data is for that.
Chriss
I attach an example based on that idea.
Unzip, open the pjx file, confirm to set the new home directory of the project and then run the start.prg
Click on the button of form1 starting form2, click on on of the buttons of form2 to set form1 textboxes to some results, which are hardcded, but you can of course return whatever you want, you're also not limnited to char fields and values, it could also be numbers, datetimes, whatever.
The example works with a shareed formcommunication.dbf table that has two fields cResult1 and cResult2, which are set as controlsource of two textboxes of form1. Form2 changes these field values and refreshe form1 to display them in one button, in the other button it sets the tetbox values.
That's also why I asked my last question, if your textboxes text11 and text12 are already having controlsources, that wouldn't hinder you to use that mechanism, it just means you already have a dbf and are able to set the fields text11 and text12 are bound to to whatever you whish to display in them, you wouldn't need the CREATE TABLE formcommunication.dbf
Since the calling form is known to refresh it, the alternative now is also to actually set textbox values, no matter if they're bound to controlsources or not. That's done in the secoond button of form2. It may be something to use, if the textbox controlsources are a cursor only form1 can access and not a dbf form2 can also open - or - if the textboxes of form1 are unbound to data.
I'd still prefer and recommend to use a dbf as your mean to transfer back (and also forth) data between two forms, because form2 shoudn't really need to know how controls on another form are named to set them, there should be a defined way of communjication via a table record, in other cases you may even use many tables and records. Actually that's what you do al the time to communicate between any forms also between different users, you store data ito a shared databse or free tables, doesn't matter, the essnce is you share data in DBFs. That's a natural thing to do. So form2 shouldn't need to know where form1 shows some data, it just wshould know where to store that shared information and form1 then picks that up by refreshing.
If you comment the line Thisform.oCallerform.refresh() from the two buttons in form2, the communication still happens, it's just not shown immediately, when click into the textboxes of form1 the result values wil show, so the refresh() is just needed to show the change of values immediately, the data already is transferred by setting the field values.
Edit: This last thing means even if you don't have an active form when form2 is called or the active form is not the one, that should get the return values, the communication by sharing data also works, the only need is to refresh the form that has new data, that's not happening on its own. But form1 could also refresh itself when form2 closes as it's modal, so the form1 refresh could also be done as THISFORM.REFRESH() in the button on form1 after the DO FORM, form2 then just needs to be made modal or the refresh is done when form2 starts, not when it ends or sets the results. All in all form2 still would only need to know the dbf record to share the data and return results, doesn't need to know the callform or its controls at all, and that's how you should always program, self contained, without needs of knowing which other controls exist, even on the same form. Data is for that.
Chriss
- Thread starter
- #23
Hi Chriss.. I dont know how to answer your question but my code looks something like this...
IF LASTKEY() = -2 && Pressing of F3
IF EMPTY(ALLTRIM(thisform.text8.value))
DO FORM PreLoad
ELSE
itmcde = ALLTRIM(thisform.text8.value)
SELECT tsulat
SET ORDER TO idnum
SEEK (itmcde)
idnam = tsulat.idnum
DO FORM PreLoad WITH idnam
ENDIF
ENDIF
and text11 display from a value from a table and text12 should display a value from form2... is this the property you are pertaining to?
IF LASTKEY() = -2 && Pressing of F3
IF EMPTY(ALLTRIM(thisform.text8.value))
DO FORM PreLoad
ELSE
itmcde = ALLTRIM(thisform.text8.value)
SELECT tsulat
SET ORDER TO idnum
SEEK (itmcde)
idnam = tsulat.idnum
DO FORM PreLoad WITH idnam
ENDIF
ENDIF
and text11 display from a value from a table and text12 should display a value from form2... is this the property you are pertaining to?
- Thread starter
- #24
Chris Miller
Programmer
Thanks for posting your code.
In that case it's totally doabloe to pass on THISFORM,too, by changing your code to
If you want to use the idea of passing in the form. In my example this is instead taken for granted to be _screen.activeform, which could get wrong.
On the other hand, the idea to use a modal form to return values from unload needs a TO Varname clause in your form calls. That's just as easy to add as is adding a second parameter.
So both of these previously recommended solutions can be added to your code, I don't know what you're struggling with in both cases.
Remember, you have detailed step by step instructions of what to do and this is just one of the steps. Passing in more parameters also needs more parameters in the form init so thos eparameetrs can also be received.
My new sample needs neither of these modifications, but as I just said relying on _screen.activeform is vague, though I think since your DO FORM is in a textbox.keypress event, this means the form is the active form, otherwise they key would not be processed by the keypress. But in general _screen.activeform can also be NULL and that can lead to errors. Or it's a different form than you want to address.
What you could also use now is how, Steve described to use the return mechaniusm foreseen for modal forms, by making the change I showed in the second code ection with TO Result. At the end of the code you then can split the result into the two parts that should go into text11 and text12.
I didn't ask that, but you indirectly at least answer one aspect, as text11 shows a value from a table, form2 duesn't need to change text11.value, it just needs to replace the field form1 shows. That's the normal way of transporting data, by storing it in a table. That's what I said many times now, already. So you don't let form2 change text11.value, you let it set the field of the record of the table that's showin in text11.
This way, of mainly thinking about where data should go in DBFs is making it far easier to write applications, because you don't care where this data is showns, every control cares for itself by havig controlsources. Those controlsources not only tell the control what to display in the initialization phase, a change of data in a controlsource also changes the value of a control, it's controlSOURCE for a reason, it's also the "sink", the field or variable to which a control stores it's value, if a user interactively changes it by using the control, but the main direction is from the table/record/field to the form, not from the form to the field of a record of a table.
Andf that's how to think always. Act on the data, not on controls, controls get their data anyway.
Now, last thing is you don't say text12 is copming from a table, but nobody hinders you to also create a new table, even if only temporarily as long as form2 is called, to bind text12 to a field of a record of a dbf, too.
You always should mainly think about data as what's in DBF files, not where and how it is displayed in controls of forms. If you focus on the data, all you need to care for is where in a DBF to store something so it appears anywhere else. All your struggles of not knowing how to reach out to text11 and text12 of form1 in form2 then go away, as you don't need to put the results into theses textboxes, all you need to do is store that data from where those textboxes get their data.
And then, when you focus on data and don't focus on controls, you also can change your for, rename controls etc. no matter what, it won't cause errors in other forms.
Chriss
In that case it's totally doabloe to pass on THISFORM,too, by changing your code to
Code:
...
IF EMPTY(ALLTRIM(thisform.text8.value))
DO FORM PreLoad WITH 0, THISFORM
ELSE
...
DO FORM PreLoad WITH idnam, THISFORM
...On the other hand, the idea to use a modal form to return values from unload needs a TO Varname clause in your form calls. That's just as easy to add as is adding a second parameter.
Code:
...
IF EMPTY(ALLTRIM(thisform.text8.value))
DO FORM PreLoad TO Result
ELSE
...
DO FORM PreLoad WITH idnam TO Result
...Remember, you have detailed step by step instructions of what to do and this is just one of the steps. Passing in more parameters also needs more parameters in the form init so thos eparameetrs can also be received.
My new sample needs neither of these modifications, but as I just said relying on _screen.activeform is vague, though I think since your DO FORM is in a textbox.keypress event, this means the form is the active form, otherwise they key would not be processed by the keypress. But in general _screen.activeform can also be NULL and that can lead to errors. Or it's a different form than you want to address.
What you could also use now is how, Steve described to use the return mechaniusm foreseen for modal forms, by making the change I showed in the second code ection with TO Result. At the end of the code you then can split the result into the two parts that should go into text11 and text12.
Mandy said:
I didn't ask that, but you indirectly at least answer one aspect, as text11 shows a value from a table, form2 duesn't need to change text11.value, it just needs to replace the field form1 shows. That's the normal way of transporting data, by storing it in a table. That's what I said many times now, already. So you don't let form2 change text11.value, you let it set the field of the record of the table that's showin in text11.
This way, of mainly thinking about where data should go in DBFs is making it far easier to write applications, because you don't care where this data is showns, every control cares for itself by havig controlsources. Those controlsources not only tell the control what to display in the initialization phase, a change of data in a controlsource also changes the value of a control, it's controlSOURCE for a reason, it's also the "sink", the field or variable to which a control stores it's value, if a user interactively changes it by using the control, but the main direction is from the table/record/field to the form, not from the form to the field of a record of a table.
Andf that's how to think always. Act on the data, not on controls, controls get their data anyway.
Now, last thing is you don't say text12 is copming from a table, but nobody hinders you to also create a new table, even if only temporarily as long as form2 is called, to bind text12 to a field of a record of a dbf, too.
You always should mainly think about data as what's in DBF files, not where and how it is displayed in controls of forms. If you focus on the data, all you need to care for is where in a DBF to store something so it appears anywhere else. All your struggles of not knowing how to reach out to text11 and text12 of form1 in form2 then go away, as you don't need to put the results into theses textboxes, all you need to do is store that data from where those textboxes get their data.
And then, when you focus on data and don't focus on controls, you also can change your for, rename controls etc. no matter what, it won't cause errors in other forms.
Chriss
Steve Meyerson
Programmer
Mandy,
Personally, I think the DBF method Chris describes is the best, safest, most reliable method.
Some of my apps require tens of values to be passed to one of maybe 6 forms. For example my Config.dbf has only a single record with one field for each value (occasionally over 50) to be saved or passed.
An example: Usually I include 2 fields to contain the main form's position (Top & Left) so in the Init of the main form, I position the form in its last position by using these values. Of course I change them in the Moved event. I could change them in Destroy instead, but in a power glitch, it may never be recorded.
Steve
Personally, I think the DBF method Chris describes is the best, safest, most reliable method.
Some of my apps require tens of values to be passed to one of maybe 6 forms. For example my Config.dbf has only a single record with one field for each value (occasionally over 50) to be saved or passed.
An example: Usually I include 2 fields to contain the main form's position (Top & Left) so in the Init of the main form, I position the form in its last position by using these values. Of course I change them in the Moved event. I could change them in Destroy instead, but in a power glitch, it may never be recorded.
Steve
- Thread starter
- #27
Hi Chriss and Steve… thank you so much for those explanations… it really help me alot… i now have the best understanding for how variables are passed and how to manipulate it… in fact text11 and text12 are now functioning as what i needed it… this project of mine is getting bigger and bigger, i thought i was fine when i finished it, but every time as we used it, we tend to see the need to add more features… but im glad that you are all here to assist and give me points and even examples… how could i ever lived without you awesome people?! 
thank you and God bless…
thank you and God bless…- Thread starter
- #28
Hi everyone... I've already finished putting value from form2 to form1... but there is one problem i encountered that i want to ask help... when im back in form 1 that everytime i press esc key, it displays the last value passed.... thanks....
Chris Miller
Programmer
I can't help you with that, nothing we posted has anything to do with the ESC key.
I can give you some poiunters about commands and functions that have to do with the ESC key.
First of all, the ESC character is CHR(27), so ASCII/Ansci code 27 is ESC. LASTKEY()=27 would react to ESC, there's the commands SET ESCAPE ON/OFF and ON KEY can react to ESC like any other key. If you program Keypress the nKeyCode parameter would be 27 when ESC was the key pressed.
Also, ESC is the key that triggers the Click event of a command button that has its button.Cancel property set .T., as it is the key to cause the Cancel reaction of a form.
Within development ESC is also the key to cancel the program execution and stop a program, but that's not what happens in an EXE.
Maybe these pointers help you find more.
Chriss
I can give you some poiunters about commands and functions that have to do with the ESC key.
First of all, the ESC character is CHR(27), so ASCII/Ansci code 27 is ESC. LASTKEY()=27 would react to ESC, there's the commands SET ESCAPE ON/OFF and ON KEY can react to ESC like any other key. If you program Keypress the nKeyCode parameter would be 27 when ESC was the key pressed.
Also, ESC is the key that triggers the Click event of a command button that has its button.Cancel property set .T., as it is the key to cause the Cancel reaction of a form.
Within development ESC is also the key to cancel the program execution and stop a program, but that's not what happens in an EXE.
Maybe these pointers help you find more.
Chriss
- Thread starter
- #30
Chris Miller
Programmer
I meant this different:
To look what you do so far to process ESC.
Instead, you suppressed it, which is simplest done by SET ESCAPE OFF.
There still might be a cancel buttn that when clicked returns (or receives) the last return value again. So even with suppressing ESC, that or a similar meachnism isn't found and could still act, as you don't want it.
Ideally you find why the last returned value is used again and change the code that does cause that.
You didn't post whatever you used from our suggestions, but whatever you use to receive a value from another form in form1, program it so the return value is processed as necessary, but then set to .null. or another value of your choce which you'll treat byignoring it, as the other form would never return such a value.
Chriss
To look what you do so far to process ESC.
Instead, you suppressed it, which is simplest done by SET ESCAPE OFF.
There still might be a cancel buttn that when clicked returns (or receives) the last return value again. So even with suppressing ESC, that or a similar meachnism isn't found and could still act, as you don't want it.
Ideally you find why the last returned value is used again and change the code that does cause that.
You didn't post whatever you used from our suggestions, but whatever you use to receive a value from another form in form1, program it so the return value is processed as necessary, but then set to .null. or another value of your choce which you'll treat byignoring it, as the other form would never return such a value.
Chriss
Chris Miller
Programmer
myself said:
For example, I suggested you use a DBF to store the return value of the other form into it, so form1 can read it out from there.
Well, if you do that, and don't delete the value from the return record, delete the return record or even the whole DBF, then redoing just the receive code you receve the same rertun value again. It is just because you didn't delete it. So, a mnechanism that receives a return value should also care for not being able to receive a value that is not a new return value, by deleting what it has received from the transport vehicle. Even better would be that the receiving code can't run only, if the other form was called and the only way the receiving code runs is that the called form returns a (new) value.
Another way to receive the same value twice is you use a PUBLIC (global) return variable in the TO gReturnvalue clause. Well, if you then recieve something and process it, but don't clear or release the public variable, it still exists and could be read many more times, as if that same value came back again from another form, while it didn't.
So complete the receiving process code.
Chriss
- Thread starter
- #33
Chris Miller
Programmer
No, the main reason for a DBF was this:
So a DBF is the possibility to share data between two object, it doesn't even matter if these two objects are forms or anything else, if they exist on the same computer or different workstations.
What you don't need for a return value is to keep it forever.
Chriss
myself said:
So a DBF is the possibility to share data between two object, it doesn't even matter if these two objects are forms or anything else, if they exist on the same computer or different workstations.
What you don't need for a return value is to keep it forever.
Chriss
- Thread starter
- #35
- Status
Similar threads
- Locked
- Question
