MS Project COM interface --getting started

I am trying to use the MS Project COM interface to get some project data for
my project.  Unfortunately I can't get past the first call to start doing
what I need.  That call is to the MSProject Application's FileOpen method.
I have tried all sorts of combinations of parameters trying to get things
right, but basically I use it like this:

proj := MSProject_MSProject new.
proj fileOpen: 'C:\My Documents\Dolphin Smalltalk 4.0\jcw smalltalk
work\project\GNU_Software.mpp'
 readOnly: false merge: (MSProjectConstants at: 'pjDoNotMerge')
taskInformation: false
  table: nil   sheet: nil   noAuto:  false userID: nil
 databasePassWord: nil  formatID: nil
 map: nil openPool: (MSProjectConstants at: 'pjDoNotOpenPool')

This fails, with an HRESULT saying that the argument value is not valid.  I
can't figure out which argument(s) is the problem.  I suspect its the
strings, but I've tried every combination I can think of (passing '', (''
asVariant), (nil asVariant)) to no avail.

I'm hoping somebody might have used this from Dolphin before.

TIA,

John Whittaker



If it helps, here's the MS Project help data for the FileOpen method:


Syntax

expression.FileOpen(Name, ReadOnly, Merge, TaskInformation, Table, Sheet,
NoAuto, UserID, DatabasePassWord, FormatID, Map, OpenPool)

expression  Optional. An expression that returns an Application object.

Name  Required String. The name of the project file, source file, or data
source to open.

ReadOnly  Optional Boolean. True if the file is opened read-only. If
selectively importing data instead of loading a complete project, ReadOnly
is ignored.

Merge  Optional Long. Specifies whether to automatically merge the file with
the active project. If Map is specified, Merge is ignored. Can be one of the
following PjMerge constants: pjDoNotMerge, pjMerge, pjAppend, or pjPrompt.
The default value is pjDoNotMerge.

TaskInformation  Optional Boolean. True if the file contains information on
tasks, for a project saved under a non-Microsoft Project file format. False
if the file contains information on resources. If Map is specified,
TaskInformation is ignored. The default value is True if the active view is
a task view; otherwise it is False.

Table  Optional String. The name of a table in which to place the resource
or task information, for a project saved under a non-Microsoft Project file
format. If Map is specified, or Name specifies a database file or format,
Table is ignored. The default value for Table is the name of the active
table.

Sheet  Optional String. The sheet to read when opening a workbook created in
Microsoft Excel version 5.0 or later. If Map is specified, or if the file
specified with Name is not a Microsoft Excel file, Sheet is ignored.

NoAuto  Optional Boolean. True if any Auto_Open macro is prevented from
running. The default value is False.

UserID  Optional String. A user ID to use when accessing a database. If Name
or FormatID isn't a database, UserID is ignored.

DatabasePassWord  Optional String. A password to use when accessing a
database. If Name or FormatID isn't a database, DatabasePassWord is ignored.

FormatID  Optional String. The file or database format. If Microsoft Project
recognizes the format of the file specified with Name, FormatID is ignored.
Can be one of the following format strings:

Format String Description
"MSProject.mpp" Microsoft Project file
"MSProject.mpt" Microsoft Project template
"MSProject.mpd" Microsoft Project database
"MSProject.mpw" Microsoft Project workspace
"MSProject.mpx" Microsoft Project 4.0 MPX file
"MSProject.odbc" ODBC database
"MSProject.xls5" Microsoft Excel 5.0/95 (7.0) workbook
"MSProject.xls8" Microsoft Excel 97 (8.0) workbook
"MSProject.mdb8" Microsoft Access 97 (8.0) database
"MSProject.csv" CSV file
"MSProject.txt" TXT file
Map  Optional String. The name of the import/export map to use when
importing data.

OpenPool  Optional Long. The action to take when opening a resource pool or
sharer file. Can be one of the following PjPoolOpen constants: pjPromptPool,
pjPoolReadOnly, pjPoolReadWrite, pjPoolAndShares, or pjDoNotOpenPool. The
default value is pjPromptPool.

Remarks

Using the FileOpen method without specifying any arguments displays the File
Open dialog box.
The Name argument can contain a file name string or an ODBC data source name
(DSN) and project name string. The syntax for a data source is
<DataSourceName>\Projectname. The less than (<) and greater than (>) symbols
must be included and a backslash ( \ ) must separate the data source name
from the project name. The DataSourceName itself can either be one of the
ODBC data source names installed on the machine, a file DSN, or a path and
file name for a file-based database.

"John Whittaker" <[hidden email]> writes:

> proj fileOpen: 'C:\My Documents\Dolphin Smalltalk 4.0\jcw smalltalk
> work\project\GNU_Software.mpp'

I don't know the answer, but have you tried using forward slashes in
the directory paths? Maybe double backslashes?

Chris.
--
http://www.double.co.nz/smalltalk

I finally succeeded in getting MSProject to "sort of" work from Dolphin.
But, after merrily proceeding along towards my work goal, I ran into a
problem which caused Dolphin (4.0) to either hang or crash.   It seems to be
related to converting a collection of IDispatch objects into a
MSProjectTasks object.  Here's a sample of how to get to the crash point:

proj := MSProject_MSProject new.
proj fileOpen: 'C:\My Documents\Dolphin Smalltalk 4.0\jcw smalltalk
work\project\test.mpp'
     readOnly: false merge: (MSProjectConstants at: 'pjDoNotMerge')
taskInformation: true
     table: ''   sheet: ''   noAuto:  false userID: ''
     databasePassWord: ''  formatID: 'MSProject.mpp'
     map: '' openPool: (MSProjectConstants at: 'pjDoNotOpenPool')


theproject := proj activeProject
tasks := theproject tasks   **** WILL CRASH HERE ****

However, if I replace the "tasks" message send to the IProjectDoc (ie,
"theproject") object with most of its method source, as in:

tasks := theproject getPropertyId: 1,

the getPropertyId returns fine with a collection of IDispatch objects.
Apparently it is the rest of the "tasks" method that causes the crash.  The
full method is:

tasks
 "Answer the <MSProjectTasks> value of the 'Tasks' property of the
receiver."

 ^MSProjectTasks attachInterface: (self getPropertyId: 1).



Does this make sense to anybody?  I'd like to get this to work if possible
and this is beyond my knowledge of COM and Dolphin.  Please help.


Thanks again,

John Whittaker



"John Whittaker" <[hidden email]> wrote in message
news:RALg6.572$[hidden email]...
> I am trying to use the MS Project COM interface to get some project data
for
> my project.  Unfortunately I can't get past the first call to start doing
> what I need.  That call is to the MSProject Application's FileOpen method.
> I have tried all sorts of combinations of parameters trying to get things
> right, but basically I use it like this:
>

John

I don't have access to MS Project, so I may not be able to help much, but
will try to assist you to get to the bottom of the problem you are
experiencing.

You wrote in message
news:HMIh6.1044$[hidden email]...
> I finally succeeded in getting MSProject to "sort of" work from Dolphin.
> But, after merrily proceeding along towards my work goal, I ran into a
> problem which caused Dolphin (4.0) to either hang or crash.   It seems to
be
> related to converting a collection of IDispatch objects into a
> MSProjectTasks object.  Here's a sample of how to get to the crash point:
> ...[snip]...
> tasks := theproject tasks   **** WILL CRASH HERE ****

Can you explain what you mean by "crash"? Does Dolphin actually terminate
unexpectedly, or do you get a walkback? Does it "crash" only when you press
Ctrl+D (display it) or also when you press Ctrl+E (evaluate it)?

If you get a walkback can you copy (using the Copy button on the walkback
dialog) and paste it here. If you get an actual crash we can tell a lot more
if some post-mortem details are provided, specifically a "Crash Dump"
(http://www.object-arts.com/wiki/html/Dolphin/CrashDump.htm#dumpFile).

> However, if I replace the "tasks" message send to the IProjectDoc (ie,
> "theproject") object with most of its method source, as in:
>
> tasks := theproject getPropertyId: 1,
>
> the getPropertyId returns fine with a collection of IDispatch objects.
> Apparently it is the rest of the "tasks" method that causes the crash.
The
> full method is:
>
> tasks
>  "Answer the <MSProjectTasks> value of the 'Tasks' property of the
> receiver."
>
>  ^MSProjectTasks attachInterface: (self getPropertyId: 1).

Two possibilities spring to mind:
1) The property isn't really returning an MSProjectTasks, but perhaps a
generic IDispatch (despite what the type library says)
2) There is a problem with the generated MSProjectTasks.

If (1) were the case then an actual fatal crash is quite likely, since this
would amount to a static type mismatch. To see if (1) is the problem replace
the #attachInterface: expression with:

^(self getPropertyId: 1) queryInterface: MSProjectTasks

If the problem still occurs, then a crash dump (or walkback and a bit of
debugging) will help in locating the problem. It's probably occurring when
Dolphin is attempting to get the #printString of the object in order to
display the result of an evaluation. In the case of a COM object which is a
"collection" this involves enumerating the elements to display them in the
same way as Smalltalk's internal collections are printed.

Regards

Blair

In article <968vn0$kb3gf$[hidden email]>,
  "Blair McGlashan" <[hidden email]> wrote:
> John
>

>
> Can you explain what you mean by "crash"? Does Dolphin actually
terminate
> unexpectedly, or do you get a walkback? Does it "crash" only when you
press
> Ctrl+D (display it) or also when you press Ctrl+E (evaluate it)?
>
> If you get a walkback can you copy (using the Copy button on the
walkback
> dialog) and paste it here. If you get an actual crash we can tell a
lot more
> if some post-mortem details are provided, specifically a "Crash Dump"
> (http://www.object-arts.com/wiki/html/Dolphin/CrashDump.htm#dumpFile).
>

By crash, I mean a full crash of Dolphin... no walkback.  There was some
Windows-generated dialog about a Dolphin dll (if I recall correctly).  I
can try to repeat at home later.  I was doing a Ctrl-D at the time.
Haven't tried it with a Ctrl-E.


> Two possibilities spring to mind:
> 1) The property isn't really returning an MSProjectTasks, but perhaps
a
> generic IDispatch (despite what the type library says)
> 2) There is a problem with the generated MSProjectTasks.
>
> If (1) were the case then an actual fatal crash is quite likely, since
this
> would amount to a static type mismatch. To see if (1) is the problem
replace
> the #attachInterface: expression with:
>
> ^(self getPropertyId: 1) queryInterface: MSProjectTasks

I have in fact done just this, and it works fine.  I get a
MSProjectTasks object back, and have been able to continue working with
it just fine.  This was the workaround I came up with.

>
> If the problem still occurs, then a crash dump (or walkback and a bit
of
> debugging) will help in locating the problem. It's probably occurring
when
> Dolphin is attempting to get the #printString of the object in order
to
> display the result of an evaluation. In the case of a COM object which
is a
> "collection" this involves enumerating the elements to display them in
the
> same way as Smalltalk's internal collections are printed.
>
> Regards
>
> Blair
>

I don't know if this might have anything to do with the problem or not,
but one of my tasks is just a blank line in my MSProject file.  Again, I
can't give a lot of details since I'm now at work not home, but this
"blank" task has lots of nil properties.  Could that be related to the
problem?
>


Sent via Deja.com
http://www.deja.com/

Blair,

Here is some additional information:

> Can you explain what you mean by "crash"? Does Dolphin actually terminate
> unexpectedly, or do you get a walkback? Does it "crash" only when you
press
> Ctrl+D (display it) or also when you press Ctrl+E (evaluate it)?
>
I tried this again tonight with Ctrl-E, and Dolphin survived fine.  Then,
unfortunately I tried inspecting the result.  Of course, then the crash
occurred.  So you appear to be right; it's something about trying to print
that resulting collection.

The actual dialog box I get from Windows is:
"Dolphin has caused an error in
DOLPHINVM004.DLL
Dolphin will now close."

> If you get a walkback can you copy (using the Copy button on the walkback
> dialog) and paste it here. If you get an actual crash we can tell a lot
more
> if some post-mortem details are provided, specifically a "Crash Dump"
> (http://www.object-arts.com/wiki/html/Dolphin/CrashDump.htm#dumpFile).
>
If you would really like more information using this technique, I can do it.
Right now, since I have a workaround (don't do things that might cause
printing that collection), I can proceed ok.  I kind of feel like the man
who went to a doctor and said, "Doctor, my leg hurts whenever I walk on it."
And the doctor replies, "So don't walk on it!"

In any case, thanks for the assistance.  The best thing about Dolphin is
this fabulous newsgroup and the open, friendly support from Object Arts.
That really sets your product apart.  I hope Dolphin doesn't grow too big to
have this kind of support.  I've followed the Python newsgroup for years,
and the open, friendly attitude of everyone here reminds me of the Python
zealots.  I think that attitude definitely helps a language thrive (and in
your case should translate to sales).

John

You wrote in message
news:Fo3i6.1256$[hidden email]...
>
> Here is some additional information:
>
> > Can you explain what you mean by "crash"? Does Dolphin actually
terminate
> > unexpectedly, or do you get a walkback? Does it "crash" only when you
> press
> > Ctrl+D (display it) or also when you press Ctrl+E (evaluate it)?
> >
> I tried this again tonight with Ctrl-E, and Dolphin survived fine.  Then,
> unfortunately I tried inspecting the result.  Of course, then the crash
> occurred.  So you appear to be right; it's something about trying to print
> that resulting collection.

Do you still get the crash if you make the #queryInterface: change?

Like I say, I don't have MS Project so I can't be sure, but if the
#queryInterface: change fixes things, then the problem would appear to be
that the type library is telling porkies and that the property is returned
as some other dispinterface and not MSProjectTasks. One way to determine
what is really being returned is to display the result of an expression such
as:

(theproject getPropertyId: 1) typeInfo printIDL

(assuming theproject has been assigned the active project as in one of your
earlier postings).

> ...
> If you would really like more information using [the crash dump]
technique, I can do it.
> Right now, since I have a workaround (don't do things that might cause
> printing that collection), I can proceed ok.  I kind of feel like the man
> who went to a doctor and said, "Doctor, my leg hurts whenever I walk on
it."
> And the doctor replies, "So don't walk on it!"

If modifying the method to use #queryInterface: fixes the problem, and
allows you to display the collection, then the crash dump will not be
necessary. If it doesn't, then I would like to see the crash dump if you
have time to locate it and send the relevant part of it, since that may help
us to improve the quality of the product.

>
> In any case, thanks for the assistance.  The best thing about Dolphin is
> this fabulous newsgroup and the open, friendly support from Object Arts.
> That really sets your product apart.  ...

You're welcome, and thanks for the feedback.

Regards

Blair