A request to support calculations

Hi Sergey,

I have a number of components that I use that provide the older style .TAG or .TAGVariant properties or object variables for user storage .. These are user defined variables that store a reference to an object.

I'm requesting that the Task object include a user defined object variable where I can store a reference to a Task calculation object. I don't see a need for this in any of the other objects (this is due to the various navigation paths that need to be traversed to do the calculations).

(or if there already is an object variable that I can use ... please let me know).

I expect that many of these calculations will actually be part of the task object - (eventually). I want to keep a lightly coupled solution rather than too much integration.

If this will not be possible, I'll look at wrapping the functions around the current task object (not my preference at this point).

Thanks in advance for your consideration!!

Regards, Bruce

Hi Bruce,


We can add the object, but would you like to store the data by some way? Like XML serialization support or something else?

I think we have to discuss it before we will start the implementation. I can consider the property as helpful only if we will store by some way. And of course we have to have some it’s common implementation. Other way you can just implement a task wrapper class with public Task property and public TAG property.

Hi Sergey,

Just to be clear what I have started!! I have created a TaskCalculation class that acts like a task wrapper class. Each Task will have a separate TaskCalculation object created when needed for calculations.

I fully expect that many of these calculations will end up in the Aspose.Tasks.Task object. If I am very fortunate, this taskcalculation class will disappear as all calculations will be in Aspose.Tasks as they currently are in MS Project Automation. This is why I'm avoiding a direct wrapper around the aspose.tasks.task object.

So all I really need is a place to put an object reference at run time to connect to an object. If you created a property (read/write) called it TaskCalc with an object data type and just made sure it was set to nothing when the object is destroyed ... and not saved as XML. I will be happy.

I have used this approach with a Diagram Component to handle complex diagram AutoLayout calculations (which require a lot of recursive algorithms). This component provided a .TAG property.(NOTE: I also use 'raiseevent' in places where additional processing may be required. This is another way to provide a tailored object without a wrapper).

If you don't feel this will add value (even in the short term), I'll find another way. Though this would help me, if it is easy to add ... great!! if it is difficult to add ... don't take time away from TimePhasedData.

Regards, Bruce

Hi Bruce,


We are discussing possible solutions now in our team. We think we can add the Tag property and two events like XmlTagReading and XmlTagWriting, so any custom data could be used and saved in XML if the corresponding handlers are defined or just used if no handlers are defined.

Let us know if it works for you.

Hi Sergey,

I really appreciate the thought you are putting into this ... However, in my particular case, I cannot think of what I would save or load for the calculations.. so the events are not critical.

I should probably check one other area ... I am breaking down the calculations into small chunks related to a specific task. Are you envisioning adding some Calc methods or properties to a task object? or are you expecting to handle the recalculation at the 'project' object level?

FYI.. I'm starting to look at the calc around adding a TaskLink. In this case, if a FS link is added ... the only two objects available are the 'pred' and 'succ' tasks... MS Project recalculates transparently when the link is added or deleted. So I'm looking at the methods and prop to move the succ task ... if necessary recognising that the entire plan needs to be recalculated at some point. So, I'm looking at the methods and properties that would help recalculate dates and other info (not timephased data).

Hope this clarifies the need..

Regards, Bruce

Hi Bruce,


I think that the recalculation must work automatically like it does in MS Project when auto project recalculation is selected. For example, when you change project’s Status Date all earned values have to be recalculated, when you add a child to a task the parent task has to be recalculated and so on…

Hi Sergey,

Here is an example of the different styles of calculations ...

I did not realise that .CalcTaskIDs updated the OutlineLevel. I already calculate this too. The documentation does not say this..

I would have expected the task object to have a recursive method .CalcOutlineLevel or something a bit more usable to handle WBS codes too.

So ... if a task needs to be moved to a new location, using a task method such as .CalcOutlineLevel ... is only needed to be run from the parent.

Or these could be transparent calculations (same for updating the Parent Task).

As part of your design, are you thinking of adding methods to the task object? (or are there restrictions to doing this?)

Regards, Bruce

Hi Sergey,

'recalculation must work automatically'

This is a nice goal; however, today, each calculation needs to be 100% correct. Today, we have very few automatic calculations ... I would appreciate having the calcuations explicit methods to be able to selectively turn them on rather than have too many things being done behind the scenes (and then realise the algorithms are slightly different).

IMHO

Regards, Bruce

Hi Bruce,


Yes I have to agree that not all automatic calculations are clear and look correct. But at first we have to repeat the way MS Project works. You can recalculate just one task for example but the task can have some dependencies and the task’s changes can impact on other tasks as well.

Hi Sergey,

Thanks for your response ... I must say that I'm a bit worried and discouraged when I read it.

I don't seem to really understand what you mean by 'repeat the way MS Project works'. I know the MS Project Automation model ... and where the calculations (or even basic functions) are not being done in Aspose.Tasks and how much time I've spent in 'discovery' mode.

In a sense, I think there is a design tradeoff... one that provides hidden calculations like MS Project or explicit calculations and a good extensible object model that can be used by developers. I'm not actually sure what the design strategy is??? There appear to be many right answers to get to the same end point.

I'd be interested to know how others feel about these comments ... I know that you have a number of other users with different requirements. My feedback is IMHO.

So... will you add the object variable to the task object.. If yes, I'm ready to use it whenever it is added. If not, let me know and I'll find an alternative approach.

Regards, Bruce

Hi Bruce,


I have created a new issue ‘Add public Tag property for Task class as a custom information storage.’ with ID = 19069 and linked to this forum thread. We are going to provide a way to save/read the information from XML files as well.

Thank you a lot for your cooperation.

Hi Sergey,

Many thanks ... for the TAG..

Can you clarify what you mean by 'save/read the information from XML files as well'.

Do you mean the MS Project XML file? or some specified xml file.

There are some capabilities that I think I mentioned before that I could find useful...

1) An event that makes the loaded MS Project XML DOM available before you load it into the Project structures.

2) An event that makes the Ready to save MS Project XML DOM available prior to saving the file.

or

1) Providing a DOM to the Project Reader (where I might have applied a transformation or completed validation) before Aspose.Tasks loads the XML

2) Providing a DOM rather than saving the file ... where I can provide validation or checks after the save has been completed and then save the file whereever I want (or encrypt the data) or include it with my application.

I can envision other useful points where events might be useful to help with calculations or handle types of errors.

I believe there are some really useful additions that could be made ... these really need some thought and design.

I'm also looking forward to seeing how you are supporting TimephasedData.. I'll start testing any version you provide.

Regards, Bruce

The issues you have found earlier (filed as 19324) have been fixed in this update.


This message was posted using Notification2Forum from Downloads module by aspose.notifier.