Thanks for posting your code.
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
...
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.
Code:
...
IF EMPTY(ALLTRIM(thisform.text8.value))
DO FORM PreLoad TO Result
ELSE
...
DO FORM PreLoad WITH idnam TO Result
...
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.
Mandy said:
text11 display from a value from a table and text12 should display a value from form2
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