2006/4/18, johnf <[EMAIL PROTECTED]>:
> Thanks for answering. You are right the task was very simple. I used the
> code as an example because in fact I'm having issues with understanding the
> OOP involved and how the FPC compiler works. It seems that having one call
> would be the OOP thing to do. But I noticed that making the call increased
> the size of the code and I wondered if the execution speed would suffer
> because of the call. In general I would say that the SQLdb is not OOP in its
> use. PQConnections,TSQLTransactions and TSQLQuery work best if they are
> placed on the form and not created at runtime. I'm not sure if this is
> because my inexperience with FPC (the way I coded it) or because of the way
> SQLdb was designed (maybe the way Delphi was designed?).
With the big CPU of today a procedure call will not slow down your
application that much :). But I'm from the old school on some parts of
code like that. The example function you made is in my "things you
don't do" list, except if it fulfills some OOP criterions and specific
reasons that would have made such a procedure a good app/code design.
:)
In the very precise case you talk, if many forms are using
PQConnections, TSQLTransactions and TSQLQuery, I would create a new
form that implement already all these controls and functions you need.
(But... see bellow.) Then I would inherit from this form. I dont' know
if lazarus is yet able to do form inheritance at design time. I saw a
thread some times ago that it was not yet able to do it in the editor.
But in the code, it will.
It requires inheritance / class creation knowledge. You could
certainly find a lot of information on the web (see Delphi) if you are
not very familiar with this. These are concepts not too hard to learn.
As for the bd controls, it should be no problems if they are created
at run time. It is probably some simple things that are missing. (I
did not try the controls, I'm talking about theory here.)
> In the Visual FoxPro world I normally would have an object (class) that is
> placed on the form to handle all interaction with the data as required. But
> so far I don't understand how to do this with the SQLdb controls. I could
> create a class to create and set all the SQLdb controls in code but I don't
> understand how to add it (the class) to the forms. Even if I did create the
> class I don't see the advantage over just placing the SQLdb controls directly
> on the forms. OOP for OOP sake does not make much sense. Placing the
> TSQLTransaction on the form handles all the 'Begin' and 'Rollback' issues and
> infact by placing a PQConnection on each form creates a new connection to the
> database - therefore, the database is then responsable for any data locking
> issues. What could easier - I don't have to worry about record locking
> except within the forms access. So you can see I have questions about how
> data is accessed.
The way to go in Delphi (and Lazarus) is to create a TDataModule and
put all your DB related stuff there. Then in the Form you 'uses' the
TDataModule and acces the DB aware controls from there. So you have
only one central location. This is much better than my previous
example bellow. (In fact, I would never do that personally; I use
DataModules.) This is a very clean OOP approach, and code reuse can be
potentially high and effective (and lower your app size and increase
efficiency with memory, etc.) I say 'could' because it depends how you
code your thing. :)
Best regards.
--
Alexandre Leclerc
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
