Hello everyone,

I have a form ( a few actually), that have command buttons that would
open an input box, and take that data and do some things with it. I
wanted to solve the problem of "OK with no input = Cancel", so I did
some research and it seems like most MVPs prefer to make their own
forms that look like Input Boxes. This article was a big help:

http://groups.google.com/group/micro...2ece95784b6786

So my question is, how am I able to take data from this form (when user
presses OK) and pass it to the other form to use? This will need to be
done on several forms so I need a generic Input box that isn't
hardcoded to just pass data to the same place.

Thanks for your time.

Any help would be greatly appreciated. Thanks.

There are, of course, many ways of solving this problem.

I have used the following approach on some applications that are Jet
MDBs.

1) create an unbound form called "HiddenKey" (or whatever)

2) Create on this form a text box to hold the data you want. (named -
HKmyfieldname)

3) In the onOpen event of whatever is the first form you always open
add:
docmd.openform "HiddenKey" ,,..... acHidden ' not sure
how many commas.

4) Create you generic custom input box.
onopenevent
forms![HiddenKey]![HKmyfieldname] = null
make sure you require an entry before enabling the OK button
onclick event
forms![HiddenKey]![HKmyfieldname] = me.Inputdatafieldname

5) When/where you call this custom input box
make sure you now have data in the
forms![HiddenKey]![HKmyfieldname]
if so then call your routines, but have them use
forms![HiddenKey]![HKmyfieldname] as the control for
whatever you want.



Ron

Thanks for the suggestion, Ron! I'll try implementing your method.
Apparently I'm not the only one who thought that it looked like it
couldn't be done without some sort of hidden business going on. I just
thought there might be an efficient way that would do it straightout.

Ron2006 wrote:
> There are, of course, many ways of solving this problem.
>
> I have used the following approach on some applications that are Jet
> MDBs.
>
> 1) create an unbound form called "HiddenKey" (or whatever)
>
> 2) Create on this form a text box to hold the data you want. (named -
> HKmyfieldname)
>
> 3) In the onOpen event of whatever is the first form you always open
> add:
> docmd.openform "HiddenKey" ,,..... acHidden ' not sure
> how many commas.
>
> 4) Create you generic custom input box.
> onopenevent
> forms![HiddenKey]![HKmyfieldname] = null
> make sure you require an entry before enabling the OK button
> onclick event
> forms![HiddenKey]![HKmyfieldname] = me.Inputdatafieldname
>
> 5) When/where you call this custom input box
> make sure you now have data in the
> forms![HiddenKey]![HKmyfieldname]
> if so then call your routines, but have them use
> forms![HiddenKey]![HKmyfieldname] as the control for
> whatever you want.
>
>
>
> Ron

Some would perhaps create some global fields perhaps, but I find the
hidden form easy to use and easy to see what fields are loaded when
testing. (I can double-click the form to have it show (visible) and see
what values are in what fields.)

This approach makes it easy to open / reuse forms throughout the app.
The only danger comes in going too deep (too many levels) and in the
effort to do so re-using a field that an earlier form is using, Sort of
like stepping on your own toes or sitting on the branch you are cutting
off. In one fairly complicated series of calls, I had to actually save
the prior value before calling the higher level form and then restoring
it after the call.

Oh, the convoluted paths we develop for ourselves.

Ron

Now what if I want to change the label on that Inputbox Form to make it
ask a different question each time depending on which source opened it?


Ron2006 wrote:
> Some would perhaps create some global fields perhaps, but I find the
> hidden form easy to use and easy to see what fields are loaded when
> testing. (I can double-click the form to have it show (visible) and see
> what values are in what fields.)
>
> This approach makes it easy to open / reuse forms throughout the app.
> The only danger comes in going too deep (too many levels) and in the
> effort to do so re-using a field that an earlier form is using, Sort of
> like stepping on your own toes or sitting on the branch you are cutting
> off. In one fairly complicated series of calls, I had to actually save
> the prior value before calling the higher level form and then restoring
> it after the call.
>
> Oh, the convoluted paths we develop for ourselves.
>
> Ron

Now what if I want to change the label on that Inputbox Form to make it
ask a different question each time depending on which source opened it?


Ron2006 wrote:
> Some would perhaps create some global fields perhaps, but I find the
> hidden form easy to use and easy to see what fields are loaded when
> testing. (I can double-click the form to have it show (visible) and see
> what values are in what fields.)
>
> This approach makes it easy to open / reuse forms throughout the app.
> The only danger comes in going too deep (too many levels) and in the
> effort to do so re-using a field that an earlier form is using, Sort of
> like stepping on your own toes or sitting on the branch you are cutting
> off. In one fairly complicated series of calls, I had to actually save
> the prior value before calling the higher level form and then restoring
> it after the call.
>
> Oh, the convoluted paths we develop for ourselves.
>
> Ron

Two things that I can think of:

1) I have not tried this but it may work just fine.
a) Add another field to that hiddenform that is titled txtQuestion.
b) In the calling form have it load the question into the
hiddenkey.txtQuestion
c) In the on openevent of the box put
me.formname.caption = forms![HiddenKey]![txtQuestion}

as I said I have not tried this but it is probably available. The
limitation on the above method is that there can be only one line of
text in the form caption. The next approach does not have that problem.

OR

2) I know that this one can work
a) create a label on the form, formated as you want and named
lblQuestion (put that as the caption also)
b) In the calling form have it load the question into the
hiddenkey.txtQuestion
c) In the on openevent of the box put
me.lblQuestion.caption = forms![HiddenKey]![txtQuestion}

In fact you can create multiple labels and fill them as required and
desired.

On approach 2 you can use a txtbox also but you then have to play
around with changing the formating more, but you may want that. Just
make them locked and not a tab stop
Ron

Thanks a bunch Ron! You've been a great help to me on this subject.
I'll try using your second method right away.

Ron2006 wrote:
> Two things that I can think of:
>
> 1) I have not tried this but it may work just fine.
> a) Add another field to that hiddenform that is titled txtQuestion.
> b) In the calling form have it load the question into the
> hiddenkey.txtQuestion
> c) In the on openevent of the box put
> me.formname.caption = forms![HiddenKey]![txtQuestion}
>
> as I said I have not tried this but it is probably available. The
> limitation on the above method is that there can be only one line of
> text in the form caption. The next approach does not have that problem.
>
> OR
>
> 2) I know that this one can work
> a) create a label on the form, formated as you want and named
> lblQuestion (put that as the caption also)
> b) In the calling form have it load the question into the
> hiddenkey.txtQuestion
> c) In the on openevent of the box put
> me.lblQuestion.caption = forms![HiddenKey]![txtQuestion}
>
> In fact you can create multiple labels and fill them as required and
> desired.
>
> On approach 2 you can use a txtbox also but you then have to play
> around with changing the formating more, but you may want that. Just
> make them locked and not a tab stop
> Ron

Also.....

To make it look more like a question box/form.

set a bunch of the data and format tab stuff that is applicable to
showing queries to No.
schroll bars
dividing lines
record selector
navigation buttons
control box - maybe

Ron