How to cycle thru ALL forms?

[MLH]

Am having trouble with the following
snippet. It stops after only cycling thru
open forms. There are many more than
that. How to modify this to cycle thru
all forms?

Sub AllOpenForms()
Dim frm As Form
' Enumerate Forms collection.
For Each frm In Forms
' Print name of form.
Debug.Print frm.Name, frm.MenuBar
Next frm
End Sub

[kaniest]

MLH wrote:

Am having trouble with the following
snippet. It stops after only cycling thru
open forms. There are many more than
that. How to modify this to cycle thru
all forms?

Sub AllOpenForms()
Dim frm As Form
' Enumerate Forms collection.
For Each frm In Forms
' Print name of form.
Debug.Print frm.Name, frm.MenuBar
Next frm
End Sub

Use the Documents collection.

[MLH]

I tried the following approach FIRST. But it does
not understand the MenuBar, complaining that
the Method or data member not found. So that's
why I tried the other approach.

Private Sub Command0_Click()
Dim DefaultWorkspace As Workspace
Dim CurrentDatabase As Database
Dim MyContainer As Container, MyDocument As Document, HowManyForms
As Integer
Dim i As Integer
Set DefaultWorkspace = DBEngine.Workspaces(0)
Set CurrentDatabase = DefaultWorkspace.Databases(0)
Set MyContainer = CurrentDatabase.Containers(1)
HowManyForms = MyContainer.Documents.Count
For i = 0 To MyContainer.Documents.Count - 1
Set MyDocument = MyContainer.Documents(i)
Debug.Print MyDocument.Name, MyDocument.MenuBar
Next i
End Sub

[Rich P]

Greetings, try this:

Sub checkAllForms()
Dim aob As AccessObject
Dim boolResult As Boolean

For Each aob In CurrentProject.AllForms
Debug.Print aob.Name
Next aob
End Sub

this code will list all the forms in your application open or closed

Rich

*** Sent via Developersdex http://www.developersdex.com ***

[fredg]

On Mon, 09 Oct 2006 12:08:56 -0400, MLH wrote:

Am having trouble with the following
snippet. It stops after only cycling thru
open forms. There are many more than
that. How to modify this to cycle thru
all forms?

Sub AllOpenForms()
Dim frm As Form
' Enumerate Forms collection.
For Each frm In Forms
' Print name of form.
Debug.Print frm.Name, frm.MenuBar
Next frm
End Sub

Public Sub ShowAllForms()
Dim db As DAO.Database
Dim cnt As Container
Dim doc As Document
Set db = CurrentDb

For Each cnt In db.Containers
If cnt.Name = "Forms" Then
For Each doc In cnt.Documents
Debug.Print doc.Name
Next doc
End If
Next cnt
End Sub

Change If cnt.Name = "Forms" Then to
If cnt.Name = "Reports" Then
of
If cnt.Name = "Tables" Then
etc. to show the other container objects.
--
Fred
Please respond only to this newsgroup.
I do not reply to personal e-mail

[MLH]

On 09 Oct 2006 16:26:55 GMT, Rich P <rp*****@aol.comwrote:

>Sub checkAllForms()
Dim aob As AccessObject
Dim boolResult As Boolean

For Each aob In CurrentProject.AllForms
Debug.Print aob.Name
Next aob
End Sub

Hmm??? Trying to convert it to something
A97 understands. Not having much luck.
I modified 2 lines above...
Dim aob As Object
For Each aob In CurrentDB.AllForms
But am still getting compile-time errors.

[MLH]

On Mon, 9 Oct 2006 09:32:03 -0700, fredg <fg******@example.invalid>
wrote:

>

Public Sub ShowAllForms()
Dim db As DAO.Database
Dim cnt As Container
Dim doc As Document
Set db = CurrentDb

For Each cnt In db.Containers
If cnt.Name = "Forms" Then
For Each doc In cnt.Documents
Debug.Print doc.Name
Next doc
End If
Next cnt
End Sub

Change If cnt.Name = "Forms" Then to
If cnt.Name = "Reports" Then
of
If cnt.Name = "Tables" Then
etc. to show the other container objects.

Thanks. Seems close, but this does not work either...
Public Sub ShowAllForms()
Dim db As DAO.Database
Dim cnt As Container
Dim doc As Document
Set db = CurrentDb

For Each cnt In db.Containers
If cnt.Name = "Forms" Then
For Each doc In cnt.Documents
Debug.Print doc.Name, doc.MenuBar
Next doc
End If
Next cnt
End Sub

Just can't seem to get it to read the MenuBar property.

[Tim Marshall]

MLH wrote:

I tried the following approach FIRST. But it does
not understand the MenuBar, complaining that

The other responses are probably fine, but the approach I've taken,
which seems to work when I've had need to do what you're doing (in my
case, I wanted to count all lines of code in my apps), is to use the
MSysObjects table.

For forms:

Select MSysObjects!Name as ModName from MSysObjects where
MSysObjects!Type = -32768

For reports:

Select MSysObjects!Name as ModName from MSysObjects where
MSysObjects!Type = -32764


--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[salad]

fredg wrote:

On Mon, 09 Oct 2006 12:08:56 -0400, MLH wrote:

>>Am having trouble with the following
snippet. It stops after only cycling thru
open forms. There are many more than
that. How to modify this to cycle thru
all forms?

Sub AllOpenForms()
Dim frm As Form
' Enumerate Forms collection.
For Each frm In Forms
' Print name of form.
Debug.Print frm.Name, frm.MenuBar
Next frm
End Sub

Public Sub ShowAllForms()
Dim db As DAO.Database
Dim cnt As Container
Dim doc As Document
Set db = CurrentDb

For Each cnt In db.Containers
If cnt.Name = "Forms" Then
For Each doc In cnt.Documents
Debug.Print doc.Name
Next doc
End If
Next cnt
End Sub

Change If cnt.Name = "Forms" Then to
If cnt.Name = "Reports" Then
of
If cnt.Name = "Tables" Then
etc. to show the other container objects.

In order to display the menubar/toolbar I think the form needs to be
opened in design mode, hidden, to get that info.
Public Sub ShowAllFormsMenus()
Dim db As DAO.Database
Dim doc As Document
Set db = CurrentDb
Dim frm As Form

With db.Containers!Forms
For Each doc In .Documents
DoCmd.OpenForm doc.name, acDesign, , , , acHidden
Set frm = Forms(doc.name)
Debug.Print doc.name; Tab; "Menubar " & frm.MenuBar; Tab;
"Toolbar " & frm.Toolbar
DoCmd.Close acForm, doc.name
Set frm = Nothing
Next
End With
db.Close
Set db = Nothing
End Sub

[kaniest]

MLH wrote:

Thanks. Seems close, but this does not work either...
Public Sub ShowAllForms()
Dim db As DAO.Database
Dim cnt As Container
Dim doc As Document
Set db = CurrentDb

For Each cnt In db.Containers
If cnt.Name = "Forms" Then
For Each doc In cnt.Documents
Debug.Print doc.Name, doc.MenuBar
Next doc
End If
Next cnt
End Sub

Just can't seem to get it to read the MenuBar property.

Because there is none. A document in the container
Container!Forms is _not_ a Form object.
Surprised? Check the help file and the object model.
AllForms was introduced after A97 to solve the
inconvenience you encountered.

[Larry Linson]

"MLH" <CR**@NorthState.netwrote

Hmm??? Trying to convert it to something
A97 understands. Not having much luck.
I modified 2 lines above...
Dim aob As Object
For Each aob In CurrentDB.AllForms
But am still getting compile-time errors.

Use your original approach, but omit the MenuBar (doesn't exist for a
document).

The name does exist, so use the name in a DoCmd.OpenForm to open the Form in
Design View, at which time there will be a valid Form available. Do
whatever it is you need to do with the Form open, then close it and move on
to the next one.

Don't get all carried away with trying to define it as Object. My
recollection is that AllForms was not included in Access 97, in any case.

Just a comment: when Access has told me that "property or method does not
exist," Access has always been correct -- either I have misspelled it, or I
am using it in a situation where it does not exist. I've done that enough
times that now I believe Access when it gives me that error message.

Larry Linson
Microsoft Access MVP

[David W. Fenton]

MLH <CR**@NorthState.netwrote in
news:nl********************************@4ax.com:

Am having trouble with the following
snippet. It stops after only cycling thru
open forms. There are many more than
that. How to modify this to cycle thru
all forms?

Sub AllOpenForms()
Dim frm As Form
' Enumerate Forms collection.
For Each frm In Forms
' Print name of form.
Debug.Print frm.Name, frm.MenuBar
Next frm
End Sub

No one has given you the answer to this question, because you didn't
specify your version of Access.

A2K has the AllForms collection, which includes, well, all the
forms, open or closed.

A97 lacked that collection, so you had to use the Documents
collection.

What you want to look at is this collection:

CurrentDB.Containers!Forms.Documents

You can use it like this:

Dim doc As Document

For Each doc in CurrentDB.Containers!Forms.Documents
DoCmd.OpenForm doc.Name
Next
Set doc = Nothing

Certain properties don't exist until it's open and you have a choic
of views for opening it. If you want to change and save properties,
you'll need to open in design view.

Free clue: you'll get more useful answers if you'll clearly specify
that you're using A97 -- you're way behind the curve and people
shouldn't be expected, 9 years after the release of A2K, to post
code that works for both pre-A2K and for A2K and later.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[MLH]

<snip>

>Use your original approach, but omit the MenuBar (doesn't exist for a
document).

The name does exist, so use the name in a DoCmd.OpenForm to open the Form in
Design View, at which time there will be a valid Form available. Do
whatever it is you need to do with the Form open, then close it and move on
to the next one.

Don't get all carried away with trying to define it as Object. My
recollection is that AllForms was not included in Access 97, in any case.

Just a comment: when Access has told me that "property or method does not
exist," Access has always been correct -- either I have misspelled it, or I
am using it in a situation where it does not exist. I've done that enough
times that now I believe Access when it gives me that error message.

Larry Linson
Microsoft Access MVP

Perfect idea. Thx, Larry.

[MLH]

<snip>

>In order to display the menubar/toolbar I think the form needs to be
opened in design mode, hidden, to get that info.
Public Sub ShowAllFormsMenus()
Dim db As DAO.Database
Dim doc As Document
Set db = CurrentDb
Dim frm As Form

With db.Containers!Forms
For Each doc In .Documents
DoCmd.OpenForm doc.name, acDesign, , , , acHidden
Set frm = Forms(doc.name)
Debug.Print doc.name; Tab; "Menubar " & frm.MenuBar; Tab;
"Toolbar " & frm.Toolbar
DoCmd.Close acForm, doc.name
Set frm = Nothing
Next
End With
db.Close
Set db = Nothing
End Sub

Yep. That worked perfectly. Its what Larry Linson said a few
lines up. I was overlooking the important fact that these forms
needed to be opened in order to make useful reference to or
read their MenuBar property setting. Thanks for the snippet.
Worked perfect right out-a-the-box.

[MLH]

I appreciate you not charging me for the "free clue"

How many people would answer a post, I wonder,
sharing with the NG whether A97 is something they
use almost daily? I have no idea. I would be curious
to know. Maybe a hundred people will reply and we'll
all know. Maybe someone will analyze the last 5-yrs
posts to determine how many are A97 specific, how
many are specific to an advanced release and how
many are non-specific.

[Larry Linson]

"MLH" <CR**@NorthState.netwrote in message
news:r1********************************@4ax.com...

>I appreciate you not charging me for the "free clue"

How many people would answer a post, I wonder,
sharing with the NG whether A97 is something they
use almost daily? I have no idea. I would be curious
to know. Maybe a hundred people will reply and we'll
all know. Maybe someone will analyze the last 5-yrs
posts to determine how many are A97 specific, how
many are specific to an advanced release and how
many are non-specific.

I pretty much assume that most of us "Access 97 Bigots" who didn't like the
idea of leaping feet-first into Access 2000 SP nothing, have, by now, come
to terms. In fact, due to an installation glitch, I don't even have a
working copy of Access 97 on my production machine, and no clients still
using it, so no compelling need (other than nostalgia) to rush to correct
the problem. As of now, I use either Access 2002 or 2003... even though
they are the same file format, it's really a good idea to test with the
exact version that the users will have.

I could, I suppose, install Access 2000 with all the SPs, because that's
reasonably stabilized, but don't have any clients who are still using it,
either. Even that is "out of support."

Actually, one of the suggestions in the FAQ is that you mention the Access
version you are using when posting.
http://www.mvps.org/access/netiquette.htm. And, if it will get you the
correct answer, why not? There's certainly no "brand of shame" associated
with that version. Few do that, however.

Larry Linson
Microsoft Access MVP

[Bri]

MLH wrote:

I appreciate you not charging me for the "free clue"

How many people would answer a post, I wonder,
sharing with the NG whether A97 is something they
use almost daily? I have no idea. I would be curious
to know. Maybe a hundred people will reply and we'll
all know. Maybe someone will analyze the last 5-yrs
posts to determine how many are A97 specific, how
many are specific to an advanced release and how
many are non-specific.

I use AC97 for development 99% of the time and then convert up to the
clients version on installation. I never assume that the people here
will know that and always mention that I am using AC97 when I post a
question. It takes hardly any time to include that info (or any other
info that might be needed to clarify the problem).

--
Bri

[Bri]

Larry Linson wrote:

I pretty much assume that most of us "Access 97 Bigots" who didn't like the
idea of leaping feet-first into Access 2000 SP nothing, have, by now, come
to terms.

The help system alone is good enough reason for keeping AC97 around. I
am continually frustrated with the help systems of all of the post AC97
versions. IMNSHO, AC97 is still the sweet spot from the developers POV.

--
Bri

[David W. Fenton]

MLH <CR**@NorthState.netwrote in
news:r1********************************@4ax.com:

I appreciate you not charging me for the "free clue"

How many people would answer a post, I wonder,
sharing with the NG whether A97 is something they
use almost daily? I have no idea. I would be curious
to know. Maybe a hundred people will reply and we'll
all know. Maybe someone will analyze the last 5-yrs
posts to determine how many are A97 specific, how
many are specific to an advanced release and how
many are non-specific.

I use A97 almost daily, as with A2K.

I don't use any of the later versions of Access, even though I have
Access 2K2 installed.

But if I were posting about a problem I was having in A97, I'd say
that my problem was in A97, since I know that most people in the
newsgroup are likely using A2K2 or A2K3.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

Bri <no*@here.comwrote in news:3pQWg.119291$1T2.13017@pd7urf2no:

I use AC97 for development 99% of the time and then convert up to
the clients version on installation.

I used to do that, but there were too many things that work just
fine in A97 that break in A2K, so I now do all of my development for
A2K clients in A2K itself.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Bri]

David W. Fenton wrote:

Bri <no*@here.comwrote in news:3pQWg.119291$1T2.13017@pd7urf2no:

>>I use AC97 for development 99% of the time and then convert up to
the clients version on installation.

I used to do that, but there were too many things that work just
fine in A97 that break in A2K, so I now do all of my development for
A2K clients in A2K itself.

What kind of things do you find breaking? I haven't had any real
problems. I recall there were a few things that didn't work in AC2K that
an alternate method worked fine in both. I don't recall specifics as
I'm now in the habit of using the method that works in both versions. I
do have one app with conditional formatting that I have to add back in
to the form after I convert it, but I only need to worry about that one
rarely. If there are some gotcha's waiting down the road it might help
to know about them ahead of time.

--
Bri

[David W. Fenton]

Bri <no*@here.comwrote in news:SFWWg.124968$R63.11256@pd7urf1no:

>
David W. Fenton wrote:

>Bri <no*@here.comwrote in
news:3pQWg.119291$1T2.13017@pd7urf2no:

>>>I use AC97 for development 99% of the time and then convert up to
the clients version on installation.

I used to do that, but there were too many things that work just
fine in A97 that break in A2K, so I now do all of my development
for A2K clients in A2K itself.

What kind of things do you find breaking?

The "subform referring to a field in parent form's recordsource"
problem was the last straw for me. I wasted days troubleshooting it.
That was after encountering a handful of other peculiarities which I
don't recall.

I haven't had any real
problems. I recall there were a few things that didn't work in
AC2K that
an alternate method worked fine in both.

There are almost always alternate approaches, but if you're the
first one to encounter and document the problem, it may be hard to
figure out what the alternative is.

I just wasted too much time on that kind of thing, and simply
stopped doing the development in A97 except if it was going to be
deployed in A97.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/