Re: PROJ 2000: Inserted Projects not found
From: Rod Gill (rod)
Date: 02/04/05
- Next message: Ronald Dodge: "Re: PROJ 2000: Inserted Projects not found"
- Previous message: Ronald Dodge: "Re: PROJ 2000: Inserted Projects not found"
- In reply to: Ronald Dodge: "Re: PROJ 2000: Inserted Projects not found"
- Next in thread: Ronald Dodge: "Re: PROJ 2000: Inserted Projects not found"
- Reply: Ronald Dodge: "Re: PROJ 2000: Inserted Projects not found"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 5 Feb 2005 09:28:07 +1300
You have another potential problem. The schedule is inserted linked to the
master? If it is and you edit the path in the master but don't also change
the sub-project, it's a matter of luck and time before one or both projects
corrupt. With any linked scenario the ONLY safe way to edit a link is to
have all affected files open, make the changes then save ALL of them. DDE is
the technology used and it's notoriously flaky.
Personally I find that keeping master projects with links and resource pools
is unreliable and limiting. I always create my consolidated projects and
pools using macros, then once all work has been done, I save, unlink and
save again. This leaves any schedule available to be linked to any master or
resource pool anyone needs.
For reporting purposes I recommend creating a consolidated project with no
links and keeping it for a weekly audit trail. This consolidated project is
then freely available for reporting purposes and also consolidates work for
each resource across all inserted projects which is useful.
I think a design review is maybe worthwhile to focus on what is most
important for this system, then look again at how you are doing things
because this problem you are having is not one that has caused issues before
and between us, we've written hundreds of macro driven systems.
--
Rod Gill
Project MVP
"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
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>
- Next message: Ronald Dodge: "Re: PROJ 2000: Inserted Projects not found"
- Previous message: Ronald Dodge: "Re: PROJ 2000: Inserted Projects not found"
- In reply to: Ronald Dodge: "Re: PROJ 2000: Inserted Projects not found"
- Next in thread: Ronald Dodge: "Re: PROJ 2000: Inserted Projects not found"
- Reply: Ronald Dodge: "Re: PROJ 2000: Inserted Projects not found"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|