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 gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Get info from a dialogue box...
- Thread starter Mandy_crw
- Start date
Mike Lewis
Programmer
Hello Mandy,
Please explain your question more clearly. In particular, what do you mean by "get those info entered in a form"? What are "those info"? And what does "form diappears after..." mean? After what?
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Please explain your question more clearly. In particular, what do you mean by "get those info entered in a form"? What are "those info"? And what does "form diappears after..." mean? After what?
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Chris Miller
Programmer
Well, as Mike already indicated that's very unspecific.
Any form can be used to enter data, that's what VFP forms mainly are about, and what can be stored can be used somewhere else along the line. In the simplest case you can use the messagebox with several button set options and use the returned value to see which button was clicked. You can also offer a popup/context menu, so you're not even needing forms.
The more complex dialog you want, you can of course do any form from the already active form. And you have ore options than just entering some info for your other form to use.
The use case you describe, in short " display a form when a button is clicked", well that's do form in a button click. "get those info entered in a form", well anything you want, just design the form for all the inputs you want the user to be able to enter, no limits here. ", and form disappears after." You can let the user end a form or end it at any moment you want with releasing it, also nothing that's specific to the use case you describe, that's just a normal form functionality to also disappear when you close it. In the simplest case the X in the title bar does that and no code at all is required.
I think what you're after was a bit buried in saying " get those info entered in a for", you want to get the info entered in the secondary form in the first form". Well, you have all options available for data to be entered and store in the second form to be read from tables or elsewhere. If you ant the second form to RETURN some input, the simplest form that does that with its return value is the Messagebox and when you want to do something similar there is RETURN from the UNLOAD event of a form. It's quite out of fashion to do these messagebox/dialog ineractions as they require modal state.
Not to say that's it's not used anymore, but people actually prefer the second form to act on something the first form passed in, like an object.
Before I go in length about any possibilites, please describe in more detail what you actually want to happen step by step.
Chriss
Any form can be used to enter data, that's what VFP forms mainly are about, and what can be stored can be used somewhere else along the line. In the simplest case you can use the messagebox with several button set options and use the returned value to see which button was clicked. You can also offer a popup/context menu, so you're not even needing forms.
The more complex dialog you want, you can of course do any form from the already active form. And you have ore options than just entering some info for your other form to use.
The use case you describe, in short " display a form when a button is clicked", well that's do form in a button click. "get those info entered in a form", well anything you want, just design the form for all the inputs you want the user to be able to enter, no limits here. ", and form disappears after." You can let the user end a form or end it at any moment you want with releasing it, also nothing that's specific to the use case you describe, that's just a normal form functionality to also disappear when you close it. In the simplest case the X in the title bar does that and no code at all is required.
I think what you're after was a bit buried in saying " get those info entered in a for", you want to get the info entered in the secondary form in the first form". Well, you have all options available for data to be entered and store in the second form to be read from tables or elsewhere. If you ant the second form to RETURN some input, the simplest form that does that with its return value is the Messagebox and when you want to do something similar there is RETURN from the UNLOAD event of a form. It's quite out of fashion to do these messagebox/dialog ineractions as they require modal state.
Not to say that's it's not used anymore, but people actually prefer the second form to act on something the first form passed in, like an object.
Before I go in length about any possibilites, please describe in more detail what you actually want to happen step by step.
Chriss
- Thread starter
- #4
hi Mike and Chriss... I do have a first form that has an ok button, that when clicked it will show another form that has an ok button also, the second form will ask for additional info from the user... pardon me i cannot explain much, thanks....
Mike Lewis
Programmer
OK, let me try to understand this.
Your first form has an OK button. So, in the Click event of that button, you need something like this:
[tt]
DO FORM MySecondForm[/tt]
So now, when the user clicks the OK button, they will see the second form.
The second form will have data-entry fields. These are typically text boxes, but might also be edit boxes, combo boxes, spinners, option groups, etc. The user can enter their data in these fields.
You now need to get that data into your program. There are two broad approaches. You can set up a table (a DBF file) to receive the data. In that case, the ControlSource of each of the data-entry fields would point to the corresponding fields in the table. As the user enters (or edits) the data, the table will automatically be updated. (I'm simplifying slightly, but that's not important.)
The other option is for your program to to take the Value property of each of the data-entry fields. That property will contain whatever the user enters. The value will be available as soon as the user finishes editing the field.
Does that help at all?
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Your first form has an OK button. So, in the Click event of that button, you need something like this:
[tt]
DO FORM MySecondForm[/tt]
So now, when the user clicks the OK button, they will see the second form.
The second form will have data-entry fields. These are typically text boxes, but might also be edit boxes, combo boxes, spinners, option groups, etc. The user can enter their data in these fields.
You now need to get that data into your program. There are two broad approaches. You can set up a table (a DBF file) to receive the data. In that case, the ControlSource of each of the data-entry fields would point to the corresponding fields in the table. As the user enters (or edits) the data, the table will automatically be updated. (I'm simplifying slightly, but that's not important.)
The other option is for your program to to take the Value property of each of the data-entry fields. That property will contain whatever the user enters. The value will be available as soon as the user finishes editing the field.
Does that help at all?
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Chris Miller
Programmer
I'd always expect OK to close a form with confirmation, not cause a dialog. Special case may the question "Are you sure?" to confirm something, but that aside, in the first place you need
first form Botton click event code:
And you've con 99% of what you need.
As you can do anything in a form, no matter if it's started from a menu item or by click of a button, you can also ask or allow the user to enter anything you want and store it where you need it.
So what else do you actually need? It would still help if you can think of a more concrete case. I think the core problem isn't calling a form, is it? It's getting the input returned.
In the simplest case of a modal secondform you call it by
And in secondform.scx have a RETURN in its unload event:
You might want to return what a user picks in a combobox, the only hurdle left for something like that is that Unload event happens after form controls have been removed, so you can't for example RETURN Thisform.Text1.value but in the OK button of secondform you could do:
Where result is a property of the form you have to add in the form designer. You could also use the Tag property as a simple solution, just be aware you can only assign strings to it, and thus, for example, not return a number (which might be plausible in case you ask for number of copies of a report to print) or a date (which might be plausible if the secondform.scx is a date picker form).
To give you an idea why you don't need Unload to return anything, you could let secondform use controls bound to a dbf like secondform.dbf, that could have multiple fields and also multiple records and then you can just use the first advice - DO secondform.scx - and then get whatever was entered in secondform by reading from secondform.dbf.
And for that matter, it could be anything, any dbf you already have and let secondform.scx work on, just like any other normal unrelated form that works on its own and doesn't return something. Which - in short - means, you can do whatever you want.
And that brings me back to the question why you're asking, you have to have something more specific in mind that you can't do with all you already know and do. What I said already before is, that what you aks needs no special additional knowledge, you don't depend on knowing the return mechanism of a form. And as you already programmed forms that have input controls and store inputs somewhere, you already have all necessary ingredients. This is what makes me and I guess also Mike Lewis think, what really is your problem, you know how to start a form and store what a user enters, you now just DO someform in a click of a form commandbutton instead of a menu item.
The second form could indeed have further buttons starting third forms.
Chriss
first form Botton click event code:
Code:
DO FORM secondformAnd you've con 99% of what you need.
As you can do anything in a form, no matter if it's started from a menu item or by click of a button, you can also ask or allow the user to enter anything you want and store it where you need it.
So what else do you actually need? It would still help if you can think of a more concrete case. I think the core problem isn't calling a form, is it? It's getting the input returned.
In the simplest case of a modal secondform you call it by
Code:
DO FORM secondform TO resultvariableAnd in secondform.scx have a RETURN in its unload event:
Code:
RETURN 42You might want to return what a user picks in a combobox, the only hurdle left for something like that is that Unload event happens after form controls have been removed, so you can't for example RETURN Thisform.Text1.value but in the OK button of secondform you could do:
Code:
Thisform.result = thisform.text2.value && or anything else
Thisform.Release()Where result is a property of the form you have to add in the form designer. You could also use the Tag property as a simple solution, just be aware you can only assign strings to it, and thus, for example, not return a number (which might be plausible in case you ask for number of copies of a report to print) or a date (which might be plausible if the secondform.scx is a date picker form).
To give you an idea why you don't need Unload to return anything, you could let secondform use controls bound to a dbf like secondform.dbf, that could have multiple fields and also multiple records and then you can just use the first advice - DO secondform.scx - and then get whatever was entered in secondform by reading from secondform.dbf.
And for that matter, it could be anything, any dbf you already have and let secondform.scx work on, just like any other normal unrelated form that works on its own and doesn't return something. Which - in short - means, you can do whatever you want.
And that brings me back to the question why you're asking, you have to have something more specific in mind that you can't do with all you already know and do. What I said already before is, that what you aks needs no special additional knowledge, you don't depend on knowing the return mechanism of a form. And as you already programmed forms that have input controls and store inputs somewhere, you already have all necessary ingredients. This is what makes me and I guess also Mike Lewis think, what really is your problem, you know how to start a form and store what a user enters, you now just DO someform in a click of a form commandbutton instead of a menu item.
The second form could indeed have further buttons starting third forms.
Chriss
tomk3
Programmer
Hello Mandy,
we do something similar, do a from and if ok, get values from another form.
Attached you find a sample project how to do that with modal form handing over parameters and receiving values back.
Unpack it and issue a set default to targetfolder in commandprompt
hth
Regards
tom
we do something similar, do a from and if ok, get values from another form.
Attached you find a sample project how to do that with modal form handing over parameters and receiving values back.
Unpack it and issue a set default to targetfolder in commandprompt
hth
Regards
tom
Mike Lewis
Programmer
Just to add to Chris's previous post, he mentioned:
In the Click of the first form:
[tt]DO FORM secondform TO resultvariable[/tt]
and in the second form's Unload:
[tt]RETURN 42[/tt]
Just keep in mind that, for that to work, the second form has to be modal. To make a form modal, set its WindowType to 1.
Once you've done that, the first form will be able to pick up the result of the second form in the variabe following TO (resultvariable in Chris's example).
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
In the Click of the first form:
[tt]DO FORM secondform TO resultvariable[/tt]
and in the second form's Unload:
[tt]RETURN 42[/tt]
Just keep in mind that, for that to work, the second form has to be modal. To make a form modal, set its WindowType to 1.
Once you've done that, the first form will be able to pick up the result of the second form in the variabe following TO (resultvariable in Chris's example).
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Chris Miller
Programmer
Right, I already mentioned modal before, and also that it's not very desirable. It hinders a user to get several things done in parallel.
My recommendation mainly focuses on not using the Unload mechanism, just telling that you're really free to use any means of data sharing you already use in any VFP application, for sure.
Not that I condemn a little Messagebox or also some similarly simple modal dialog. But only really when it's all part of a short lasting modal interaction. And some of the things that work modal nowadays actually enforcing it with "lightbox" (for anyone not knowing it google it) so you're really forced through this pipeline of interaction. And many of the things could just simply be a combobox on the main form itself instead of a pop-up dialogue. If it takes a more complex secondary form it's already suspicious you want it to return something, just one value, from the whole form back to the caller. You want to get some workflow going, so design it the way it's worth the name "flow" and not a jumping forth and back.
So I look at it in the form of a Venn diagram:
set1: Need an extra dialogue form (for reasons of reuse, complexity, whatever)
set2: Need something from that extra dialogue (a simple value, confirmation, yes/no decision)
And I see no intersection between the two sets.
If it's small enough, put it on the main form already. Even if it's more complex, you have things like containers, page frames and their pages navigable by tabs and many more ways to have more sections in one form, so also reasons of screen size are coverable by this. You totally remove the need to return data, it's all in the form. And even for sake of reusability, make a container or page class and thereby let it be usable on many forms.
If it's really complex, how is it that only a single return value helps about it at all, why divert and come back? Make it a multi step workflow and let one form go over to the next, if you like the simplicity of maintaining multiple forms over multiple pages, or whatever. So don't go main->diallogue1->main->dialogue2->main->dialogue3->main->Finish but go step1form->step2form->step3form->finish. In both cases steps may be skipped. The multi step workflow will neither return something nor even get previous step data passed in to form init() parameters. Well, you're free to implement it that way, too, of course, but why at all? All the single step forms can share data in one or several DBFs. We're working in VFP here, aren't we?
Chriss
My recommendation mainly focuses on not using the Unload mechanism, just telling that you're really free to use any means of data sharing you already use in any VFP application, for sure.
Not that I condemn a little Messagebox or also some similarly simple modal dialog. But only really when it's all part of a short lasting modal interaction. And some of the things that work modal nowadays actually enforcing it with "lightbox" (for anyone not knowing it google it) so you're really forced through this pipeline of interaction. And many of the things could just simply be a combobox on the main form itself instead of a pop-up dialogue. If it takes a more complex secondary form it's already suspicious you want it to return something, just one value, from the whole form back to the caller. You want to get some workflow going, so design it the way it's worth the name "flow" and not a jumping forth and back.
So I look at it in the form of a Venn diagram:
set1: Need an extra dialogue form (for reasons of reuse, complexity, whatever)
set2: Need something from that extra dialogue (a simple value, confirmation, yes/no decision)
And I see no intersection between the two sets.
If it's small enough, put it on the main form already. Even if it's more complex, you have things like containers, page frames and their pages navigable by tabs and many more ways to have more sections in one form, so also reasons of screen size are coverable by this. You totally remove the need to return data, it's all in the form. And even for sake of reusability, make a container or page class and thereby let it be usable on many forms.
If it's really complex, how is it that only a single return value helps about it at all, why divert and come back? Make it a multi step workflow and let one form go over to the next, if you like the simplicity of maintaining multiple forms over multiple pages, or whatever. So don't go main->diallogue1->main->dialogue2->main->dialogue3->main->Finish but go step1form->step2form->step3form->finish. In both cases steps may be skipped. The multi step workflow will neither return something nor even get previous step data passed in to form init() parameters. Well, you're free to implement it that way, too, of course, but why at all? All the single step forms can share data in one or several DBFs. We're working in VFP here, aren't we?
Chriss
tomk3
Programmer
Hello,
maybe you can put it in a pageframe with 2 pages (thats what we do often), so no need for a second form
regards
tom
maybe you can put it in a pageframe with 2 pages (thats what we do often), so no need for a second form
regards
tom
Chris Miller
Programmer
Tom,
we're thinking along the same lines.
and Mandy,
I think however it turns out, you now have all you already had before this thread plus the idea of DO FORM... TO Varname and RETURN in the Unload of a modal second form. The way TO Varname works also is fully described in the help topic of DO FORM.
I just think your question also arises, because you've had an issue, that could need to be addressed differently. As you said "and form disappears after" I think you have a form that stays visible although you close it, and that could point out a more complex problem. Because, of course, a form usually disappears when a user or your code closes it, there is no secret to know about clearing a closed form from the display, a form.release() includes removing it visually. A form persisting visually is not just graphics persisting, it points out the form object stayed open despite the closing of the form.
And again, before I go in length into details what the reason for that could be, it would help if you develop your idea and ask us to recommend what code to use for the idea or show your current code for reproducing any problem and fixing it.
Chriss
we're thinking along the same lines.
and Mandy,
I think however it turns out, you now have all you already had before this thread plus the idea of DO FORM... TO Varname and RETURN in the Unload of a modal second form. The way TO Varname works also is fully described in the help topic of DO FORM.
I just think your question also arises, because you've had an issue, that could need to be addressed differently. As you said "and form disappears after" I think you have a form that stays visible although you close it, and that could point out a more complex problem. Because, of course, a form usually disappears when a user or your code closes it, there is no secret to know about clearing a closed form from the display, a form.release() includes removing it visually. A form persisting visually is not just graphics persisting, it points out the form object stayed open despite the closing of the form.
And again, before I go in length into details what the reason for that could be, it would help if you develop your idea and ask us to recommend what code to use for the idea or show your current code for reproducing any problem and fixing it.
Chriss
- Thread starter
- #13
Dan Olsson
Programmer
Judging by the subject ONLY, I would answer with this: Link
- Thread starter
- #15
- Status
Similar threads
