Al Williams said:
Albert,
I am glad I asked the question. Your answers were very helpful. I also
studied your website information. I'd like to ask a few more questions.
Q1. Is there a way to see the Property Sheet when a form is opened in
Dialog? I would like to see what happens to Properties as the form is
opened. I understand from your response that neither PopUp nor Modal are
set
to Yes when the dialog form is opened. It is just that I'm inquisitive
and
would like to observe the property sheet, or have a way to read the
properties.
I don't think so.....(I could be proven wrong!!). However, the form
properties such as model, and popup do NOT CHANGE when you open the form.
You can easily show this by placing a button on this acDialog form. You then
can use the following code behind the button
MsgBox "model set = " & Me.Modal & vbCrLf & _
"popup set = " & Me.PopUp
You will see that the settings in the forms property sheet don't change in
this case...even when you open the form in acDialog mode. So, I don't think
you can show the property sheet, but you can certainly examine the
properties in the sheet by writing code, and display them as above.
Q2. In your response to the requestor, you used apiGetParent and
hWndAccessApp to determine "something" about the dialog form. I did a VBA
help search for hWndAccessApp but didn't get a response. What does
hWndAccessApp tell you about the dialog form?
First, how to find in help:
In access 2003, I whack ctrl-g (to get to the vba side...as the help is
split between user side...and programming side).
I typed in hWndAccessApp in the immediate window..and hit help (f1 key) (it
explains what the above value returns.
What hWndAccessApp returns is what is called in programming circles a
windows handle. (you use those a LOT more in VB, and c++). All windows are
given a "number" by the operating system with witch to work with. So, each
window on the computer is assigned a number by the operating systems.
Now, we have to go back to our original assumption:
The form is going to be opened as regular form, or as a acDialog
form. If we open the form in regular mode, then ms-access will have TWO
possible windows (the main ms-access window, and also a standard window that
is our form that we can click on. However, if we open up the form in
acDialog mode, then it has the focus, and ms-access has only ONE window. So,
that api will return the SAME window value for both our form, and for
ms-access! (that api returns what is the "parent" window --- and they will
be the same in this case).
So that code simply checks if ms-access and the current ms-access form
window have the same handle.
I should note that you also (correctly) pointed out that if you open the
form with model+pop up set, then ms-access again will have JUST one window.
So, that code will ALSO return true for forms that are opened with the
model+popup set. However, as mentioned, we are assuming that the forms will
NOT have these values set. And, if those values are going to be set, then
that api code is of no use, and will not tells what we want to know.
Q3. As I read the Modal Property help more closely, I discovered that it
says that you can build a custom dialog form by setting Modal and PopUp to
Yes and BorderStyle to Dialog. I tried it and the form appears to act
like a
form called by docmd.OpenForm ..., acDialog. Do you know how it differs
from
a form opened by docmd.OpenForm.
They still do NOT act the same!!
The difference is still that the calling code does not halt. And, the term
"custom dialog" is more loosely used above.
. Also, why would one build a custom dialog
form that way rather than using the docmd.OpenForm?
You might want to open the form, but have your code continue running. (well,
then we would NOT use acDialog). So, you might want a form that holds the
focus, but not necessary opened as a acDialog form. And, if you do NOT need
a acDialog from, then I would use the settings, as then I would not foget to
use the acDialog in code! I mean, if you want a dialog like looking form, it
is nice to be able to change the settings, and NOT have to go into code to
change how it looks. So, without question, if you do NOT need a acdialog
form (which halts code), then don't use the acDialog option of the
"openform" command.
The real big question is when, or why would you use acDialog in place of
those 3 settings? Of course, the answer is that acDialog halts code...and
model+popup + "border as dialog" does not!.
A common, and classic example of needing acDialog would be to launch a form
to add a new entry to combo box. We often have a combo box based on a table,
and when I user enters a value in the combo box that is NOT in the list,
then you can use the following code to add that new record.
Private Sub Distributee_NotInList(NewData As String, Response As Integer)
if MsgBox("Do you want to add this value to the list?", _
vbYesNo) then
DoCmd.OpenForm "frmAddClient", , , , acFormAdd, acDialog, NewData
Response = acDataErrAdded
Else
Response = acDataErrContinue
End If
End Sub
So, the above is great example of using acDialog. The user types in a value
into the comb box, the above "not in list" event of the combo fires, and if
the user wants to add that entry to the table that we are using for the
combo box, then we launch a form, and let the user enter that new record.
The above needs to use acDialog, and there are NO form settings in the
property sheet that will allow the above to work. Only when the user CLOSES
that form, does the code after the openform command continues to run.
So, the ONLY kind of forms that halts calling code are acDialog.