Outlook design 1

[r4dix]

Hey.. I am pretty new to this forum.. i did search, but I haven't found an answer to this question.

I am designing an outlook like application (seems everyone does that nowdays). Anyway, my question is how is it built? Is it an SDI application with multiple views? or MDI masked for SDI? What would be the best approach to design a clone?

Any thoughts are appreciated!

//rad

 

[Cagliostro]

it is a complex SDI application. There are implemented functionalities of SMTP/POP*/IMAP/HTTP mail clients.

Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[r4dix]

Oof.. Well I sorta know what its functionalities are

In a general sense it is an SDI application (at least it does look like it!), however I doubt that it is implemented via standart SDI doc-view architecture.

Although it could be an SDI, document implemented around personal folders.. and just switching views.

Any other ideas?

//rad

 

[PerFnurt]

Well, if you wish to apply a Doc/View architecture I think you could consider it a MDI where each .pst is handled by a separate doc.

The obvious (and trivial) difference from a "normal" MDI would be GUI interaction regarding to open/close of ".pst".

Outlook's Folder list would translate to some kind of loaded-doc-selector/browser. The Folder list is naturally not a view in the Doc/View sense. A (dockable) child of the MainFrame perhaps?

The "Outlook Bar" would be yet another dockable non-DocView-View with shortcuts into the Folder list.

How far are you prepared to go? I mean if you're into make a full clone (VBA macros, rules wizard, calendar, contact journal, notes, COM-compilant interface and whatnot) I expect you'll have a couple of years of work...

/Per

_{if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;}

 

[PerFnurt]

Darn, now you got me going.... ;-)

Perhaps it could be regarded as this:
Let the &quot;.pst&quot; be a compound file, that is a file that contains other files. See MSDN on COleStreamFile and COleDocument.

Each subfile would be mapped to a certain document type (ie a MailDocument, CalendarDocument etc). Each document would have its own set of views (just like a normal Doc/View would), that way the Inbox & Outbox etc would just be different views of the MailDocument, a CalendarView would be... bah you get the point.

Opening the .pst would (narutally) open the compound file (and keep it open until app/.pst is closed), while selecting for example the Inbox would open the MailDocument-subfile and its corresponding view.




/Per

_{if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;}

 

[r4dix]

Nice! Thank you Per.. very intersting ideas.

Yeah I was thinking about MDI implementation mostly. Need to look into COleDocument.

Usually Outlookbar implementations are derived from Toolbar or ControlBar (i think BCG uses CControlBar).

It would definitely take alot of time to write a complete clone.. and even more time to debug.. heh. I was rather interested in architecture beneath outlook's design.. something that's been bugging me for long time.

//rad