PROJ 2000: Inserted Projects not found

[Ronald Dodge]

How can I tell if an inserted project is open or not via code without
causing the dialog box to pop up in the event it's not open?

I had to uncheck the following options in the Options>View:

Show external successors
Show external predecessors
Show Links Between Projects dialog on open

But this above only prevents the dialog from popping up for any inserted
project that hasn't been selected to show all subtasks or some other action
that would cause the dialog box to open. The following source code doesn't
help either cause when it's set to *NOTHING*, it causes the dialog box to
pop up as well. I just want to be able to skip over it via code.

ActiveProject.SubProjects(I).SourceProject

TIA

 

[JackD]

I think it was rod who suggested sendkeys. Did you try that?

 

[Jan De Messemaeker]

Hi,

Actually, I did, and I noticed he didn't react to that.
Pity, it is often the last resort... let VBA type enter instead of having
somebody sit on his desk doing only that.
HTH

 

[Ronald Dodge]

But what good would that do when the macro halts at the line:

MSProj.OutlineShowAllTasks

cause the dialog box has openned waiting for a response?

 

[Jan De Messemaeker]

Hi,

It would do the equivalent of an "Enter" keystroke.
Did you try?
If not enter, which keystroke do you need?
The pointis, the woindow will pop up but your pro-gram will rspond, so it
can run unattended.
HTH

 

[Ronald Dodge]

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:

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?

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.

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.

 

[JackD]

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

 

[Ronald Dodge]

But you still didn't answer the question, how is it going to execute the
SendKeys Method/Statement (which ever is used) to clear out the dialog box,
when the macro has been halted.

 

[Ronald Dodge]

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.

 

[Rod Gill]

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.

 

[Ronald Dodge]

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 Dodge]

As I have said before, none of the error stuff prevents the dialog box from
popping up as I have tried them all

On Error Resume Next
MSProj.DisplayAlerts = False
MSProj.Alerts(False) 'Won't allow to do the = False
Application.DisplayAlerts = False (this is the Excel side since this code is
ran from Excel)

I would be interested to see what all would be needed to be able to use the
OLEDB methods with regards to MPP files.

 

[JackD]

See the file titled prjoledb.htm on the project cd or on any pc with project
installed. It explains most of the details.

 

[Rod Gill]

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?

 

[Jan De Messemaeker]

Hi,

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

 

[Ronald Dodge]

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 Dodge]

What if the sendkeys buffer has already been cleared out prior to the macro
executing a message box?

The only thing I can think of doing as I mentioned in response to Rod's
statement is to use:

A boolean variable to determine if the program has been halted or not
Application.Ontime function to call on a procedure, but if not executed
within an allotted time period, the call gets cancelled.
If it has begun it's execution within it's allotted time period, it would
then execute the SendKeys statement.

I would just have to test this to be sure that it works out this way, which
I tend to think it will given the code isn't in break mode and there's
nothing that would be set to cause the macro to be entirely in a stand
still.

 

[Jan De Messemaeker]

Hi Ronald,

I'm not going to take the time to look up exctly how I did it, but it DOES
WORK perfectly.

 

[Ronald Dodge]

I have tried it both your way and my way, neither of which worked in getting
rid of the dialog box.

Any other ideas?

 

[Ronald Dodge]

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

Any other ideas?