SimpleGraph 2.0 Released!

[Kambiz]

Hi guys,

Finally the new release of SimpleGraph is available to download.

Don't forget to see readme file for the complete list of updates. There, you will find some new things, which are not used in SGDemo.

If you found a bug, please inform it right here, thank you!

Have fun,
Kambiz

[Adem]

The file

www.delpharea.com/products/simplegraph/simplegraph.zip

does not seem to exist.

[elias]

delphiarea.com
http://www.delphiarea.com/products/simplegraph/simplegraph.zip

Better look at http://www.delphiarea.com/products/simplegraph/

***

I'm crushed! What a lot of changes! I guess it would be too difficult to me change all the TsimpleGraph at this point; however I'll incorporate it little by little.

good work.

[kokkoras]

Congrats in advance!

Kambiz, you should give us a break, say, untill September, to incorporate all those goodies in our projects.

edit: very generous of you to acknowledge some of us in the documentation.

edit2: let's make a graph (using the demo) to create the object hierarchy of the library.

Fotis Kokkoras

[Kambiz]

Thank you!

let's make a graph (using the demo) to create the object hierarchy of the library.

Good idea!

[Adem]

Kambiz,

Thank you for the excellent work.

I have gone through the v2.0 sources and I'dlike to make a few minor suggestions. These will not affect the current functionality.

-- it might be good idea to declare TGraphChangeFlags as below

TGraphChangeFlag = (gcState, gcData, gcStyle, gcCaption, gcPlacement, gcDependency);
TGraphChangeFlags = set of TGraphChangeFlag;

-- it might be good idea to declare TObjectSides as below

TObjectSide = (osLeft, osTop, osRight, osBottom);
TObjectSides = set of TObjectSide;

-- TGraphObject contains these variables in its private section. It would be better if they were prefixed with the 'F' character.

InSyncFont: Boolean;
PendingChanges: TGraphChangeFlags;
UpdateCount: Integer;

-- TGraphLink contains these variables in its private section. It would be better if they were prefixed with the 'F' character.

OldVersion: Integer;
SourceID: DWORD;
TargetID: DWORD;
UpdatingEndPoints: Boolean;

-- TSimpleGraph contains these variables in its private section. It would be better if they were prefixed with the 'F' character.

GraphModified: Boolean;
IgnoreNotification: Boolean;
InsertedObject: TGraphObject;
LockedCalcBounds: array[0..1] of TRect;
SavedCanvas: TCanvas;
SelectionRect: TRect;
UndoStorage: TMemoryStream;
UpdateCount: Integer;
UpdateSelectionCount: Integer;
UpdatingScrollBars: Boolean;
WheelAccumulator: Integer;

Finally, I have a request:

When there are a large number of nodes, it is very time consuming to iterate TSimpleGraph.Objects in order to find which node a particular node (TGraphNode) is linked to (and by what TGraphLink object).

Instead of having to iterate through TSimpleGraph.Objects, could we have two more private variables in TGraphNode class, such that TGraphNode has 2 more private variables.

FNodesLinkedTo: TList;
FNodesLinkedFrom: TList;

These lists (as the names suggest) contain the counterpart node *and* the TGraphLink object for that particular link. Then, a couple of suitable procedures make this functionality public for the node.

I really hope you will consider this. I can do the coding if necessary.

[kokkoras]

I'm crushed as well !

[kokkoras]

How about renaming the component to TNotSoSimpleGraph ?

I am a bit puzzled. Is there any way to have a container (ex. TList) with only the type of objects desired? As far as I know all the objects are in a single list now. We don't have links and nodes anymore. Just objects.

[kokkoras]

Finally, I have a request:

When there are a large number of nodes, it is very time consuming to iterate TSimpleGraph.Objects in order to find which node a particular node (TGraphNode) is linked to (and by what TGraphLink object).

Instead of having to iterate through TSimpleGraph.Objects, could we have two more private variables in TGraphNode class, such that TGraphNode has 2 more private variables.

FNodesLinkedTo: TList;
FNodesLinkedFrom: TList;

These lists (as the names suggest) contain the counterpart node *and* the TGraphLink object for that particular link. Then, a couple of suitable procedures make this functionality public for the node.

I really hope you will consider this. I can do the coding if necessary.

Nice comment! This is exactly what I have done in my app. Each node knows the links that are connected over itself. But I dont keep this info in the TSimpleGraph infrastructure. The same holds for links. In both cases I have external objects for which the TSimpleGraph hosted objects are just the visualization.

If we add such lists then, when you delete a link you have to iterate over all nodes, find those that "used" this link, delete the reference from the list and repack the list to remove the hole. But afterall, Adem's requirement is much more frequent than mine (i.e. deleting links).

So, If my opinion counts, I vote for.

Fotis

[Kambiz]

-- it might be good idea to declare TGraphChangeFlags as below

TGraphChangeFlag = (gcState, gcData, gcStyle, gcCaption, gcPlacement, gcDependency);
TGraphChangeFlags = set of TGraphChangeFlag;

-- it might be good idea to declare TObjectSides as below

TObjectSide = (osLeft, osTop, osRight, osBottom);
TObjectSides = set of TObjectSide;

I'll do it although only set types are used in the code.

-- TGraphObject contains these variables in its private section. It would be better if they were prefixed with the 'F' character.

InSyncFont: Boolean;
PendingChanges: TGraphChangeFlags;
UpdateCount: Integer;

-- TGraphLink contains these variables in its private section. It would be better if they were prefixed with the 'F' character.

OldVersion: Integer;
SourceID: DWORD;
TargetID: DWORD;
UpdatingEndPoints: Boolean;

-- TSimpleGraph contains these variables in its private section. It would be better if they were prefixed with the 'F' character.

GraphModified: Boolean;
IgnoreNotification: Boolean;
InsertedObject: TGraphObject;
LockedCalcBounds: array[0..1] of TRect;
SavedCanvas: TCanvas;
SelectionRect: TRect;
UndoStorage: TMemoryStream;
UpdateCount: Integer;
UpdateSelectionCount: Integer;
UpdatingScrollBars: Boolean;
WheelAccumulator: Integer;

Whenever it was saved to place a field in protected or public section, they are there. And, whenever it was possible I've provided a protected method for accessing to the private field. The remained private fields are really private variables an because of that without F prefix.

When there are a large number of nodes, it is very time consuming to iterate TSimpleGraph.Objects in order to find which node a particular node (TGraphNode) is linked to (and by what TGraphLink object).

Instead of having to iterate through TSimpleGraph.Objects, could we have two more private variables in TGraphNode class, such that TGraphNode has 2 more private variables.

FNodesLinkedTo: TList;
FNodesLinkedFrom: TList;

These lists (as the names suggest) contain the counterpart node *and* the TGraphLink object for that particular link. Then, a couple of suitable procedures make this functionality public for the node.

Consider that since this release:

1. Links as well as nodes can be hooked to a link. So, if we define a list of hooked objects, it should be contain of all graph object types.
2. Two objects can connect together more than once. Because of that, you have to look again in all the objects to find all connections.

Maybe for some specific implementations we can use a list to speed up things, but in general it doesn't help so much.

There are three OnObjectHook, OnObjectUnhook, and OnLinkObjects events, and TGraphObjectList type that a host application can use it to build up a custom list of connected objects if needed.

[kokkoras]

I knew from the first time I heard about links originated or ended upon other links, that this will create some trouble. But for those drawing flow charts, it's fine. For me creating semantic networks, it's not. We can't have them all.

fotis

[Kambiz]

Is there any way to have a container (ex. TList) with only the type of objects desired? As far as I know all the objects are in a single list now. We don't have links and nodes anymore. Just objects.

Since the initial release of component, there was only two list: Objects and Selected Objects.

You should use OnObjectInsert and OnObjectRemove events to manage your own custom lists.

[Kambiz]

I knew from the first time I heard about links originated or ended upon other links, that this will create some trouble. But for those drawing flow charts, it's fine. For me creating semantic networks, it's not. We can't have them all.

Simply use the following code, to prevent links being used as a connection point.

Code: Select all

procedure TForm1.SimpleGraphObjectInsert(Graph: TSimpleGraph;
  GraphObject: TGraphObject);
begin
  with GraphObject do
    if IsLink then
      Options := Options - [goLinkable];
end;

[kokkoras]

Since the initial release of component, there was only two list: Objects and Selected Objects.
You should use OnObjectInsert and OnObjectRemove events to manage your own custom lists.

Yes, you are right. I am away from programming for quite some time and forgot that.

[Kambiz]

My gosh! Seems you don't like to write even a single line of code in your application, right? Dropping components on the form, setting properties, and voila!