Tell if Form is a Dialog

Is there a way to tell if a form was opened as a dialog or not? I'm opening a
form via:

stDocName = "Form1"
DoCmd.OpenForm stDocName, , , stLinkCriteria, , acDialog

In the Unload event handler of Form1 I would like to execute some code but only
if it's a dialog. I tried using the Modal property to determine if it's a
dialog, but it didn't seem to help. How can I tell if Form1 is a dialog?

Alex,

In the Modal Property help, Microsoft says that when Modal and PopUp
properties are set to Yes (which is what Dialog does) that menus and
toolbars, in addition to other windows, are disabled.

HTH

--
Al Williams


"Alex" wrote:

Is there a way to tell if a form was opened as a dialog or not? I'm opening a
form via:

stDocName = "Form1"
DoCmd.OpenForm stDocName, , , stLinkCriteria, , acDialog

In the Unload event handler of Form1 I would like to execute some code but only
if it's a dialog. I tried using the Modal property to determine if it's a
dialog, but it didn't seem to help. How can I tell if Form1 is a dialog?

"Al Williams" wrote in message
news
Alex,

In the Modal Property help, Microsoft says that when Modal and PopUp
properties are set to Yes (which is what Dialog does) that menus and
toolbars, in addition to other windows, are disabled.

The above is quite interesting, but of course, the above is still not the
same thing as a dialog form. They are still VERY different animals.....

Sure, if you open a form in dialog mode, then that form is in effect a model
form, but the behaviors are still very different. So, while a dialog form is
model, a model form is NOT a dialog form.

The poster was asking about a dialog form, and not a model/popup form. So,
if you open a form in dialog mode without the model+popup settings, then you
can't check them.

It might be possible that the poster *can* use a model+popup form in place
of the dialog form, but we don't know that.

One code approach is to put the following code in a public module:

Private Declare Function apiGetParent _
Lib "User32" Alias "GetParent" (ByVal hWnd As Long) As Long


Public Function IsDialog(f As Form) As Boolean


Dim lngParentHWnd As Long

lngParentHWnd = apiGetParent(f.hWnd)

If lngParentHWnd = hWndAccessApp Then
IsDialog = True
Else
IsDialog = False
End If


End Function


You can then in your forms on-load event use:

if isDialog(me) = true then
' this is dialog...

else
' this not dialog
end if


Note that the above works, but if your form is set to a popup form, then
isDialog returns true regardless if you actually opened the form in dialog
mode. So, this code is of no use if the forms popup property is set to
yes (but, this would NOT likely be the case).

As mentioned, you might want to be sure that you actually want a dialog form
in place of a popup, or model form. I explain the difference between model
and dialog he

http://www.members.shaw.ca/AlbertKal...log/Index.html

Another solution is to simply pass some flag, or mode via the open args
function....

I hope the above helps ....
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal

Hi Albert,

I agree that modal and dialog are diferent. My information comes from VBA
help for OpenForm Method which says that when WindowMode for OpenForm is set
to acDialog that the form's Modal and PopUp properties are set to Yes. I
then found in Modal Property help that setting both Modal and PopUp
properties to Yes disables menus and toolbars in addition to other windows.
That description matches what I observed when I was having problems with a
form that opened in Dialog mode. Would you let me know what I misunderstand?
Thanks.

Al

--
Al Williams


"Albert D.Kallal" wrote:

"Al Williams" wrote in message
news
Alex,

In the Modal Property help, Microsoft says that when Modal and PopUp
properties are set to Yes (which is what Dialog does) that menus and
toolbars, in addition to other windows, are disabled.

The above is quite interesting, but of course, the above is still not the
same thing as a dialog form. They are still VERY different animals.....

Sure, if you open a form in dialog mode, then that form is in effect a model
form, but the behaviors are still very different. So, while a dialog form is
model, a model form is NOT a dialog form.

The poster was asking about a dialog form, and not a model/popup form. So,
if you open a form in dialog mode without the model+popup settings, then you
can't check them.

It might be possible that the poster *can* use a model+popup form in place
of the dialog form, but we don't know that.

One code approach is to put the following code in a public module:

Private Declare Function apiGetParent _
Lib "User32" Alias "GetParent" (ByVal hWnd As Long) As Long


Public Function IsDialog(f As Form) As Boolean


Dim lngParentHWnd As Long

lngParentHWnd = apiGetParent(f.hWnd)

If lngParentHWnd = hWndAccessApp Then
IsDialog = True
Else
IsDialog = False
End If


End Function


You can then in your forms on-load event use:

if isDialog(me) = true then
' this is dialog...

else
' this not dialog
end if


Note that the above works, but if your form is set to a popup form, then
isDialog returns true regardless if you actually opened the form in dialog
mode. So, this code is of no use if the forms popup property is set to
yes (but, this would NOT likely be the case).

As mentioned, you might want to be sure that you actually want a dialog form
in place of a popup, or model form. I explain the difference between model
and dialog he

http://www.members.shaw.ca/AlbertKal...log/Index.html

Another solution is to simply pass some flag, or mode via the open args
function....

I hope the above helps ....
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal

I agree that modal and dialog are diferent. My information comes from VBA
help for OpenForm Method which says that when WindowMode for OpenForm is
set
to acDialog that the form's Modal and PopUp properties are set to Yes.

Well, yes, but the above needs further clarification. Do note that a dialog
form STILL has different behaviors (I explain them below). First, a form
does NOT have a acDialog setting in the properties sheet. The ONLY WAY to
open in dialog mode is to use the docmd.Openform like:

docmd.OpenForm "myform",,,,,acDialog.

So, yes, when you use the openform command with acDialog, then the form is
opened in both popup, and model mode, but the forms PROPERTY SHEET is NOT
UPDATED to reflect this information. What this means is that a acDialog form
is model (so the form is opened as model, but the property settings are NOT
CHANGED). However, as mentioned, while MOST of the behaviors are the same,
some are not!!

This also means that checking the property sheet when you open a form as
dialog mode results in no useful information. (and, thus this why the poster
is asking how to do this). How can one tell that a form is opened as dialog
as opposed to model+popup? (you can't actually). However, the user does NOT
want a model+popup...but is using a dialog form.

So, our REAL question (in the context of the original question) is how can
we distinguish when a regular form is opened as acDialgo, and not?

Now, I explain below that the behaviors of the forms are still VERY
different.

I
then found in Modal Property help that setting both Modal and PopUp
properties to Yes disables menus and toolbars in addition to other
windows.
That description matches what I observed when I was having problems with a
form that opened in Dialog mode. Would you let me know what I
misunderstand?

The above is also true, but a dialog form HALTS calling code, and a
model+popup form DOES NOT halt calling code. So, their behaviors is still
MUCH different.

Thus, if you need to display form to a user, grab some information, and
RETURN THAT information to the CALLING CODE, then you need to use a acDialog
form.

So, the msgbox command, the inputbox command, and acDialog forms all halt
code. We thus use these "dialogs" to prompt the user for information, and
then the calling code can use that information after the user ok's the
input. So, we are talking about dialogs here to prompt for information. You
just can't do that with model forms. So, model+popup forms dialog forms!

Regular plain jane forms, model forms, and model+popup forms DO NOT halt
code, and all operate the same from a coding point of view (ie: the code
that opened the form does not halt). In effect, the difference here is one
is a dialog, and other is just a form. We thus need to learn, or understand
the concept of a dialog prompt.

I explain in detail below how to do this. Note clearly that a model+popup
form will NOT WORK in this case. You can read the following example, but the
code snippets will NOT work with just model+popup...as that does NOT halt
the calling code.

So, dialog forms, or things like msgbox command are dialogs, and they HALT
the called code and WAIT until the user gives input. So, if you need code
that waits for user input, and THEN continues, you have to use a acDialog
form, and a model+popup form is no good as it does not halt calling code.

http://www.members.shaw.ca/AlbertKal...log/Index.html

Very simply put, a acDialog form is a dialog form that WAITS for prompting a
user.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal

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.

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?

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… Also, why would one build a custom dialog
form that way rather than using the docmd.OpenForm?

Thanks.

Al

--
Al Williams


"Albert D.Kallal" wrote:

I agree that modal and dialog are diferent. My information comes from VBA
help for OpenForm Method which says that when WindowMode for OpenForm is
set
to acDialog that the form's Modal and PopUp properties are set to Yes.

Well, yes, but the above needs further clarification. Do note that a dialog
form STILL has different behaviors (I explain them below). First, a form
does NOT have a acDialog setting in the properties sheet. The ONLY WAY to
open in dialog mode is to use the docmd.Openform like:

docmd.OpenForm "myform",,,,,acDialog.

So, yes, when you use the openform command with acDialog, then the form is
opened in both popup, and model mode, but the forms PROPERTY SHEET is NOT
UPDATED to reflect this information. What this means is that a acDialog form
is model (so the form is opened as model, but the property settings are NOT
CHANGED). However, as mentioned, while MOST of the behaviors are the same,
some are not!!

This also means that checking the property sheet when you open a form as
dialog mode results in no useful information. (and, thus this why the poster
is asking how to do this). How can one tell that a form is opened as dialog
as opposed to model+popup? (you can't actually). However, the user does NOT
want a model+popup...but is using a dialog form.

So, our REAL question (in the context of the original question) is how can
we distinguish when a regular form is opened as acDialgo, and not?

Now, I explain below that the behaviors of the forms are still VERY
different.

I
then found in Modal Property help that setting both Modal and PopUp
properties to Yes disables menus and toolbars in addition to other
windows.
That description matches what I observed when I was having problems with a
form that opened in Dialog mode. Would you let me know what I
misunderstand?

The above is also true, but a dialog form HALTS calling code, and a
model+popup form DOES NOT halt calling code. So, their behaviors is still
MUCH different.

Thus, if you need to display form to a user, grab some information, and
RETURN THAT information to the CALLING CODE, then you need to use a acDialog
form.

So, the msgbox command, the inputbox command, and acDialog forms all halt
code. We thus use these "dialogs" to prompt the user for information, and
then the calling code can use that information after the user ok's the
input. So, we are talking about dialogs here to prompt for information. You
just can't do that with model forms. So, model+popup forms dialog forms!

Regular plain jane forms, model forms, and model+popup forms DO NOT halt
code, and all operate the same from a coding point of view (ie: the code
that opened the form does not halt). In effect, the difference here is one
is a dialog, and other is just a form. We thus need to learn, or understand
the concept of a dialog prompt.

I explain in detail below how to do this. Note clearly that a model+popup
form will NOT WORK in this case. You can read the following example, but the
code snippets will NOT work with just model+popup...as that does NOT halt
the calling code.

So, dialog forms, or things like msgbox command are dialogs, and they HALT
the called code and WAIT until the user gives input. So, if you need code
that waits for user input, and THEN continues, you have to use a acDialog
form, and a model+popup form is no good as it does not halt calling code.

http://www.members.shaw.ca/AlbertKal...log/Index.html

Very simply put, a acDialog form is a dialog form that WAITS for prompting a
user.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal

"Al Williams" wrote in message
...
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.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal

Hi Albert,

Thank you for your explanation!

I put together a test database with 3 forms because it helps me to actually
try out ideas and see how things work. In this database, Form1 called the
other two forms.

Form2 was called with an OpenForm Dialog and Form3 was called by OpenForm as
a normal form open.

I set Form3 up as a “custom dialog� form with Modal and PopUp set to Yes and
BorderStyle set to Dialog.

Using the function apiGetParent that you provided to the requestor, I
discovered that both the acDialog form and the custom dialog form return
IsDialog = True. I then added a MsgBox message right after the
DoCmd.OpenForm for both Form2 and Form3 and discovered that the code in Form1
doesn’t halt after calling the custom dialog form (Form3) but it does halt
when Form2 ( the form called with an acDialog) is called, which is just what
you said happens.

I also added MsgBox statements and verified that the properties of a form
opened using acDialog aren’t modified to have Modal and/or PopUp set to Yes
(and they continue to be set to Yes for the custom dialog form).

Doing the above helped me to understand what is happening, what to do, and
it certainly ought to make it easier for me to remember it. Thank you very
much for your explanations.

Al


--
Al Williams


"Albert D.Kallal" wrote:

"Al Williams" wrote in message
...
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.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal