HELP!!!! - Newcomer (to Project) needs some programming tips

[B. Chernick]

Ok, I'm going to admit I'm lost. I am unfamiliar with the internals of
Project 2003 and I'm not even sure if I'm using the right terminology.

Big Picture: I was handed legacy VB6 code that instantiates Project 2000,
loads a blank main project, inserts a number of other projects through vb
code, and then does some number crunching. I'm supposed to rewrite it in
VB.Net 2.0 using Project Professional 2003 and SQL Server 2000. To put it
mildly, the legacy code is unstructured, undocumented, virtually untraceable,
probably way too big for the job it does, and the original programmer
disappeared sometime around 2001. Business as usual for me.

I've gotten as far as loading the main blank project from the server but
beyond that I'm lost. My next step will be to try and insert projects but
I'm still looking through the interop structure.

If anyone else has ever done anything like this, or has a favorite example
or tutorial, please share it. (Alternatives would be even better but I
think Project 2003 and the Interop interface are mandatory. I don't think
setting up a project server is an option at this time.) For that matter
would this sort of thing be much easier in Project 2007?

 

[Dean C]

I'm not sure why you are automating inserting projects into a consolidated
schedule when you can insert them one time, linked to the project and save
the consolidated schedule. After that, you just open the consolidated
schedule.

A lot of number crunching can be done using custom fields, but all files
should use the same custom fields.

If you feel that you have to replicate what was done previously, I assume
that you have already viewed the object browser and viewed the Properties
window in the Visual Basic Editor. The easiest way to understand the database
structure of Project is to step into the macro below to the "Next" statement
then look at the locals window. Expand "mytask" and you can go up to the
project (parent) and application levels to see what's under the hood.
Unfortunately, not everything is exposed to VBA and you can only select and
copy one line at a time.

sub ProjectStructure ()
for each mytask in activeproject.tasks
next mytask
end sub

 

[B. Chernick]

Actually I'm not sure either, other than obeying the boss. In fact I'm not
sure I understand parts of your reply. So far as I can comprehend, the
legacy project adds one or more Projects to a base blank project, plugs
dates into them, and then does some sort of recalculate. Haven't got into
that yet, not even sure how much of it is Project and how much is custom
code.

(By the way, I should emphasize there's not going to be any use of VBA.
This is entirely Dot Net programming. Other Dot Net projects may be reusing
parts of this one.)

I think I have at least a rough understanding of Project's internal object
structure (http://msdn2.microsoft.com/en-us/library/aa209914(office.11).aspx)
but what is frustrating me now is that the legacy code muddles the Project
structure with a maze of oddly named wrapper classes that are extremely hard
to trace. I am doubley handicapped by the fact that this involves
manufacturing management, another new area for me, and the legacy code mixes
up the terminology for Project and some of our local manufacturing.

My immediate problem is that the legacy project is apparently using the
<project>.FileOpen command to load all the projects but when I try the same
in my prototype I wind up with separate projects, not a 'consolidated' one,
if that's the right term.

I suppose I should also confess that I went strait from Unix to Dot Net with
very little exposure to the COM/ActiveX world.

Thanks!

 

[Rod Gill]

Try:
1) Creating the results needed manually (and document quickest/simplest
method)
2) Get it all working in VBA
3) Copy your VBA code to VB.Net
4) Modify to get it working in VB.Net

You will note that the VBA solution will run faster than .Net (C# or VB) as
it runs within the Project process.
VB will be quicker and easier to develop in and the result equally fast. C#
has no optional parameters and poor Intellisense.

The above process gives you one bite at a time rather than one big goal.
--

Rod Gill
Microsoft MVP for Project

Author of the only book on Project VBA, see:
http://www.projectvbabook.com

 

[B. Chernick]

Honestly I don't even know if what they want can be done in VBA. Granted I
have never done anything in Project, let alone in Project VBA. Can you
create VB forms within Project VBA?

 

[Rod Gill]

You can create basic user forms, but that is all. If you can't re-produce
the basic steps manually, you will never finish! Get the manual steps done,
then automate them in vba then copy and paste to VB. Get them working in VB
then add your user interface.

--

Rod Gill
Microsoft MVP for Project

Author of the only book on Project VBA, see:
http://www.projectvbabook.com

 

[B. Chernick]

Thanks to all of you for your help but I think it's time to terminate this
thread and start a new one. Something's come up.