We have a quite strange problem that seems to be related to GoDiagram, but I do not really have any idea what could be the reason of it. Anyway, I’ll try to explain it:
We programmatically create a node of a type derived from GoSubgraph (it is created collapsed). Usually, it works correctly, the node appears on the view. But sometimes, it does not appear immediately.
When that happens, selecting with the GoToolRubberBanding some nodes arround the position where the newly created node should be, makes it appear (only partially visible, if the GoToolRubberBanding only covered a portion of the yet to be born node), but the node itself is not selected.
I tried to add several InvalidateViews after the node creation, but it didn’t change anything.
I finally managed to have some more information on what condition triggered this strange behaviour: It depends (probably among other unknown factors) on the GoView.DocPosition of the document. For instance, it works correctly for a position of (-20;55), incorrectly from (-20;56) to (-20,64), then correctly again. I give those figures in case they may remind something to someone.
Does anybody have any inspiration ? I’m really stuck with this one.
That’s pretty odd. GoDiagram certainly doesn’t do anything special at any particular positions. (Although I should check to see if there is any code that behaves differently if the user == “Gathar”.)
Programmatically, can you look at the Bounds of your subgraph node and see if they are reasonable? Perhaps you just need to look at it with the debugger. Looking at the value of GoSubGraph.ComputeBorder() might be instructive too.
I looked at the bounds by drawing them (I overloaded paint on the subgraph, maybe I can send a screenshot tomorrow). They are quite reasonable.
I’ve also drawn the bounds of the document. They look reasonable too. If I drop the node outside of the current document bounds, those are correctly updated (which implied the node bounds are correct), even though the node itself is not drawn (paint is not called).
If you have “Gathar” in your source code, please let me know. This is probably in a file full of bugs ;)
I was going to ask next if Paint is called at all in the offending circumstances. Wisely, you anticipated that question. Basically if Paint is being called, but it’s not visible, there might be some other object in front, covering it up with the background color. Not likely.
The only known relevant difference is the Y value for GoView.DocPosition, right?
What happens if, when the subgraph is visible, you scroll the view up and down? Does it disappear and reappear?
If I pan the view to another position, the problem disappears. Then I pan it back close to the original positon, it is here again.
The zoom factor did not seem to have any effect. Changing the X position did not seem to have an effect either. However, I have not tried that many combinations of values for {X, Y, zoom}, I mostly explored the Y dimension.
I send an image from my program. The red rectangle is [GoView.DocumentTopLeft->GoView.DocumentSize]. The external blue rectangle around the nodes (which are actually collapsed subgraphs) are the GoSubGraph.ComputeBorder. The text at the top left is the GoView.DocPosition and the scale.
The partially drawn rectangle is where the new node should be (one can see the doc limit updated correctly), it was drawn when I selected the node just on top of it with the toolRubberBanding.
This is certainly a most unusual problem. Thanks for taking the trouble to debug this.
I am having a hard time imagining how this could possibly be happening. There are only a few things which prevent an object from having its Paint method being called. GoObject.CanView() needs to be true, and its Bounds and ExpandPaintBounds need to intersect the area being repainted.
Could you change the blue rectangle to be drawn at the GoSubGraph.Bounds? Could you also draw a rectangle at the GoSubGraph.ExpandPaintBounds?
Do you ever have this problem when the subgraphs are expanded?
Do you ever have this problem with non-subgraph nodes?
Do you have any painting-related overrides of any GoView properties or methods? Or of any GoObjects, other than the ones you just added for this debugging exploration?
In our real application, subgraphs are not expanded at this time, so I cannot say. I just tried in the problem configuration, and it worked fine with expanded subgraphs.
Some time ago, I had a similar problem with normal nodes (they are derived from GoGeneralNode). At the time, I did not have the time to investigate it. I cannot reproduce it with the current version, maybe it depends on other magic values to happen ?
The only painting override we use in the real world is on the icons, to change the appearance of the icons by using a color transformation matrix or adding overlay icons. I’ve deactivated it, just to see, the problem was still here.
Well, I’m mystified. We have thousands of customers, and I don’t recall ever hearing about behavior anything like this. (Unless the programmer had somehow messed up the Bounds or ExpandPaintBounds or visiblity, which you have already ruled out in your application. And that’s pretty unusual anyway.)
If you replace your GoSubGraph.CollapsedObject with a simple GoRectangle, does it change anything?
I did as suggested, and replaced my CollapsedObject by : CollapsedObject = new GoRectangle();
And then it worked…
Then I added the following line : CollapsedObject.Size = new SizeF(32, 32);
And it stopped working. Changing the size to (50,50) made it work again with the GoView.DocPosition==(-20,60). Switching this value to (-2,78) (the same offset than the one from (32,32) to (50,50) made the problem reappear.
I understand debugging this problem is not an easy task, since it may be somewhere in our customization of GoDiagram behaviour. Would it be possible to have a relevent excerpt of the painting code, so that I may override in my GoView the painting algorithm and see in debug mode what happens ?
That’s non-trivial code, so it won’t be possible for you to override the behavior.
I'll see if I can figure it out, given what you just described. I think it just has to do with the implementation of GoSubGraph, but that's just speculation on my part.
Just for the record, Walter contacted me directly for a more detailed investigation.
I curently still don’t know exactly what the problem was, but part of it was that we added the subgraph to the graph before initialising it fully, and therefore at the time of addition, it was in a bad position. Exchanging those lines of code made the problem disappear.