Hello,
I have three questions about constraints in combination with parent/child relationships. Here is the situation:
Add a task to an empty gantt view. Ensure the constraint is set to 'Start No Earlier Than' and set the constraint date somewhere past the start date of the project. Add a sub-task. Notice that the constraint of the first task task changes to 'As Soon As Possible'. It's possible that this is by design, but I can't find any documentation on that.
Question 1: Is it possible to not have this behaviour (at least when I'm adding the tasks by code)? I retrieve tasks from a database, so constraints should not automatically change when I add them to the gantt view. A work around is to store the constraint of the first task, then add the child, and then restore the constraint of the first task. But this is not a nice solution.
The situation for the second question:
Set the constraint of the first task again to 'Start No Earlier Than' and the constraint date somewhere past the start date of the project. Now add another sub-task a child of the second task. The constraint of the first task doesn't change, but the constraint of the second task does (like in my first question). Now the third task starts at the start date of the project, although both that task and it's grandparent has a constraint set to a date in the future.
Question 2: Why is the start date not the same as the constraint date? When I change the constraint date of the third task manually, the start date does follow it. So I think this might be a bug.
Last situation:
Set the constraint of the third task to 'As Soon As Possible'. The constraint date of the grand parent is not followed.
Question 3: Why does the grand child ignore that constraint? How can I make sure the grandchild doesn't start before the grandparent's constraint? Note that it works fine if the direct parent has a constraint set.
I'm using version 10.3.20103.2145.
Thank you for contacting Infragistics.
Please note that the version of our controls that you are using is no longer supported or maintained. If you'll upgrade to the latest version, you'll see that the behavior you described in numbers 2 and 3 no longer occurs. The behavior you described in number 1 still occurs, but that's the expected behavior. If you'd like to see different behavior in our controls, feel free to submit your ideas at http://ideas.infragistics.com.
Yes, we would like to upgrade, but that requires our clients to update to CLR 4.0. We are in the process of finding out if that's possible in the near feature.
Could you tell me in which version the last two problems are solved? Because I tried this out with the demo project manager, which is v14.1, and I still have the same problems.
Thank you for your response.
In order to change which account a product key is registered to, you need to send an email to registrations@infragistics.com with the product key, the old username and the new username.
Please let me know if you have any other questions about this.
Hi, TorX here (I had to switch accounts because all our keys are registered to our IT account, and I can't seem to register them to my own account).
In your first reply, you already said that the behavior is by design. Furthermore I suggested the same workaround. Thanks for the support though. :)
I hope you are able to fix the issues described in questions 2 and 3.
Our developers have reviewed the first issue and determined that the UltraGanttView is behaving as designed. They suggest setting the parent task's Constraint to StartNoEarlierThan after adding the child task.
As it turns out, I misunderstood what you had stated in your original post. After reading it again more closely, I was able to reproduce the issues. It turns out there are two issues you have described. The first is the changing of the constraint of a parent task when a child task is added. The second is a child task ignoring its parent's constraint when the child's constraint is set to AsSoonAsPossible.
I have reported this issues to our developers. I have created support case CAS-140700-R0V1V8 to track the first issue and support case CAS-140800-D9J1K2 to track the second issue.