Kevin O'Neill
----- Original Message -----
From: "Glenn Lawler" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, April 28, 2006 7:48 AM
Subject: [delphi-en] Re: Why not use use db-aware controls.
> > You mean that db-aware controls are more complex and therefore more
> > difficult to maintain?
> >
>
> Not at all. They are much easier to maintain as long as you do not
> change anything about your application or the backend you are using
> that conflicts with the code that implements the control. The problem
> is, those kinds of conflicts happen a lot. My point is that when they
> do, you can spend more time coding workarounds than you would spend
> coding your own interface to the standard controls in the first place.
>
> > I'm working on an application server framework, also including
> basic
> > business objects. If I provide easy linking with db-aware controls
> I
> > need to hold their data in a TDataSet descendant. An alternative
> way is
> > followed by tiOPF which contains so called "persistent object-aware
> > controls". Also I could leave it to the user to create the
> link
> > between controls and the object's data.
> > Comments?
> >
>
> My comment is that the guys that created these components made them
> simple to use by hiding information. You can get the same effect as
> the data aware components using standard components. We have written
> our own library that binds all the standard windows controls to
> queries. We have completely eliminated the BDE and have written
> another library that goes directly to ODBC to communicate with the
> database. The way we have implemented both libraries that is
> different than the shrink wrap ones we have used is that they are
> highly granular. That is, there are both very high level and very low
> level calls you can make to our libraries that allow for complete
> control. For example, we have a BindControl call (a separate one for
> each standard control) in which you pass the control as a parameter
> along with a pointer to a library structure. After that single call,
> everything is handled by the library both to and from the control.
> However, you can do other calls that override just about anything you
> need to override in terms of the behavior of the control. Since we
> wrote the library, we can add any other functionality we need when
> that need arises.
>
> In general, my advice is this: Learn how to write software using the
> basic underlying language, in this case, Pascal. The main reason we
> started using Turbo Pascal many years ago and moved away from IBM
> Compiled Basic (written by Microsoft) is that the Pascal language was
> based on an ANSI standard, and Basic was not. If you do that and
> learn how to abstract and modularize (library) your code, you will
> find that you can make your own code just as easy to use as the
> shrink wrap solutions, but still maintain complete control over how
> it works.
>
> We try to use the Windows API in our libraries for greater control.
> APIwithDelphi is a group that is all about how to use Delphi in this
> way:
>
> http://groups.yahoo.com/group/APIwithDelphi/
>
> We are in the process of porting a lot of our code to Linux and when
> you write you own libraries, you can achieve platform independence.
> We are currently investigating FreePascal for this with some success
> already.
>
> Glenn Lawler
>
> --- In [email protected], constantijnw <[EMAIL PROTECTED]> wrote:
-----------------------------------------------------
Home page: http://groups.yahoo.com/group/delphi-en/
To unsubscribe: [EMAIL PROTECTED]
SPONSORED LINKS
| C programming language | Computer programming languages | Java programming language |
| The c programming language | C programming language | Concept of programming language |
YAHOO! GROUPS LINKS
- Visit your group "delphi-en" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
