Zugg Software :: View topic - Zeus Pre-release v1.02 ready (MAPI Mail Viewer)

Posted: Tue Jun 29, 2004 5:23 am

I have uploaded the latest pre-release of the Zeus application system.

There is a new demo application called "mailview.zml". This is the MAPI Mail Viewer program. It requires an installed email client that supports Extended MAPI. Currently, I believe the only email client that supports this is Microsoft Outlook. (not Outlook Express, only full Outlook).

I have only tested this using Outlook XP on Windows XP Home.

Please create a NEW TOPIC thread to report any problems with other versions of Outlook.

The included ZMAPI.DLL is the DLL file that implements the Zeus ObjectStore object for accessing the MAPI message store in Outlook.

I haven't gotten any new documentation written yet. But the new features to look for in this version of Zeus are:

1) The <TREE> component. Look at the sample code for mailview.zml to see how this tree is filled with the MAPI folders. Basically you can fill a <TREE> with anything stored in a "collection" COM object (or, actually, any object at all since you can specify the actual property names used by <TREE>)

2) The <GRID> component. This is the "Collection Viewer" component. You give it a collection and specify the fields of the objects stored in the collection that you want in your columns. The mailview.zml file shows how various types of columns can be created, including columns that display bitmap images (it tries to mimic the look of Outlook XP so it has columns for things like attachments, etc). You'll see events for specifying custom fonts for cells, etc. The actual mailview.zml uses the <GRID> component in a special way...virtual mode. In virtual mode, the <GRID> doesn't store any data internally...you provide a COM object for each row in the grid on request. There is code for reading ahead multiple objects to speed up performance, as well as reading all objects, like before a sort. The component will warn you if you try to sort a huge list since it might take a while to load all of the objects.

The effect of this is that you can view a mail folder of any size, and the <GRID> component only fetches those rows that it needs to display. I've succesfully displayed a mail folder with over 10,000 messages in it without any delay at all.

There seems to be some caching issues involved in the MAPI code itself, however. In order to work properly, the grid still needs to know the total number of objects (rows) to display. It seems that the first time you ask MAPI for the number of messages in a folder, it has to do something that takes a bit of time. I still don't understand this yet since it's not supposed to do that. But it's definitely something in the MAPI DLL and not in the <GRID> display.

The <GRID> supports clicking on column headers for sorting. Obviously, in order to sort the <GRID> must examine every row in the grid, so be careful with large message folders as mentioned above.

3) The <SPLITTER> component allows you to add dragable splitter bars between components. The mailview.zml has a splitter to the right of the folder list, and just below the message grid.

None of the column sizes or splitter positions are saved or anything yet. That will have to wait until I add the INI file support, but this is planned.

4) The Autoleft='true' and Autotop='true' code has been replaced with Align='prevleft' and Align='prevtop' to align a control with the previous control on the left or above it. The AutoCenter='true' has been replaced with Align='center' to center a control horizontally.

5) Added the Update method for controls to force them to repaint. Also fixed a variety of bugs in the core.recalc routine so that it works now. The argument to core.recal is either the ControlName.PropertyName you want to refresh, or the ControlName to refresh all properties of the control. If you call core.recalc for a Panel control, then all children controls of that panel are also recalculated. The mailview.zml demo uses this to update the current mail message being viewed when the selection in the <GRID> changes.

6) Color properties are now implemented. You can use any of the standard web color names, or the form #RRGGBB or $RRGGBB to specify an RGB value.

7) You can now set "compound" properties. For example, to change the font style of an edit control, you can now do:
<EDIT Font.Style='+bold'/>
where Font is the Font property of the edit control and Style is a property of the Font. Previously you could only change direct properties of a control. This also works in the Script code.

8) Related to the Align "prevleft" and "prevtop" alignments...there is a new property called RefControl where you specify the name of the component you want to align against instead of the previous control, which is the default.

Gee, what else...I don't know...with being sick for a week I've forgotten some of the other new stuff. I obviously need to spend some time documenting. There are lots and lots of properties and methods of the <TREE> and <GRID> components that need to be documented before people can really use this stuff. But that will come over time. For example, <TREE>s can actually have multiple columns, <GRID>s support two-color banding (set Banding.Active='true' to see it). Everything also supports database access, but I haven't written the DB hooks yet, so nothing is exposed that you can use yet, but that's one of the next things I plan to work on.

Anyway, I hope you like the new features. I think the mailview.zml demo app is starting to look a lot more like what eMobius will look like by default. It's obviously not useable yet since you can't send mail, replay, view attachments, or anything like that. But just being able to grab the Outlook PST file data like this was a major step towards a working email client. And I think it's really starting to show some of the nifty features of Zeus. In my opinion, the <TREE> and <GRID> components are easier to use than any other application development system I have seen, and are more powerful than most with their "virtual" features that allow support for huge trees and grids without taking up a ton of memory and resources.

Oh, to download, go to the www.emobius.com site and click the Download button.

Remember, for bug reports, create a NEW TOPIC thread. Only post to this thread to say how cool you think this stuff is Wink

Posted: Tue Jun 29, 2004 5:35 am

Oh, one other thing to mention for people looking at the demo. This mailview.zml also shows how you can use external DLL files with COM objects in them. In this case, we call CreateObject to create a zmapi.zMAPIStore object. This object implements the Zeus "zMessageStore" interface, defines in the core Zeus module. If you wanted to, you could write your own "zMessageStore" COM object, and just replace the CreateObject call in the demo application with a call to your own message store object, and the rest of the demo app would still work.

So, for example, you could write a "ExchangeMessageStore" COM object and then use this same demo application to view your Microsoft Exchange email instead of your MAPI email.

The related Zeus COM Interfaces are:

zCollection: the Zeus version of the Collection object in Visual Basic. Fully supports the VBScript for each construct and is completely compatible with other Collection objects.

zFolder: A folder object. A folder contains a collection of subfolders and a collection of Messages.

zMessage: A message object. Currently only defines a minimal set of properties like Subject, Sender, etc. Will ultimately be expanded considerably.

zProfile: A user profile (username/password). Used in ZMAPI to log into your MAPI data store.

zMessageStore: The global COM object that implements a couple of methods to fetch a collection of Profiles, a collection of Folders, etc.

zAttachment: A file attachment. Currently just a placeholder interface.

zRecipient: A single recipient. Currently just a placeholder and may eventually be replaced with something like zContact for full contact management.

But if you look at the mailview.zml file, you'll see only a few references to these objects. Since the <TREE> and <GRID> components don't know anything about MAPI themselves, it would be easy to write another demo application that just makes direct COM calls to Outlook.Application, for example, instead of using MAPI. I'll probably do this eventually just to show how it's done. But with Outlook.Application COM calls, you can't get stuff like the Sender Email address for a mail message like you can with MAPI.

Anyway, I mention all of this because this is the first demo application that gets serious about COM objects and starts to show the different layers of application development:

1) The ZML file: the user interface layer
2) External DLL files: custom COM objects specific to a particular application (like the ZMAPI objects)
3) Internal Components: visual controls such as <TREE> and <GRID> that are built into the Zeus core system.

Posted: Tue Jun 29, 2004 9:07 am

Sigh...you really should have created a new topic for this. It's hard to discuss problems in the main thread like this.

I'm going to need help from others on this because it sounds like somehow you have disabled the ability to create COM objects from the Microsoft Scripting component. It's possible that something in your system security settings has done this, or that Internet Explorer is somehow disabling functionality by turning off COM objects in the the entire system scripting routines (which would be an annoying and kludgy way for them to do it, but I won't assume anything at the moment)

You probably need to try playing more with this on your system. For example, try to create some other COM object like

Set Test = Createobject("Word.Application")

if you have MS Word installed, or something like that. Try to see if it's just the zMapi stuff or if it's a general problem on your system. The drive it's installed on doesn't matter at all.