DELPHI AREA :: View topic - TSimpleGraph issues and suggestions

through

[^/[Print]\]

DELPHI AREA -> DELPHI AREA's Products

#1: TSimpleGraph issues and suggestions Author: kokkoras, Location: Thessaloniki, Greece

Posted: 21/10/05 22:28
—
Hi,

I have been playing with TSimpleGraph for some time and I would like to mention a few changes I have made.

1. I set "fTag: TObject;" instead of "fTag: Integer;" That way it is possible to associate graph nodes with other objects.

2. I implemented an fVAlignment property for vertical alignment of the text of a node.

3. I have made nodes "drop aware", that is, when a node is dropped over another node an event is fired and a proper event handler can be triggered.

4. There is an issue with the function TGraphNode.GetTextRect: TRect;
When zooming, at certain zoom percentages the text of a node is truncated and part of it is replaced by dots (...). I think it is related to some decimal values convetred to integers. I have quick-fixed this by setting Result.Right := MaxTextRect.Right+2; instead of conditionally calculating it.

5. There is an issue with procedure TSimpleGraph.ToggleNodesAt(const Rect: TRect; KeepOld: Boolean);
The problem is related to selecting horizontal or vertical links with a selection rectangle and the cause is the zero dy or dx, respectively. An easy workaround is to expand the bounded box of links by 1, all around.

6. Finally, I have moved some code that draws links, after code that draws nodes. That way the links are not covered by other nodes. This affects printing as well.

Thats all. I think that issues No4 and No5 affect all of us using TSimpleGraph. The other mentioned here are alterations for my own needs.

That's all. BTW, well done for this nice component.

Fotis

#2: Re: TSimpleGraph issues and suggestions Author: lbc, Location: Italy

Posted: 22/10/05 12:53
—

kokkoras wrote:

Hi,

There is an issue with the function TGraphNode.GetTextRect: TRect;
When zooming, at certain zoom percentages the text of a node is truncated and part of it is replaced by dots (...). I think it is related to some decimal values convetred to integers. I have quick-fixed this by setting Result.Right := MaxTextRect.Right+2; instead of conditionally calculating it.

Hello
I think the (...) dots depend on the text flags DT_END_ELLIPSIS set inside GraphNode.DrawText procedure

DrawTextFlags := DT_WORDBREAK or DT_NOPREFIX or DT_END_ELLIPSIS or TextAlignFlags[Alignment];

to avoid those dots you can try something like:

DT_WORDBREAK or DT_NOPREFIX or TextAlignFlags[Alignment];

to avoid text clipping:
DT_WORDBREAK or DT_NOPREFIX or DT_NOCLIP or TextAlignFlags[Alignment]

HTH

#3: Author: kokkoras, Location: Thessaloniki, Greece

Posted: 23/10/05 10:45
—
Well, my point is that, as soon as some text is fully displayd because it fits in the available node width, it should be fit in all zooming states. Having those dots is a nice feature but only when the text doesn't fit.

Thanks for the reply.

Fotis K.

#4: Author: lbc, Location: Italy

Posted: 23/10/05 15:08
—
Hello
ok, actually i can reproduce your point
as far as I can see, the zooming "core" is located in the WMPaint(var Msg: TWMPaint) procedure
look at:

Code:

....

SetMapMode(MemDC, MM_ANISOTROPIC);
SetWindowExtEx(MemDC, 100, 100, nil);
SetViewPortExtEx(MemDC, Zoom, Zoom, nil);
...

As far as the text issue it seems to me that setting the Text Margin to 0 can help a bit in keeping the same "text proportions" at all zooming states

HTH

#5: The code Author: sergisan,

Posted: 23/10/05 22:37
—
kokkoras,

are you planning to post the code ?

Serg...

#6: Author: kokkoras, Location: Thessaloniki, Greece

Posted: 24/10/05 08:29
—
here is the code:

Code:

function TGraphNode.GetTextRect: TRect;

locate the following 2 lines of code:

Code:

if Result.Right > MaxTextRect.Right then
Result.Right := MaxTextRect.Right;

and replace them with:

Code:

Result.Right := MaxTextRect.Right+1;

regards

fotis

#7: Author: kokkoras, Location: Thessaloniki, Greece

Posted: 24/10/05 08:36
—

lbc wrote:

Hello
As far as the text issue it seems to me that setting the Text Margin to 0 can help a bit in keeping the same "text proportions" at all zooming states
HTH

It's true because it gives the same result: more space for the text to fit. But the drawback is that Margin is for another usage.

fotis

#8: Re: The code Author: kokkoras, Location: Thessaloniki, Greece

Posted: 24/10/05 08:40
—

sergisan wrote:

kokkoras,
are you planning to post the code ?
Serg...

Do you mean the zoom issue or the truncated text issue? I have already posted the second one. I will check for the former soon.

fotis

#9: Author: kokkoras, Location: Thessaloniki, Greece

Posted: 24/10/05 08:49
—
ok, here is the quick fix for the "selection of horizontal and vertical links" issue - I hope its understood.

Code:

procedure TSimpleGraph.ToggleNodesAt(const Rect: TRect; KeepOld: Boolean);
var
GraphObject: TGraphObject;
I: Integer;
R: TRect;
myLinkRect: TRect; //FOTIS: additional var
begin
if not KeepOld then
SelectedObjects.Clear;
for I := Objects.Count - 1 downto 0 do
begin
GraphObject := Objects[I];
// FOTIS: handle the horizontal or vertical link anomaly due to IntersectRect
if GraphObject.IsLink then begin
myLinkRect:= GraphObject.BoundsRect;
myLinkRect.Top:= myLinkRect.Top-1;
myLinkRect.Bottom:= myLinkRect.Bottom+1;
myLinkRect.Left:= myLinkRect.Left-1;
myLinkRect.Right:= myLinkRect.Right+1;
if IntersectRect(R, Rect, myLinkRect) then
GraphObject.Selected := not GraphObject.Selected;
end;
//FOTIS: handle non-Link objects
if ((not GraphObject.IsLink) and (IntersectRect(R, Rect, TGraphNode(GraphObject).BoundsRect)) )
then
GraphObject.Selected := not GraphObject.Selected;
end;
end;

fotis

#10: Author: lbc, Location: Italy

Posted: 24/10/05 13:16
—
Hello

kokkoras wrote:

It's true because it gives the same result: more space for the text to fit. But the drawback is that Margin is for another usage.

fotis

yes, anyway my suggestion was to investigate if the text issue could be related in some way to the Margin calculations...

As i said the zooming "core" seems to be located in the WMPaint(var Msg: TWMPaint) procedure inside the section

SetMapMode(MemDC, MM_ANISOTROPIC);
SetWindowExtEx(MemDC, 100, 100, nil);
SetViewPortExtEx(MemDC, Zoom, Zoom, nil);

but i don't see how this section could to be corrected (if needed) to solve the text issue..

as far as the other code sections related to zoom (like the SetZoom) seem not having any issue

#11: Author: kokkoras, Location: Thessaloniki, Greece

Posted: 24/10/05 13:55
—
In my early atempts to fix the problem, I also investigated the margin value, but I abandon it as soon as I discovered that it is a fixed value, set by the user (or the default value, anyway).

Regarding the textExtend calculations, I think they come after the zoom state has been set. That's why I changed the code I mentioned in the other post. The fact that it happens at certain zoom states supports this. Anyway, I think adding a pixel width is not a big deal unless the context of use requires precision.

fotis.

#12: Author: lbc, Location: Italy

Posted: 24/10/05 14:29
—

kokkoras wrote:

The fact that it happens at certain zoom states supports this. Anyway, I think adding a pixel width is not a big deal unless the context of use requires precision.

fotis.

Hello
i agreee with you
by the way have you had the chance to test with a lot of fonts, sizes, text styles etc. if your fix eliminate definitely that text issue at any zoom state?

#13: Author: kokkoras, Location: Thessaloniki, Greece

Posted: 24/10/05 14:53
—

Quote:

Hello
i agreee with you
by the way have you had the chance to test with a lot of fonts, sizes, text styles etc. if your fix eliminate definitely that text issue at any zoom state?

Yes I have tested it. It works ok as soon as the node is not changed manually, in terms of width. If it does though, the problem sometimes re-appears, but this is expected due to the nature of the textExtend calculations made internally.

That is, my fix provides an initial width in which the initial text fits well, in any zoom state.

BTW, in my understanding, the textExtend function returns the space (TRect) required to display the given text in the given canvas (or DC in C++ ternimology) using the Font settings set for the canvas. Since the code under consideration is a method of TGraphNode, calculations should use the font used in that particular node. Under this perspective I can not see any other location for the problem than the internals of the textExtend function. I guess there is a usual round step somewhere instead of an Int()+1 (or Roof). For example, if the text requires 100.4 pixels width to fit then the desired integer should be 101, not 100.

fotis

#14: Author: lbc, Location: Italy

Posted: 24/10/05 16:07
—
well, thank you

just an idea: so, what about replacing the zooming section (basically currently implemented inside WMPaint by calling Windows mapping mode) with a simple for... loop inside the SetZoom procedure that just "scales" down/up all the existent nodes (ie: SimpleGraph.SelectedObjects or Objects) by a factor? So the texts sizes could be calculated there...

Of course the WMPaint is more efficient (for example i suppose it has been implemented for eliminating the flickering)

#15: Author: kokkoras, Location: Thessaloniki, Greece

Posted: 24/10/05 16:27
—
I think, I can live with the current state for the time being. I am quite bussy at the moment with other stuff. Crying or Very sad

#16: Author: kokkoras, Location: Thessaloniki, Greece

Posted: 24/10/05 16:34
—

lbc wrote:

well, thank you

just an idea: ......

I think you will introduce unnessesary load in that way. It is quite optimal in the current state. I think it is implemented the way it should be!!

Regards (neighboor) Smile

#17: Author: lbc, Location: Italy

Posted: 24/10/05 18:33
—
yep, it was just a temporary idea Smile

anyway even if it's not a big issue i think it's would be nice to get the text displayed the same (ie: without dots) at any zoom state

greetings to Greece Very Happy

#18: Author: Kambiz, Location: Tehran, Iran

Posted: 29/10/05 16:50
—
Hi,

Fixing the mentioned issue was more difficult than it seemed, because the problem was actually inside the DrawText API.

Anyway, the problem is fixed and you can download the new release with some other improvements from the site.

Thanks to all,
Kambiz

#19: Author: kokkoras, Location: Thessaloniki, Greece

Posted: 30/10/05 13:04
—
Nice! Thanks!!

#20: Author: lbc, Location: Italy

Posted: 30/10/05 16:31
—
excellent job! thank you!

#21: Author: kokkoras, Location: Thessaloniki, Greece

Posted: 31/10/05 01:47
—
Thanks for the vertical alignment adition (for a moment I got confused because the new code was located in the same places I had put my modifications for vertical alignment - only the names where different!!!).

Now, I am still having that issue with the romboidals (using v.1.60). I attach some captures to illustrate the problem. Please note that the links should be absolutely vertical.

Can anyone reproduce this?? (I am using D7Ent with 7.1 update)

thanks

#22: Author: Kambiz, Location: Tehran, Iran

Posted: 31/10/05 16:16
—
kokkoras,

Finally I could reproduce the bug, and I'm trying to fix it.

Please check out the following link for this bug:
http://www.delphiarea.com/forum/viewtopic.php?t=527

Cheers

#23: Author: kokkoras, Location: Thessaloniki, Greece

Posted: 31/10/05 16:30
—

Kambiz wrote:

kokkoras,
Finally I could reproduce the bug, and I'm trying to fix it.

It looks like the section between the arrow and the rhombus is not calculated correctly for vertical links. Are the appex points well defined? I suspect round issues again... Question

Kambiz wrote:

Please check out the following link for this bug:
http://www.delphiarea.com/forum/viewtopic.php?t=527
Cheers

I saw it. Are these two issues related??

Please, take your time. They are not critical bugs.

Fotis

DELPHI AREA -> DELPHI AREA's Products

output generated using printer-friendly topic mod. All times are GMT

Page 1 of 1