BorlandTalk.com Forum Index BorlandTalk.com
Borland discussion newsgroups
 
Archives   FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

OO Newbie Form Design question

 
Post new topic   Reply to topic    BorlandTalk.com Forum Index -> Delphi OO design
View previous topic :: View next topic  
Author Message
Huhtaman
Guest





PostPosted: Tue Feb 22, 2005 12:58 am    Post subject: OO Newbie Form Design question Reply with quote



Hello All:

Our applications use modal forms to display to our users. We dynamically
create, then destory these forms after they are used. In addition, we also
pass parameters for use in some of these forms.

We have been doing this by placing a procedure in the form unit
typically called ShowXYZForm(Var Parameter1, Parameter2: String); The old
code is listed below.

We want to make this a more granular process and need to accomplish the
following:


1) We want to encapsulate the Create, Showmodal, Free in some kind of
object method
2) We need a way to pass parameters to the specific form, then have
those parameters properly assigned.

My thoughts are to accomplish this as follows:

A) Create a formshow object that will accept a TForm decendent, create
it, show it, then destroy it.

B) Next, I need to be able to accept different combinations of
parameters and get them properly assigned to the shown form.
This is where I am having problems -
How can I pass different sets of parameters into the instantiated
form and get them properly assigned ???

My idea is to have some kind of object TPassObject then descend
other obects from that say TXYZPassObect = Class TPassObject

Would this work if I sent the TPassObject as a property of the
formshow object ???

Would I attach the TPassObject as a parameter in the Create of each
passed form ???


Is there a cleaner and/or easier way to do this type of thing ???


Thank you.


Neil Huhta











Old Code:

Procedure ShowXYZForm(Var Parameter1, Parameter2: String);
Begin
If Not(Assigned(fmXYZForm)) Then
fmXYZForm:=TfmXYZForm.Create(Application);
Try
fmXYZForm.Param1:=Parameter1;
fmXYZForm.Param2:=Parameter2;
fmXYZForm.Showmodal;
Finally
fmXYZForm.Free;
fmXYZForm:=nil;
End;
End;


Back to top
Lee_Nover
Guest





PostPosted: Tue Feb 22, 2005 6:21 am    Post subject: Re: OO Newbie Form Design question Reply with quote



Quote:
1) We want to encapsulate the Create, Showmodal, Free in some kind
of object method
add a class method to the base form

something like:
class function TVnosOsnovaF.UrediObjekt(const AObjekt: IOsnova): Boolean;
begin
with Create(nil) do
try
Nalozi(AObjekt);
Visible:=false;
Result:=IsPositiveResult(ShowModal);
finally
Free;
end;
end;



Quote:
2) We need a way to pass parameters to the specific form, then have
those parameters properly assigned.

check the above method .. it accepts an interface param
Nalozi is a virtual abstract method that each TVnosOsnovaF descendant must
implement
my Nalozi methods then check the AObjekt for various interface types and
loads what it can
the List forms also have a virtual abstract class method:
class function VnosRazred: TVnosOsnovaClass; virtual; abstract;
each descendant then implements this and just returns the TVnosOsnovaF
class for it's type

this the base List form's Edit action code:
procedure TSifrantOsnovaF.actNavUrediExecute(Sender: TObject);
var
LObj: IOsnova;
begin
with vstMain do
begin
LObj:=GetObjekt(FocusedNode);
if VnosRazred.UrediObjekt(LObj) then
begin
InvalidateNode(FocusedNode);
PosodobiObjekt(LObj);
SpremenjenObjekt(LObj);
end;
end;
end;

descendants don't have to implement anything :)

hth :)

Back to top
Joanna Carter (TeamB)
Guest





PostPosted: Tue Feb 22, 2005 9:06 am    Post subject: Re: OO Newbie Form Design question Reply with quote



"Huhtaman" <nhuhta (AT) digital (DOT) net> a écrit dans le message de news:
421a83ba$1 (AT) newsgroups (DOT) borland.com...

Quote:
We have been doing this by placing a procedure in the form unit
typically called ShowXYZForm(Var Parameter1, Parameter2: String); The old
code is listed below.

By using your procedure in a module, you are relying on the form variable to
hold the instance of that form. What would happen if you called your
procedure twice ? The first instance of the form would be overwritten by the
second instance of the form and you would have a memory leak because you can
no longer free the first instance.

Quote:
We want to make this a more granular process and need to accomplish
the
following:

1) We want to encapsulate the Create, Showmodal, Free in some kind of
object method
2) We need a way to pass parameters to the specific form, then have
those parameters properly assigned.

As Lee says, you need a class method.

But first you have to decide whether you want to allow multiple instances of
a form class to exist at the same time, or whether you want a second call to
the Create/Show method to bring an existing form to the front.

To allow for multiple instances of the form :

//////////////////////////////
type
TXYZForm = class(...)
...
public
class procedure Execute(var Parameter1, Parameter2: string);
end;

// remove this form from the auto-create list
// and remove this var, it is not required.
//var
// XYZForm: TXYZForm

implementation

class procedure TXYZForm.Execute(var Parameter1, Parameter2: String);
var
instance: TXYZForm
begin
instance := TXYZForm.Create(nil);
try
instance.Param1 := Parameter1;
instance.Param2 := Parameter2;
instance.Showmodal;
finally
instance.Free;
end;
end;


// if you wanted to react to the result of a form being shown, then you
could always
// change the class procedure to a class function :

class function TXYZForm.Execute(var Parameter1, Parameter2: String):
TModalResult
var
instance: TXYZForm
begin
instance := TXYZForm.Create(nil);
try
instance.Param1 := Parameter1;
instance.Param2 := Parameter2;
Result := instance.Showmodal;
finally
instance.Free;
end;
end;
/////////////////////////////

It is not a good idea to try and show an existing instance of a form if the
method were called twice, as this would mean having to ignore the new
parameters or simply changing the parameters on the existing form thereby
changing the state of the original instance and upsetting the logic of the
first call.

By using a class method, you are encapsulating the logic for each form class
into that form class.

Your idea of using a Parameter Object is a good idea in other circumstances
but, because you would have to write a different Parameter Object class for
each variant of the form, you might as well change the parameter list in the
Execute class method of each form class.

Does this solve the problem, or have I missed something ?

Joanna

--
Joanna Carter (TeamB)

Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker



Back to top
Oktay Sancak
Guest





PostPosted: Tue Feb 22, 2005 1:48 pm    Post subject: Re: OO Newbie Form Design question Reply with quote

Hi,

For these kinds of problems, i would highly recommend to use class
procedures(as the Joanna said) I saw a similar solution(from one of the
Joanna's answers on this newsgroup) about the form's Show/Close
procedures. That was an excellent solution which i'm already using.
Nice work Joanna!

Kind Regards,

Oktay Sancak

Joanna Carter (TeamB) wrote:


Quote:
By using your procedure in a module, you are relying on the form
variable to hold the instance of that form. What would happen if you
called your procedure twice ? The first instance of the form would be
overwritten by the second instance of the form and you would have a
memory leak because you can no longer free the first instance.


Quote:
As Lee says, you need a class method.

But first you have to decide whether you want to allow multiple
instances of a form class to exist at the same time, or whether you
want a second call to the Create/Show method to bring an existing
form to the front.

To allow for multiple instances of the form :

//////////////////////////////
type
TXYZForm = class(...)
...
public
class procedure Execute(var Parameter1, Parameter2: string);
end;

// remove this form from the auto-create list
// and remove this var, it is not required.
//var
// XYZForm: TXYZForm

implementation

class procedure TXYZForm.Execute(var Parameter1, Parameter2: String);
var
instance: TXYZForm
begin
instance := TXYZForm.Create(nil);
try
instance.Param1 := Parameter1;
instance.Param2 := Parameter2;
instance.Showmodal;
finally
instance.Free;
end;
end;


// if you wanted to react to the result of a form being shown, then
you could always
// change the class procedure to a class function :

class function TXYZForm.Execute(var Parameter1, Parameter2: String):
TModalResult
var
instance: TXYZForm
begin
instance := TXYZForm.Create(nil);
try
instance.Param1 := Parameter1;
instance.Param2 := Parameter2;
Result := instance.Showmodal;
finally
instance.Free;
end;
end;
/////////////////////////////

It is not a good idea to try and show an existing instance of a form
if the method were called twice, as this would mean having to ignore
the new parameters or simply changing the parameters on the existing
form thereby changing the state of the original instance and
upsetting the logic of the first call.

By using a class method, you are encapsulating the logic for each
form class into that form class.

Your idea of using a Parameter Object is a good idea in other
circumstances but, because you would have to write a different
Parameter Object class for each variant of the form, you might as
well change the parameter list in the Execute class method of each
form class.

Does this solve the problem, or have I missed something ?

Joanna

--
Joanna Carter (TeamB)

Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker



Back to top
Huhtaman
Guest





PostPosted: Tue Feb 22, 2005 6:09 pm    Post subject: Re: OO Newbie Form Design question Reply with quote

Joanna:

Thank you for your help. Your idea looks like the correct way to
proceed - but - I have a few questions.

1) My application is designed only to allow 1 instance of any form to be
alive at a time. Since I am using a primary thread to show all windows, I
don't think that it is possible for the user to open any window twice - ie
memory leak. If this were an MDI app - I believe this code would be
problematic. Is that correct ???

2) Your model changes my procedure to a public method of type class. I
have never seen this done before.

class procedure Execute(var Parameter1, Parameter2: string);

Is this done so that the Execute procedure can be called before the form
object is created ???

If so, do I reference it as Unitname.Execute(Parameter1, Parameter2) ???

The differences between your code and mine seem sublte - Does your way
prevent multiple instances somehow ??? Can you explain the advantages of
using the Class Procedure ???


Thank you for your time. I appreciate your advice.


Neil Huhta









"Joanna Carter (TeamB)" <joanna (AT) nospam (DOT) co.uk> wrote

Quote:
"Huhtaman" <nhuhta (AT) digital (DOT) net> a écrit dans le message de news:
421a83ba$1 (AT) newsgroups (DOT) borland.com...

We have been doing this by placing a procedure in the form unit
typically called ShowXYZForm(Var Parameter1, Parameter2: String); The old
code is listed below.

By using your procedure in a module, you are relying on the form variable
to
hold the instance of that form. What would happen if you called your
procedure twice ? The first instance of the form would be overwritten by
the
second instance of the form and you would have a memory leak because you
can
no longer free the first instance.

We want to make this a more granular process and need to accomplish
the
following:

1) We want to encapsulate the Create, Showmodal, Free in some kind of
object method
2) We need a way to pass parameters to the specific form, then have
those parameters properly assigned.

As Lee says, you need a class method.

But first you have to decide whether you want to allow multiple instances
of
a form class to exist at the same time, or whether you want a second call
to
the Create/Show method to bring an existing form to the front.

To allow for multiple instances of the form :

//////////////////////////////
type
TXYZForm = class(...)
...
public
class procedure Execute(var Parameter1, Parameter2: string);
end;

// remove this form from the auto-create list
// and remove this var, it is not required.
//var
// XYZForm: TXYZForm

implementation

class procedure TXYZForm.Execute(var Parameter1, Parameter2: String);
var
instance: TXYZForm
begin
instance := TXYZForm.Create(nil);
try
instance.Param1 := Parameter1;
instance.Param2 := Parameter2;
instance.Showmodal;
finally
instance.Free;
end;
end;


// if you wanted to react to the result of a form being shown, then you
could always
// change the class procedure to a class function :

class function TXYZForm.Execute(var Parameter1, Parameter2: String):
TModalResult
var
instance: TXYZForm
begin
instance := TXYZForm.Create(nil);
try
instance.Param1 := Parameter1;
instance.Param2 := Parameter2;
Result := instance.Showmodal;
finally
instance.Free;
end;
end;
/////////////////////////////

It is not a good idea to try and show an existing instance of a form if
the
method were called twice, as this would mean having to ignore the new
parameters or simply changing the parameters on the existing form thereby
changing the state of the original instance and upsetting the logic of the
first call.

By using a class method, you are encapsulating the logic for each form
class
into that form class.

Your idea of using a Parameter Object is a good idea in other
circumstances
but, because you would have to write a different Parameter Object class
for
each variant of the form, you might as well change the parameter list in
the
Execute class method of each form class.

Does this solve the problem, or have I missed something ?

Joanna

--
Joanna Carter (TeamB)

Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker





Back to top
Joanna Carter (TeamB)
Guest





PostPosted: Tue Feb 22, 2005 6:54 pm    Post subject: AnyRe: OO Newbie Form Design question Reply with quote

"Huhtaman" <nhuhta (AT) digital (DOT) net> a écrit dans le message de news:
421b7556$1 (AT) newsgroups (DOT) borland.com...

Quote:
1) My application is designed only to allow 1 instance of any form to
be
alive at a time. Since I am using a primary thread to show all windows, I
don't think that it is possible for the user to open any window twice - ie
memory leak. If this were an MDI app - I believe this code would be
problematic. Is that correct ???

The code I have shown strictly allows multiple instances of the form to be
created and shown, but in actual fact this is not possible because the form
is shown modally and the whole application has to wait until the form is
closed.

Quote:
2) Your model changes my procedure to a public method of type class. I
have never seen this done before.

class procedure Execute(var Parameter1, Parameter2: string);

Is this done so that the Execute procedure can be called before the
form
object is created ???

The Execute method is part of the class, not part of an object that the
class can create.

To put it simply, a class method operates on the cookie cutter; an instance
method operates on the cookie.

In some ways class methods can be considered to be 'global', but they are
constrained within a class, thereby ensuring that any data that they operate
on has to either : exist as data of the class (cookie cutter), not of the
instance (cookie), or has to be passed to the method as a parameter.

Class methods are designed to be called without having to create an instance
of the class. They are called by prepending them with the name of the class
:

begin
..
TXYZForm.Execute(param1, param2);
...
end;

True OO programming does nothing outside of a class, so things like the
variable in the unit can be deleted as it is the responsibility of the class
to maintain a reference to the instance and to free it when necessary.

Quote:
The differences between your code and mine seem sublte - Does your way
prevent multiple instances somehow ??? Can you explain the advantages of
using the Class Procedure ???

Let me take you through the method one line at a time :

Quote:
class procedure TXYZForm.Execute(var Parameter1, Parameter2: String);

The procedure is declared as a class method to allow us to call the method
without first creating an instance of the class (see previous demo calling
code).

Quote:
var
instance: TXYZForm

This var is simply to allow us to set the parameters on the instance of the
form before showing it. Each time this method is called, the var is
re-initialised to a new instance of the form class. If I were to have a form
class that didn't require any parameters, I could also do away with the var
by using the following syntax which creates an unnamed temporary variable :
{
with TXYZForm.Create(nil) do
try
ShowModal;
finally
Free;
end;
}
Quote:
begin
instance := TXYZForm.Create(nil);
try

Notice that we pass nil as the Owner of the form; this is because we are
taking the responsibility for managing its memory ourselves; all an Owner
would do would be to free the form when it was freed, if we forgot.

We put the call to the constructor before a try block to ensure that, if an
exception occurs during the constructor, it will set the var to nil and,
although the code inside the try block will not be called, the call to Free
inside the finally block will not raise an exception if called on a nil
pointer.

Quote:
instance.Param1 := Parameter1;
instance.Param2 := Parameter2;
instance.Showmodal;

This code set up and shows the form, execution will wait here until the form
is closed.

Quote:
finally
instance.Free;

Any code inside a finally block will execute, whether or not an exception
was raised in the try block, therebyt guaranteeing to free the instance.

Quote:
end;
end;

Please question anything that is not clear enough; it is all too easy to
assume understanding :-)

Joanna

--
Joanna Carter (TeamB)

Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker



Back to top
Huhtaman
Guest





PostPosted: Tue Feb 22, 2005 9:43 pm    Post subject: Re: AnyRe: OO Newbie Form Design question Reply with quote

Joanna:

Thank you very very much. It is all very clear now. That class procedure
is way cool. I am just learning OOP and feel like a kid in a Candy store. I
have some other ideas and can hardly wait to try and play around with them.
You have been very very helpful. In particular the cookie cutter analogy is
very helpful to us new people.

My next task is to learn how to do abstraction with classes - ie TPerson
Class - TEmployee Class - THourlyEmployeeClass, etc.

Do you have any suggestions on useful tutorials or excersizes for
learning how to do this sort of thing ??? I am scanning the net and doing
reading - there are some interesting materials out there. I do best by doing
and following actual code.

Once again, thank you very much.


Neil Huhta


Back to top
Bob Dawson
Guest





PostPosted: Tue Feb 22, 2005 9:51 pm    Post subject: Re: AnyRe: OO Newbie Form Design question Reply with quote

"Huhtaman" wrote
Quote:

My next task is to learn how to do abstraction with
classes - ie TPerson Class - TEmployee Class -
THourlyEmployeeClass, etc.

Good choice--like knowing class methods, the ability to treat class types as
variables is a really significant item in the OO programmer's toolkit.

bobD



Back to top
Joanna Carter (TeamB)
Guest





PostPosted: Tue Feb 22, 2005 10:25 pm    Post subject: Re: AnyRe: OO Newbie Form Design question Reply with quote

"Huhtaman" <nhuhta (AT) digital (DOT) net> a écrit dans le message de news:
421ba766$1 (AT) newsgroups (DOT) borland.com...

Quote:
My next task is to learn how to do abstraction with classes - ie
TPerson
Class - TEmployee Class - THourlyEmployeeClass, etc.

Now do you mean, as Bob suggests, using class types as variables, or do you
mean deriving one class from another ?

Assuming you mean how to design class hierarchies, then the example you talk
about can be both simple and complex at the same time :-)

Certainly, THourlyEmployee would derive from TEmployee, but there is a
possibility that TEmployee would not necessarily derive from TPerson.

The problems start when you have a Person who can be both an Employee and/or
a Customer either separately or at the same time. In that case you have to
consider the use of the Role pattern.

IOW an Employee is a Person who adopts the role of an Employee, or Customer
or Pilot or Student, etc. So instead of simply deriving from TPerson, you
would tend to write a Role class and then derive Employee or whatever from
that class. The Person would then contain a list of 0-n Roles.

Of course, I could be on entirely the wrong track here Smile Let us know what
*you* mean by abstraction.

Joanna

--
Joanna Carter (TeamB)

Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
Quote:




Back to top
Andrea Raimondi
Guest





PostPosted: Tue Feb 22, 2005 10:40 pm    Post subject: Re: OO Newbie Form Design question Reply with quote

Huhtaman wrote:

Quote:
Is there a cleaner and/or easier way to do this type of thing ???
Thank you.

My take:

TGeneralParam = class
public
property Value : String; // This can be used as a general param
end;

TParamList = class
// Create your list object here, you know, Add, Delete, whatever
end;

TMyBaseForm = class(TForm)
public
procedure AddParam(AValue : String);
property ParamList : TParamList read FParamList;
end;

TMyFormClass = class of TMyBaseForm;

TFormManager = class
public
procedure InitInstance; // Here you create the form
procedure Show(Modal : Boolean); // Handle here
procedure FreeInstance;// FreeAndNil here if necessary

procedure AddParam(AValue : String);// Call this code after
// creating the instance and
// call the forms' AddParam
property FormClass : TMyFormClass;
end;

This is probably far from being optimal, but should endow you with an
easy to update/modify mechanism while still being flexyble enough.

Quote:
Neil Huhta

Andrew
--
Online thoughts blog
http://araimondi.blogspot.com
Experts Exchange profile
http://www.experts-exchange.com/M_1621390.html

Back to top
Martin James
Guest





PostPosted: Wed Feb 23, 2005 3:01 pm    Post subject: Re: AnyRe: OO Newbie Form Design question Reply with quote


Quote:

The code I have shown strictly allows multiple instances of the form to be
created and shown, but in actual fact this is not possible because the
form
is shown modally and the whole application has to wait until the form is
closed.


Well, not quite - what happens if a modal form is being shown and a timer,
or other message, fires a handler which tries to create/show another modal
form? I suspect that this new form would be shown & get focus because I've
seen lots of modal messageBoxes on my screen, usually saying 'Access
Violation' Smile. My record is over 200 so far.

Rgds,
Martin



Back to top
Joanna Carter (TeamB)
Guest





PostPosted: Wed Feb 23, 2005 3:05 pm    Post subject: Re: AnyRe: OO Newbie Form Design question Reply with quote

"Martin James" <mjames_falcon (AT) dial (DOT) pipex.com> a écrit dans le message de
news: [email]421c99e0 (AT) newsgroups (DOT) borland.com[/email]...

Quote:
Well, not quite - what happens if a modal form is being shown and a timer,
or other message, fires a handler which tries to create/show another modal
form? I suspect that this new form would be shown & get focus because
I've
seen lots of modal messageBoxes on my screen, usually saying 'Access
Violation' Smile. My record is over 200 so far.

How many properly designed applications do you know that use timers to show
forms ??!! :-)

As the doctor replied to the patient who said 'it hurts when I do this',
'well stop doing it ' :-)

Joanna

--
Joanna Carter (TeamB)

Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker



Back to top
Jim Cooper
Guest





PostPosted: Thu Feb 24, 2005 12:26 pm    Post subject: Re: AnyRe: OO Newbie Form Design question Reply with quote


Quote:
Certainly, THourlyEmployee would derive from TEmployee, but there is a
possibility that TEmployee would not necessarily derive from TPerson.

Its not certain THourlyEmployee would derive from TEmployee either Smile
This is a classic example of when to use the Strategy pattern, because
hourly employees can be promoted to salaried employees.

This exact issue was the topic in my April 2004 article in TDM


Cheers,
Jim Cooper

__________________________________________

Jim Cooper [email]jcooper (AT) tabdee (DOT) ltd.uk[/email]
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
__________________________________________

Back to top
Joanna Carter (TeamB)
Guest





PostPosted: Thu Feb 24, 2005 12:55 pm    Post subject: Re: AnyRe: OO Newbie Form Design question Reply with quote

"Jim Cooper" <jcooper (AT) tabdee (DOT) ltd.uk> a écrit dans le message de news:
[email]421dc7e4 (AT) newsgroups (DOT) borland.com[/email]...

Quote:
Its not certain THourlyEmployee would derive from TEmployee either Smile
This is a classic example of when to use the Strategy pattern, because
hourly employees can be promoted to salaried employees.

And I was trying to make it simple :-)

You are absolutely right; in fact I always tell folks to design without
inheritance and only create superclasses from commonality in classes, not
try to design hierarchies from the superclass down. This means more code
that may get thrown away but it seems to avoid too much over-inheritance.

Joanna

--
Joanna Carter (TeamB)

Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker



Back to top
Jim Cooper
Guest





PostPosted: Thu Feb 24, 2005 4:57 pm    Post subject: Re: AnyRe: OO Newbie Form Design question Reply with quote


Quote:
in fact I always tell folks to design without
inheritance and only create superclasses from commonality in classes, not
try to design hierarchies from the superclass down.

Good advice, I think :-)

I often start by writing one class and as I add bits decide whether they
should stay there, be moved up or down the inheritance hierarchy, or
sideways into a new class. If I find I need to move both up and sideways
I've found a possible interface candidate, or crap design :-)

I'm not afraid to move things more than once, either Smile And I'm finding
more and more these days it can pay to delay the move for a while, even
at the expense of having temporarily duplicate code.

Quote:
This means more code that may get thrown away but it seems to avoid too
much over-inheritance.

Yes. People often talk about having shallow, wide inheritance
hierarchies (which works for interfaces as well as classes). But getting
too wide is also an indication of a potential problem, IMO. For
interfaces add the smells of too many interfaces implemented in one
object, and too many objects implementing any given interface.

Cheers,
Jim Cooper

__________________________________________

Jim Cooper [email]jcooper (AT) tabdee (DOT) ltd.uk[/email]
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
__________________________________________

Back to top
Display posts from previous:   
Post new topic   Reply to topic    BorlandTalk.com Forum Index -> Delphi OO design All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2006 phpBB Group
SEO toolkit © 2004-2006 webmedic.