Forms collection - add event?

[Jerry Boone]

I'm looking for a way to fire a public sub/function when a form is opened
and closed - without using form level events.

I have already done some extensive form work with instancing, looping
through the forms collection, bringing forms to the front with API via hWnd,
et.. and so on.

The problem is that users are loosing windows behind others and I thought I
would put a list together on an existing left handed menu of (i.e.) "My open
forms".

I have this already working now, but I am using Form_Current and Form_Close
events at the form level to do it. This is very tedious (I have 204 forms
currently in the db) and the thought of remembering to put these events on
new forms going forward kind of gives me cold-sweat nightmares... (dam, did
I remember to put that code in?).

Does anyone know of a way to tap the forms collection using withevents?

Another helpful hint regarding accessing the Window menu contents could be
helpful, but prefer the other way if possible.

Thanks

--
Jerry Boone

[Anthony England]

"Jerry Boone" <je***@gomaps.com.nospam> wrote in message
news:44**********************@news.hubris.net...

I'm looking for a way to fire a public sub/function when a form is opened
and closed - without using form level events.

I have already done some extensive form work with instancing, looping
through the forms collection, bringing forms to the front with API via
hWnd,
et.. and so on.

The problem is that users are loosing windows behind others and I thought
I
would put a list together on an existing left handed menu of (i.e.) "My
open
forms".

I have this already working now, but I am using Form_Current and
Form_Close
events at the form level to do it. This is very tedious (I have 204 forms
currently in the db) and the thought of remembering to put these events on
new forms going forward kind of gives me cold-sweat nightmares... (dam,
did
I remember to put that code in?).

Does anyone know of a way to tap the forms collection using withevents?

Another helpful hint regarding accessing the Window menu contents could be
helpful, but prefer the other way if possible.

Thanks

--
Jerry Boone

If your users can't cope with the standard Access MDI, then you could
restrict what they do. Opening forms using acDialog, or perhaps not
allowing forms to be maximised/minimized/re-sized. By designing it for
idiots you can ensure that idiots don't screw it up.
I can imagine that you are having nightmares with this - it doesn't sound
much fun to implement. The easiest and most practical thing I can suggest
is simply to refresh the MyForms list either by some event like when the
form that displays the list gets the focus, or a refresh button, or even a
timer event. Or perhaps you could have some menu item called ShowMeMyForms
which opened a modal form showing a refreshed list. They could go to a form
by double-clicking it on the list.
I can't think of any way you might raise an event. The nearest solution I
could come up with in the 2 minutes I spent reflecting was to refrain from
using the DoCmd.OpenForm but write a simple wrapper function which did two
things: open the form and run some code. It would work and you could search
project wide for any rogue appearances of DoCmd.OpenForm, but I still
wouldn't recommend it.

[Anthony England]

"Jerry Boone" <je***@gomaps.com.nospam> wrote in message
news:44**********************@news.hubris.net...

I'm looking for a way to fire a public sub/function when a form is opened
and closed - without using form level events.

I have already done some extensive form work with instancing, looping
through the forms collection, bringing forms to the front with API via
hWnd,
et.. and so on.

The problem is that users are loosing windows behind others and I thought
I
would put a list together on an existing left handed menu of (i.e.) "My
open
forms".

I have this already working now, but I am using Form_Current and
Form_Close
events at the form level to do it. This is very tedious (I have 204 forms
currently in the db) and the thought of remembering to put these events on
new forms going forward kind of gives me cold-sweat nightmares... (dam,
did
I remember to put that code in?).

Does anyone know of a way to tap the forms collection using withevents?

Another helpful hint regarding accessing the Window menu contents could be
helpful, but prefer the other way if possible.

Thanks

--
Jerry Boone

If your users can't cope with the standard Access MDI, then you could
restrict what they do. Opening forms using acDialog, or perhaps not
allowing forms to be maximised/minimized/re-sized. By designing it for
idiots you can ensure that idiots don't screw it up.
I can imagine that you are having nightmares with this - it doesn't sound
much fun to implement. The easiest and most practical thing I can suggest
is simply to refresh the MyForms list either by some event like when the
form that displays the list gets the focus, or a refresh button, or even a
timer event. Or perhaps you could have some menu item called ShowMeMyForms
which opened a modal form showing a refreshed list. They could go to a form
by double-clicking it on the list.
I can't think of any way you might raise an event. The nearest solution I
could come up with in the 2 minutes I spent reflecting was to refrain from
using the DoCmd.OpenForm but write a simple wrapper function which did two
things: open the form and run some code. It would work and you could search
project wide for any rogue appearances of DoCmd.OpenForm, but I still
wouldn't recommend it.

[rkc]

Jerry Boone wrote:

I'm looking for a way to fire a public sub/function when a form is opened
and closed - without using form level events.

I have already done some extensive form work with instancing, looping
through the forms collection, bringing forms to the front with API via hWnd,
et.. and so on.

The problem is that users are loosing windows behind others and I thought I
would put a list together on an existing left handed menu of (i.e.) "My open
forms".

I have this already working now, but I am using Form_Current and Form_Close
events at the form level to do it. This is very tedious (I have 204 forms
currently in the db) and the thought of remembering to put these events on
new forms going forward kind of gives me cold-sweat nightmares... (dam, did
I remember to put that code in?).

Does anyone know of a way to tap the forms collection using withevents?

Another helpful hint regarding accessing the Window menu contents could be
helpful, but prefer the other way if possible.

The Forms class doesn't have any events to monitor.

There may be some genius that will come up with something, but I think
I would spend an hour or two writing a code generator while I waited
for that to happen.

[Jerry Boone]

Ok - thanks guys.

I just went ahead and coded all the forms. It's a pain but the overall
result is professional and consistent. A lot of the forms operate as
instances and a form handler (that's too complex to change right now)
already exists. If you want, here is a screen shot of the end result (look
toward the bottom of the menu and compare form captions)
http://www.gomaps.com/screenshot1.jpg Double clicking on one of those items
brings the corresponding form to the front. I kind of like it, comments?
I was hoping someone would say something like "instantiate a class object
with form collection ability and wire up a gadget sub that fires on widget's
withevents". Of course... it could be that I just reached pure insanity and
should go back to painting cars or something.

--
Jerry Boone

"Jerry Boone" <je***@gomaps.com.nospam> wrote in message
news:44**********************@news.hubris.net...

I'm looking for a way to fire a public sub/function when a form is opened
and closed - without using form level events.

I have already done some extensive form work with instancing, looping
through the forms collection, bringing forms to the front with API via hWnd, et.. and so on.

The problem is that users are loosing windows behind others and I thought I would put a list together on an existing left handed menu of (i.e.) "My open forms".

I have this already working now, but I am using Form_Current and Form_Close events at the form level to do it. This is very tedious (I have 204 forms
currently in the db) and the thought of remembering to put these events on
new forms going forward kind of gives me cold-sweat nightmares... (dam, did I remember to put that code in?).

Does anyone know of a way to tap the forms collection using withevents?

Another helpful hint regarding accessing the Window menu contents could be
helpful, but prefer the other way if possible.

Thanks

--
Jerry Boone

[rkc]

Jerry Boone wrote:

If you want, here is a screen shot of the end result (look
toward the bottom of the menu and compare form captions)
http://www.gomaps.com/screenshot1.jpg Double clicking on one of those items
brings the corresponding form to the front. I kind of like it, comments?

Certainly would wake you up in the morning.

[CDMAPoster]

Jerry Boone wrote:

I'm looking for a way to fire a public sub/function when a form is opened
and closed - without using form level events.

This may be an over-simplification, but will monitoring Forms.Count for
changes on a hidden form work as a quasi-event?

James A. Fortune
CD********@FortuneJames.com

[DFS]

Jerry Boone wrote:

Ok - thanks guys.

I just went ahead and coded all the forms. It's a pain but the
overall result is professional and consistent. A lot of the forms
operate as instances and a form handler (that's too complex to change
right now) already exists. If you want, here is a screen shot of the
end result (look toward the bottom of the menu and compare form
captions) http://www.gomaps.com/screenshot1.jpg Double clicking on
one of those items brings the corresponding form to the front. I
kind of like it, comments?
Pretty cool stuff. I sometimes need to open form instances, but haven't
figured out how to do it when the datasource is based on a standalone query.

What's that vertical navigation strip along the left? Is that an ActiveX
control?

I was hoping someone would say something like "instantiate a class
object with form collection ability and wire up a gadget sub that
fires on widget's withevents". Of course... it could be that I just
reached pure insanity and should go back to painting cars or
something.
"Jerry Boone" <je***@gomaps.com.nospam> wrote in message
news:44**********************@news.hubris.net...

I'm looking for a way to fire a public sub/function when a form is
opened and closed - without using form level events.

I have already done some extensive form work with instancing, looping
through the forms collection, bringing forms to the front with API
via hWnd, et.. and so on.

The problem is that users are loosing windows behind others and I
thought I would put a list together on an existing left handed menu
of (i.e.) "My open forms".

I have this already working now, but I am using Form_Current and
Form_Close events at the form level to do it. This is very tedious
(I have 204 forms currently in the db) and the thought of
remembering to put these events on new forms going forward kind of
gives me cold-sweat nightmares... (dam, did I remember to put that
code in?).

Does anyone know of a way to tap the forms collection using
withevents?

Another helpful hint regarding accessing the Window menu contents
could be helpful, but prefer the other way if possible.

Thanks

--
Jerry Boone

[rkc]

CD********@FortuneJames.com wrote:

Jerry Boone wrote:

I'm looking for a way to fire a public sub/function when a form is opened
and closed - without using form level events.

This may be an over-simplification, but will monitoring Forms.Count for
changes on a hidden form work as a quasi-event?

If the navigation strip is a seperate form then using a timer event
to update the view according to count would be a solution. I think
Anthony sort of suggested that.

[Jerry Boone]

Yes, he did suggest that - and it is a good solution, but I already use that
timer event on other things... particularly for 30 minute nag messages to
alert users of overdue items of multiple types.

--
Jerry Boone
"rkc" <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in message
news:1z****************@twister.nyroc.rr.com...

CD********@FortuneJames.com wrote:

Jerry Boone wrote:

I'm looking for a way to fire a public sub/function when a form is openedand closed - without using form level events.

This may be an over-simplification, but will monitoring Forms.Count for
changes on a hidden form work as a quasi-event?

If the navigation strip is a seperate form then using a timer event
to update the view according to count would be a solution. I think
Anthony sort of suggested that.

[Jerry Boone]

That's funny - never thought of that. Maybe I should have the yellow form
change from sunrise to sunset later in the afternoon? Moonlight for second
and third shift... :)

--
Jerry Boone
"rkc" <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in message
news:iW*******************@twister.nyroc.rr.com...

Jerry Boone wrote:

If you want, here is a screen shot of the end result (look
toward the bottom of the menu and compare form captions)
http://www.gomaps.com/screenshot1.jpg Double clicking on one of those items brings the corresponding form to the front. I kind of like it,

comments?
Certainly would wake you up in the morning.

[Jerry Boone]

I don't think you can get it anymore, but if you find a copy - give it a
try. Sheridan ListBar, the grids are Sheridan DataWidgets 3.1 (now
Infragistics, and don't waste your time trying to get their new controls to
work - they are exceptional in visual studio though). Neither of these
controls play "nice" with Access and you have to code them to do what you
want. Their gui based property editors just don't work well inside Access
since they were designed solely for visual studio 5 & 6. Well, I should say
that the only gui based properties I set are colors or things that "happen"
to show up in the Access property dialog. Everything else is done with
code.

In a conference one time I trapped Sheridan (on stage in front of many
folks) and mentioned that I used them in Access and they said "Really! It
works in Access?", then I let them know about the rest of the story... I
guess I was hoping they would make a few changes to their model and make it
Access compliant, instead they went and decided to get rich - what a bunch
of jerks :)

As for multi-instancing... I did it a little differently, but I really like
what Allen did here:

http://www.allenbrowne.com/ser-35.html

--
Jerry Boone
"DFS" <nospam@dfs_.com> wrote in message
news:Cz***************@bignews1.bellsouth.net...

Jerry Boone wrote:

Ok - thanks guys.

I just went ahead and coded all the forms. It's a pain but the
overall result is professional and consistent. A lot of the forms
operate as instances and a form handler (that's too complex to change
right now) already exists. If you want, here is a screen shot of the
end result (look toward the bottom of the menu and compare form
captions) http://www.gomaps.com/screenshot1.jpg Double clicking on
one of those items brings the corresponding form to the front. I
kind of like it, comments?
Pretty cool stuff. I sometimes need to open form instances, but haven't
figured out how to do it when the datasource is based on a standalone

query.
What's that vertical navigation strip along the left? Is that an ActiveX
control?

I was hoping someone would say something like "instantiate a class
object with form collection ability and wire up a gadget sub that
fires on widget's withevents". Of course... it could be that I just
reached pure insanity and should go back to painting cars or
something.
"Jerry Boone" <je***@gomaps.com.nospam> wrote in message
news:44**********************@news.hubris.net...

I'm looking for a way to fire a public sub/function when a form is
opened and closed - without using form level events.

I have already done some extensive form work with instancing, looping
through the forms collection, bringing forms to the front with API
via hWnd, et.. and so on.

The problem is that users are loosing windows behind others and I
thought I would put a list together on an existing left handed menu
of (i.e.) "My open forms".

I have this already working now, but I am using Form_Current and
Form_Close events at the form level to do it. This is very tedious
(I have 204 forms currently in the db) and the thought of
remembering to put these events on new forms going forward kind of
gives me cold-sweat nightmares... (dam, did I remember to put that
code in?).

Does anyone know of a way to tap the forms collection using
withevents?

Another helpful hint regarding accessing the Window menu contents
could be helpful, but prefer the other way if possible.

Thanks

--
Jerry Boone

[CDMAPoster]

Jerry Boone wrote:

Yes, he did suggest that - and it is a good solution, but I already use that
timer event on other things... particularly for 30 minute nag messages to
alert users of overdue items of multiple types.

--
Jerry Boone

In:

http://groups.google.com/group/comp....b38e0abd1559d5

I did some timing without using the timer event. Perhaps that will get
around the problem with the timer event being in use.

James A. Fortune
CM********@FortuneJames.com

If you think of life as a very hi-res training game for a moment, what
would it be worth to play the game for a day, to feel air fill your
lungs, to feel sunshine on your face, to navigate the space and to
interact with the other players?

[rkc]

CD********@FortuneJames.com wrote:

Jerry Boone wrote:

Yes, he did suggest that - and it is a good solution, but I already use that
timer event on other things... particularly for 30 minute nag messages to
alert users of overdue items of multiple types.

--
Jerry Boone

In:

http://groups.google.com/group/comp....b38e0abd1559d5

I did some timing without using the timer event. Perhaps that will get
around the problem with the timer event being in use.

Something has trigger a call to the sub routine that all that code is
run in. What would that be?

[CDMAPoster]

rkc wrote:

CD********@FortuneJames.com wrote:

Jerry Boone wrote:

Yes, he did suggest that - and it is a good solution, but I already use that
timer event on other things... particularly for 30 minute nag messages to
alert users of overdue items of multiple types.

--
Jerry Boone

In:

http://groups.google.com/group/comp....b38e0abd1559d5

I did some timing without using the timer event. Perhaps that will get
around the problem with the timer event being in use.

Something has trigger a call to the sub routine that all that code is
run in. What would that be?

How about this code behind the hidden form:

Public Sub Form_Load()
Dim lngHold As Long
Dim lngFormCount

lngFormCount = Forms.Count
Do While boolCheckFormCount
If Forms.Count <> lngFormCount Then
lngFormCount = Forms.Count
If lngFormCount >= 3 Then
'This form and at least two others are open
Call MyFormFocusSettingSub
End If
End If
'pause a moment
For lngHold = 1 To 100
DoEvents
Next lngHold
Loop
DoCmd.Close acForm, Me.Name
End Sub

A global variable like boolCheckFormCount can close the form when
monitoring is not needed. The form can be re-opened when monitoring is
desired. Or just open the form when the database starts up and let the
form stay open all the time. The ToDo lists don't look too CPU
intensive. Am I missing something?

James A. Fortune
CM********@FortuneJames.com

[Jerry Boone]

Thanks for your suggestions.

As I mentioned before, a timer solution would work. Since the forms
collection is very small, it would be a quick peice of code.

There is one very annoying thing that occurs with timers though. When you
are writing code and the timer event fires... the vbe does some validation
(since it is running the timer based code/sub), the current line you are
editing turns red, plus any intellisense drop selection folds up... it's a
real pain in the neck, even compared to loosing edit & continue in .net for
3 years. I can likely get around it, but it would require some yes/no
decision when the db starts with my userid at login.

I will kick it around, for now it's running with "current" and "activate"
events on each form calling a sub in a module via one line call statement.
My fear is that each time I (or another developer) puts a form in we will
forget to toss these events in. Oh well - again, thanks - I appreciate your
suggestions!

[DFS]

Jerry Boone wrote:

I don't think you can get it anymore, but if you find a copy - give
it a try. Sheridan ListBar, the grids are Sheridan DataWidgets 3.1
(now Infragistics, and don't waste your time trying to get their new
controls to work - they are exceptional in visual studio though).
Neither of these controls play "nice" with Access and you have to
code them to do what you want. Their gui based property editors just
don't work well inside Access since they were designed solely for
visual studio 5 & 6. Well, I should say that the only gui based
properties I set are colors or things that "happen" to show up in the
Access property dialog. Everything else is done with code.

OK. Thanks.

Looking at it, I realize I can code one of those in native Access, using a
no-border form and a table to store the menu entries.

As far as the way it behaves, if you click one of the lower entries, like
Miscellaneous, does it, and all the entries above it, shift to the top? I
think that's the way those things work.

[CDMAPoster]

Jerry Boone wrote:

Thanks for your suggestions.

As I mentioned before, a timer solution would work. Since the forms
collection is very small, it would be a quick peice of code.

There is one very annoying thing that occurs with timers though. When you
are writing code and the timer event fires... the vbe does some validation
(since it is running the timer based code/sub), the current line you are
editing turns red, plus any intellisense drop selection folds up... it's a
real pain in the neck, even compared to loosing edit & continue in .net for
3 years. I can likely get around it, but it would require some yes/no
decision when the db starts with my userid at login.

I will kick it around, for now it's running with "current" and "activate"
events on each form calling a sub in a module via one line call statement.
My fear is that each time I (or another developer) puts a form in we will
forget to toss these events in. Oh well - again, thanks - I appreciate your
suggestions!

TB,

You're welcome. Let us know how it turns out.

James A. Fortune
CD********@FortuneJames.com

[Jerry Boone]

Right - yes, like outlook. Very smooth though. Icons can be an image and
it's quite dynamic in that I can add/subtract items from my parent/child
tables and it's done.

--
Jerry Boone
"DFS" <nospam@dfs_.com> wrote in message
news:yp****************@bignews2.bellsouth.net...

Jerry Boone wrote:

I don't think you can get it anymore, but if you find a copy - give
it a try. Sheridan ListBar, the grids are Sheridan DataWidgets 3.1
(now Infragistics, and don't waste your time trying to get their new
controls to work - they are exceptional in visual studio though).
Neither of these controls play "nice" with Access and you have to
code them to do what you want. Their gui based property editors just
don't work well inside Access since they were designed solely for
visual studio 5 & 6. Well, I should say that the only gui based
properties I set are colors or things that "happen" to show up in the
Access property dialog. Everything else is done with code.

OK. Thanks.

Looking at it, I realize I can code one of those in native Access, using a
no-border form and a table to store the menu entries.

As far as the way it behaves, if you click one of the lower entries, like
Miscellaneous, does it, and all the entries above it, shift to the top? I
think that's the way those things work.