If I open a form using

DoCmd.OpenForm "frmShowInformationDetail", , , , acFormAdd, acDialog, NewData

is there a way to detect that acDialog was used for the WindowMode
parameter. Basically, I would like the form to detect if it was opened as
acDialog and if so disable one or more controls. Given that acDialog suspends
code from executing until the form is closed, I can't manipulate the form
from the form that opened it.

I'd like a more graceful way than using DoCmd to open the form as a hidden
form, changing the controls and then executing DoCmd again to display it as a
Dialog.

"dch3" <(E-Mail Removed)> wrote in message
news:530261B5-8439-4F98-A48A-(E-Mail Removed)...
> If I open a form using
>
> DoCmd.OpenForm "frmShowInformationDetail", , , , acFormAdd, acDialog,
> NewData
>
> is there a way to detect that acDialog was used for the WindowMode
> parameter. Basically, I would like the form to detect if it was opened as
> acDialog and if so disable one or more controls. Given that acDialog
> suspends
> code from executing until the form is closed, I can't manipulate the form
> from the form that opened it.
>
> I'd like a more graceful way than using DoCmd to open the form as a hidden
> form, changing the controls and then executing DoCmd again to display it
> as a
> Dialog.


I could be wrong, but it seems to me I looked into this and couldn't find a
way to do it -- maybe it could be done with some Windows API code, but I
don't recall if I explored that possibility or not. But since you're using
code to open the form in dialog mode, how about just passing an argument via
OpenArgs that would tell the form what mode it's in?

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

I'm already passing in some .OpenArgs used for setting values in the controls
- some of the forms are used with .NotInList events. Given that I'm trying to
be consistent in how my data collection forms operate, I was hoping to avoid
having to go back and modify the DoCmd that open the forms and the various
Loads.

I might go with disabling/hiding the controls by default and then enabling
them with statements immediately following the DoCmd.

I take it that this won't work...
DoCmd.OpenForm "frmLoadListDetail",,,,,acHidden
[INSERT CODE HERE
DoCmd.OpenForm "frmLoadListDetail",,,,,acDialog

Damn shame you can't declare you'r own properties for a form.

Yeah, I know I could try it but I'm a lazy son of a

"Dirk Goldgar" wrote:

> "dch3" <(E-Mail Removed)> wrote in message
> news:530261B5-8439-4F98-A48A-(E-Mail Removed)...
> > If I open a form using
> >
> > DoCmd.OpenForm "frmShowInformationDetail", , , , acFormAdd, acDialog,
> > NewData
> >
> > is there a way to detect that acDialog was used for the WindowMode
> > parameter. Basically, I would like the form to detect if it was opened as
> > acDialog and if so disable one or more controls. Given that acDialog
> > suspends
> > code from executing until the form is closed, I can't manipulate the form
> > from the form that opened it.
> >
> > I'd like a more graceful way than using DoCmd to open the form as a hidden
> > form, changing the controls and then executing DoCmd again to display it
> > as a
> > Dialog.
>
>
> I could be wrong, but it seems to me I looked into this and couldn't find a
> way to do it -- maybe it could be done with some Windows API code, but I
> don't recall if I explored that possibility or not. But since you're using
> code to open the form in dialog mode, how about just passing an argument via
> OpenArgs that would tell the form what mode it's in?
>
> --
> Dirk Goldgar, MS Access MVP
> www.datagnostics.com
>
> (please reply to the newsgroup)
>

"dch3" <(E-Mail Removed)> wrote in message
news:A9227DAB-D5D6-412C-8BC6-(E-Mail Removed)...
> I'm already passing in some .OpenArgs used for setting values in the
> controls
> - some of the forms are used with .NotInList events. Given that I'm trying
> to
> be consistent in how my data collection forms operate, I was hoping to
> avoid
> having to go back and modify the DoCmd that open the forms and the various
> Loads.

I sympathize.

Hmm. By looking at the window classes of the form and of its parent window,
I can tell whether the form is popup or not. If it's opened in dialog mode,
it's also popup, so if I don't have to distinguish between dialog mode and
plain old popup, this can work:

'----- code for form -----
Private Declare Function apiGetParent Lib "user32" _
Alias "GetParent" (ByVal hwnd As Long) As Long
'Returns the handle of the parent window of the specified window.

Private Sub Form_Load()

Dim hWndParent As Long

Debug.Print "Me", Me.hwnd, fGetClassName(Me.hwnd)

hWndParent = apiGetParent(Me.hwnd)
Debug.Print "Parent", hWndParent, fGetClassName(hWndParent)

Debug.Print "Access", Application.hWndAccessApp, _
GetClassName(Application.hWndAccessApp)

' Note: fGetClassName comes from a module posted on the Access Web,
' but it looks like you don't really need it, so I won't post the link
now.

End Sub

'----- end code -----

In Immediate window:

DoCmd.OpenForm "frmDialog"
Me 5048118 OForm
Parent 60031730 MDIClient
Access 68158248 OMain

(close form between calls)

Docmd.OpenForm "frmDialog", WindowMode:=acDialog
Me 5310262 OFormPopup
Parent 68158248 OMain
Access 68158248 OMain

So it looks like, if the parent Hwnd is the same as hWndAccessApp, the form
is popup or dialog. I haven't tested this exhaustively, but it's a step in
the right direction.


--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

To solve an unrelated need, I ended up creating SUBs which encapsulate the
DoCmd.OpenForm (or .OpenReport) statements. Instead of directly opening the
form/report, they are now opened using openFrmManifest, openRptLoadList, etc.
So basically, I can use the same technique to work around this.

"Dirk Goldgar" wrote:

> "dch3" <(E-Mail Removed)> wrote in message
> news:A9227DAB-D5D6-412C-8BC6-(E-Mail Removed)...
> > I'm already passing in some .OpenArgs used for setting values in the
> > controls
> > - some of the forms are used with .NotInList events. Given that I'm trying
> > to
> > be consistent in how my data collection forms operate, I was hoping to
> > avoid
> > having to go back and modify the DoCmd that open the forms and the various
> > Loads.
>
> I sympathize.
>
> Hmm. By looking at the window classes of the form and of its parent window,
> I can tell whether the form is popup or not. If it's opened in dialog mode,
> it's also popup, so if I don't have to distinguish between dialog mode and
> plain old popup, this can work:
>
> '----- code for form -----
> Private Declare Function apiGetParent Lib "user32" _
> Alias "GetParent" (ByVal hwnd As Long) As Long
> 'Returns the handle of the parent window of the specified window.
>
> Private Sub Form_Load()
>
> Dim hWndParent As Long
>
> Debug.Print "Me", Me.hwnd, fGetClassName(Me.hwnd)
>
> hWndParent = apiGetParent(Me.hwnd)
> Debug.Print "Parent", hWndParent, fGetClassName(hWndParent)
>
> Debug.Print "Access", Application.hWndAccessApp, _
> GetClassName(Application.hWndAccessApp)
>
> ' Note: fGetClassName comes from a module posted on the Access Web,
> ' but it looks like you don't really need it, so I won't post the link
> now.
>
> End Sub
>
> '----- end code -----
>
> In Immediate window:
>
> DoCmd.OpenForm "frmDialog"
> Me 5048118 OForm
> Parent 60031730 MDIClient
> Access 68158248 OMain
>
> (close form between calls)
>
> Docmd.OpenForm "frmDialog", WindowMode:=acDialog
> Me 5310262 OFormPopup
> Parent 68158248 OMain
> Access 68158248 OMain
>
> So it looks like, if the parent Hwnd is the same as hWndAccessApp, the form
> is popup or dialog. I haven't tested this exhaustively, but it's a step in
> the right direction.
>
>
> --
> Dirk Goldgar, MS Access MVP
> www.datagnostics.com
>
> (please reply to the newsgroup)
>

"dch3" <(E-Mail Removed)> wrote in message
news:0844D048-37D0-41D9-BD44-(E-Mail Removed)...
> To solve an unrelated need, I ended up creating SUBs which encapsulate the
> DoCmd.OpenForm (or .OpenReport) statements. Instead of directly opening
> the
> form/report, they are now opened using openFrmManifest, openRptLoadList,
> etc.
> So basically, I can use the same technique to work around this.


What? A *practical* workaround? Is that permitted?

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

Wouldn't say its practical - more like "a very eloquently, intelligently
designed" solution. Its actually one of techniques that I'm particularly
proud of. Nice to know that I still remember something from the 'Intro to
Java' CLASS that I took nearly a decade ago.

"Dirk Goldgar" wrote:

> "dch3" <(E-Mail Removed)> wrote in message
> news:0844D048-37D0-41D9-BD44-(E-Mail Removed)...
> > To solve an unrelated need, I ended up creating SUBs which encapsulate the
> > DoCmd.OpenForm (or .OpenReport) statements. Instead of directly opening
> > the
> > form/report, they are now opened using openFrmManifest, openRptLoadList,
> > etc.
> > So basically, I can use the same technique to work around this.
>
>
> What? A *practical* workaround? Is that permitted?
>
> --
> Dirk Goldgar, MS Access MVP
> www.datagnostics.com
>
> (please reply to the newsgroup)
>
>