[spambayes-dev] Python programming for outlook plugins & spambayesuninstall

Mark Hammond mhammond at skippinet.com.au
Thu Sep 11 17:52:56 EDT 2003


> Thank you for your feedback. I've been doing some reading and
> tinkering.
> I noticed that the "unregister" does not remove the tool bars. With
> version 10a4 I was not able to re-register the source version and make
> it all work. I downloaded 10a5. This version did work, but only after
> adding all the missing files to the outlook2000\dialogs\resources
> directory

I think that has been fixed for the next source release.

> and making changes to msgstore.py (for some reason
> errored on:
> folder_eid, ret_class = store.GetReceiveFolder(msg_class, 0) ) perhaps
> because my folder names are dutch.

Can you please send me the specific exception you got?

> While doing all the research on outlook automation it struck me that
> there are a lot of incompatible ways of interacting with the different
> outlook versions. Spambayes was the first program I found
> that seemed to
> handle all versions of outlook while not needing tons of tedious code.
> My compliments to you.

Thanks :)  Generally it is just a matter of choosing the right tool for the
job :)

> I noticed while messing with the dialogs.h/dialogs.rc files that you
> seem to import these from visual studio. I assume you do some of your
> interface design in this program and then convert this over
> somehow. Do
> you have more information on this?

Not really - we rolled it ourselves.  Adam Walker hacked together a script
to parse these rc files - you can find them in the directory along with the
rc file.

The parent directory - Outlook2000\dialogs, and specifically dlgcore.py, has
code that is largely agnostic to how resources are loaded or parsed (so long
as they are Windows dialog structures!), and create a generic "windows
dialog".

The other files in the "dialogs" directory are very specific to "dialogs
that get data from a SpamBayes OptionsClass" - ie, it is not really specific
to SpamBayes, but is specific to the spambayes OptionClass module.
Currently though, Outlook is the only app that defines dialogs using this.
It is feasable that other SpamBayes apps, eg the pop3proxy toolbar, could
also use dialogs from this system (in which case the code would get
restructured)

> There are a lot of programs that do server-side spam
> filtering, and also
> a lot that do client side spam filtering (like spambayes). The only
> product I know that neatly ties them together is cloudmark. They went
> paid I believe and I wasn't too impressed when I used their
> application
> last year.

Our biggest issue with server side filtering is that we are not "rule" based
as such, and use data unique to each user.  This just doesn't lend itself to
server side apps the way things stand.

Mark.




More information about the spambayes-dev mailing list