Re: Question about Class Helpers

Jolyon,

Interesting idea .... very interesting idea.

If you don't find these 3 hours, maybe that could be shared amongst several developers (hint, hint)

Didier

Jolyon Smith wrote:
In article <47577c9b@xxxxxxxxxxxxxxxxxxxxxx>, Didier Gasser-Morlay says...

I am all ears, what "proper design and coding techniques" would you suggest to add some "dbawareness" to an existing hierarchy of edit components

Turn the problem about....

Instead of trying to think how you can add DB awareness to an existing control, instead try thinking about how you might make a DB framework aware of those controls.

I did exactly that with my first real work in Delphi - an encapsulation of the (then) Gupta SQL/API.

This was "inspired" by my previous life as a Gupta SQL Windows developer where you could write this sort of thing in your application SQL code:

SELECT NAME, ACTIVE FROM CUSTOMER INTO :editName, :chkActive
WHERE CUSTOMER_ID = :CustomerID

When you fetched the result, the data from the NAME and the ACTIVE column would be put INTO the referenced "containers".

The "containers" could be variables or (the fun part) GUI controls!!

(of course, it worked both ways, so that SQL parameters could also reference GUI controls as INPUTS to an SQL command as well as identifying them as recipients of results)

I realised that with RTTI in Delphi, the same thing was possible, so in my implementation I could do exactly the same thing.


Now of course, I couldn't possibly anticipate ALL the classes of controls that might ever be referenced in runtime SQL, and it wasn't really viable to support only a specific set of classes, so I implemented an abstract "binder" class with the sole responsibility for "Get"ting and "Set"ting data from a specific control class on request from the SQL API framework.

I implemented a set of binder classes (a binder class being truly trivial) for the most common controls, TEdit, TListBox, TCheckBox etc etc.

Of course, any controls that inherited from a class for which a binder class was registered would be supported by that binder, OR you could implement an even more specialised binder for that specific sub-class.


This meant that you didn't have to choose TDBEdit vs TEdit, you just used TEdit. And if you wanted to use some other control, you didn't need a TDB... version of that control, you just needed a suitable binder class to be registered.


I eventually went further and supported "parameters" on container references, so if you wanted to (e.g.) select some item in a list, not ADD an item to a list, then you could do that directly in the SQL:

SELECT NAME FROM CUSTOMER INTO :lbCustomers[select] WHERE CUSTOMER_ID = :SelectedCustomerID

The parameters were simply passed to the getter/setter in the binder that could do with it whatever was appropriate or needed.


Just to see how far this could be taken, just for a demo I implemented a binder class for good ol' TChart that supported so many parameters that I was able to create simple, complete charts with only a single SQL statement, with parameters to specify designated axis labels, data series etc etc!


I still have all that code - Delphi 1.0 originally, but eventually ported to 32-bit and then migrated to ODBC... not as "clean" as the Gupta SQL/API version due to the inadequacies of ODBC itself, but the same basic idea.

I keep promising one day to return to it - update it for ADO etc etc.

Just need to find those extra 3 hours in the day that I need to fit it all in!

:)

.

Relevant Pages

  • Re: Question about Class Helpers
    ... This was "inspired" by my previous life as a Gupta SQL Windows developer ... The "containers" could be variables or GUI controls!! ... really viable to support only a specific set of classes, ... I implemented a set of binder classes (a binder class being truly ...
    (borland.public.delphi.non-technical)
  • Re: Setting form properties
    ... I call a SQL function I wrote in SQL ... > subform control, down to the form on the subform..... ... > determines what update rights a user has on the form. ... 10 subform *controls* on the tab pages, which may or may not be the ...
    (microsoft.public.access.formscoding)
  • Re: Give a man a fish?
    ... You can actually learn much about SQL just by switching your queries to SQL view. ... Next, you will be learning about forms, and the various controls you can put on them The controls and the form both have events that fire when something happens. ... Functions such as the Spacein your example are part of the VBA code, but you can use them in contexts outside of code. ...
    (microsoft.public.access.reports)
  • Re: Office 2000 / Office 2007 compatibility question
    ... My tools are chalked full of Active-x controls because I loves me a good tree- ... wheel is that I have to relearn the wheel. ... regarding SQL so I was wondering if you knew whether or not Access SQL got an ...
    (comp.databases.ms-access)