Selecting window mode for a form

[kMan]

Hello guys,

I am opening multiple instance of a form by the following approach:

dim frm1, frm2 as Form
set frm1 = new Form_frmCustomerSelection

<here I would select a customer in the newly opened form>

dim custID as Integer

custID = frm1.Controls("controlname") <-- To assign the selected ID from
the hidden form, frm1

problem, though, is that Access runs through the code, without waiting for
frm1 to be hidden.

previously I used this approach.

docmd.openform "frmCustomerSelection" windowmode:= acDialog

this would pause the code until frm1 was hidden.... how could pass window
mode with this set frm1 = ... method... or is there another way to do this

 

[Albert D. Kallal]

Well, my first answer would be say don't use multiple instances.

However, I had to solve the same problem.

The solution is quite simple, but does require you to modify your
approaches.

old concept:

call open form acDialog. code waits
form goes visible = false

we can now examine values from that form

close the form

In the new approach:

create new instance of form
make form visible
set a reference in the new form to this form

have the new instance form call sub rouitne when done (ie: when
closing) ****

*** this last part is different. essentially you have to adopt a coding
practice for all forms that return values.

Here is a actual code snip that does the above:

Public Function GetNewName()

' user booked....get a name

Set frmSearch = New Form_frmContactsSearch
frmSearch.Visible = True
frmSearch.bolSelectOnly = True
frmSearch.Caption = "Select contact to book to"
Set frmSearch.frmPrevious = Me
frmSearch.cmdAdd.SetFocus

' return code continues on below seldone
End Function

Public Function SelDone()

' return code if user selects a name in form search
' if we return here from form search..then a selection was made

Dim bolOk As Boolean
Dim strSql As String

Dim lngContactID As Long

lngContactID = Nz(frmSearch!ContactID, 0)

etc....etc .etc...

the code you are looking at above is in the first forms code module..and
calls that search form (which is a instance of the form, sinc eI can have
many search forms open).

So, what this means is that:

* you code is not linear in execution anymore. It is bit harder to
think, and build your code this way
* the advantage is that you can not have many instances open, and
still have high-re-use of the form.

You can still have other forms also call and use this form...just adopt a
programming standard that "seldone" is the routine that continues AFTER the
form. If seldone is not called by the form instance..then the user
cancelled.

The closing/calling code in the form instance (which is our "ok" button on
this form) is:

frmPrevious.SelDone
DoCmd.Close acForm, Me.Name

So, you have to change from the old way of:

getsome value = dialog prompt form -- wait for user, code halts

to:

launch form, then "return" to a public function routine to CONTINUE
running the code....

the added bonus of this approach is that you can see that AFTER I open the
instance of that form, the code continues..and I setup a few additional
things. I use to be a big fan of acdialog forms, and that trick of visiable
= faluse to contue the callkng code was great. However ther eis MANY
interface shortcomings, such as no menus working, no focus change can occur
etc. With the above approcach, you don't get frozen interface, can use
custom menu bars...etc....

 

[Albert D. Kallal]

* the advantage is that you can not have many instances open, and
still have high-re-use of the form.


should read:

* the advantage is that you can now have many instances open, and
still have high-re-use of the form.