Re: PROJ 2000: Inserted Projects not found

From: Ronald Dodge (ronald.dodge_at_cfgraphics.com)
Date: 02/04/05 

Date: Fri, 4 Feb 2005 08:36:14 -0500

Okay, here's the scenerio that I have ran into

A project gets linked to the mini schedule

At some point of time in the future, the pathname to the project has been
changed, which can happen cause of an Unknown customer project ID number
initially set to TBD, but then later changed to the ID number within the
pathname when it becomes known, as customer service and others uses the
search feature within Windows Explorer to search for various projects based
on either our number or the customer's project number. Yes, some users only
have customer project ID number to go by, not the number that we have within
our own company initially speaking, such as Sales people.

Once this pathname has been changed, the next time the mini schedule is
openned and attempts to open the project file, it doesn't locate the file,
which then a message box pops up when openned manually.

Since it can't locate the file, within the window that shows all of the
tasks, you will only see the pathname to the inserted project that the task
has for the project, which via code, you can see this pathname in the
property of MSProj.Subprojects(I).Path where I is the index number of the
inserted project

Click on this task that has the pathname in it.

At the top, click on the "Show" button, then click on "All Subtasks"

This is when the dialog box comes up when done manually. This is the same
dialog box that pops up when ran through code.

As I initially said, this is both, a training issue, and an issue I still
need to address via code as this CPS schedule impacts quite a few people. I
don't even know how many to really guess other than I know it's into the 3
digits. I initially started to deal with this issue from the training side
as I had put together some things, and it looks like it is working out, but
only time will tell. However, if someone makes a mistake, I still need to
have the code side to be able to skip over it.

To tell you the truth, I haven't found the SendKeys to be too reliable
either as the timing part is just too inconsistent. That's another reason
why I don't like to leave it up to just chance. Even with Janet's
suggestion of using a message box to clear out the sendkeys buffer, what
happens if the sendkeys buffer is already empty when the message box comes
up?

The only thing I can think of doing though is setting up a variable such as
a boolean variable, and then use the Application.Ontime function to call on
another procedure within the same module so much time later (I.e. 3 seconds
later), and then set a cancellation time, so if the procedure can't be
called on within so much time (I.e. within 2 seconds of the time it was
called on), cancel it's call so as it doesn't get called on. The called on
procedure (if began within the allotted time period) would then check the
boolean variable to see if the main procedure has continued (False) or been
Halted (True), and if it's been halted, then execute the SendKeys statement. 

-- 
Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000
"Rod Gill" <rod AT project-systems DOT co DOT nz> wrote in message
news:O1MhS4kCFHA.1292@TK2MSFTNGP10.phx.gbl...
> The key will only get used if a program prompts for a user input at which
> time queued keys get used.
>
> But maybe we are looking at the wrong problem. Why are you getting a
dialog
> for the OutlineShowAllTasks command?
>
> -- 
>
> Rod Gill
> Project MVP
>
>
> "Ronald Dodge" <ronald.dodge@cfgraphics.com> wrote in message
> news:u8oxBtjCFHA.464@TK2MSFTNGP15.phx.gbl...
> > So are you saying that using the sequence below would still get rid of
the
> > dialog box?
> >
> > VBA.SendKeys "{ESC}", False
> > MSProj.OutlineShowAllTasks
> >
> > Cause if I have it setup as:
> >
> > MSProj.OutlineShowAllTasks
> > VBA.Sendkeys "{ESC}", False
> >
> > The SendKeys statement in the latter case would not get executed, but in
> > the
> > earlier case, there's the chance it could be executed too quickly before
> > the
> > dialog box pops up.
> >
> > -- 
> > Ronald R. Dodge, Jr.
> > Production Statistician
> > Master MOUS 2000
> >
> > "Rod Gill" <rod AT project-systems DOT co DOT nz> wrote in message
> > news:eBObsbjCFHA.2876@TK2MSFTNGP12.phx.gbl...
> >> I think Jack has correctly explained what you need to do, so maybe if I
> > put
> >> into other words what he has already said it might help?.
> >>
> >> If you execute a VBA command to control Project that might show a
dialog
> > box
> >> you need to use sendkeys FIRST to send an {ESC} key. Escape is the
safest
> >> key to use.
> >>
> >> Look also at the DisplayAlerts=False method in Help and use that as
well.
> >> Don't forget to use DisplayAlerts=True at the end of the macro as well.
> >>
> >> If you are only reading data, then try oledb to read data directly from
> > .mpp
> >> files: no dialogs and much faster. You only need to open Project files
> > using
> >> automation if you want to write data to a file or force recalculation
> >> (for
> >> example after updating data in a database where your projects are
stored.
> >>
> >> -- 
> >>
> >> Rod Gill
> >> Project MVP
> >>
> >>
> >> "Ronald Dodge" <ronald.dodge@cfgraphics.com> wrote in message
> >> news:OhSGk3iCFHA.2180@TK2MSFTNGP10.phx.gbl...
> >> > Oh, in regards to assuming that the dialog box appears, what if it
> >> > doesn't?
> >> > The computer has a tendency of storing the keystrokes in the buffer
> > until
> >> > there is time for them to be executed, which if it holds off until
the
> >> > code
> >> > switches back over to Excel (where the code is actually being
executed
> >> > from
> >> > with data going from MS Project to Excel cause MS Project can only
> > handle
> >> > so
> >> > many projects within 1 mini schedule before it gets to be eating up
too
> >> > much
> >> > RAM usage), and then the keystrokes actually takes place.  This can
> >> > mess
> >> > things up.
> >> >
> >> > -- 
> >> > Ronald R. Dodge, Jr.
> >> > Production Statistician
> >> > Master MOUS 2000
> >> >
> >> > "JackD" <momokuri@gmail> wrote in message
> >> > news:OrgHNdhCFHA.444@TK2MSFTNGP15.phx.gbl...
> >> >>
> >> >> "Ronald Dodge" <ronald.dodge@cfgraphics.com> wrote in message
> >> >> news:Osuxt9gCFHA.3740@TK2MSFTNGP09.phx.gbl...
> >> >> > But 2 issues with the suggestion.  As I pointed to with the first
> >> >> > issue,
> >> >> >
> >> >> > Issue 1: When the macro halts, it's not even going to go to the
next
> >> > line,
> >> >> > even with the statement of:
> >> >>
> >> >> The macro is halting because a dialog box pops up right?
> >> >> So you have to make the dialog box go away.
> >> >>
> >> >> > On Error Resume Next
> >> >> >
> >> >> > Issue 2:  Even assuming we get around the first issue, how will
the
> >> >> program
> >> >> > know if the dialog box has popped up or not?
> >> >>
> >> >> You don't. So just assume it has popped up and send the keys to get
> >> >> rid
> >> >> of
> >> >> it. You would just need to verify that what you send didn't change
any
> > of
> >> >> the data in your project. It is likely that sending the enter or
> >> >> escape
> >> > key
> >> >> is harmless.
> >> >>
> >> >>
> >> >> >
> >> >> > Think about it, it's a lot like the same type of behavior as what
> >> > happens
> >> >> > when you put in an InputBox function within the code.  When the
> >> >> > input
> >> > box
> >> >> > pops up, the code pauses until the user responds.  Only difference
> >> >> > is
> >> > with
> >> >> > the InputBox function, you know it's going to happen all the time
> >> >> > versus
> >> >> > with this dialog box, without the code knowing if the inserted
> > project
> >> > is
> >> >> > open or not, it's not going to know if the dialog box has loaded
or
> >> >> > not.
> >> >>
> >> >> Assume it does. In project sometimes you just have to do things
> >> >> without
> >> >> knowing what the current condition is. Same with some of the write
> >> >> only
> >> >> properties. You can't know what they are in advance, so simply set
> >> >> them
> >> >> to
> >> >> what you want.
> >> >> >
> >> >> > I did think about the SendKeys method/statement (yes there's a
> >> >> > method
> >> > and
> >> >> a
> >> >> > statement with a slight difference between the 2), but cause of
how
> > VBA
> >> >> > works, that's what had me even question it.  I do have macros that
> > uses
> >> >> the
> >> >> > SendKeys method/statement as there is no other way to get around
it,
> >> >> > but
> >> >> in
> >> >> > those cases, it's all predetermined and it's dealing with a third
> > party
> >> >> > program which can't be manipulated even through OLE or DDE.  The
> >> >> > only
> > 3
> >> >> > commands that works with such programs are "Shell" function (to
open
> >> >> > the
> >> >> > program), "AppActivate" statement (to activate the window) and
> >> > "SendKeys"
> >> >> > statement.(to indirectly manipulate the program).  However, for
this
> > to
> >> >> > work, the behavior of the third party program must be predictable
> >> >> > within
> >> >> the
> >> >> > limitations that it has to work with.
> >> >>
> >> >> I'm not sure that third party programs have anything to do with
this.
> >> >>
> >> >> -Jack
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>