Global variables, reading variables from a file

[Andrew Cushen]

Hi all,

I have a problem that's been bugging me for awhile.

I have code in the Application_Startup() event that reads
an integer value from a file, and writes it into an
Integer variable.

I also have code in the Application_Quit() event that
writes the value of that same variable into the same file,
overwriting the value in the file.

And, I have code in the Application_NewMail() event that
increments the variable.

The problem is, it's not working. I have verified that the
code in each event is working properly.

But, every time I check the value of the variable after
restarting Outlook, it's zero, despite the fact that I
know there was a non-zero value in the variable before
shutdown. And reading the file in a text editor between
restarts of Outlook shows zero. If I put a value into the
file using a text editor, the variable is still zero upon
restarting Outlook.

My thought is that I'm missing something about where & how
to declare the integer variable. I tried Dim-ing it in the
General Declarations area with no luck.

Any input will be much appreciated!


Thanks,

-Andrew

 

[Sue Mosher [MVP]]

It might help if you showed a code snippet. My guess is that maybe you're
not saving the file.

 

[Ken Pinard]

First,
Have you checked the file to see what is in it? Does it contain non-zero
bytes? You can change your write statement to write out the value of 64 a
couple of times to verify that it is writing (64 should be an "A").

Second,
Check your open statement for reading. A common mistake is to open a
read file in Write Mode. That will force the file to be empty and have no
data for reading.

Third,
On your read statement do you check to see if the file is empty before
reading?

Just some ideas,

HTH
Ken

 

[Andrew Cushen]

Here's the code, as requested, Sue:

(I removed the path to the file for brevity)
'***************************
' Code to write to file:

Private Sub Application_Quit()

Dim intFileNum As Integer
intFileNum = FreeFile
Open "[path to file]mailLog.dat" For Output As intFileNum
Write #intFileNum, intMailCnt
Close #intFileNum

End Sub
'*************************

Code to read from file:
Private Sub Application_Startup()

Dim intFileNum As Integer
intFileNum = FreeFile 'get next available free file #
Open "[path to file]mailLog.dat" For Input As #intFileNum
Input #intFileNum, intMailCnt ' read int from file
Close #intFileNum ' must close file

End Sub

'*******************

Then, in the Application_NewMail() event, I'm just using

intMailCnt = intMailCnt + 1

to increment the variable. As I stated in my original
post, I've debugged my code & it seems to work- it writes
to the file, & reads from the file.

So again, my question is: where & how to Dim the variable-
at the top of the code window? As Static? etc. etc.

I'm pretty well stumped at his point.


Thanks all,

-Andrew

 

[Sue Mosher [MVP]]

intMailCnt just needs to be a module-level variable, not declared in the
NewMail event handler:

Dim intMailCnt as Integer

You might include a debug.print statement in the Application_NewMail event
handler to keep track of the count. You know, right, that NewMail does not
fire for each incoming item?
--
Sue Mosher, Outlook MVP
Author of
Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

Here's the code, as requested, Sue:

(I removed the path to the file for brevity)
'***************************
' Code to write to file:

Private Sub Application_Quit()

Dim intFileNum As Integer
intFileNum = FreeFile
Open "[path to file]mailLog.dat" For Output As intFileNum
Write #intFileNum, intMailCnt
Close #intFileNum

End Sub
'*************************

Code to read from file:
Private Sub Application_Startup()

Dim intFileNum As Integer
intFileNum = FreeFile 'get next available free file #
Open "[path to file]mailLog.dat" For Input As #intFileNum
Input #intFileNum, intMailCnt ' read int from file
Close #intFileNum ' must close file

End Sub

'*******************

Then, in the Application_NewMail() event, I'm just using

intMailCnt = intMailCnt + 1

to increment the variable. As I stated in my original
post, I've debugged my code & it seems to work- it writes
to the file, & reads from the file.

So again, my question is: where & how to Dim the variable-
at the top of the code window? As Static? etc. etc.

.

 

[Andrew Cushen]

Sue-

<< You know, right, that NewMail does not
fire for each incoming item?
I had noticed that this appeared to be the case, that the
event fires once for each "batch" of incoming mailo, not
each mail. Is there any sort of a NewMail collection I can
look through to determine how many e-mails came in
a "batch"?

Also-

Regarding my original question- I have, in fact, Dim'ed my
integer as you suggested. Code still not working. Any
other thoughts?

Thanks,

-Andrew

 

[Andrew Cushen]

Update-

It appears that the code to read the value out of the file
is now working. But the code to write the value back at
shutdown is not working- even though it does the right
thing if I step through it in the Debugger. It is writing
zero to the file, not the value of the Integer, at app
shutdown.

Does Outlook trash all variables BEFORE the
Application_Shutdown() event fires? Because that would
explain what I'm seeing...

More puzzled than ever,

-Andrew

 

[Sue Mosher [MVP]]

Unless you're using a lot of rules to move items to different folders, it's
probably better to use the MAPIFolder.Items.ItemAdd event to monitor the
Inbox. You might find the article at
http://www.win2000mag.com/Articles/Index.cfm?ArticleID=9167 useful.

I'd put in a breakpoint or two or at least some Debug.Print statements or
track intMailCnt as a watch variable.

--
Sue Mosher, Outlook MVP
Author of
Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

 

[Andrew Cushen]

I should have said "Application_Quit()",
not "...shutdown", in my last post!

-Andrew

 

[Sue Mosher [MVP]]

I was thinking that might be what you were running into. It's best to avoid
using the Application_Quit event handler for anything. Instead, watch the
Explorers and Inspectors collection and when the last Explorer or Inspector
shuts down, if there are also other windows open, run your quitting code.
--
Sue Mosher, Outlook MVP
Author of
Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

 

[Andrew Cushen]

Thanks Sue, you're the Authority,as usual! ;-)


-Andrew

 

[Andrew Cushen]

Hi all-

Sue: I am, in fact, using quite a few Rules (62,
actually!!), both for deleting Junk mail and for moving e-
mail into different folders.
So perhaps the ItemAdd event wouldn't work so well?

Is there a property I could read that, when the
Application_NewMail() event fires, holds the number of new
e-mails - given that the Application_NewMail() may fire
once for multiple e-mails, as you stated earlier?

Barring that, is there ANY robust approach that will allow
me to accurately count incoming e-mails when I use a lot
of Rules?? Or, maybe even better, to count the number of e-
mails permanently deleted by my Rules?

Would I have to resort to something like:

1)alter each of those Rules that Permanently Delete e-
mails to instead dump the e-mail into a holding folder
2)count the number of e-mails in that folder
3)increment my Variable
4)Permanently Delete the e-mails from the holding folder

??

I fear that this might not work too well, as well as
slowing Outlook down significantly. What would happen when
e-mail comes in from one of my accounts, the code starts
working, then, a second or less later, e-mail comes in
from a different account? I have 3 or 4 accounts receiving
e-mail. I fear I might see "undefined" (love that Weasel
Word!) behavior if a lot of e-mails come in from different
accounts in a short period of time.

[*** WARNING- POSSIBLE RANT COMING ***]
Frankly, I started this "project" for my own amusement,
thinking it would be reasonably easy, and a good way to
help me move from "beginner VBA programmer"
toward "experienced VBA programmer" (whatever that may
be, ;-). However, several Clients have since expressed an
interest in code like, or very similar to, this. I have
become somewhat dismayed to learn that what should be a
straightforward, small "project", in fact is not
straightforward at all! The Application_NewMail() event
does NOT do what its name states/implies, which is typical
of Microsoft, though not limited to them by any means.

I mean, come on! Counting incoming e-mails seems like a
basic need, one that should be provided by the Language or
the Object Model; the implementation should be robust and
easy to use, so that it lends itself to use as a building-
block for larger, "real" projects. It seems like the more
I research this, trying to resolve it, the more I
hear "this function doesn't do what its name says it
does", or "the alternate solution will work only in a
perfect situation, not a real-life one" or "the
functionality you need is not implemented the way you need
it", etc., etc. Rather than getting a workable solution, I
hear warnings about what certain approaches WON'T do.
(Please note I am NOT speaking against anyone who has had
the kindness to try to help me here; I understand that no
one can tell me how to do something that the tools don't
support. [I'd like to thank Sue Mosher in particular.]
What bothers me is the basic capabilities that seem to be
missing from the tools themselves.)

Am I missing something here? Programming is hard enough
without artificial limits and missing basic functionality.

I'm sorry if this turned into a rant; it's just that I
have found so many frustrating situations similar to this
in trying to learn to program Microsoft products, that I
just had to get this off my chest. Surely others feel the
same?

And again, any constructive suggestions are GREATLY
appreciated.


-Andrew Cushen

 

[Sue Mosher [MVP]]

Comments inline.

Sue: I am, in fact, using quite a few Rules (62,
actually!!), both for deleting Junk mail and for moving e-
mail into different folders.
So perhaps the ItemAdd event wouldn't work so well?
Right.

Is there a property I could read that, when the
Application_NewMail() event fires, holds the number of new
e-mails - given that the Application_NewMail() may fire
once for multiple e-mails, as you stated earlier?
No.

Barring that, is there ANY robust approach that will allow
me to accurately count incoming e-mails when I use a lot
of Rules?? Or, maybe even better, to count the number of e-
mails permanently deleted by my Rules?

Would I have to resort to something like:

1)alter each of those Rules that Permanently Delete e-
mails to instead dump the e-mail into a holding folder
2)count the number of e-mails in that folder
3)increment my Variable
4)Permanently Delete the e-mails from the holding folder

Yes, something like that. I'd try using a single rule to put a copy of every
incoming item in a separate folder and then periodically count the number of
items in that folder. This rule would need to run before all others.

I fear that this might not work too well, as well as
slowing Outlook down significantly. What would happen when
e-mail comes in from one of my accounts, the code starts
working, then, a second or less later, e-mail comes in
from a different account? I have 3 or 4 accounts receiving
e-mail. I fear I might see "undefined" (love that Weasel
Word!) behavior if a lot of e-mails come in from different
accounts in a short period of time.

[*** WARNING- POSSIBLE RANT COMING ***]
Frankly, I started this "project" for my own amusement,
thinking it would be reasonably easy, and a good way to
help me move from "beginner VBA programmer"
toward "experienced VBA programmer" (whatever that may
be, ;-). However, several Clients have since expressed an
interest in code like, or very similar to, this. I have
become somewhat dismayed to learn that what should be a
straightforward, small "project", in fact is not
straightforward at all! The Application_NewMail() event
does NOT do what its name states/implies, which is typical
of Microsoft, though not limited to them by any means.

Never imply functionality from the name of an event. Look it up.

FWIW, Redemption offers a NewMail event that passes the actual item.

I mean, come on! Counting incoming e-mails seems like a
basic need, one that should be provided by the Language or
the Object Model; the implementation should be robust and
easy to use, so that it lends itself to use as a building-
block for larger, "real" projects. It seems like the more
I research this, trying to resolve it, the more I
hear "this function doesn't do what its name says it
does", or "the alternate solution will work only in a
perfect situation, not a real-life one" or "the
functionality you need is not implemented the way you need
it", etc., etc. Rather than getting a workable solution, I
hear warnings about what certain approaches WON'T do.
(Please note I am NOT speaking against anyone who has had
the kindness to try to help me here; I understand that no
one can tell me how to do something that the tools don't
support. [I'd like to thank Sue Mosher in particular.]
What bothers me is the basic capabilities that seem to be
missing from the tools themselves.)

Most people I've encountered who had a need to count email messages are
doing it at the server level.

That said, Outlook is quirky and has significant limitations. Workarounds
for many abound. Keep in mind that you're preaching to the choir here. If
you want Microsoft to see your suggestions, send them to
(e-mail address removed) and (e-mail address removed)

 

[Andrew Cushen]

Sue,

Thanks for your thoughts. As usual you're the one to get a
straight answer from. As far as what you said:

<< Never imply functionality from the name of an event.
Look it up. >>
-You're absolutely right on this one; a quick glance at
the docs would have told me the function didn't do what it
appeared to; live and learn. I blame laziness and lack of
time! Never again.

<< Most people I've encountered who had a need to count
email messages are doing it at the server level. >>
-This one is a sore point for me. I deal with small
businesses as most of my clients. Most of them simply
cannot afford a "solution" like Exchange or SQL Server.
The fact of the matter is that Office comes with many
computers at little or no additional cost; even when it
must be paid for, most people consider it a part of the
computer, almost like the operating system. So the Client
doesn't understand when you tell them Outlook or Access
just doesn't do what they need, either without costly
programming, or at all. The program has done everything
else they needed, and "this is just a little additional
function. Why wouldn't Microsoft have included it?" Of
course educating the Client is part of my job, but
programs like Outlook and Access have grown to include so
many functions that the line between them and the Server
versions of the apps has been blurred.
None of this is Microsoft's, or your, fault- of course!
But it does confuse the issue. So when I hear "you need to
buy the Server version for umpteen thousand dollars" to
get a robust version of a function that is IN Access or
Outlook but doesn't quite do what it says it does, I get
annoyed.
Perhaps there needs to be a "middle tier" of products
between the mostly-client-based Access and Outlook, and
the strictly-Server-and-mucho-dinero SQL Server and
Exchange.
I guess what I'm saying is don't lead us to believe an
Office app can do what it can't; a lot of higher-end
functions seem to only work in a glass house. Again, this
is not directed at you, Sue, and perhaps I will follow
your suggestion and forward my points to Micrsoft. As far
as preaching to the choir, though, who else will
sympathize when you need to vent but others who are going
through the same thing? :->

-As far as Redemption, as much as I hear good things about
it, for most of my clients, an additional expenditure for
something they thought they were getting IN OUTLOOK is
just not going to happen in these economic times. Perhaps
more Client Education from me would help here. Or not...

-Next, I will try to implement what you suggested about
the Rules & folders when I have some time. Thanks for the
input.


Thanks to all who have helped me on this newsgroup, and
thanks for putting up with my rants...


-Andrew

 

[Sue Mosher [MVP]]

Aren't there low-cost POP servers that do some mail stats? I haven't looked,
but I bet there's a market for it.

 

[Andrew Cushen]

Hmmm...

Maybe this shows a Microsoft bias on my part :->, but it
had never occurred to me to look for a third-party app to
do some of this!

Of course, that would mean the client hosting their own e-
mail, and none of my clients have a T-1. Unfortunately,
most DSL and Cable providers in my area specifically
prohibit running servers on their connections. I suppose
one could loom into third-party hosting, but then you've
got TWO costs...

I thank you for the thought, though, and will keep it in
mind.

And now I think it's time to put this thread to sleep!

-Andrew