top left of TDBTree nodes drifts as zoom factor changes

[WolfDog]

Another forum member posted something about this about 6 years ago, but as far as I could tell reading the thread no solution was forthcoming.

I want my user to be able to Zoom a TDBTree from 100% to about 400% (in case they have problems with their eyesight or something).

I'm not talking about a mouse click and drag, but by accessing a trackbar (TAdvTrackBar to be specific) to set the zoom factor. This is because I am zooming all my text controls in the application, not just the TBTrees.

The problem is that setting the value of the ->View3DOptions->Zoom property, while it works, does not guarantee that the TDBTree component will always display the nodes from the the top left corner (as is the default after creating the nodes based on the database records).

I've discovered I can get part way there by storing and resetting ->View3DOptions->HorizOffset and ->View3DOptions->VertOffset, but it only works the first time, i.e., if the user then changes the Zoom factor again, the top left where the nodes begin starts to drift and can move away from the top left very, very quickly and cannot thereafter be easily restored, at least programmatically.

I've experimented with a few things but have so far been unable to figure out what values are changing that are causing this problem. I hope you have a solution as many in my user base are seniors and I believe this will prove to be a significant feature in my application. Thanks.

[Yeray]

Hello,

Another forum member posted something about this about 6 years ago, but as far as I could tell reading the thread no solution was forthcoming.

Could you please post here the link to that thread?

[WolfDog]

http://www.teechart.net/support/viewtop ... =5&t=11122

[WolfDog]

By the way, if it isn't clear what I'm talking about, I can make a short video to show you. Just let me know.

[WolfDog]

There's a related problem I should have mentioned. In addition to the drift, the display of the tree nodes (and structure) also becomes smaller and smaller as one readjusts the zoom factor, i.e., after zooming, if the user then adjusts the zoom by going back down to, say, near 100%, the tree actually gets smaller than it was originally before any zoom factor was applied in the first place. It is in fact possible to get the tree very, very small doing this even though the zoom factor is never dropping below 100%.

This may be an issue with the TAdvTrackBar though. I can't say since I haven't tested that, but as that component has been in widespread use for a long time, it seems doubtful. Nevertheless, I will check.

Anyhow, after several years of being a customer, I have only asked for support a couple of times, so I have relatively little understanding of how it works, but I'm somewhat surprised it is taking this long. I hope you will get back to me soon.

[WolfDog]

Update: I just discovered that if I don't update the scrollbars positions after the zoom, the drift disappears. As is, I have been updating those positions manually with the mouse, not programmatically. But this leads me to believe that if I store the position values in a static variable and reset them to the previous values before the user zooms again, I may be able to compensate for this effect. Of course, there ought to be another, better way. Is there?

[WolfDog]

There doesn't appear to be any way to reset the scrollbar positions.

I tried changing the code in the source to that suggested in the link I provided (http://www.teechart.net/support/viewtop ... =5&t=11122) previously, but resetting the Position property appears to have no effect whatsoever.

I also tried using the Windows API calls, e.g.,

Code: Select all

		SetScrollPos(tree->Handle, SB_HORZ, 0, true);
		SendMessage(tree->Handle, WM_HSCROLL, SB_THUMBPOSITION, 0);
		SetScrollPos(tree->Handle, SB_VERT, 0, true);
		SendMessage(tree->Handle, WM_VSCROLL, SB_THUMBPOSITION, 0);

They also had no effect. Maybe because Windows 10 no longer supports them, or ... well, it's over my head.

So ... I have found a way to zoom and keep things from drifting from the top left with multiple zooms by storing (in the TAdvTrackBar's OnMouseUp event) and resetting the View3DOptions->HorizOffset and View3DOptions->VertOffset (in the TAdvTrackBar's OnChange event) each time the user zooms -- BUT no way to restore or reset the scrollbars ...

That's not exactly critical, but from a cosmetic and user-friendly point of view, it would be nice.

Oh well. No help has been forthcoming anyway. I'm beginning to get the impression I'm pretty much on my own. Nice.

[Yeray]

Hello,

Can you please send us a simple project showing the status of the problem? I understand it comes from the project attached in this post, but it would be helpful if we could get your progress too.

[WolfDog]

It does NOT come "from the project attached in this post." I never said it did.

I found that post discussing the same problem; that's all.

As for sending a simple project to show you the status of the problem, no, I will not.

I figured out what I could. As I have already indicated, the original problem posted about here is no longer the problem. The only remaining problem is the one I mentioned last, which had to do with programmatically changing the positions of the scrollbars after the zoom.

So I figure you could look into the problem if you chose to, with or without a "simple project" from me. Of course, I don't expect it. I know that TeeTree is kind of an afterthought relative to the main product. I'm just having to learn to re-make my peace with that.

No hard feelings, but I'm done.

[Yeray]

Hello,

I'm sorry to hear you are so disappointed.
Even if it's true that TeeTree isn't a top priority in Steema Software, it doesn't mean we are omitting what is posted in this section of the forums, and concretely in this thread.

I'm asking for a simple project showing your progress because, taking the only project I could find as a reference, I wasn't able to implement the workarounds you described. So I must be missing something relevant and I was interested on understanding what it might be; because a better understanding of any workaround may help us to find a fix for the component.
Looking at the problem again, I found a small improvement for it in TeeTree sources you can implement (as I see you own the sources) and test it. It consists on using Doubles instead of Integers at TCustomTree.View3DChangedZoom in TeeTree.pas:

Code: Select all

Procedure TCustomTree.View3DChangedZoom(NewZoom:Integer);
var tmp : Double;
    x,y: Double;
begin
  if ZoomCentered then
     ZoomFromCenter(NewZoom,ChartXCenter,ChartYCenter)
  else
  begin
    tmp:=1-(0.01*(View3DOptions.Zoom-NewZoom));

    with View3DOptions do
    begin
      x:=ChartXCenter-(ChartXCenter*tmp);
      y:=ChartYCenter-(ChartYCenter*tmp);

      HorizOffsetFloat:=HorizOffsetFloat-x;
      VertOffsetFloat :=VertOffsetFloat-y;
    end;
  end;

  if Assigned(OnZoom) then OnZoom(Self);
end;

Regarding the problem with the Tree looking different with Zoom at 100 before and after modifying it, I think the change above also improves this. Could you please confirm it?

[WolfDog]

Okay, well, sorry about my attitude.

I admit I get too impatient sometimes. I'm pretty good at understanding documentation (I've taught myself nearly everything mostly by reading -- not so much videos, professional instruction, etc. -- and used to write documentation), but I'm not so good sometimes at understanding code, especially Pascal.

I'm probably one of the worst programmers around. I'm entirely self-taught, and it gets a bit frustrating forking out thousands of dollars every year only to find out that a lot of these great tools that are supposed to make development easier aren't supported all that well, i.e., often little to no documentation and not much support otherwise either.

I guess what it amounts to is that when I set out on this journey, I didn't know what I was getting into.

Anyhow, something you may be interested in noting is that the TCustomTree.CenterInView method also causes this problem, i.e., the drift away from the top left -- it doesn't always, but does some of the time, and some of the time, the tree gets set back to the top left where it belongs, too.

Weird.

I don't recall having noticed this in the past, so it may be that it was working without causing the drift a couple of versions ago. But then again, maybe I just didn't notice because I wasn't so near release and wasn't worrying so much about cosmetics.

In any case, I've given up on Zooming the tree as I've run into one complication after another. The code you offered hasn't helped me that much, and there are other problems I've come across as well. So I am now simply resizing the various tree elements. As of now it's working very well. I don't have to worry about offsets, offset drift or scrollbar positions.

I've got the font, the folder image, the connections and the crossbox all resizing appropriately.

The only thing that isn't resizing is the distance between the crossbox and the node folder image.

I haven't so far been able to figure out where that value is kept or how to reset it. If you can help with that, I will go away a very happy customer ... for now.

Thanks.

[Yeray]

Hello,

Anyhow, something you may be interested in noting is that the TCustomTree.CenterInView method also causes this problem, i.e., the drift away from the top left -- it doesn't always, but does some of the time, and some of the time, the tree gets set back to the top left where it belongs, too.

I haven't been able to reproduce this in a simple tree with some nodes and Selected.ScrollToCenter property set to "true". Can you arrange a simple example project we can run as-is to reproduce the problem here?

In any case, I've given up on Zooming the tree as I've run into one complication after another. The code you offered hasn't helped me that much, and there are other problems I've come across as well. So I am now simply resizing the various tree elements. As of now it's working very well. I don't have to worry about offsets, offset drift or scrollbar positions.

I've got the font, the folder image, the connections and the crossbox all resizing appropriately.

The only thing that isn't resizing is the distance between the crossbox and the node folder image.

I haven't so far been able to figure out where that value is kept or how to reset it.

We'd need to see what are you exactly doing in a simple application to try to find a way to solve the problem you are experiencing.

Thanks in advance!

[WolfDog]

At this point, I'm FAR MORE INTERESTED NOW in how to scale the space between the crossboxes and the nodeshapes, as I said previously.

As for the CenterInView thing, I figured out what was happening. The method centers the node in the view even if it is so high in the tree that it forces the top offset to cause the drift away from the top as I said. This is the case with the horizontal offset as well. The reason you may not be noticing it is that as soon as you grab the scrollbars and start adjusting them, the first time you let up on the mouse, it can get corrected, i.e., depending on where the scrollbar is when you let go of the mouse button, the tree often goes back to being flush top left.

In short, it's not really a bug, I guess. It is just not the way I want it to work.

So I came up with my own version that fixes the "problem." I call it "BringIntoView." It's based on your code, except that it ignores animation capability as I'm not really interested in that and it is in C++. Rather than providing a project, which seems a bit pointless now that I have figured out what the problem was and explained it, but I am offering that code here -- that takes care of my objection -- for your perusal and/or use:

Code: Select all

void __fastcall TMyTTree::BringIntoView(TTreeNodeShape *NodeShape)
{
	TPoint P;
	int tmpX;
	int tmpY;

	if (!NodeShape)
		return;

	P = Canvas->Calculate3DPosition(NodeShape->XCenter(), NodeShape->YCenter(), TeeTreeZ);
	tmpX = ChartXCenter;
	if (tmpX == 0)
		tmpX = (ClientWidth / 2);

	P.X = P.X - tmpX;
	P.Y = P.Y - (ClientHeight / 2);

        // here's the code that keeps the offsets from moving away from the topleft flush default positions
	if (View3DOptions->HorizOffsetFloat < P.X)
		View3DOptions->HorizOffsetFloat = View3DOptions->HorizOffsetFloat - P.X;

	if (View3DOptions->VertOffsetFloat < P.Y)
		View3DOptions->VertOffsetFloat = View3DOptions->VertOffsetFloat - P.Y;
}

If you can get back to me about that scaling issue, I'd appreciate it.

[Yeray]

Hi,

At this point, I'm FAR MORE INTERESTED NOW in how to scale the space between the crossboxes and the nodeshapes, as I said previously.

We'd need to know how are you exactly "resizing the various tree elements" so we can reproduce the situation here and try to provide a way to scale that space.

So I came up with my own version that fixes the "problem." I call it "BringIntoView." It's based on your code, except that it ignores animation capability as I'm not really interested in that and it is in C++. Rather than providing a project, which seems a bit pointless now that I have figured out what the problem was and explained it, but I am offering that code here -- that takes care of my objection -- for your perusal and/or use:

Thanks for sharing the code! I see it works fine.
Here it is the same code translated to Delphi:

Code: Select all

procedure TForm1.BringIntoView(NodeShape: TTreeNodeShape);
var P: TPoint;
    tmpX, tmpY: Integer;
begin
   if (not Assigned(NodeShape)) then
      exit;

   P := NodeShape.Tree.Canvas.Calculate3DPosition(NodeShape.XCenter(), NodeShape.YCenter(), TeeTreeZ);
   tmpX := NodeShape.Tree.ChartXCenter;
   if (tmpX = 0) then
      tmpX := (ClientWidth div 2);

   P.X := P.X - tmpX;
   P.Y := P.Y - (ClientHeight div 2);

   // here's the code that keeps the offsets from moving away from the topleft flush default positions
   if (NodeShape.Tree.View3DOptions.HorizOffsetFloat < P.X) then
      NodeShape.Tree.View3DOptions.HorizOffsetFloat := NodeShape.Tree.View3DOptions.HorizOffsetFloat - P.X;

   if (NodeShape.Tree.View3DOptions.VertOffsetFloat < P.Y) then
      NodeShape.Tree.View3DOptions.VertOffsetFloat := NodeShape.Tree.View3DOptions.VertOffsetFloat - P.Y;
end;