Re: PROJ 2000: Inserted Projects not found

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

Date: Fri, 4 Feb 2005 15:16:24 -0500

I have tried it both ways, and neither way worked to get rid of the dialog
box.

Any other ideas? 

-- 
Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000
"Ronald Dodge" <ronald.dodge@cfgraphics.com> wrote in message
news:OrSmC6rCFHA.960@TK2MSFTNGP09.phx.gbl...
> 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
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
> >
> >
>
>
Loading