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 SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Form not 'halting' to accept input

Status
Not open for further replies.

fredzeppelin

Technical User
Mar 17, 2005
26
0
0
US
I have a form with 2 controls.


A combo box that has a row source in a table, nothing fancy, just the only field, all records.

A continue button. The on-click event is set to basically no-op.

When I open the form programmatically, it opens, and doesn't wait for any events, it just returns control to the caller.

What could cause the form to not wait for input?

It worked yesterday, .....

Is there a better way?
I want to open the form, pick from the combo box, click continue, 'return' back to the calling code while leaving the form open (so I can pick off the contents of the combo box later). Then close the form later from the calling code.

If there's a Faq or thread, point the way. I had no idea what key words to search on

.....brad
 
Hi. If your 'calling code' simply states "Docmd.OpenForm", then that's all it will do. then the 'calling code' just continues on its way.

Seems you're wanting the code to do something for you (wait) that you are not instructing it to do. Not sure how it "worked yesterday" if you haven't changed anything.

I'm not sure what you mean that your button "The on-click event is set to basically no-op", but I'd put in code in the on-click event that then goes back to the 'calling code' or whatever it is you are trying to do.

something like that. you have to code the events that you want to happen, it just won't happen for you.

If you don't understand, please provide more info such as all code, what you mean by 'calling code' (is it a function or from a form or what?) and what exactly it is you are trying to accomplish with this.

Thanks--g


Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244
 
You said:

I'd put in code in the on-click event that then goes back to the 'calling code' ....

Yes, Exactly what I want.
So what code do I put there?

In other languages, this is called a subroutine return. How do I do that here?

I don't even know how to search for it.
====
Yesterday, when I couldn't figure this out, I assigned the onclick to a procedure, which at one point I left blank. That worked. Go figure. Today it surely doesn't

 
I don't know where/what your 'calling code' is, so it's hard to help you.

Why exactly are you doing this? If you are currently on a form, and click a button to pop-up this second form, then pick something from a combo box, and hit another button to return to the first form...you can do all of that on the first form.

Or if you are on a form, and want to prompt the user for some info, you could use inputbox.

Or are you using a Function?

Again, without know what you are doing, how you get to this form, why you need to be there, and where you want to return to, it's hard to help...

Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244
 
You can play with the windowmode arguement of the openform method. If not not passing anything in there at all (default is acWindowNormal), it will just open the form, and proceed with the rest of the code in the calling routine. Then you can use the acDialog option, which makes the form mimick the message boxes (modal), this will halt execution in the calling form/routine until the form is closed (or one for instance makes it hidden). If you need to pass any information, pass it when the user clicks the "close" button, if you have one, or try either the close or unload event of the form.

[tt]docmd.openform "myform",,,,,acDialog[/tt]

Roy-Vidar
 
Another cool thing to use with forms is to use the OpenArgs. OpenArgs is the last argument with the DoCmd.OpenForm. You can use the OpenArgs to control all sorts of things when loading the form, or to control how the form acts. For example, I use OpenArgs to decide to open a form in Read-Only or with Admin priveledges. Or to display a reduced or full recordset. OR change how command button acts (for example, to close a form, or hide a form).

I am sure it can be adjust to your needs.

I want to open the form, pick from the combo box, click continue

Have the command button open the form. SetFocus to the ComboBox. You can have the code hide the first combo box ... or not.

'return' back to the calling code while leaving the form open (so I can pick off the contents of the combo box later)

This part of the code had to run from the second form. First, you can use the DoCmd.OpenForm command again. By default, Access will only open the form once, so by openning the form from the second form, you can excert some control by using the OpenArgs option.

...But there are lots of ways to handle this type of thing. You have two great tipsters responding to your thread, and perhaps others may chime in with other ideas.

Richard
 
1. I can't find acDialog documented anywhere, except that it's a 'windowmode'. I did find a whole bunch of gibberish by a guy in Canada, saying how different and complicated it was, and mere mortal programmers probably didn't use it right (lol).

2. On the other hand, I've done a bunch of experimentation and have had an epiphany of sorts. I'll have to keep thinking about it, but it's apparent that I'm asking a nonsense question. It's simply not applicable to this object model, even tho' it's full of things called procedures.

3. All the code in Access VBA I've written so far has been basically one form opening another, opening another, etc. and then closing back to 'main', sort of like a chain of calls. And I don't really see any other way around it. A whole additional level of spaghetti code. When I inherited this project, it took me days to figure out what called whom, when.

Anyway, thanks very much[\b] for the help, it didn't exactly answer the question I asked, but it told me what I needed to know.



 
Open the form in design mode, and make sure the Properties window is open ("View" -> "Properties")

Select the form by clicking on the top left square where the verticle and horizonatl rulers meet.

Now click on the "Evnts" in the Property window. For test purposes, select "OnOpen" (you can also use On GotFocus, On Current)

Code:
If Len(OpenArgs & "") Then
   'there are opening arguments, code for action

Else
   'there are no opening arguments

End If

Richard
 
Open the form in Dialog mode. This will pause the code execution in the calling form.

Declare a Form variable in the general section of the form:

Dim frmCallingForm As Form

In the Open event, set the variable to the calling form:
Code:
Private Sub Form_Open(Cancel As Integer)
Set frmCallingForm = Screen.ActiveForm
End Sub

Now you have full control over the 'calling form' directly from the dialog form. Do whatever needs to be done while the dialog is open. For instance, set the values of certain controls:

frmCallingForm("TextBoxName") = "Some Text"
frmCallingForm("ListBoxName").RowSource = "Select FieldName From TableName Where Condition"
frmCallingForm("ListBoxName").Requery

and so on...

When you close the dialog, the calling form will resume code execution, with all the information filled in.

If you use a naming convention in all your objects, you can find a way to remove most or all of the hardcoding and make your dialog very flexible and re-usable.

One small example:
Suppose you need to set a date box on many forms by using a calendar control. The date box should have the same name on all forms. And setting the date is made simply by:

frmCallingForm("DateBox") = Me("CalendarControlName")

No matter the names and number of calling forms, the date will be always filled in by just one dialog.


HTH

Dan

[pipe]
Daniel Vlas
Systems Consultant

 
Wow, lots of great feedback and good ideas. I think I have a much clearer idea of how this works. I've had this confusion that an openform was like a call to an independent subroutine, yet I know that the code that follows the call executes, cause I manipulate the open form all the time. Great, I get it now.

Now, my MS Press books, and the MSDN don't have much to say on acDialog.
1. Is the only difference from an acNormal open that execution halts in the caller?
2. I assume that I need to create controls to 'control' the open dialog, (e.g.) close
Nothing happens automagically as in a MsgBox, e.g. vbOkCancel ?

danvlas said:
No matter the names and number of calling forms, the date will be always filled in by just one dialog.

Substitute 'select from a combobox' and that's exactly what I'm trying to accomplish

Thanks to all, I'll continue to experiment. Right now, this is the only thing between me and finished. (Except for cosmetics)

...brad
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top