Hi,
I am using View.Document.TopLeft and View.Document.Size properties to set the size of the document inorder to remove extra white spaces that may exist around (and as such the scroll bars might also disappear).
However, if the user drags a GoObject around such that scroll bars might appear (due to auto scrolling), the document size resets back to its previous values (Apparently because ComputeDocBounds etc calls were made, which recalculated the bounds).
Can you please let me know how I should set the document size and top left so that this behavior does not occur.
I dont want to override ComputeDocBounds since I am OK with default implementation, I only want to set the proper document top left and size when the user selects to remove extra white space via a menu.
Thanks,
Rafique
Would setting GoDocument.FixedSize true satisfy your requirements?
Well actually I need the document to properly expand as objects are added and moved. So I guess setting the GoDocument.FixedSize property wouldnt help my cause.
Thanks,
Rafique
When FixedSize is false, as it normally is, the document’s extent will automatically grow to include any added or moved objects. You say you want that behavior.
But that may well result in the need for scroll bars, assuming your GoView hasn’t gotten bigger or its DocScale hasn’t gotten smaller. Are you trying to control whether scroll bars appear at all? Perhaps setting GoView.ShowHorizontalScrollBar and .ShowVerticalScrollBar would be useful.
Or are you trying to prevent people from dragging objects to the top and left? If so, then setting GoView.ShowsNegativeCoordinates to false might be useful, although it doesn’t actually prevent objects from going to negative coordinates.
I am just trying to set the document size and top left properties. But when the user makes some changes on the view such as moving goobjects around, the values that I set are getting overriden.
For eg suppose that there is one GoObject in the view at location 1000,1000 and size 50,50.
And View.Document.TopLeft is 0,0 and View.Document.Size is 1500, 1500
Thus there is ample space between the left edge of the document and the GoObject. I set the View.Document.TopLeft to 900, 900 so as to minimize the space between the left edge of the document and the GoObject and the View.Document.Size to 600,600. This should shrink the document size.
This works and the document gives the “illusion” of being shrunk. However, when I move the GoObject around especially towards the edge of the client area, the empty space that had been removed due to change in View.Document.TopLeft to 900,900 from 0,0 gets reset and the document becomes big again.
Rafique
That’s odd. I’m not getting that behavior when I try it.
If you set a breakpoint on the GoDocument.TopLeft setter, can you tell why it gets called with a value of (0,0)?
This is probably unrelated, but in version 2.5 we have changed the behavior of GoView.RescaleToFit not to always include the origin (0, 0). However, that method does not modify the document’s TopLeft or Size properties, just the view’s DocPosition and DocScale properties.
After setting the topleft and size properties if I drag a node (which has a link connected to it) around,
TopLeft property gets reset to 0,0 in
GoDocument’s UpdateDocumentBounds(GoObject obj) when the obj is a LabeledLink
At that time, does the GoLabeledLink.Bounds value include (0,0)? If so, that would explain the behavior you see.
Did you extend that GoLabeledLink by adding additional child objects that are not positioned to be along the link by an override of LayoutChildren?
Yes the bounds of the link returns 0,0 for location ie top/left.
I am using the MidLabel property of the link to set a label. The positon of the label does not coinicide with 0,0.
I also add child object to link that can be dragged around but this behavior occurs even when I do not add these draggble child objects.
Well, the Bounds of a GoLabeledLink is computed to just be the union of the Bounds of all its children. Check the link’s Count of children, to see if it’s the number you would expect. One for the RealLink, one for the MidLabel, and maybe one more if you had added the draggable child object or whatever.
Maybe you accidentally added a child object when constructing or copying the link.
Yes you are right. I had added a few invisible child objects which arent positioned until the user chooses to.
Looks like I will have to override Bounds to return the union of all the visible children.
Thanks,
Rafique
Instead of overriding GoObject.ComputeBounds, why not override LayoutChildren to always move those invisible objects to some safe place, such as the same position as the MidLabel, or such as centered at the mid-label point?
Yes you are right, I guess I can try this too.
Thanks,
Rafique