If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
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? |
#2
|
|||
|
|||
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? |
#3
|
|||
|
|||
"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 |
#4
|
|||
|
|||
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 |
#5
|
|||
|
|||
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 |
#6
|
|||
|
|||
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 |
#7
|
|||
|
|||
"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 |
#8
|
|||
|
|||
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 |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Need Help In Printing Current Record in Specific Report | RNUSZ@OKDPS | Setting Up & Running Reports | 1 | May 16th, 2005 09:06 PM |
Design help, please | SillySally | Using Forms | 27 | March 6th, 2005 04:11 AM |
Opening Form Based on Switchboard | S Jackson | Using Forms | 7 | December 15th, 2004 10:43 PM |
open a form through a subform in access 2000 | Tammy | Setting Up & Running Reports | 12 | October 22nd, 2004 02:43 PM |
dlookup | miaplacidus | Using Forms | 9 | August 5th, 2004 09:16 PM |