Re: PROJ 2000: Inserted Projects not found

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Jan De Messemaeker (jandemes)
Date: 02/04/05 

Date: Fri, 4 Feb 2005 08:44:47 +0100

Hi,

Before leaving the program you loop through a simple message box to clear
the sendkeys buffer. 

--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/index.htm
32-495-300 620
"Ronald Dodge" <ronald.dodge@cfgraphics.com> schreef in bericht
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
> >
> >
>
>