It does fire, but...

I need the task and the date that was right-clicked on, even when the right-click is on the chart area. Currently, in the event parameters the "Task" is null. I managed to get the time using MouseDown event though:

//Task the_task = this.TestSetsView1.TaskFromPoint(e.Location);//=> NULL???

Infragistics.Win.UltraWinSchedule.TimelineView.TimeSlotUIElement tsui;

DateTime? time = this.TestSetsView1.DateTimeFromPoint(e.Location, out tsui);

But how do I reliably get the corresponding task?(I did consider finding a point in the corresponding task surface in the grid, but that is a very poor way of doing it)

AND

I need the context menu in both areas. That is what the customer wants. For the Grid area the task is sufficient, I will use current date and time.

C'mon, nobody has any better idea?

Hi,
All you need to do to get the Task and the TaskDetails when you right-click on a task is make the task Active before you right click on it. Just click on the Task Bar to make a particular task active if you are using the chart area to show the Context menu. ContextMenuInitializing event returns null for e.Task if there is no active task.

You can set,
AutoDisplayDefaultContextMenu = AutoDisplayDefaultContextMenu.GridAreaOrChartArea
to show ContextMenu in both the GridArea and the ChartArea.

Thanks,
Josheela

Hi

So you would expect the user to first click on a task on the grid view and than right-click the same task on the chart view?
This is an even more unacceptable solution that the one I presented, if this is what you mean.
And I think you do.

So please ask someone with more experience to help, you obviously do not know how to resolve this issue. There is no shame in doing so, I have around 20 years of software dev and I still have to do it from time to time.

And anyway, as far as I can see, this smells like a design problem inside the control itself, because the lines of the grid rows do not extend in the chart area, as I would have expected. Also the corresponding task is not selected automatically before the right click on the chart, which is a serious problem, no matter how you put it. So it seems that someone just glued 2 different controls together instead of redesigning /extending the grid which is what he should have done. 

-Florin

Hello

Getting any kind of information using the  graphical appearance of the control is a very bad way because the control appearance can easily change with control versions. What if, at some point, you decide that 2 or more tasks that have the same chart views should be grouped and the group should have only one line in the chart area, showing some sort of statistic like "20 tasks starting now". You have folding, of course, but that depicts dependencies between tasks, not their start time. So some user may need this type of functionality simply to visualize the total load of some project per day. True, you can make another "totalizer" task programmatically, but what if that should be just a view like the explorer list view, where you have to present the same data in multiple ways(and switch quickly between them)? 

Someone else may also want the grid to the right of the chart, because in his/hers language you write from right to left (I do believe Arabic is like that).

These are just 2 simple example I could think of while writing this, just to illustrate how bad is this practice.

Further more, it breaks any good design pattern imaginable for OOP. It also makes the control behavior inconsistent, since "TaskToolTipDisplaying" event does have the task of the chart tooltip it is belonging to.

-Florin