none
Where does "Project.ActualWork" come from? And why doesn't "Project.Work" give the expected answer? RRS feed

  • Question

  • Hi folks,

    I haven't done much with Project in VBA, but I've been using VBA for a very long time in the other Office apps (even back to the WordBasic days).  I don't recall running into this situation before (or maybe I just forgot). In Project Pro 2010,  if I start typing something like  "n = oProject.a", where oProject was previously defined with "Dim oProject as Project" ", I get the completion pop-up list of members for the Project object.  There is no "ActualWork" or "Work" member in the popup.  Neither do these members appear in the main application Project item in the Object Browser.

    However, when I debug a VBA routine where oProject is set to ActiveProject and look at the local window for oProject while paused, there are both ActualWork and Work members in the oProject list.  I also find I can debug.print both members.  However, while oProject.ActualWork gives the same answer as oProject's ProjectSummaryTask's object's "ActualWork" member, oProject.Work returns (for the project in question) "True" instead of what the ProjectSummaryTask's "Work" member returns.

    Aside - Even though ActualWork doesn't appear in the member pop-up list for a Project object while typing in VBE, if I type "oProject.actualwork", VBE will still capitalize ActualWork when I complete the line.  Huh?

    So, where are Project.ActualWork and Project.Work coming from, what do they mean, and why doesn't Project.Work return a value similar in type to what Project.ActualWork is returning?  Is this some kind of runtime internal inheritance thing between the Project and Task classes?

    Thanks!

    Wednesday, April 24, 2013 3:55 PM

Answers

  • Work and actual work used to belong to Project Object in the first release of Project VBA. This wasn't logical, and as Work and Actual work were already under ProjectSummaryTask, they hid Work and Actualwork in the Project Object, but left it for backwards compatibility.

    Something has changed or broken the .Work. It won't get fixed as the solution is to always use ProjectSummaryTask. So this is just a bit of history for you!


    Rod Gill

    The one and only Project VBA Book

    Rod Gill Project Management

    • Marked as answer by linearprism Friday, April 26, 2013 6:16 PM
    Thursday, April 25, 2013 8:42 PM
    Moderator

All replies

  • The Project Object model resembles what you see and use in Project visually. So, Work and Actual Work for the entire project belong to the Project Summary task (Row zero).

    Try ActiveProject.ProjectSummaryTask.Work


    Rod Gill

    The one and only Project VBA Book

    Rod Gill Project Management

    Wednesday, April 24, 2013 9:36 PM
    Moderator
  • Thanks, Rod.  I found the ProjectSummaryTask members after the dynamically appearing Project.ActualWork and Project.Work members didn't return consistent types.  This is actually more of a Project object model / VBA quirk question.  I'm trying to understand how these members show up on the Project object at VBE line-parse time and runtime, but don't appear in the VBE completion member pop-up list, the object browser member list or the online help Project member lists.  Also, why, if Project.ActualWork returns a result consistent with ProjectSummaryTask.ActualWork, Project.Work returns what appears to be a boolean instead of what you get from ProjectSummaryTask.Work.

    In other words, where are the Project object ActualWork and Work members coming from if they aren't listed in any of the definitions as members of the Project object, and why does Project.Work return "True" instead of a numeric like Project.ActualWork?

    Thanks again.

    Wednesday, April 24, 2013 10:04 PM
  • Work and actual work used to belong to Project Object in the first release of Project VBA. This wasn't logical, and as Work and Actual work were already under ProjectSummaryTask, they hid Work and Actualwork in the Project Object, but left it for backwards compatibility.

    Something has changed or broken the .Work. It won't get fixed as the solution is to always use ProjectSummaryTask. So this is just a bit of history for you!


    Rod Gill

    The one and only Project VBA Book

    Rod Gill Project Management

    • Marked as answer by linearprism Friday, April 26, 2013 6:16 PM
    Thursday, April 25, 2013 8:42 PM
    Moderator
  • Thanks, Rod.  That's what I was trying to understand.

    Friday, April 26, 2013 6:17 PM