Anyone know if Microsoft is planning to fix this bug? I'd imagine it
shouldn't take that much code to fix it. It's been several years that
people have been complaining about this on the web.

Basically if you have a Rule that automatically marks certain mail read, the
task tray notification icon (little yellow envelope) stays there. It is
supposed to disappear.

This bug forces the user to continuously open and sort through the inbox to
see what arrived, when there is nothing there - it was already processed and
marked read. This often affects spam plug-ins.

The bug existed in Outlook 2003, and still there in Outlook 2007. Now it's
2008. So at least it's been 5 years.

"fpbear" wrote in message
...
Anyone know if Microsoft is planning to fix this bug? I'd imagine
it shouldn't take that much code to fix it. It's been several years
that people have been complaining about this on the web.

Basically if you have a Rule that automatically marks certain mail
read, the task tray notification icon (little yellow envelope) stays
there. It is supposed to disappear.

This bug forces the user to continuously open and sort through the
inbox to see what arrived, when there is nothing there - it was
already processed and marked read. This often affects spam
plug-ins.

The bug existed in Outlook 2003, and still there in Outlook 2007.
Now it's 2008. So at least it's been 5 years.


The design was to trigger the tray icon when new items were received
in the Inbox. Has nothing to do with rules. The trigger occurs
before rules are ever exercised against any e-mails. The tray icon
doesn't trigger after the rules are applied to see what might be left
as marked unread in the Inbox. So, by design, the tray icon is doing
what it was supposed to do. That it doesn't do what you want is
different than it doesn't work as designed.

Rather than use the tray icon, and because you want to see what is
*left* AFTER the rules have executed, disable the tray icon and add a
rule at the end of the list that pops open an alert window. If all
the prior rules failed to trigger then the catchall rule at the end
will fire to let you know there was a new item delivered to your
Inbox. If some of the prior rules should also fire off an alert and
also use the stop-clause, you'll have to add the alert clause to those
rules. You end up using the rule-fired alert window to let you know
of new e-mails rather than the tray icon that wasn't designed the way
that you want it to work.

Vanguard, that does not sound correct.

(a) When a message is marked read in the preview pane, the flag disappears
from the task tray.

(b) When a message is marked read because of a rule, the flag stays around.

So your argument that I'm coming up with some new feature doesn't make much
sense to me. It only makes sense to sync up (a) and (b) behavior.

There is interaction between mail being marked read and the flag, because
this is the behavior in the preview pane. By default this is set to mark
the mail read when the selection changes. I like to set mine to mark the
mail read after 1 second. In any of these cases, the task tray flag
disappears.

The programmers could use the same communication mechanism to get rid of the
flag during the mark-read rule processing.

When a message is marked read in the preview pane, the software talks to the
task tray flag somehow.

Why is it so hard to talk to the flag in the same way for a rule? Did the
programmer use some highly unconventional technique?

Also, something about software application architecture best practices:

When the mark-read rule is processing, it is not the job of the rule engine
to check for all the remaining messages that are still unread. Instead this
should be the job of the application module that is responsible for the
read/unread status and display changes pertaining to that status.

I have a feeling that during the creation of the rule engine some programmer
used an unconventional technique and just changed the bold face to non-bold
formatting for a read message and said to the software development manager
"hey I'm all done." .... instead of using the proper API.

"fpbear" wrote in message
...
Vanguard, that does not sound correct.

(a) When a message is marked read in the preview pane, the flag
disappears from the task tray.

And once you commit the manual action through the GUI, the status gets
updated. Whether you read (or mark as read) a message that would or
would not have triggered a rule is irrelevant when manually marking
the message as read.


(b) When a message is marked read because of a rule, the flag stays
around.

That was the premise of your original post, that the tray icon did not
reflect the results of the Inbox items and their read-status AFTER the
rules had been executed.

marking a message read using rules happens during MAPI processing while
reading it in the reading pane happens after the mapi spooler is finished
handling it so you can't compare the behavior.

Either use the method vanguard suggested or use the unread (or a custom
search) folder to read new mail and ignore (or disable) the tray icon.

--
Diane Poremsky [MVP - Outlook]
Author, Teach Yourself Outlook 2003 in 24 Hours
Need Help with Common Tasks? http://www.outlook-tips.net/beginner/
Outlook 2007: http://www.slipstick.com/outlook/ol2007/

Outlook Tips by email:


Outlook Tips: http://www.outlook-tips.net/
Outlook & Exchange Solutions Center: http://www.slipstick.com
Subscribe to Exchange Messaging Outlook newsletter:


** Please include your Outlook version, Account type, and Windows Version
when requesting assistance **


"fpbear" wrote in message
...
Vanguard, that does not sound correct.

(a) When a message is marked read in the preview pane, the flag disappears
from the task tray.

(b) When a message is marked read because of a rule, the flag stays
around.

So your argument that I'm coming up with some new feature doesn't make
much sense to me. It only makes sense to sync up (a) and (b) behavior.

There is interaction between mail being marked read and the flag, because
this is the behavior in the preview pane. By default this is set to mark
the mail read when the selection changes. I like to set mine to mark the
mail read after 1 second. In any of these cases, the task tray flag
disappears.

The programmers could use the same communication mechanism to get rid of
the flag during the mark-read rule processing.

When a message is marked read in the preview pane, the software talks to
the task tray flag somehow.

Why is it so hard to talk to the flag in the same way for a rule? Did the
programmer use some highly unconventional technique?

"fpbear" wrote in message
...
Also, something about software application architecture best
practices:

When the mark-read rule is processing, it is not the job of the rule
engine to check for all the remaining messages that are still
unread. Instead this should be the job of the application module
that is responsible for the read/unread status and display changes
pertaining to that status.

I have a feeling that during the creation of the rule engine some
programmer used an unconventional technique and just changed the
bold face to non-bold formatting for a read message and said to the
software development manager "hey I'm all done." .... instead of
using the proper API.




I have run across many perceived ease-of-use anomalies that when
reported has the developer claiming that it is working as designed. I
then go read the Functional Specification and come back with the claim
that the behavior is not so specified. The result is usually to
change from "working as designed" to "working as coded". So I end up
issuing a trouble ticket to report the ease-of-use defect and won't
close it based on the lame "working as coded" excuse. But as a QA
tester, I can't change the product but only recommend changes or
report defective behavior that differs from the spec (I can report
what I think is a defect but have to work on getting the developers to
agree if it is not spec'ed that way). After all, you are complaining
to a peer community of users that can't do anything to change the
product. What do you want us users to do about it?

Are you familiar with MAPI or the Outlook object model and rules engine?

--
Diane Poremsky [MVP - Outlook]
Author, Teach Yourself Outlook 2003 in 24 Hours
Need Help with Common Tasks? http://www.outlook-tips.net/beginner/
Outlook 2007: http://www.slipstick.com/outlook/ol2007/

Outlook Tips by email:


Outlook Tips: http://www.outlook-tips.net/
Outlook & Exchange Solutions Center: http://www.slipstick.com
Subscribe to Exchange Messaging Outlook newsletter:


** Please include your Outlook version, Account type, and Windows Version
when requesting assistance **


"fpbear" wrote in message
...
Also, something about software application architecture best practices:

When the mark-read rule is processing, it is not the job of the rule
engine to check for all the remaining messages that are still unread.
Instead this should be the job of the application module that is
responsible for the read/unread status and display changes pertaining to
that status.

I have a feeling that during the creation of the rule engine some
programmer used an unconventional technique and just changed the bold face
to non-bold formatting for a read message and said to the software
development manager "hey I'm all done." .... instead of using the proper
API.

"VanguardLH" wrote in message
...

And once you commit the manual action through the GUI, the status gets
updated. Whether you read (or mark as read) a message that would or would
not have triggered a rule is irrelevant when manually marking the message
as read.

In the first sentence it sounds like you're essentially saying that manually
marking read works ok, which is no surprise. I don't understand the second
sentence.

That was the premise of your original post, that the tray icon did not
reflect the results of the Inbox items and their read-status AFTER the
rules had been executed.

It's when the rules is executed when this bug manifests itself, not sometime
after. When a rule specifically executes to mark the item read, the new
message flag does not go away. But there is no more new message anymore
because the user made it so via the rule.

Microsoft saw this logic when items are manually marked read, and clears the
tray icon. Why is this logic not clear when using a rule?

Ok so then I should ask this question instead,

Does a mail filtering rule to mark read deserve to be disconnected from
normal UI (tray status) behavior because it is automatic vs. someone
clicking to mark read?

"Diane Poremsky {MVP}" wrote in message
...
marking a message read using rules happens during MAPI processing while
reading it in the reading pane happens after the mapi spooler is finished
handling it so you can't compare the behavior.

The MAPI rules processing engine is integrated to the UI enough to change
the message subject from bold to normal when it is marked read. Then, with
a little extra programming, Microsoft could "complete the job" and trigger
another detection routine make that little task tray icon disappear if there
are no more unread messages. Just call the same function that is called
when the user manually clicks to mark as read.

Either use the method vanguard suggested or use the unread (or a custom
search) folder to read new mail and ignore (or disable) the tray icon.

Vanguard has a neat idea but that involves disabling the tray icon. The
tray icon is more user friendly than a pop up box. I would go nuts if I had
a pop up box every time I get new emails. It would be better if Microsoft
just finally fixes this in Outlook 2012.