So you are saying that when saving your document, everything is lined up the way you want it, but when you reload, you don’t get precisely the same document?
Those GoView operations do not modify the document. I don't think you need to call UpdateScrollbars in any case. RescaleWithCenter might well change what people see, but that doesn't change the document. Users can always scroll and zoom without any code of yours.
Do you need to save and restore the GoDocument.Bounds?
Yes. I save the document and everything looks fine. All the nodes are perfectly “snapped” in place and the document is centered.
Then I close the document and reopen it. Sometimes everything is fine. Sometimes only a few things are out of place. Sometimes (but rarely) everything is out of place.
I did notice a few things however. To consistantly get everything loading up properly if I perform a "select all" either using Ctrl-A (or simply by highlighting all of the nodes) and then move the whole tree to any location (it doesn't really matter where just as long as I am moving all of the nodes together) and then save the tree, the next time it loads everything seems to look fine. My thinking is that since I have an EventHandler that saves node locations each time they get moved by moving all the nodes together all of the "current/new" coordinates for each node gets saved at once and I don't have to worry about the effect you cautioned me about in your previous post where I might not be saving the node location correctly for newly added nodes and therefore it saves the current "pre-recentered/pre-repositioned/pre-snapped" location of all the nodes which is why things are screwed up when the document is reloaded.
I guess that most of the issues I am having can be attributed to the fact that I am having difficulty trying to obtain the correct X/Y coordinates of just about everything related to GoDiagram. After so much trial and error I really do feel like most of my code related to placement is just guesswork b/c nothing seems to be working consistantly.
Take the GoNode.Position and GoNode.Location properties for example. Both values essentially return the same information. Except when they don't. :) This phenomena seems to occur rarely, some of the time, mostly, always and never.
I am desperately trying to find out the document's current location using a million different approaches. I am also tryingto determine each individual node's location and the GoView and GoDocument's size and center points.
One attempt I made to center my document was to use some code you provided me a few posts ago:
this.view.SheetStyle = GoViewSheetStyle.Sheet;
RectangleF b = this.view.Document.ComputeBounds();
this.view.Document.Bounds = b;
The code above almost worked except it made all of my links and nodes appear to look anemic and improperly scaled. So I tried to modify the code by attempting to calculate the DocExtentCenter using a custom method that I wrote below.
The problem with the code above is that sometimes it works perfectly and sometimes it doesn't!
When stepping through the debugger in Visual Studio I noticed that the reason why it was failing to center the document correctly some of the time was because I would get negative X/Y values returned for fHeight and fWidth. I don't understand how this can be possible when I was under the impression that a document can't be larger than the view that contains it.
As for the UpdateScrollbars, ideally I don't want the scrollbars to show up UNLESS they are needed! This is what I thought "auto" meant. However, they seem to be appearing regardless of whether or not any objects are located out of the default viewable area on the screen. Even calling UpdateScrollbars doesn't really seem to do anything. For the most part it seems like the only way to get rid of them when they aren't necessary is to click on an empty area in the document and use my scrollwheel. Once I do that, the scrollbars disappear.
Not to jump around too much, but getting back on the topic of Location (specifically talking about individual node location in this context), I have noticed that at times when I am debugging I will have a breakpoint set right where a particular newly added node is having it's X/Y coordinate set and I am trying to use the GoDocument.isUnoccupied method. A good example is where I am adding parents to a child that is married to someone already in my tree who's parent's are currently located directly above (96 pixels) both the child and his spouse. The father is 82 pixels to the left of the child and the mother is 82 pixels to the right, 96 pixels above and directly between the child and his spouse. The issue arises when I want to add the spouse's parents. I add them and when the father is about to get placed it checks to see if the X/Y coordinates that it is about to be placed at are occupied by anything. The outcome should be that isUnoccupied returns false, because the mother from the existing set of parents is currently occupying that space. However, what often seems to be the case is that the new father node gets placed directly on top of the mother node from the other set of parents.
The size of a GoView and the size of its GoDocument are completely independent of each other. When the size of the GoDocument cannot fit in the visible area of the GoView at the current GoView.DocScale and with the current GoView.DocPosition, it will show/enable scrollbar(s).
So in addition to setting the GoDocument.Bounds to be the minimum needed to show everything in it (from ComputeBounds), if you want to get rid of the scrollbars you'll need to make sure the GoView.DocPosition is such that everything is in view. You can do that by:
goView1.DocPosition = goView1.Document.TopLeft;
As far as the difference between the GoNode.Position and GoNode.Location properties -- I think that's well documented. The Position is always the top-left corner of the object. The Location might be the same or might be different than the Position, depending on the design of the class.
It seems to me that as long as you aren't trying to grid-align any nodes or do any other adjustments, the nodes in the document that you load ought to be positioned exactly where they had been when you saved the document. Until you get that working correctly, it's understandable why grid alignment might cause some movement in some of the nodes. Perhaps you want to save and restore the GoDocument.Bounds, and maybe even the GoView.DocPosition and the GoView.DocScale, although those are more problematic when the GoView.Size might have changed.
myView.RescaleWithCenter(myView.DocScale, myView.DocExtentCenter);
It makes everything so thin and "brittle" looking?
I know you mentioned something about antialiasing but I noticed that as soon as I click either one of the scrollbars (not even scroll with them -just clicking either one of them) the thin lines return to normal. Why does this happen? How can I get the lines to appear normal from the get-go?
If my Document Bounds are X = 458.0, Y = 234.0 and all I have is 1 node. Why does my node appear at the top left corner of the document and not at those coordinates?
The appearance of anti-aliased lines just depends on the positioning of the line relative to the pixels of the monitor. Changing the GoView.DocPosition fractionally, or changing the GoView.DocScale fractionally, without actually modifying any GoObjects, can cause changes in appearance.
I think I may be onto what is causing me so many headaches with centering my document.
For starters I swear that there is absolutely NOTHING that I can do that will properly center my document. In addition, I cannot get rid of the scrollbars unless I set their properties to HIDE!
It's impossible!
I don't understand how it's possible that when I load a document into a view and then set the document's X/Y coordinates to 0,0 like 100 times and I KNOW for a FACT that the document should not extend beyond the the boundaries of the view that there are still scrollbars!
The only thing I can think of is that the document size is bigger than the view EVEN when combined area of the objects in the document are much, much smaller which is a whole other problem.
If this is the case then how can I somehow "crop" all the unnecessary white space around my tree so that document only takes up as much space as the tree needs?
But remember what I said earlier -- you also need to make sure the GoView.DocPosition is such that scrollbars aren't necessary. This is one way to do that:
Oh, wait, you have GoView.SheetStyle set to a value other than None.
That intentionally changes the view's concept of how big the document is, without actually changing the GoDocument.Bounds.
That is necessary so that you can scroll a small document to the middle of the view, when the view is larger than the document at the current scale.
Please note that other applications, such as NotePad and Word, do not allow the user to center the text in the window. If a document in those applications has a single line of text, the scrollbar has to be able to scroll up far enough to be able to position the text in the vertical middle of the window.
The only reason I have the GoView.SheetStyle set to a value other than none is b/c that’s what you suggested that I do. I’m not tied to setting it that way.
I will set whatever settings I need to in order to get the effect that I want.
So if I take out the SheetStyle setting and put in the code you suggested will that work?
As for your whole NotePad and Word analogy, I'm not quite sure that I follow what you're saying. Isn't it more analogous to an Windows MDI application where child windows exist like in Adobe Photoshop?
My understanding is that each child window in Adobe Photoshop is like a GoDocument and the Adobe Photoshop workspace is like a GoView.
Just like I can draw a picture in Photoshop, resize it, position the child window that contains it in the center of the Photoshop workspace, grab the edges of the window and drag inwards to create scrollbars or outwards to get rid of them, I want to be able to do the same with GoDocuments in my GoView.
Removing the GoView.SheetStyle setting seems to handle the scrollbars always being present. I am still running in circles trying to center the friggin thing though. :)
OK. So centering works. As we figured out on the phone, the issue was that I created the GoView object programatically and added it as a control to my form instead of using the Visual Studio designer and dragging it from the toolbox. By adding the GoView programatically not all of the necessary properties were set (the important one being the GoView's size) and as a result of not actually setting a default size everything seemed to not work properly.
There is one caveat. The same one that has been an issue from the beginning.
The links become thin and brittle and the nodes look "off" -sort of look like they have shadows but that might just be a side effect of the nodes stretching and causing the black border at the top of my node's background image to appear stretched.
I posted two screenshots of the before and after in another post.
You mentioned something about anti-aliasing or something to that effect.
Once again, the thinness phenomena goes away when I click a scrollbar. It's quite odd.
This is the last remaining issue preventing me from getting the whole tree to center just the way I need it to.
The code that you have provided for attempting to snap nodes to grid has never really worked perfectly.
SizeF size = new SizeF(0, 1);
this.view.MoveSelection(sel, size, true);
I have tried several different X/Y values for the size variable and none seem to get me the result I want. There are several issues at hand here.
Since I call my snap-to-grid method each time the user loads a document into the view and after each modification of the document itself all of the nodes will always snap to the new location after either 1 of these 2 scenarios occur. This means that by using the X/Y value for size above each node will shift down 1 cell each and every time.
The above outcome wouldn't be so bad b/c the tree gets recentered every time too. However, what seems to be happening is that instead of the new X/Y coordinates being set prior to the nodes getting added to the document they are set after the fact. Since the nodes are all already in their respective locations the end result is that when the code to "snap the nodes to grid" is called each node is evaluated and has it's X/Y coordinates changed individually and if there happens to be an existing link/node in the new location it will shift that existing object to some other random location.
The ideal implementation of snap-to-grid would be an actual, real "GoDocument.SnapToGrid()" method that took care of all the intricacies of all this positioning stuff by storing all of the existing nodes X/Y coordinates, apply the snapping, save the new locations, add the nodes to the document and then layout the tree.
I am storing all of the node location information but for whatever reason I can't seem to get it from GoNode.Location.X/Y. All I ever get is 16,16 which seems to represent a value relative to the cell the node is snapped to.