Coding Custom Input Box

[Garret]

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/microsoft.public.access/browse_thread/thread/d52ece95784b6786

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.

 

[Garret]

Any help would be greatly appreciated. Thanks.

 

[Ron2006]

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

 

[Garret]

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]

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

 

[Garret]

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?

 

[Garret]

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]

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

 

[Garret]

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]

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

 

[Garret]

Sorry for my long absence. Alright I've got it working quite well.
However, I noticed that on the Default Windows Input Box, it somehow
keeps focus to the OK button and the text box at the same time, so that
the user can type into the box, and then just press Enter after and it
would be the same as clicking the OK button. How would I do this on my
custom Input box? Right now the text box has focus on open, then when
the user presses Enter the focus shifts to the OK button, then it has
to be pressed again to "click" the button.
Thanks for any help on this.

 

[Garret]

Nevermind, I figured it out. Just set the "Default" property of the OK
button on the form to Yes, and if the Enter key is pressed at any time
while the form is open, then it acts the same as if the button has been
pressed. Just posting this for anyone who might search for answers
from this thread.