extgraph-developer — Extgraph developer list

[Extgraph-developer] Unit splitting

[Marco W. <ma...@wo...>]

Hi guys,

We seriously need to break up the unit. Maintainability will go down the 
drain if don't act soon. I'll take the lead here and suggest how it 
should continue and am curious on how you guys think about this. Since 
you suggested naming the TSimplegraph into TExtGraph, I suggest prefixis 
'eg'.

Marco.

egCommon.pas

    * EGraphStreamError
    * TGraphObjectList
    * TGraphScrollbar
    * TGraphStreamableObject
    * TMemoryHandleStream

egGraph.pas

    * TGraphObject
    * TGraphLink
    * TGraphNode
    * TSimpleGraph

egNodes.pas

    * TEllipticNode
    * TPentagonalNode
    * TPolygonalNode
    * TRectangularNode
    * TRhomboidalNode
    * TRoundRectangularNode
    * TTriangularNode

egSVG.pas

    * ...SVG classes

[Extgraph-developer] BezierLink code

[Stefan M. <ste...@po...>]

Hey,
=20
Since we're throwing code around, I thought I'd join in on the fun :)
Here's my code for the BezierLink, it does however have a "problem":
I don't know how to implement the DrawText for this thing, where =
*should* we put the text, any ideas?
=20
As you can see I've renamed TSimpleGraph to TExtGraph, I think that'll =
be a good thing for the next release.
=20
Cheers,
Stefan
=20
=20
  TMarkerType =3D (mtNone, mtSizeW, mtSizeE, mtSizeN, mtSizeS, mtSizeNW,
    mtSizeNE, mtSizeSW, mtSizeSE, mtMove, mtMoveStrartPt, mtMoveEndPt,
    mtSelect, mtStretchBezier); (* SM - added mtStretchBezier for =
TBezierLink *)
=20
  TGraphMouseState =3D (gsNone, gsMoveResizeNode, gsSelectRect, =
gsMoveLink, gsStretchBezier);
  (* SM - added gsStretchBezier for TBezierLink *)
=20
  TBezierLink =3D class(TGraphLink)
    class procedure DrawDraft(Canvas: TCanvas; const ARect: TRect); =
override; =20
    procedure DrawBody(Canvas: TCanvas); override;
  protected
    function FindMarkerAt(X, Y: Integer): TMarkerType; override;
    procedure DrawMarkers(Canvas: TCanvas); override;
  private
    fPointsAltered : Boolean;
  public
    points: array [0..3] of TPoint;
    NumLine: integer;
    lpPoints: array of TPoint;
    lpTypes: array of Byte;
    DraggingPoint: integer;
    function ContainsPoint(X, Y: Integer): Boolean; override;
    destructor Destroy; override;
  end;
=20
{ TBezierLink }
function TBezierLink.ContainsPoint(X, Y: Integer): Boolean;
var
  Margin: Integer;
  R: TRect;
  i: integer;
begin
  Result :=3D False;
  if Showing and (FromNode <> nil) and (ToNode <> nil) then begin
    if (TextRegion <> 0) and PtInRegion(TextRegion, X, Y) then
      Result :=3D True
    else begin
      if Selected then begin
        for i :=3D 1 to 2 do begin
          with points[i] do SetRect(r, X, Y, X, Y);
          InflateRect(r, Owner.MarkerSize, Owner.MarkerSize);
          Result :=3D PtInRect(r, Point(X,Y));
          if result then Exit;
        end;
      end;
      for i :=3D 1 to NumLine-1 do begin
        Margin :=3D Pen.Width + Owner.MarkerSize;
        Margin :=3D Margin div 2;
        R :=3D MakeRect(Point(lppoints[i-1].x, lppoints[i-1].y), =
Point(lppoints[i].x, lppoints[i].y));
        InflateRect(R, Margin, Margin);
        Result :=3D PtInRect(R, Point(X, Y));
        if Result then Break;
      end;
    end;
  end;
end;
=20
destructor TBezierLink.Destroy;
begin
  SetLength(lpPoints, 0);
  SetLength(lpTypes, 0);
  inherited;
end;
procedure TBezierLink.DrawBody(Canvas: TCanvas);
var
  i: integer;
//  r: TRect;
//  Margin: Integer;
begin
  with StartPt do Canvas.MoveTo(X, Y);
  if (points[0].x <> StartPt.x) or=20
     (points[0].y <> StartPt.y) or=20
     (points[3].x <> EndPt.x) or=20
     (points[3].y <> EndPt.y)  then begin
    points[0] :=3D StartPt;
    if not fPointsAltered then points[1] :=3D Point(StartPt.x, EndPt.Y);
    if not fPointsAltered then points[2] :=3D Point(EndPt.x, StartPt.y);
    points[3] :=3D EndPt;
  end;
  BeginPath(Canvas.Handle);
  PolyBezier(Canvas.Handle, Points, 4);
  EndPath(Canvas.Handle);
  FlattenPath(Canvas.Handle);
  NumLine :=3D getpath(Canvas.Handle, lpPoints, lpTypes, 0);
  setlength(lppoints, NumLine);
  setlength(lptypes, NumLine);
  GetPath(Canvas.Handle, lppoints[0], lptypes[0], NumLine);
  for i :=3D 0 to NumLine-1 do begin
    case lpTypes[i] of
      PT_MOVETO: Canvas.MoveTo(lppoints[i].x, lppoints[i].y);
      PT_LINETO: Canvas.LineTo(lppoints[i].x, lppoints[i].y);
    end;
  end;
//  Shows the Rectangles which are used in ContainsPoint():
//  for i :=3D 1 to NumLine-1 do begin
//    Margin :=3D Pen.Width + Owner.MarkerSize;
//    Margin :=3D Margin div 2;
//    R :=3D MakeRect(Point(lppoints[i-1].x, lppoints[i-1].y), =
Point(lppoints[i].x, lppoints[i].y));
//    InflateRect(R, Margin, Margin);
//    Canvas.Rectangle(R);
//  end;
end;
=20
class procedure TBezierLink.DrawDraft(Canvas: TCanvas; const ARect: =
TRect);
var
  i: integer;
  points: array [0..3] of TPoint;
  NumLine: integer;
  lpPoints: array of TPoint;
  lpTypes: array of Byte;
begin
  Canvas.MoveTo(Arect.TopLeft.X, Arect.TopLeft.Y);
  if (points[0].x <> Arect.TopLeft.X) or=20
     (points[0].y <> Arect.TopLeft.Y) or=20
     (points[3].x <> Arect.BottomRight.x) or=20
     (points[3].y <> Arect.BottomRight.y) then begin
    points[0] :=3D Arect.TopLeft;
    points[1] :=3D Point(Arect.TopLeft.x, Arect.BottomRight.Y);
    points[2] :=3D Point(Arect.BottomRight.x, Arect.TopLeft.y);
    points[3] :=3D Arect.BottomRight;
  end;
  BeginPath(Canvas.Handle);
  PolyBezier(Canvas.Handle, Points, 4);
  EndPath(Canvas.Handle);
  FlattenPath(Canvas.Handle);
  NumLine :=3D getpath(Canvas.Handle, lpPoints, lpTypes, 0);
  setlength(lppoints, NumLine);
  setlength(lptypes, NumLine);
  GetPath(Canvas.Handle, lppoints[0], lptypes[0], NumLine);
  for i :=3D 0 to NumLine-1 do begin
    case lpTypes[i] of
      PT_MOVETO: Canvas.MoveTo(lppoints[i].x, lppoints[i].y);
      PT_LINETO: Canvas.LineTo(lppoints[i].x, lppoints[i].y);
    end;
  end;
end;
=20
procedure TBezierLink.DrawMarkers(Canvas: TCanvas);
var
  i: integer;
  r: TRect;
begin
  inherited;
  if Selected then begin
    for i :=3D 1 to 2 do begin
      with points[i] do SetRect(r, X, Y, X, Y);
      InflateRect(r, Owner.MarkerSize, Owner.MarkerSize);
      Canvas.FrameRect(r);
    end;
  end;
end;
=20
function TBezierLink.FindMarkerAt(X, Y: Integer): TMarkerType;
var
  Marker: TMarkerType;
  Pt: TPoint;
  i: integer;
  r: TRect;
begin
  Result :=3D mtNone;
  if Showing then begin
    if Selected then begin
      Pt :=3D Point(X, Y);
      for Marker :=3D mtMoveStrartPt to mtMoveEndPt do begin
        if PtInRect(MarkerRect(Marker), Pt) then begin
          Result :=3D Marker;
          Exit;
        end;
      end;
      for i :=3D 1 to 2 do begin
        with points[i] do SetRect(r, X, Y, X, Y);
        InflateRect(r, Owner.MarkerSize, Owner.MarkerSize);
        if PtInRect(r, Pt) then begin
          Result :=3D mtStretchBezier;
          DraggingPoint :=3D i;
          Exit;
        end;
      end;
    end;
    if ContainsPoint(X, Y, true) then
      Result :=3D mtSelect;
  end;
end;
=20
{ / TBezierLink }
=20
procedure TExtGraph.MouseDown(Button: TMouseButton; Shift: TShiftState; =
X, Y: Integer);
var
  Pt: TPoint;
begin
...
      // A Link is under cursor
      else
      begin
        if (Button =3D mbLeft) and not=20
           (ssDouble in Shift) and=20
           (MarkerAtCursor in [mtMoveEndPt, mtMoveStrartPt]) then begin
          if MarkerAtCursor =3D mtMoveEndPt then
            StartPoint :=3D TGraphLink(ObjectAtCursor).FromNode.Center
          else
            StartPoint :=3D TGraphLink(ObjectAtCursor).ToNode.Center;
          StopPoint :=3D Pt;
          State :=3D gsMoveLink;
          Linking :=3D True;
        end;
        if (Button =3D mbLeft) and not=20
           (ssDouble in Shift) and=20
           (MarkerAtCursor in [mtStretchBezier]) then
          State :=3D gsStretchBezier;
      end;
    end;
...

procedure TExtGraph.MouseMove(Shift: TShiftState; X, Y: Integer);
const
  FreezeTopMarkers  =3D [mtMove, mtSizeNW, mtSizeN, mtSizeNE];
  FreezeLeftMarkers =3D [mtMove, mtSizeNW, mtSizeW, mtSizeSW];
var
...
  BezierAtCursor: TBezierLink;
begin
...
    else if State =3D gsStretchBezier then begin
      BezierAtCursor :=3D TBezierLink(ObjectAtCursor);
      BezierAtCursor.fPointsAltered :=3D True;
      BezierAtCursor.points[BezierAtCursor.DraggingPoint] :=3D =
Point(X,Y);
      BezierAtCursor.DrawBody(Canvas);
      Invalidate;
    end
...
end;
=20
initialization
...
  TExtGraph.Register(TBezierLink);
finalization
...
  TExtGraph.Unregister(TBezierLink);

RE: [Extgraph-developer] TGraphNode.Layout

[vrecion <pav...@sy...>]

OK I will add it to code. It will appear in the next cvs release.

 

Pavel

 

  _____  

From: ext...@li...
[mailto:ext...@li...] On Behalf Of Marco
Wobben
Sent: Wednesday, February 23, 2005 11:29 AM
To: ext...@li...
Subject: [Extgraph-developer] TGraphNode.Layout

 

I've added a new property to the nodes: 

  published
    property Layout: TTextLayout read fTextLayout write SetTextLayout
default tlCenter;

And a routine implementation using it:

function TGraphNode.GetTextRect: TRect;
var
  MaxTextRect: TRect;
  DrawTextFlags: Integer;
  h: integer;
begin
  if Text <> '' then
  begin
    MaxTextRect := GetMaxTextRect;
    DrawTextFlags := DT_WORDBREAK or DT_NOPREFIX or DT_END_ELLIPSIS or
      DT_EDITCONTROL or TextAlignFlags[Alignment];
    Owner.Canvas.Font := Font;
    Result := MaxTextRect;
    h := Windows.DrawText(
      Owner.Canvas.Handle, PChar(Text), Length(Text), Result,
      Owner.DrawTextBiDiModeFlags(DrawTextFlags) or DT_CALCRECT);
    if Result.Right > MaxTextRect.Right then
      Result.Right := MaxTextRect.Right;
    if Result.Bottom > MaxTextRect.Bottom then
      Result.Bottom := MaxTextRect.Bottom;
    if not IsRectEmpty(Result) then
    begin
      { MW stripped any vertical alignment from the horizontal stuff. }
      case Alignment of
        taLeftJustify:
          OffsetRect(Result, Left, 0);
        taRightJustify:
          OffsetRect(Result, Left + (MaxTextRect.Right - Result.Right) -
Margin, 0);
      else
        OffsetRect(Result, Left + (MaxTextRect.Right - Result.Right) div 2,
0);
      end;
      { MW added vertical alignment }
      case Layout of
        tlTop:
          OffsetRect(Result, 0, Top);
        tlCenter:
          OffsetRect(Result, 0, Top + (MaxTextRect.Bottom - Result.Bottom)
div 2);
        tlBottom:
          OffsetRect(Result, 0, (MaxTextRect.Bottom-Result.Bottom) - h);
      end;
    end;
  end
  else
    FillChar(Result, SizeOf(Result), 0);
end;

[Extgraph-developer] TGraphNode.Layout

[Marco W. <in...@ca...>]

I've added a new property to the nodes:

  published
    property Layout: TTextLayout read fTextLayout write SetTextLayout 
default tlCenter;

And a routine implementation using it:

function TGraphNode.GetTextRect: TRect;
var
  MaxTextRect: TRect;
  DrawTextFlags: Integer;
  h: integer;
begin
  if Text <> '' then
  begin
    MaxTextRect := GetMaxTextRect;
    DrawTextFlags := DT_WORDBREAK or DT_NOPREFIX or DT_END_ELLIPSIS or
      DT_EDITCONTROL or TextAlignFlags[Alignment];
    Owner.Canvas.Font := Font;
    Result := MaxTextRect;
    h := Windows.DrawText(
      Owner.Canvas.Handle, PChar(Text), Length(Text), Result,
      Owner.DrawTextBiDiModeFlags(DrawTextFlags) or DT_CALCRECT);
    if Result.Right > MaxTextRect.Right then
      Result.Right := MaxTextRect.Right;
    if Result.Bottom > MaxTextRect.Bottom then
      Result.Bottom := MaxTextRect.Bottom;
    if not IsRectEmpty(Result) then
    begin
      { MW stripped any vertical alignment from the horizontal stuff. }
      case Alignment of
        taLeftJustify:
          OffsetRect(Result, Left, 0);
        taRightJustify:
          OffsetRect(Result, Left + (MaxTextRect.Right - Result.Right) - 
Margin, 0);
      else
        OffsetRect(Result, Left + (MaxTextRect.Right - Result.Right) div 
2, 0);
      end;
      { MW added vertical alignment }
      case Layout of
        tlTop:
          OffsetRect(Result, 0, Top);
        tlCenter:
          OffsetRect(Result, 0, Top + (MaxTextRect.Bottom - 
Result.Bottom) div 2);
        tlBottom:
          OffsetRect(Result, 0, (MaxTextRect.Bottom-Result.Bottom) - h);
      end;
    end;
  end
  else
    FillChar(Result, SizeOf(Result), 0);
end;

RE: [Extgraph-developer] TGraphNode.Parent

[Stefan M. <ste...@po...>]

Hi Marco,
=20
I've updated your privileges on SF, you should now be able to add / =
change tasks.
=20
As for your ideas, I especially like the layers and do not have a =
problem with any of the other suggestions.=20
Please do keep us updated, we'd love to see some code once you've got =
things up and running.
=20
If you need any help on any of the things, please contact us, maybe we =
can help / assist.
=20
Cheers,
Stefan

________________________________

Van: ext...@li... namens Marco Wobben
Verzonden: wo 23-2-2005 10:00
Aan: ext...@li...
Onderwerp: [Extgraph-developer] TGraphNode.Parent


Hi guys,

Just some thoughts (and work in progress) on the GraphObjects...

Parent
I'm building some code into the TGraphNode to support some kind of =
Parent much like the TControl does in the VCL. This is for the obvious =
reason to support a grouping like behaviour. Parents would paint =
themselves first and in addition it would paint it's children. Similarly =
if moved, it would move the children. In several vector drawing tools it =
would be considered some kind of grouping where the parent is simply the =
first object in the list.

Layer
I'm also thinking about layers similar to this. Every GraphObject would =
be defaulted to the single layer in the TSimpleGraph. The Graph could =
have several layers and including a visible property and an ActiveLayer =
index. It would certainly add value to the current ZOrder and individual =
visible states.

Lock
Simple to realize is the lock propert on individual Nodes instead of the =
entire Graph. This could be finetuned into the layering and parenting...

So far my thoughts. As work progresses I'll keep you posted. In the =
meanwhile I've discovered that I cannot add Tasks and stuff in the =
SourceForge site. Is there something you can do to arrange this?

Marco.

--=20
Phone   +31 650.69.27.31
Email   ma...@wo...
ICQ     432807
Skype   marcowobben

"Trust is a future that brings what is needed, exactly how it is needed"

RE: [Extgraph-developer] TGraphNode.Parent

[vrecion <pav...@sy...>]

Hi Marco.

 

Layers and locks are fine.

Regarding Parent and grouping:

There is intention to move to svg. In svg format there is group element that
encapsulates several objects into one group. Furthermore groups can be
nested. 

So in fact grouping capability is already there.

There is an example application that enables to insert svg object into
graph.

I hope that this behavior is what you have in mind.

 

Pavel

 

  _____  

From: ext...@li...
[mailto:ext...@li...] On Behalf Of Marco
Wobben
Sent: Wednesday, February 23, 2005 9:46 AM
To: ext...@li...
Subject: [Extgraph-developer] TGraphNode.Parent

 

Hi guys,

Just some thoughts (and work in progress) on the GraphObjects...

Parent
I'm building some code into the TGraphNode to support some kind of Parent
much like the TControl does in the VCL. This is for the obvious reason to
support a grouping like behaviour. Parents would paint themselves first and
in addition it would paint it's children. Similarly if moved, it would move
the children. In several vector drawing tools it would be considered some
kind of grouping where the parent is simply the first object in the list.

Layer
I'm also thinking about layers similar to this. Every GraphObject would be
defaulted to the single layer in the TSimpleGraph. The Graph could have
several layers and including a visible property and an ActiveLayer index. It
would certainly add value to the current ZOrder and individual visible
states.

Lock
Simple to realize is the lock propert on individual Nodes instead of the
entire Graph. This could be finetuned into the layering and parenting...

So far my thoughts. As work progresses I'll keep you posted. In the
meanwhile I've discovered that I cannot add Tasks and stuff in the
SourceForge site. Is there something you can do to arrange this?

Marco.



-- 
Phone   +31 650.69.27.31
Email   ma...@wo...
ICQ     432807
Skype   marcowobben
 
"Trust is a future that brings what is needed, exactly how it is needed"

RE: [Extgraph-developer] TSimplegraph.DrawObjectOrder

[vrecion <pav...@sy...>]

Yeah ZOrder will be usefull.

Pavel

 

  _____  

From: ext...@li...
[mailto:ext...@li...] On Behalf Of Marco
Wobben
Sent: Wednesday, February 23, 2005 9:46 AM
To: ext...@li...
Subject: [Extgraph-developer] TSimplegraph.DrawObjectOrder

 

Hi guys,

My first real need and adjustment to the code is the being able to influence
the drawing order of the GraphObjects. For this to work I've done the
following:

*	Introduced a new TDrawObjectOrder enumeration (ooZOrder,
ooLinksFirst, ooNodesFirst)
*	Added a published property DrawObjectOrder (default value
ooLinksFirst for backward compatible behaviour)
*	Rewritten the TSimpleGraph.Draw method a little.

Below is a small snippet to show you how this influences the drawing of
GraphObjects, you can compare it to the existing code in this method which
always draws links first and the other objects on top of that. However this
ignores the ZOrder and the need for it to happen the other way around (as it
does in my case).

Hope to write about more changes I've made and add even more usable changes
soon...

Regards,
Marco.

procedure TSimpleGraph.Draw(Canvas: TCanvas);
var
  I: Integer;

  (* MW *)
  procedure DrawObjects(aType: TDrawObjects);
  var
    i: integer;
  begin
    for I := 0 to Objects.Count - 1 do
      with Objects[I] do
        if (aType = doAll) or
          (IsLink and (aType = doLinks)) or
          (not IsLink and (aType = doNodes)) then
          Draw(Canvas);
  end;

begin
  (* MW *)
  case DrawObjectOrder of
    ooNodesFirst: DrawObjects(doNodes);
    ooLinksFirst: DrawObjects(doLinks);
  end;

  if Linking and ((State = gsMoveLink) or
    ((CommandMode = cmLinkNodes) and (FirstNodeOfLink <> nil))) then
  begin
    Canvas.Pen.Mode := pmNot;
    Canvas.Pen.Width := 1;
    Canvas.Pen.Style := psSolid;
    DefaultLinkClass.DrawDraft(Canvas,
      Rect(StartPoint.X, StartPoint.Y, StopPoint.X, StopPoint.Y));
  end;

  (* MW *)
  case DrawObjectOrder of
    ooNodesFirst: DrawObjects(doLinks);
    ooLinksFirst: DrawObjects(doNodes);
  else
    DrawObjects(doAll);
  end;

  if Linking and (CommandMode = cmLinkNodes) and (FirstNodeOfLink <> nil)
then
  ...
  ...

[Extgraph-developer] TGraphNode.Parent

[Marco W. <in...@ca...>]

Hi guys,

Just some thoughts (and work in progress) on the GraphObjects...

*Parent*
I'm building some code into the TGraphNode to support some kind of 
Parent much like the TControl does in the VCL. This is for the obvious 
reason to support a grouping like behaviour. Parents would paint 
themselves first and in addition it would paint it's children. Similarly 
if moved, it would move the children. In several vector drawing tools it 
would be considered some kind of grouping where the parent is simply the 
first object in the list.

*Layer*
I'm also thinking about layers similar to this. Every GraphObject would 
be defaulted to the single layer in the TSimpleGraph. The Graph could 
have several layers and including a visible property and an ActiveLayer 
index. It would certainly add value to the current ZOrder and individual 
visible states.

*Lock*
Simple to realize is the lock propert on individual Nodes instead of the 
entire Graph. This could be finetuned into the layering and parenting...

So far my thoughts. As work progresses I'll keep you posted. In the 
meanwhile I've discovered that I cannot add Tasks and stuff in the 
SourceForge site. Is there something you can do to arrange this?

Marco.

-- 
Phone   +31 650.69.27.31
Email   ma...@wo...
ICQ     432807
Skype   marcowobben

"Trust is a future that brings what is needed, exactly how it is needed"

[Extgraph-developer] TSimplegraph.DrawObjectOrder

[Marco W. <in...@ca...>]

Hi guys,

My first real need and adjustment to the code is the being able to 
influence the drawing order of the GraphObjects. For this to work I've 
done the following:

    * Introduced a new TDrawObjectOrder enumeration (ooZOrder,
      ooLinksFirst, ooNodesFirst)
    * Added a published property DrawObjectOrder (default value
      ooLinksFirst for backward compatible behaviour)
    * Rewritten the TSimpleGraph.Draw method a little.

Below is a small snippet to show you how this influences the drawing of 
GraphObjects, you can compare it to the existing code in this method 
which always draws links first and the other objects on top of that. 
However this ignores the ZOrder and the need for it to happen the other 
way around (as it does in my case).

Hope to write about more changes I've made and add even more usable 
changes soon...

Regards,
Marco.

procedure TSimpleGraph.Draw(Canvas: TCanvas);
var
  I: Integer;

  (* MW *)
  procedure DrawObjects(aType: TDrawObjects);
  var
    i: integer;
  begin
    for I := 0 to Objects.Count - 1 do
      with Objects[I] do
        if (aType = doAll) or
          (IsLink and (aType = doLinks)) or
          (not IsLink and (aType = doNodes)) then
          Draw(Canvas);
  end;

begin
  (* MW *)
  case DrawObjectOrder of
    ooNodesFirst: DrawObjects(doNodes);
    ooLinksFirst: DrawObjects(doLinks);
  end;

  if Linking and ((State = gsMoveLink) or
    ((CommandMode = cmLinkNodes) and (FirstNodeOfLink <> nil))) then
  begin
    Canvas.Pen.Mode := pmNot;
    Canvas.Pen.Width := 1;
    Canvas.Pen.Style := psSolid;
    DefaultLinkClass.DrawDraft(Canvas,
      Rect(StartPoint.X, StartPoint.Y, StopPoint.X, StopPoint.Y));
  end;

  (* MW *)
  case DrawObjectOrder of
    ooNodesFirst: DrawObjects(doLinks);
    ooLinksFirst: DrawObjects(doNodes);
  else
    DrawObjects(doAll);
  end;

  if Linking and (CommandMode = cmLinkNodes) and (FirstNodeOfLink <> 
nil) then
  ...
  ...

RE: [Extgraph-developer] Some Observations Using ExtGraph

[Pavel V. <cz3...@ti...>]

Hi Mark and Stefan,
Unicode support is already implemented, while Unicode is in fact our "nat=
ive"
encoding of xml files. UTF8, to be more precise In the new version Unicod=
e
support will be enhanced to UTF16.
Regarding data association, there is also already something implemented.
In the example published on project home pages (see how to create dynamic=

svg) there is an working example where you can see attachment of two type=
s
of data: svg data and code. SVG data are processed by graph canvas, XPasc=
al
code is processed by underlying engine and is used to change SVG data. Al=
though
I do not consider it final state, as processing and data handling capabil=
ities
will be enhanced, even now you can do some node specific operations (like=

reading data from text file and change node visual representation) , now
you can also store data (other than svg), to try it just add some xml chi=
ld
element and add whatever you want. You can see and edit this data in inte=
grated
xml editor. These things works now. What is missing is integrated event
based mechanism. Now there is only one event implemented - redraw of grap=
h,
when OnRefresh script is called (in the example analog clock change shape=

according to computer time).
Hopefully example on http://extgraph.sourceforge.net/docs/howto/svgclocks=
.htm
shows the principles - the way how to create shapes, change them dynamcal=
ly
according to external changes like change of computer clock  and how to
link graphics, data and code.
You can also look at Unicode suport - create child node in svg file,  wri=
te
some text in UTF8 as and xml element value or xml comment and look at it
in internal editor (double click svg node), you should see national chara=
cters.

Pavel


>Subject: RE: [Extgraph-developer] Some Observations Using ExtGraph
>From: "Stefan Melis" <ste...@po...>
>To: <ext...@li...>
>Date: Fri, 19 Nov 2004 16:52:32 +0100
>
>
>Mark,
>
>> The two things I'm particularly keen on are unicode support and the
>ability to associated arbitrary data with each node in the graph. I saw
>some 
>> discussion on associating data with nodes in the Delphi Area forums.
>What are the plans for unicode support?
>
>Since I don't specifically need unicode support I haven't thought about
>it yet.
>That doesn't mean it's a bad idea, quite the contrary perhaps ;)
>I have to admit though that my experience with unicode is limited. Maybe=

>Pavel knows more about it?
>
>
>Stefan
>

>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer


-------------------------- 
Pos=EDlejte SMS p=F8es internet zdarma a bez reklamy. Pouze s TISCALI. 
V=EDce na http://www.tiscali.cz 

RE: [Extgraph-developer] Some Observations Using ExtGraph

[Stefan M. <ste...@po...>]

Mark,

> The two things I'm particularly keen on are unicode support and the
ability to associated arbitrary data with each node in the graph. I saw
some=20
> discussion on associating data with nodes in the Delphi Area forums.
What are the plans for unicode support?

Since I don't specifically need unicode support I haven't thought about
it yet.
That doesn't mean it's a bad idea, quite the contrary perhaps ;)
I have to admit though that my experience with unicode is limited. Maybe
Pavel knows more about it?


Stefan

Re: [Extgraph-developer] Some Observations Using ExtGraph

[Mark B. <ma...@na...>]

Stefan Melis wrote:

>One other thing, since we are in pre-beta we can still use a lot of
>input as to features people would like to see implemented. Please let us
>now how Simple/ExtGraph works out for you and let us now what features
>you think are missing.
>

The two things I'm particularly keen on are unicode support and the 
ability to associated arbitrary data with each node in the graph. I saw 
some discussion on associating data with nodes in the Delphi Area 
forums. What are the plans for unicode support?

-Mark

RE: [Extgraph-developer] Some Observations Using ExtGraph

[Stefan M. <ste...@po...>]

Mark,

Thank you very much for your comments.
Since we've only just started converting from SimpleGraph (which is
originally written by Kambiz R. Kajostah and is subject to his license)
to ExtGraph (which is subject to MPL) we're bound to find more 'errors'
like you did. The CVS is now used to distribute code between the
developers and since we are in pre-beta we haven't been paying much
attention to these points as opposed to implementing new functionallity.
Sure enough, it's good to see that other people do notice these things
and point them out, again, thank you.

One other thing, since we are in pre-beta we can still use a lot of
input as to features people would like to see implemented. Please let us
now how Simple/ExtGraph works out for you and let us now what features
you think are missing.


Cheers,
Stefan

Ps. Pavel, I've been looking at the "gridding" for the PolyLine
TGraphLink I think I've found a "nicer" way of implementing this.
Instead of defining the entire Grid every time a node is moved, I could
integrate the Tgrid into TExtGraph and only recalc the Grid's area that
is being altered (by movement of a node or such).


-----Oorspronkelijk bericht-----
Van: ext...@li...
[mailto:ext...@li...] Namens Mark
Boland
Verzonden: donderdag 18 november 2004 2:15
Aan: ext...@li...
Onderwerp: [Extgraph-developer] Some Observations Using ExtGraph

Hi,

I stumbled across ExtGraph/SimpleGraph yesterday and I'm evaluating it
for use in an application. Here are a few things I've noticed working
with the source from CVS.

- No packages in CVS. Adding packages for say Delphi 6 to 2005 would be
handy.
- No license information in source. There should be a prominate notice
at the top of the source files to say it's under the MPL.
- I reckon RegisterComponents for TSimpleGraph should use 'ExtGraph' as
opposed to 'DelphiArea'.

One thing I noticed was that the verison number (in the comments at the
top of the source for) for TSimpleGraph from CVS is 1.52 where as if you
download the SimpleGraph file release the version number is 1.542. Is
there any particular reason for this?

-Mark


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS
DOWNLOAD - A multidimensional database that combines robust object and
relational technologies, making it a perfect match for Java, C++,COM,
XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer

[Extgraph-developer] Some Observations Using ExtGraph

[Mark B. <ma...@na...>]

Hi,

I stumbled across ExtGraph/SimpleGraph yesterday and I'm evaluating it 
for use in an application. Here are a few things I've noticed working 
with the source from CVS.

- No packages in CVS. Adding packages for say Delphi 6 to 2005 would be 
handy.
- No license information in source. There should be a prominate notice 
at the top of the source files to say it's under the MPL.
- I reckon RegisterComponents for TSimpleGraph should use 'ExtGraph' as 
opposed to 'DelphiArea'.

One thing I noticed was that the verison number (in the comments at the 
top of the source for) for TSimpleGraph from CVS is 1.52 where as if you 
download the SimpleGraph file release the version number is 1.542. Is 
there any particular reason for this?

-Mark

[Extgraph-developer] New web pages

[Pavel V. <cz3...@ti...>]

Updated pages:
http://extgraph.sourceforge.net/index.html
Comments welcomed as usual.
I am working on TXMLPartner code integration. I have to change a lot of
things in XML framework, but it is starting to work.
I hope that the change will be for good.
Pavel

_________________________________________________________________________=


Uspora az 30 % na POVINNEM RUCENI! Mimoradne ceny pro auta starsi 10 let!=

Pojisteni pripojneho vozidla zdarma. 800 100 777

http://adsweb.tiscali.cz/csob.html

RE: [Extgraph-developer] RE: XML framework

[Pavel V. <cz3...@ti...>]

SynEdit or JVCL HLEditor? That's not easy decision.
JVCL HLEditor has two advantages:
- it is part of much broader package, and JCLJVCL we will use anyway, bec=
ause
of XPascal, so we will have  one dependency, instead of two.
- JVCL HLEditor supports  autocompletion and templates. As far as I know
Synedit supports autocompletion only.

On the other hand SynEdit has more hilighters available and, as you menti=
oned,
is used more often.
There are of course more differencies, like that SynEdit hilighter looks
better, but  IMHO not so important.

>-- P=F9vodn=ED zpr=E1va --
>Subject: RE: [Extgraph-developer] RE: XML framework
>From: "Stefan Melis" <ste...@po...>
>To: <Ext...@li...>
>Date: Wed, 3 Nov 2004 09:31:15 +0100
>
>
>I guess it's a good thing we can mess about with our baby's genetics tha=
n
>;)
>Here at work we also use the SynEdit package, I like how it works and th=
ere's
>a very active community around it.
>But then again, there's nothing wrong with the JEDI project... 
>
>Cheers,
>Stefan
>
>
>-----Oorspronkelijk bericht-----
>Van: ext...@li... [mailto:extgraph-dev=
elo...@li...]
>Namens Pavel Vrecion
>Verzonden: dinsdag 2 november 2004 13:01
>Aan: Ext...@li...
>Onderwerp: [Extgraph-developer] RE: XML framework
>
>I hope that mixing will bring the best, but there is famous saying (from=

>Oscar Wild I think).
>When one woman said to him that she is pretty and he is clever, so we to=
gether
>can have pretty and clever children, he replied that opposite outcome i.=
e.
>ugly and dull children is also possible.

>So I will try my best to have nice and clever child, feature rich, simpl=
e,
>fast and well documented and supported XML framework.
>
>Syntax hilighting is based on TJvHLEditor which is part of  JCL/JVCL pro=
ject
>lead by JEDI  see http://www.delphi-jedi.org.
>There is another good option SynEdit, which is on also one of sf project=
s.
>
>
>
>>-- P=F9vodn=ED zpr=E1va --
>>Subject: RE: [Extgraph-developer] (no subject)
>>From: "Stefan Melis" <ste...@po...>
>>To: <Ext...@li...>
>>Date: Tue, 2 Nov 2004 12:08:41 +0100
>>
>>
>>Pavel,
>>
>>I think that if you can combine the best of both worlds this must lead
>to
>>the best solution.
>>We might not need all the features XMLPartner offers us now but we 
>>might need them later. Implementing it now would be far more easy than

>>when there's a jungle of code surrounding it.
>>As I am not up-to-date with XML, xsl, xpath and really anything 
>>surrounding XML, I would like to trust you in making the right 
>>decision, as you seem to know a hell of a lot more about it than I.
>>
>>One other thing, I saw in the (xgraph) demo app that you use a 
>>Syntax-highlighter, which one are you using for this?
>>
>>Cheers,
>>Stefan
>>
>>-----Oorspronkelijk bericht-----
>>Van: ext...@li... 
>>[mailto:ext...@li...]
>>Namens Pavel Vrecion
>>Verzonden: dinsdag 2 november 2004 11:31
>>Aan: Ext...@li...
>>Onderwerp: [Extgraph-developer] (no subject)
>>
>>I took a look at TurboPower XML Partner which is Pascal implementation
>of
>>XML DOM (Document Object Model) and other XML related technologes like
>SAX
>>(event based) parser, xpath and xsl processing ....
>>Question is is to switch to it.
>>I would like to summarize pros and cons, but before I must describe 
>>current status a little.
>>In current version XML processing is based on my library which I call
XObjects.
>>Intention of XObjects is to create easy to use XML framework aimed 
>>especially at database and xml processing.
>>From implemntation recommendations from w3c.org it differs in following=

>areas.
>>Condtradictory to usual DOM it works with fewer objects. Typical 
>>example is XML element and attribute. Usually these are implemented as

>>different objects,  I use only one for both XML node which has type 
>>flag. Advantages of this approach is that there is less to explain, 
>>programmer can work,
>learn
>>and understand fewer objects and processing of XML data is more straigh=
tforward.
>> For example you need to store incomming XML data into database. 
>>Typically sometimes are data stored in elements and/or attributes. 
>>Using usual DOM implementation you must find if requiered are stored in=

>
>>element or attribute and then use DOM object accordingly. Using 
>>XObjects you just do not care while both are the same and you work with=

>Node.Name and Node.Value.
>>Another added value is data type. XML can be typed and XObjects takes

>>care about typecastings and conersions. You can use for example 
>>Node.AsString, AsNumber, AsBoolean, AsDate ....  Sometimes decimal 
>>deilimiter is point, sometimes comma. In datetime types there is jungle=
.
>>Another valuable trick is that during parsing element names are not 
>>stored in String value, but it is refernce to sorted StringList. It 
>>means that
>redundant
>>in memory strings are automatically removed, and taska like finding all=

>element
>>with given name is much faster, while binary search and direct 
>>addressing is used instead of  repeated sequence searches.
>>
>>I compared performace of XObjects and XMLPartner on large xml files 
>>(2MB
>>+) and I found expected results. While XObjects parsing time is longer,=

>>it consumes less memory. In both cases, memory and time is about 30%.

>>I have also found that TurboPower made DOM extensions very similar to
mine.
>>For example they have option to create Attribute and Element string lis=
ts.
>>
>>I have discussed advantages of XObjects , now I will make commented 
>>list of XML Partner TurboPower solution.
>>- XML Partner has broader support of character encoding, especially 
>>they suport more UTF versions. It seams that there is not sufficient 
>>support
>of
>>national character sets, which is neither in XObjects, but is in 
>>OpenXML,  which is yet another pascal XML DOM implementation.
>>- SAX like event based parser, in XObjects misiing
>>- faster, but more memory consuming, parsing
>>- validation against DTD, good error handling
>>- XPath implementation, feature that is in XObjects in development
>>- buffered streams, this feature enables processing of data larger than=

>available
>>memory, missing in XObjects
>>- XSLT processing and transformations to HTML, XML, text and RTF, very
>good
>>feature that can enhance processing capabalities in the future
>>- very good documentation 500+ pages manual and winhelp, XObjects has

>>almost none
>>- broader support and probably stability, while XML Partner has been 
>>used longer and in far more installations.
>>
>>This leads me to an idea to use extended XML Partner and switch to it

>>from XObjects. Features probably can enhanced so, that we can have the

>>best
>from
>>both worlds. It  would probably also mean to became a developer of XML
>Partner
>>to ensure, that new added features will be present in future releases.
>>


_________________________________________________________________________=


Uspora az 30 % na POVINNEM RUCENI! Mimoradne ceny pro auta starsi 10 let!=

Pojisteni pripojneho vozidla zdarma. 800 100 777

http://adsweb.tiscali.cz/csob.html

RE: [Extgraph-developer] RE: XML framework

[Stefan M. <ste...@po...>]

I guess it's a good thing we can mess about with our baby's genetics =
than ;)
Here at work we also use the SynEdit package, I like how it works and =
there's a very active community around it.
But then again, there's nothing wrong with the JEDI project...=20

Cheers,
Stefan


-----Oorspronkelijk bericht-----
Van: ext...@li... =
[mailto:ext...@li...] Namens Pavel =
Vrecion
Verzonden: dinsdag 2 november 2004 13:01
Aan: Ext...@li...
Onderwerp: [Extgraph-developer] RE: XML framework

I hope that mixing will bring the best, but there is famous saying (from =
Oscar Wild I think).
When one woman said to him that she is pretty and he is clever, so we =
together can have pretty and clever children, he replied that opposite =
outcome i.e.
ugly and dull children is also possible.
So I will try my best to have nice and clever child, feature rich, =
simple, fast and well documented and supported XML framework.

Syntax hilighting is based on TJvHLEditor which is part of  JCL/JVCL =
project lead by JEDI  see http://www.delphi-jedi.org.
There is another good option SynEdit, which is on also one of sf =
projects.



>-- P=F9vodn=ED zpr=E1va --
>Subject: RE: [Extgraph-developer] (no subject)
>From: "Stefan Melis" <ste...@po...>
>To: <Ext...@li...>
>Date: Tue, 2 Nov 2004 12:08:41 +0100
>
>
>Pavel,
>
>I think that if you can combine the best of both worlds this must lead
to
>the best solution.
>We might not need all the features XMLPartner offers us now but we=20
>might need them later. Implementing it now would be far more easy than=20
>when there's a jungle of code surrounding it.
>As I am not up-to-date with XML, xsl, xpath and really anything=20
>surrounding XML, I would like to trust you in making the right=20
>decision, as you seem to know a hell of a lot more about it than I.
>
>One other thing, I saw in the (xgraph) demo app that you use a=20
>Syntax-highlighter, which one are you using for this?
>
>Cheers,
>Stefan
>
>-----Oorspronkelijk bericht-----
>Van: ext...@li...=20
>[mailto:ext...@li...]
>Namens Pavel Vrecion
>Verzonden: dinsdag 2 november 2004 11:31
>Aan: Ext...@li...
>Onderwerp: [Extgraph-developer] (no subject)
>
>I took a look at TurboPower XML Partner which is Pascal implementation
of
>XML DOM (Document Object Model) and other XML related technologes like
SAX
>(event based) parser, xpath and xsl processing ....
>Question is is to switch to it.
>I would like to summarize pros and cons, but before I must describe=20
>current status a little.
>In current version XML processing is based on my library which I call =
XObjects.
>Intention of XObjects is to create easy to use XML framework aimed=20
>especially at database and xml processing.
>From implemntation recommendations from w3c.org it differs in following
areas.
>Condtradictory to usual DOM it works with fewer objects. Typical=20
>example is XML element and attribute. Usually these are implemented as=20
>different objects,  I use only one for both XML node which has type=20
>flag. Advantages of this approach is that there is less to explain,=20
>programmer can work,
learn
>and understand fewer objects and processing of XML data is more =
straightforward.
> For example you need to store incomming XML data into database.=20
>Typically sometimes are data stored in elements and/or attributes.=20
>Using usual DOM implementation you must find if requiered are stored in =

>element or attribute and then use DOM object accordingly. Using=20
>XObjects you just do not care while both are the same and you work with =
Node.Name and Node.Value.
>Another added value is data type. XML can be typed and XObjects takes=20
>care about typecastings and conersions. You can use for example=20
>Node.AsString, AsNumber, AsBoolean, AsDate ....  Sometimes decimal=20
>deilimiter is point, sometimes comma. In datetime types there is =
jungle.
>Another valuable trick is that during parsing element names are not=20
>stored in String value, but it is refernce to sorted StringList. It=20
>means that
redundant
>in memory strings are automatically removed, and taska like finding all
element
>with given name is much faster, while binary search and direct=20
>addressing is used instead of  repeated sequence searches.
>
>I compared performace of XObjects and XMLPartner on large xml files=20
>(2MB
>+) and I found expected results. While XObjects parsing time is longer,
>it consumes less memory. In both cases, memory and time is about 30%.=20
>I have also found that TurboPower made DOM extensions very similar to =
mine.
>For example they have option to create Attribute and Element string =
lists.
>
>I have discussed advantages of XObjects , now I will make commented=20
>list of XML Partner TurboPower solution.
>- XML Partner has broader support of character encoding, especially=20
>they suport more UTF versions. It seams that there is not sufficient=20
>support
of
>national character sets, which is neither in XObjects, but is in=20
>OpenXML,  which is yet another pascal XML DOM implementation.
>- SAX like event based parser, in XObjects misiing
>- faster, but more memory consuming, parsing
>- validation against DTD, good error handling
>- XPath implementation, feature that is in XObjects in development
>- buffered streams, this feature enables processing of data larger than
available
>memory, missing in XObjects
>- XSLT processing and transformations to HTML, XML, text and RTF, very
good
>feature that can enhance processing capabalities in the future
>- very good documentation 500+ pages manual and winhelp, XObjects has=20
>almost none
>- broader support and probably stability, while XML Partner has been=20
>used longer and in far more installations.
>
>This leads me to an idea to use extended XML Partner and switch to it=20
>from XObjects. Features probably can enhanced so, that we can have the=20
>best
from
>both worlds. It  would probably also mean to became a developer of XML
Partner
>to ensure, that new added features will be present in future releases.
>
>
>_______________________________________________________________________
>__
>
>Uspora az 30 % na POVINNEM RUCENI! Mimoradne ceny pro auta starsi 10 =
let!
>Pojisteni pripojneho vozidla zdarma. 800 100 777
>
>http://adsweb.tiscali.cz/csob.html
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE LinuxWorld=20
>Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=CCk
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE LinuxWorld=20
>Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dclick
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer


_________________________________________________________________________=


Uspora az 30 % na POVINNEM RUCENI! Mimoradne ceny pro auta starsi 10 =
let!
Pojisteni pripojneho vozidla zdarma. 800 100 777

http://adsweb.tiscali.cz/csob.html





-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE LinuxWorld =
Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=CCk
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer

[Extgraph-developer] RE: XML framework

[Pavel V. <cz3...@ti...>]

I hope that mixing will bring the best, but there is famous saying (from
Oscar Wild I think).
When one woman said to him that she is pretty and he is clever, so we tog=
ether
can have pretty and clever children, he replied that opposite outcome i.e=
.
ugly and dull children is also possible.
So I will try my best to have nice and clever child, feature rich, simple=
,
fast and well documented and supported XML framework.

Syntax hilighting is based on TJvHLEditor which is part of  JCL/JVCL proj=
ect
lead by JEDI  see http://www.delphi-jedi.org.
There is another good option SynEdit, which is on also one of sf projects=
.



>-- P=F9vodn=ED zpr=E1va --
>Subject: RE: [Extgraph-developer] (no subject)
>From: "Stefan Melis" <ste...@po...>
>To: <Ext...@li...>
>Date: Tue, 2 Nov 2004 12:08:41 +0100
>
>
>Pavel,
>
>I think that if you can combine the best of both worlds this must lead
to
>the best solution.
>We might not need all the features XMLPartner offers us now but we might=

>need them later. Implementing it now would be far more easy than when th=
ere's
>a jungle of code surrounding it.
>As I am not up-to-date with XML, xsl, xpath and really anything surround=
ing
>XML, I would like to trust you in making the right decision, as you seem=

>to know a hell of a lot more about it than I.
>
>One other thing, I saw in the (xgraph) demo app that you use a Syntax-hi=
ghlighter,
>which one are you using for this?
>
>Cheers,
>Stefan
>
>-----Oorspronkelijk bericht-----
>Van: ext...@li... [mailto:extgraph-dev=
elo...@li...]
>Namens Pavel Vrecion
>Verzonden: dinsdag 2 november 2004 11:31
>Aan: Ext...@li...
>Onderwerp: [Extgraph-developer] (no subject)
>
>I took a look at TurboPower XML Partner which is Pascal implementation
of
>XML DOM (Document Object Model) and other XML related technologes like
SAX
>(event based) parser, xpath and xsl processing ....
>Question is is to switch to it.
>I would like to summarize pros and cons, but before I must describe curr=
ent
>status a little.
>In current version XML processing is based on my library which I call XO=
bjects.
>Intention of XObjects is to create easy to use XML framework aimed espec=
ially
>at database and xml processing.
>From implemntation recommendations from w3c.org it differs in following
areas.
>Condtradictory to usual DOM it works with fewer objects. Typical example=

>is XML element and attribute. Usually these are implemented as different=

>objects,  I use only one for both XML node which has type flag. Advantag=
es
>of this approach is that there is less to explain, programmer can work,
learn
>and understand fewer objects and processing of XML data is more straight=
forward.
> For example you need to store incomming XML data into database. Typical=
ly
>sometimes are data stored in elements and/or attributes. Using usual DOM=

>implementation you must find if requiered are stored in element or attri=
bute
>and then use DOM object accordingly. Using XObjects you just do not care=

>while both are the same and you work with Node.Name and Node.Value.
>Another added value is data type. XML can be typed and XObjects takes ca=
re
>about typecastings and conersions. You can use for example Node.AsString=
,
>AsNumber, AsBoolean, AsDate ....  Sometimes decimal deilimiter is point,=

>sometimes comma. In datetime types there is jungle.
>Another valuable trick is that during parsing element names are not stor=
ed
>in String value, but it is refernce to sorted StringList. It means that
redundant
>in memory strings are automatically removed, and taska like finding all
element
>with given name is much faster, while binary search and direct addressin=
g
>is used instead of  repeated sequence searches.
>
>I compared performace of XObjects and XMLPartner on large xml files (2MB=

>+) and I found expected results. While XObjects parsing time is longer,
>it consumes less memory. In both cases, memory and time is about 30%. 
>I have also found that TurboPower made DOM extensions very similar to mi=
ne.
>For example they have option to create Attribute and Element string list=
s.
>
>I have discussed advantages of XObjects , now I will make commented list=

>of XML Partner TurboPower solution.
>- XML Partner has broader support of character encoding, especially they=

>suport more UTF versions. It seams that there is not sufficient support
of
>national character sets, which is neither in XObjects, but is in OpenXML=
,
> which is yet another pascal XML DOM implementation.
>- SAX like event based parser, in XObjects misiing
>- faster, but more memory consuming, parsing
>- validation against DTD, good error handling
>- XPath implementation, feature that is in XObjects in development
>- buffered streams, this feature enables processing of data larger than
available
>memory, missing in XObjects
>- XSLT processing and transformations to HTML, XML, text and RTF, very
good
>feature that can enhance processing capabalities in the future
>- very good documentation 500+ pages manual and winhelp, XObjects has al=
most
>none
>- broader support and probably stability, while XML Partner has been use=
d
>longer and in far more installations.
>
>This leads me to an idea to use extended XML Partner and switch to it fr=
om
>XObjects. Features probably can enhanced so, that we can have the best
from
>both worlds. It  would probably also mean to became a developer of XML
Partner
>to ensure, that new added features will be present in future releases.
>
>
>________________________________________________________________________=
_
>
>Uspora az 30 % na POVINNEM RUCENI! Mimoradne ceny pro auta starsi 10 let=
!
>Pojisteni pripojneho vozidla zdarma. 800 100 777
>
>http://adsweb.tiscali.cz/csob.html
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Read=
er's
>Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=CCk
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dclick
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer


_________________________________________________________________________=


Uspora az 30 % na POVINNEM RUCENI! Mimoradne ceny pro auta starsi 10 let!=

Pojisteni pripojneho vozidla zdarma. 800 100 777

http://adsweb.tiscali.cz/csob.html

RE: [Extgraph-developer] (no subject)

[Stefan M. <ste...@po...>]

Pavel,

I think that if you can combine the best of both worlds this must lead =
to the best solution.
We might not need all the features XMLPartner offers us now but we might =
need them later. Implementing it now would be far more easy than when =
there's a jungle of code surrounding it.
As I am not up-to-date with XML, xsl, xpath and really anything =
surrounding XML, I would like to trust you in making the right decision, =
as you seem to know a hell of a lot more about it than I.

One other thing, I saw in the (xgraph) demo app that you use a =
Syntax-highlighter, which one are you using for this?

Cheers,
Stefan

-----Oorspronkelijk bericht-----
Van: ext...@li... =
[mailto:ext...@li...] Namens Pavel =
Vrecion
Verzonden: dinsdag 2 november 2004 11:31
Aan: Ext...@li...
Onderwerp: [Extgraph-developer] (no subject)

I took a look at TurboPower XML Partner which is Pascal implementation =
of XML DOM (Document Object Model) and other XML related technologes =
like SAX (event based) parser, xpath and xsl processing ....
Question is is to switch to it.
I would like to summarize pros and cons, but before I must describe =
current status a little.
In current version XML processing is based on my library which I call =
XObjects.
Intention of XObjects is to create easy to use XML framework aimed =
especially at database and xml processing.
From implemntation recommendations from w3c.org it differs in following =
areas. Condtradictory to usual DOM it works with fewer objects. Typical =
example is XML element and attribute. Usually these are implemented as =
different objects,  I use only one for both XML node which has type =
flag. Advantages of this approach is that there is less to explain, =
programmer can work, learn and understand fewer objects and processing =
of XML data is more straightforward.
 For example you need to store incomming XML data into database. =
Typically sometimes are data stored in elements and/or attributes. Using =
usual DOM implementation you must find if requiered are stored in =
element or attribute and then use DOM object accordingly. Using XObjects =
you just do not care while both are the same and you work with Node.Name =
and Node.Value.
Another added value is data type. XML can be typed and XObjects takes =
care about typecastings and conersions. You can use for example =
Node.AsString, AsNumber, AsBoolean, AsDate ....  Sometimes decimal =
deilimiter is point, sometimes comma. In datetime types there is jungle.
Another valuable trick is that during parsing element names are not =
stored in String value, but it is refernce to sorted StringList. It =
means that redundant in memory strings are automatically removed, and =
taska like finding all element with given name is much faster, while =
binary search and direct addressing is used instead of  repeated =
sequence searches.

I compared performace of XObjects and XMLPartner on large xml files (2MB
+) and I found expected results. While XObjects parsing time is longer,
it consumes less memory. In both cases, memory and time is about 30%.=20
I have also found that TurboPower made DOM extensions very similar to =
mine.
For example they have option to create Attribute and Element string =
lists.

I have discussed advantages of XObjects , now I will make commented list =
of XML Partner TurboPower solution.
- XML Partner has broader support of character encoding, especially they =
suport more UTF versions. It seams that there is not sufficient support =
of national character sets, which is neither in XObjects, but is in =
OpenXML,  which is yet another pascal XML DOM implementation.
- SAX like event based parser, in XObjects misiing
- faster, but more memory consuming, parsing
- validation against DTD, good error handling
- XPath implementation, feature that is in XObjects in development
- buffered streams, this feature enables processing of data larger than =
available memory, missing in XObjects
- XSLT processing and transformations to HTML, XML, text and RTF, very =
good feature that can enhance processing capabalities in the future
- very good documentation 500+ pages manual and winhelp, XObjects has =
almost none
- broader support and probably stability, while XML Partner has been =
used longer and in far more installations.

This leads me to an idea to use extended XML Partner and switch to it =
from XObjects. Features probably can enhanced so, that we can have the =
best from both worlds. It  would probably also mean to became a =
developer of XML Partner to ensure, that new added features will be =
present in future releases.


_________________________________________________________________________=


Uspora az 30 % na POVINNEM RUCENI! Mimoradne ceny pro auta starsi 10 =
let!
Pojisteni pripojneho vozidla zdarma. 800 100 777

http://adsweb.tiscali.cz/csob.html





-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE LinuxWorld =
Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=CCk
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer

[Extgraph-developer] (no subject)

[Pavel V. <cz3...@ti...>]

I took a look at TurboPower XML Partner which is Pascal implementation of=

XML DOM (Document Object Model) and other XML related technologes like SA=
X
(event based) parser, xpath and xsl processing ....
Question is is to switch to it.
I would like to summarize pros and cons, but before I must describe curre=
nt
status a little.
In current version XML processing is based on my library which I call XOb=
jects.
Intention of XObjects is to create easy to use XML framework aimed especi=
ally
at database and xml processing.
From implemntation recommendations from w3c.org it differs in following
areas. Condtradictory to usual DOM it works with fewer objects. Typical
example is XML element and attribute. Usually these are implemented as di=
fferent
objects,  I use only one for both XML node which has type flag. Advantage=
s
of this approach is that there is less to explain, programmer can work,
learn and understand fewer objects and processing of XML data is more str=
aightforward.
 For example you need to store incomming XML data into database. Typicall=
y
sometimes are data stored in elements and/or attributes. Using usual DOM
implementation you must find if requiered are stored in element or attrib=
ute
and then use DOM object accordingly. Using XObjects you just do not care
while both are the same and you work with Node.Name and Node.Value.
Another added value is data type. XML can be typed and XObjects takes car=
e
about typecastings and conersions. You can use for example Node.AsString,=

AsNumber, AsBoolean, AsDate ....  Sometimes decimal deilimiter is point,
sometimes comma. In datetime types there is jungle.
Another valuable trick is that during parsing element names are not store=
d
in String value, but it is refernce to sorted StringList. It means that
redundant in memory strings are automatically removed, and taska like fin=
ding
all element with given name is much faster, while binary search and direc=
t
addressing is used instead of  repeated sequence searches.

I compared performace of XObjects and XMLPartner on large xml files (2MB
+) and I found expected results. While XObjects parsing time is longer,
it consumes less memory. In both cases, memory and time is about 30%. 
I have also found that TurboPower made DOM extensions very similar to min=
e.
For example they have option to create Attribute and Element string lists=
.

I have discussed advantages of XObjects , now I will make commented list
of XML Partner TurboPower solution.
- XML Partner has broader support of character encoding, especially they
suport more UTF versions. It seams that there is not sufficient support
of national character sets, which is neither in XObjects, but is in OpenX=
ML,
 which is yet another pascal XML DOM implementation.
- SAX like event based parser, in XObjects misiing
- faster, but more memory consuming, parsing
- validation against DTD, good error handling
- XPath implementation, feature that is in XObjects in development
- buffered streams, this feature enables processing of data larger than
available memory, missing in XObjects
- XSLT processing and transformations to HTML, XML, text and RTF, very go=
od
feature that can enhance processing capabalities in the future
- very good documentation 500+ pages manual and winhelp, XObjects has alm=
ost
none
- broader support and probably stability, while XML Partner has been used=

longer and in far more installations.

This leads me to an idea to use extended XML Partner and switch to it fro=
m
XObjects. Features probably can enhanced so, that we can have the best fr=
om
both worlds. It  would probably also mean to became a developer of XML Pa=
rtner
to ensure, that new added features will be present in future releases.


_________________________________________________________________________=


Uspora az 30 % na POVINNEM RUCENI! Mimoradne ceny pro auta starsi 10 let!=

Pojisteni pripojneho vozidla zdarma. 800 100 777

http://adsweb.tiscali.cz/csob.html

RE: [Extgraph-developer] RE: ExtGraph web changes

[Stefan M. <ste...@po...>]

Hi,

Alrighty... Indeed, seeing people actually use the framework would be
very cool for starters.
With regard to SVG, it would indeed not be so good to implement the same
thing twice. I too, would prefer a SVG-only implementation of the nodes.
I will have to play around with the current version a little to get the
hang of SVG / Xpascal and such, but it seems pretty straighforward.
For now an addition to SVG 1.1 that will allow ConnectionPoints will be
enough to keep us going for a while...

But first, some playing around in the fresh code at college tonight! :)
Class is about Operating System design, so I'll probably be able to
*not* pay attention ;)

Cheers,
Stefan

-----Oorspronkelijk bericht-----
Van: Pavel Vrecion [mailto:pav...@pl...]=20
Verzonden: maandag 1 november 2004 16:46
Aan: Stefan Melis
Onderwerp: Re: [Extgraph-developer] RE: ExtGraph web changes

Hi,
regarding money, I mentioned ridiculous amounts, well just fun. I do not
have any expectations either.
And I think that money should be collected through companies that use
the system for business purposes, and we are far from such situation.
At this point donations in the form of usage, bug reporting and
cooperation will satisfy me, and I will consider it a great success.=20
There are many projects that never manage to reach this point. Even to
reach this mark there is still a lot to do.

I will not be against some profit, but I not will be unsatisfied, if
nothing in terms of money will come out of it.

SVG is running only partially, but you can already do something with it.

There is some work to do before alpha release.
I also think that migration from current rectangle and other objects to
svg is the first task, and then to use svg only points and methods. Why
to implement the same functionality twice in different ways, right?

Unless better way will be found (something I omitted or hidden to me in
current SVG specs, or new SVG version) connections points will be
implemented as an extension to SVG 1.1. Maybe we can later to ask w3c to
make an enhancement into new version, while this must be common problem
for all svg graphers.

Pavel

Stefan Melis wrote:

>Hi,
>
>I like it, especially the brewery part! :D For people to be able to=20
>donate we need to opt-in on SF with a PayPal account though.
>Since I don't really care about the money I've left this untouched, but

>perhaps someone is mad enough to donate something and it would be a=20
>shame if they wouldn't be able to.
>
>Now that we have SVG up and running, I think it would be a good idea to

>start thinking about the ConnectionPoints.
>As you said a little while ago, maybe it would be best if we remove the

>old TPolygonalNode, TRectangularNode, etc. and replace them all with=20
>pure, SVG-only implementations, so that we only have to implement=20
>ConnectionPoints for SVG nodes?
>
>What do you think?
>
>Cheers,
>Stefan
>
> =20
>
>-----Oorspronkelijk bericht-----
>Van: Pavel Vrecion [mailto:pav...@pl...]
>Verzonden: maandag 1 november 2004 11:46
>Aan: Stefan Melis; Kim Bracknell
>Onderwerp: ExtGraph web changes
>
>Hi Stefan and Kim,
>
>I have just  uploaded new pages.
>index.html - on first page there is "why you  should join"
>howtojoin.html - ways how you can help.
>
>I tried to make it light and funny. But I am not sure if I did not=20
>missed the point.
>look at: http://extgraph.sourceforge.net/
>
>Your comments?
>
>Pavel
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE LinuxWorld=20
>Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dclick
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
> =20
>

[Extgraph-developer] RE: ExtGraph web changes

[Stefan M. <ste...@po...>]

Hi,

I like it, especially the brewery part! :D
For people to be able to donate we need to opt-in on SF with a PayPal
account though.
Since I don't really care about the money I've left this untouched, but
perhaps someone is mad enough to donate something and it would be a
shame if they wouldn't be able to.

Now that we have SVG up and running, I think it would be a good idea to
start thinking about the ConnectionPoints.
As you said a little while ago, maybe it would be best if we remove the
old TPolygonalNode, TRectangularNode, etc. and replace them all with
pure, SVG-only implementations, so that we only have to implement
ConnectionPoints for SVG nodes?

What do you think?

Cheers,
Stefan

 =20

-----Oorspronkelijk bericht-----
Van: Pavel Vrecion [mailto:pav...@pl...]=20
Verzonden: maandag 1 november 2004 11:46
Aan: Stefan Melis; Kim Bracknell
Onderwerp: ExtGraph web changes

Hi Stefan and Kim,

I have just  uploaded new pages.
index.html - on first page there is "why you  should join"
howtojoin.html - ways how you can help.

I tried to make it light and funny. But I am not sure if I did not
missed the point.
look at: http://extgraph.sourceforge.net/

Your comments?

Pavel

RE: [Extgraph-developer] (no subject)

[Stefan M. <ste...@po...>]

Pavel,

I've read the how-to and everything works fine. It is a great
demonstration!
I'm currently checking the text for any errors and I will report them to
you a.s.a.p.

Cheers,
Stefan

-----Oorspronkelijk bericht-----
Van: Pavel Vrecion [mailto:pav...@pl...]=20
Verzonden: donderdag 28 oktober 2004 23:16
Aan: Stefan Melis
Onderwerp: Re: [Extgraph-developer] (no subject)

I have just made cvs post - so new code is there.
Pls, can you test if how-to document is useable?

Pavel

Stefan Melis wrote:

>Hi Pavel!
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE LinuxWorld=20
>Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dclick
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
> =20
>

[Extgraph-developer] svg how to

[Pavel V. <cz3...@ti...>]

I have updated our home page. There is how-to. 
Pls read it, try it, comment it, improve it.

Pavel

NOKIA 2300 nebo SIEMENS A57 od 577 Kc
http://adsweb.tiscali.cz/handsety.html

[Extgraph-developer] CVS download problem and SVG connection points

[Pavel V. <cz3...@ti...>]

1. CVS
I have tried to download main.pas (I suppose that you mean main.pas in XG=
raph)
through direct dowload from sf web page and I opened it  in Delhi without=

problem.
Problem can be that there are unix LF and your  version of Delphi cannot
handle it. I use version 7.
Try to convert LF to CRLF, or open/save it some editor that  can handle
this.

2. Licence
All Turbo Power code is released under MPL.

3. SVG
In SVG specs there are two elements that can be used for linking. First
is <a> attribute that specifies the target as in HTML. 
Second element is marker that specifes how line, polyline ends. This feat=
ure
should be implemented to enable saving graph in pure svg.
<a> attribute can be used to specify the target. However it is not fully
in conformace with original meaning, while svg authors ment it for usage
linke interactive maps on web and zooming of svg picture piece . Neverthe=
less
I think that we can tweak <a> element meaning so that if href  target poi=
nts
to local object, we will draw connection link line.
For purpose of user connection poins we will have to enhance svg by our
extension that will specify coordinates of points. That means to define
in our namespace new element. This element  could look like this:
<?xml version=3D"1.0" standalone=3D"yes"?>
<svg width=3D"4in" height=3D"3in" version=3D"1.1"
     xmlns =3D 'http://www.w3.org/2000/svg'
     xmlns:extgraph=3D"http://extgraph.org/extgraph
>
    <extgraph:connectionpoint x=3D"10" y=3D"20">
</svg>

Pavel

>I've downloaded the CVS source (one by one via browser, couldn't get it
to
>work yesterday, damned CVS/Proxy!) 
>The code looks good, I haven't been able to compile it however, Delphi
whinig
>about the first line in the first unit (main.pas) being longer than 1023=

>chars... (?)
>
>If you could make a news-item when you release your new CVS-code on SF
I'll
>be able to download it as soon as it gets online. 
>I want to start working on the implementation of the ConnectionPoints fo=
r
>SVG nodes asap. Have you found anything interesting supporting such thin=
gs
>in SVG? If not, how are we going to solve that problem?
>
>Be careful with the SF-code of TurboPower, it might be published under
a
>different license (like GPL) which could get us into trouble when we'd
use
>it in our code and release it under MPL, as GPL requires all source link=
ing
>to it (and linking is a very, verrry wide concept) to be GPL'ed aswell..=
.
>GPL-ing our code would mean all software using ExtGraph *must* be releas=
ed
>under GPL aswell, and we wouldn't want to get our bosses (and inherently=

>ourselves) into that kind of trouble.... :)
>Nonetheless we might pick up some ideas from their source, it surely is
a
>vast resource...
>
>Cheers,
>Stefan
>
> 
>
>-----Oorspronkelijk bericht-----
>Van: ext...@li... [mailto:extgraph-dev=
elo...@li...]
>Namens Pavel Vrecion
>Verzonden: donderdag 28 oktober 2004 15:16
>Aan: Ext...@li...
>Onderwerp: RE: [Extgraph-developer] (no subject)
>
>Hi,
>so we have enabled another sf feature - mailng list.
>Kim Breknell gave me some changes, ecpecially english corrections to or
home
>page.
>I have new version, so far locally. I plan to distribute it to sf togeth=
er
>with promissed how-to document.
>I have found interesting information. Company TurboPower has closed busi=
ness,
>but they placed almost all their code to sf as open source.
>I will look at it - there should be a fortune of more than 10 years deve=
lopment.
>Maybe something valuable can be there for us, too.
>
>Pavel
>
>>-- P=F9vodn=ED zpr=E1va --
>>From: "Stefan Melis" <ste...@po...>
>>To: <ext...@li...>
>>Subject: [Extgraph-developer] (no subject)
>>Date: Thu, 28 Oct 2004 11:46:52 +0200
>>
>>
>>Hi Pavel!
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by:
>>Sybase ASE Linux Express Edition - download now for FREE LinuxWorld 
>>Reader's Choice Award Winner for best database on Linux.
>>http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dclick
>>_______________________________________________
>>Extgraph-developer mailing list
>>Ext...@li...
>>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>NOKIA 2300 nebo SIEMENS A57 od 577 Kc
>http://adsweb.tiscali.cz/handsety.html
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Read=
er's
>Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=CCk
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dclick
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer


NOKIA 2300 nebo SIEMENS A57 od 577 Kc
http://adsweb.tiscali.cz/handsety.html