I’d like each node in a subgraph to be notified whenever it’s relativeposition to the subgraph has changed. This can occur when the node moves (I already handle this case correctly), the subgraph is resized manually (A), or automatically by moving another node in the subgraph (B).
I tried to override the following member functions of the subgraph :
DoResize : Works only for A
OnBoundsChanged : Works only for B
Bounds.set : Works for A and B, but much to many notifications. I’d like to be notified when the move is finished, not while it is happening.
Do you have any suggestion ?
Should I change the tools ?
Instead of overriding those methods, why not implement GoView.ObjectResized and GoView.SelectionMoved event handlers?
You didn’t say how you implemented the case when the node moves, but perhaps you don’t need that code either.
Implementing GoView event handlers means that you won’t get events when you make programmatic changes to a node or subgraph (you’ll only get events when the user does something), but I assume you can handle that explicitly in your code after you make those programmatic changes.
Instead of overriding those methods, why not implement GoView.ObjectResized and GoView.SelectionMoved event handlers?[/quote]
Ok, I’ll look at those functions.
[QUOTE=walter]
You didn't say how you implemented the case when the node moves, but perhaps you don't need that code either.
[/quote]
I had to specialize the GoToolDragging for other reasons (dragging onto a subgraph...) so I put this code there.
[QUOTE=walter]
Implementing GoView event handlers means that you won't get events when you make programmatic changes to a node or subgraph (you'll only get events when the user does something), but I assume you can handle that explicitly in your code after you make those programmatic changes.
[/quote]
That’s quite fine with me.
Between overiding object functions, using GoView event handlers, overriding tools behaviour, there are many levels of customization in GoDiagram. How can you always find the good one ? Are there any guidelines ?
Well, most GoView events happen because the user did something with the mouse. Obviously there are the mouse events such as GoView.ObjectDoubleClicked or BackgroundSingleClicked. (Note that many of the Control mouse events aren’t likely to be useful for diagrams, since they don’t understand that there are different parts to the client area of a GoView.) But there are higher-level events such as SelectionDeleting, ExternalObjectsDropped, and LinkCreated that correspond to common operations that are implemented by GoView and its standard GoTools.
Many GoView events are raised by the tools – for example, GoToolDragging.DoMouseUp raises the GoView.SelectionMoved and SelectionCopied events. So if you have overridden GoToolDragging.DoDragging to execute something when the state is GoInputState.Finish, that is called immediately before those GoView events are raised.
GoDocument.Changed events happen because of a change to a GoObject, a GoLayer, or the GoDocument itself. Although most changes happen because of a GoView event, such changes can also happen independent of any direct GoView event, typically because your code does something. (There might not even be any GoView displaying a GoDocument!) GoDocument.Changed event handlers (or an override of GoDocument.OnChanged) are useful when you want to make sure some side-effect happens or some invariant is maintained, particularly as your application gets more complicated and there are more sections of code that need to interact.
Many of the GoObject.On… methods correspond directly to GoView events, e.g. GoObject.OnDoubleClick, or to methods of particular tools, e.g. DoResize is called by GoToolResizing.DoResizing. You’ll note that those methods take a GoView as an argument, so that you can take the state of the view, including any input state, into account.
Why can you put double-click event handling code in both the GoView and on a particular GoObject class? Depending on how you organize your application, it might be more convenient to put it one place or the other.
Visual Studio makes it easy to define event handlers for GoViews. It is also handy to be able to put it on the GoView when you want the code to handle double-clicks for multiple different kinds of classes.
On the other hand, if you have several or many different kinds of classes, it would be cleaner to put the relevant code with the particular object class, rather than having to put switches in the GoView event handlers. That helps keep the Form class uncluttered with code that is ought to be specific to the particular object classes.
That’s been our experience building diagram applications far more complex than any of the samples. For example: http://www.nwoods.com/sanscript