Hi
I have tried to load some tree structure from a COM interface in WinGanttView and it does go overboard because of too many items apparently. Is there a way to insert parent tasks in collapsed status and then get an event when the user clicks on its expanding "+" button?
I have seen the data binding option but it seems that you have to have all the data already loaded.
Can anyone point me to a SIMPLE example (VS 2013)?
Thank you,
Hi Florin,
The GanttView doesn't have any kind of load-on-demand functionality like the WinGrid does. I suppose it might be possible to implement something like this, but frankly, I think the hardest part would be getting an expansion indicator to show up for a task that has no children. You'd have to use a CreationFilter or something for that and it would be extremely tricky and difficult in my opinion.
In theory, perhaps what you could do is load ONE child task under each parent task which has children. Then load the rest of the children only when the task is expanded. But then there's another problem in that the control doesn't currently expose any event for expanding or collapsing tasks.
Frankly, the GanttView isn't really intended for very large amounts of data. Showing a tremendous amount of data in the control wouldn't be very useful to a user - they wouldn't be able to find anything they needed. So perhaps the best solution would be for you to somehow filter the data down to something more manageable.
But please Submit a Feature Request and perhaps we can add better on-demand support in the future.
It than seems that this control is specially designed to break any possible assumption you can logically make about it. It has a grid and a chart, but you can't get the grid task from the chart, so the chart behaves like it is not really a part of the same control with the grid with a tree. It has a tree, but you can't load as you would in a single grid control, which is a logical conclusion to reach from the first problem.
Now I have to explain to the users that even though they manually built that tree in another web interface they can't manage all the items in the same control...because... there are too many items on it? True, the web interface does not have the Gantt chart to the right of the items , but the items still show up in there when you expand a tree item...
And this was supposed to be implemented in 2 weeks. 2 weeks ago. I was better off building the damn control myself.So I will not submit any feature request. No point in doing so , I will probably get fired from the project anyway.
If I wanted counter-intuitive badly-designed narrow-purpose non-generic controls -> they are already in windows. No need to pay any extra for a supplementary license.
- Florin
How many tasks are we talking about here?
And what kind of issues are you seeing when you load all of them?
Can you send me a sample project demonstrating the issue? If so, perhaps there's something we can do to improve the performance or find a way to make it work.
I can't send you any samples the architecture is not common, the control is being loaded from a COM in .NET(COM exposed assembly), and I would need to replicate the whole thing just to replicate this. the whole .Net COM gets loaded & called by a vbs script which in turn is executed by a web page that belongs to a commercial product that extends this way. There are at least 60 parent tasks with 5 childs each (in average). At some point the control either spews out some exception or simply the control transforms in a red crossed rectangle and the parent dialog gets stuck, I have to kill the parent process and IE to get back on track. But I have a better ideea: I will add all parent tasks, each with its own child named "600 child tasks. Click here to load." and no graph. I hope that having click on grid event is not an assumption that this control will prove wrong.
If this is indeed an issue of loading too much data into the control, then where the data comes from is irrelevant to the problem. We wouldn't need an app with real data loaded from COM in order to reproduce it - or even real data. So perhaps you could somehow export your data into XML or create some fake data that is similar to the real data and try to reproduce the issue that way. If we can see what's happening, we can take a look and try to get it fixed.
60 parents tasks with 5 children each is not an unreasonable amount of data for the control to display. There's no reason why the control should not be able to handle that.
Judging by your description of the issue, it doesn't sound to me like an issue of memory or too much data. The red X indicates that an exception occurred when painting the control. This is one of the most common hallmarks of a threading issue. So my guess is that you are using a background thread to load your data and somewhere along the way, your application is not properly marshaling the data to the UI thread and that's what is causing the crash. Of course, I don't know your application or how the COM, VBScript, or web page fit in here, but the fact that the data is coming from another process seems to lend credence to my theory.