SimpleGraph 2.0 Released!

Please post bug reports, feature requests, or any question regarding the DELPHI AREA products here.

SimpleGraph 2.0 Released!

Postby Kambiz » February 23rd, 2006, 12:40 am

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
Attachments
sg2.gif
SimpleGraph 2.0
sg2.gif (43.92 KiB) Viewed 3651 times
Last edited by Kambiz on February 23rd, 2006, 1:36 pm, edited 1 time in total.
Kambiz
User avatar
Kambiz
Administrator
Administrator
 
Posts: 2408
Joined: March 7th, 2003, 7:10 pm

Postby Adem » February 23rd, 2006, 3:47 am

Adem
Active Member
Active Member
 
Posts: 22
Joined: February 20th, 2006, 12:47 pm

Postby elias » February 23rd, 2006, 8:54 am

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.
elias
Senior Member
Senior Member
 
Posts: 90
Joined: November 8th, 2005, 12:09 pm
Location: Galicia, Spain

Postby kokkoras » February 23rd, 2006, 4:27 pm

Congrats in advance!

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

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

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

Fotis Kokkoras
User avatar
kokkoras
Moderator
Moderator
 
Posts: 317
Joined: March 12th, 2005, 11:19 pm
Location: Thessaloniki, Greece

Postby Kambiz » February 23rd, 2006, 6:11 pm

Thank you!

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


Good idea!
Kambiz
User avatar
Kambiz
Administrator
Administrator
 
Posts: 2408
Joined: March 7th, 2003, 7:10 pm

Postby Adem » February 23rd, 2006, 6:32 pm

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.
Adem
Active Member
Active Member
 
Posts: 22
Joined: February 20th, 2006, 12:47 pm

Postby kokkoras » February 23rd, 2006, 6:32 pm

I'm crushed as well ! :shock: :shock: :shock: :shock:
User avatar
kokkoras
Moderator
Moderator
 
Posts: 317
Joined: March 12th, 2005, 11:19 pm
Location: Thessaloniki, Greece

Postby kokkoras » February 24th, 2006, 12:43 pm

How about renaming the component to TNotSoSimpleGraph :lol: :lol: ?

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.
User avatar
kokkoras
Moderator
Moderator
 
Posts: 317
Joined: March 12th, 2005, 11:19 pm
Location: Thessaloniki, Greece

Postby kokkoras » February 24th, 2006, 12:58 pm

Adem wrote: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
User avatar
kokkoras
Moderator
Moderator
 
Posts: 317
Joined: March 12th, 2005, 11:19 pm
Location: Thessaloniki, Greece

Postby Kambiz » February 24th, 2006, 1:18 pm

Adem wrote:-- 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.

Adem wrote:-- 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.

Adem wrote: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.
Last edited by Kambiz on February 24th, 2006, 1:30 pm, edited 2 times in total.
Kambiz
User avatar
Kambiz
Administrator
Administrator
 
Posts: 2408
Joined: March 7th, 2003, 7:10 pm

Postby kokkoras » February 24th, 2006, 1:25 pm

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
User avatar
kokkoras
Moderator
Moderator
 
Posts: 317
Joined: March 12th, 2005, 11:19 pm
Location: Thessaloniki, Greece

Postby Kambiz » February 24th, 2006, 1:35 pm

kokkoras wrote: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
User avatar
Kambiz
Administrator
Administrator
 
Posts: 2408
Joined: March 7th, 2003, 7:10 pm

Postby Kambiz » February 24th, 2006, 1:37 pm

kokkoras wrote: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;
Kambiz
User avatar
Kambiz
Administrator
Administrator
 
Posts: 2408
Joined: March 7th, 2003, 7:10 pm

Postby kokkoras » February 24th, 2006, 1:38 pm

Kambiz wrote: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.
User avatar
kokkoras
Moderator
Moderator
 
Posts: 317
Joined: March 12th, 2005, 11:19 pm
Location: Thessaloniki, Greece

Postby Kambiz » February 24th, 2006, 1:42 pm

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!
Kambiz
User avatar
Kambiz
Administrator
Administrator
 
Posts: 2408
Joined: March 7th, 2003, 7:10 pm

Next

Return to DELPHI AREA Products

Who is online

Users browsing this forum: No registered users and 2 guests

cron