Rob Eberhardt

cleverness ensues

skip navigation

 Friday, November 18, 2005

So there's a bug/limitation/pile-o-crap in CDO (the programmatic interface to use MAPI (the programmatic interface to get at & use Outlook or Exchange stuff)).  A key bit from the MSDN CDO reference:

Calendar folders are not supported in the public folders store provided with Microsoft® Exchange, and AppointmentItem objects are stored as Message objects. An attempt to read IsRecurring in this case returns CdoE_NO_SUPPORT.

This has majorly stunk for me, since I'm doing a project which needs to dump out some Exchange Public Calendars' AppointmentItems, and to use their StartDate and EndDate properties.  Common refrains to this song and dance:

  • Public member 'StartDate' on type 'Message' not found. and Public member 'EndDate' on type 'Message' not found.
  • Ok, I'll follow the guru's advice, and explicitly force it to an AppointmentItem: ctype(oMsg, MAPI.AppointmentItem)... Nope, I still hear: Specified cast is not valid.
  • But wait, what's the oMsg.Type?? IPM.Appointment is my answer. Well... (dead end).

Fortunately there's this: MAPI Property Tags.  I can get at those two properties via CdoPR_START_DATE and CdoPR_End_DATE.


DIM dtStartDate as Date = oMsg.Fields(MAPI.CdoPropTags.CdoPR_START_DATE).Value
DIM dtEndDate as Date = oMsg.Fields(MAPI.CdoPropTags.CdoPR_End_DATE).Value
Not really properties, but something to work with at least. 

UPDATE: I hit the same problem with getting the users who originally posted and last modified an item, except worse -- they seem to be documented nowhere.  I reverse-engineered the fields collection (dumped the data, looked for what I wanted, found the matching ID, converted to a hexadecimal property tag), and found them:

CONST CDoPR_RE_PostedBy = &H3FF8001F
CONST CDoPR_RE_ModifiedBy = &H3FFA001F
DIM strPostedBy as String = oMsg.Fields(CDoPR_RE_PostedBy).Value
DIM strModifiedBy as String = oMsg.Fields(CDoPR_RE_ModifiedBy).Value
I don't see these tags in the CDO Property Tag list, and google searches for them come back empty.  (That said, consider my discovery subject to change with future versions.)

Too bad there also seems to be no way to use these property tags with a MessageFilter, or to get RecurrencePattern.

Unfortunately, this is part of a bigger problem.  I'm not sure, but I suspect CDO was simply never finished.  Get this: If you want to open a user-created folder, there's no way to do so directly by name.  The normal method, getFolder(), only accepts a 76-digit FolderID!  There is a solution, but ain't pretty.

Here's another bonus from that same link:

If your application is running as a Microsoft® Windows NT® service, you cannot access the Microsoft Exchange Public Folders through the normal hierarchy because of a notification conflict. You must use the InfoStore objects Fields property to obtain the Microsoft Exchange property PR_IPM_PUBLIC_FOLDERS_ENTRYID, property tag &H66310102. This represents the top-level public folder and allows you to access all other public folders through its Folders property.
...And yes, that seems to apply to applications.

Another gem (this seems so ludicrous that I want to doubt it): CDO MAPI in needs to run with impersonation, even if the authenticated user has a matching Exchange account.  It did fix my problem, though, so there's some more anecdotal evidence.  (Perhaps it's actually the old Windows domain double-hop bug?)

In general, I've noticed CDO seems to require a whole lot of Hex flags to do simples operation like open a message object.  ...Well, a whole lot for what should is supposed to be object-oriented code.  I've been wrapping up most of these basic operations with a class, but the vast amount of CDO hacks contained are too ugly to be seen here anytime soon. 

SO, Lemsons and the rest of the Exchange Team, have you touched CDO in the last 5 years???  It sure seems to be a stunted and abandoned technology.

good resource:
CDO Live (almost as outdated as CDO itself, though)

11/18/2005 11:26 PM Eastern Standard Time  #    Disclaimer  |   | 

 Thursday, November 17, 2005

You scored as Batman, the Dark Knight. As the Dark Knight of Gotham, Batman is a vigilante who deals out his own brand of justice to the criminals and corrupt of the city. He follows his own code and is often misunderstood. He has few friends or allies, but finds comfort in his cause.

Batman, the Dark Knight


Lara Croft


Neo, the "One"


The Terminator




William Wallace


El Zorro


Indiana Jones


The Amazing Spider-Man


Captain Jack Sparrow


James Bond, Agent 007

Which Action Hero Would You Be? v. 2.0

"You're nocturnal; you enjoy working at night" -- yeah, I guess that's me. The technology angle seems pretty obvious too.

11/17/2005 1:00 AM Eastern Standard Time  #    Disclaimer  |   | 

 Saturday, November 12, 2005

Been a long time since I did my song roll.  So here are the first 10 random picks:

King's X - Far, Far Away
U2 - Who's Gonna Ride Your Wild Horses
Newsboys - Shine
The Commodores - Old-fashion Love
Us3 - Knowledge of Self
Porcupine Tree - Phase III
Stuart Hamm - Snoopy's Theme Song - Peanuts
Sting - Why Should I Cry for You?
Relient K - Chap Stick, Chapped Lips, and Things Like Chemistry
Ohio Players - Only A Child Can Love

Good mixture, I think.

11/12/2005 5:12 PM Eastern Standard Time  #    Disclaimer  |   | 

 Friday, November 04, 2005

The Windows calculator has Standard and Scientific modes... 

Suddenly conspicuous today in its absence was a Conversion mode.  (Heck, I've got a little app on my phone which does this.)  Cmon Vista, it just makes sense! 

Especially while we dumb Americans keep resisting metric.  Liquid volume is where it's hairiest, figuring out:

  • 3 teaspoons to 1 tablespoon
  • 2 tablespoons to 1 fl. oz
  • 4 fl. oz to 1 gill
  • 2 gills to 1 cup
  • 2 cups to 1 pt
  • 2 pts to 1 qt
  • 4 qts to 1 gal
...We should really just drop most of those units.  (What's the point of ×2 units, anyway??)  It should be much simpler, like:
  • 16 tablespoons to 1 cup
  • 16 cups to 1 gal

If elected, I promise to simplify liquid volumes immediately.

11/4/2005 4:32 PM Eastern Daylight Time  #    Disclaimer  |   | 

 Wednesday, November 02, 2005

Seen while fighting with AVG Free (an otherwise great A/V program)....

avgwb.dat - Entry Point Not Found
The procedure entry point ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß could not be located in the dynamic link library GDI32.dll. 

I realize the Broken/WTF-type posts are a staple around here (probably because it's easy to point and laugh).  So I've made it official with a new category.

11/2/2005 1:38 AM Eastern Daylight Time  #    Disclaimer  |   | 

 Thursday, October 20, 2005

That's not only the name of a great website on the subject, but also my reaction to this bank website's web browser choices:

I let em know how silly this is:

Your choices of web browsers are VERY outdated, by about 10 years!

The main CURRENT web browsers are:
* Internet Explorer
* Mozilla Firefox
* Opera
* Apple Safari
* Konqueror
Take a look at for current browser stats sometime.

Just a heads-up from a web developer. Hope it helps you get it together.

They also offer Unix as a choice of Computer Type, but not Linux.  Even worse: it's a screen for requesting technical support.  (I sure hope their techs know Mosaic well!!)

Along those lines, I just noticed that this month is the 4th anniversary of IE6.  Happy Birthday, IE!

10/20/2005 5:21 PM Eastern Daylight Time  #    Disclaimer  |   | 

Anne van Kesteren just posted about the Opera 9 Preview.  More notable to me is the testcase for Linking to style sheets with HTTP headers.

Here's the code:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "">
<html lang="en">
  <title>CSS: Linking to style sheets with HTTP headers</title>
  <meta name="Author" content="Krijn Hoetmer ~">
  <h1>Linking to style sheets with <abbr title="HyperText Transfer Protocol">HTTP</abbr> headers</h1>

  <p>This line should (or could) be red.</p>
  <pre><code>Link: &lt;index.css&gt;; REL=&quot;stylesheet&quot;; MEDIA=&quot;screen&quot;</code></pre>


The testcase already works (P element in red) in the current Firefox 1.07 (but not IE, natch).  Style code is utterly missing from the document -- there are no style attributes, and no <style> or <link> elements.

That's because they're not in the document.  It's in the headers of the HTTP response which delivered the document.  I had to find the style insertion with the Fiddler tool (a great IE addin), and this is what I found in the HTTP headers:

Link: <index.css>; REL="stylesheet"; MEDIA="screen"

I must've missed the memo where this became a standard (since multiple browsers now support it).  I miss how it's a good idea too...

Yes, there's a gee whiz factor to it.  I could even think of possible uses for HTTP style includes (like configuring includes at the website level via the web server, something which IIS already can do with normal include files). 

But it just seems like a bad idea.

Granted, the line between protocol and document was crossed long ago with HTTP-EQUIV META tags.  This, however, crosses it in the opposite direction, by putting not meta-data, not layout or behavior data, but style data into a transport protocol!

Now I'm no code purist -- I feel most like a "SAVD" on Molly's scale  (What's bizarre is that I'd consider Anne much closer to a purist, a "SASS" to Molly.) 

We have CSS to get the font tags out of HTML.  Why not cram it into something even more poorly suited like HTTP?!

VERY bad idea.

10/20/2005 3:51 PM Eastern Daylight Time  #    Disclaimer  |   |