I've just about finished beating my string grid table into submission and I'm about to move onto the dbgrid.

Currently I'm using my own modified copy of Mike Skolnik's grid and using the OnTitleClick event to set the index. What I'd like to do is somehow communicate back to the dataset (EDBTable, EDBQuery or nlhSGTable) in some way to get them to alter their index/order by clause. I've already subclassed Tim's table and query to do things I want so I have no problem with a few more mods if needed.

Any suggestions about ways to do this?

Roy Lambert

Roy,

<< Currently I'm using my own modified copy of Mike Skolnik's grid and using
the OnTitleClick event to set the index. What I'd like to do is somehow
communicate back to the dataset (EDBTable, EDBQuery or nlhSGTable) in some
way to get them to alter their index/order by clause. I've already
subclassed Tim's table and query to do things I want so I have no problem
with a few more mods if needed.

Any suggestions about ways to do this? >>

Given that ORDER BY modifications tend to be very subjective, I would just
add an event to your dataset descendant and then just call a method in the
dataset descendant that triggers the event that allows the end user of your
dataset to modify the ORDER BY or change the index as necessary.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Given that ORDER BY modifications tend to be very subjective, I would just
>add an event to your dataset descendant and then just call a method in the
>dataset descendant that triggers the event that allows the end user of your
>dataset to modify the ORDER BY or change the index as necessary.

That would take care of my nlhSGTable but I'm really looking for a common approach across all three items (EDBTable, EDBQuery, nlhSGTable). I can't spot any usable event or method in TDataset. You with your greater knowledge might know of something.

Its a shame that TDataset didn't introduce a BeforeIndexChange or even better a GeneralUserDoSomething method

I have a couple of half baked ideas to try out - you never know one of them might work.

Roy Lambert

Roy,

<< Its a shame that TDataset didn't introduce a BeforeIndexChange or even
better a GeneralUserDoSomething method >>

Why would you need that ?  The grid will control the whole process.  In
fact, it really has to, especially when you consider trying to parse every
variation of SQL in order to extract the proper ORDER BY (think derived
tables) in order to update the grid (the reverse of having the grid dictate
everything).

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

><< Its a shame that TDataset didn't introduce a BeforeIndexChange or even
>better a GeneralUserDoSomething method >>
>
>Why would you need that ? The grid will control the whole process. In
>fact, it really has to, especially when you consider trying to parse every
>variation of SQL in order to extract the proper ORDER BY (think derived
>tables) in order to update the grid (the reverse of having the grid dictate
>everything).

NOTE ALL COMMENTS BELOW REFER TO DBGRIDS ONLY

That rather baffles me. With the grids I know and understand the grid isn't in control of an index change process. Its just acting as a notifier to the table or query via some form of user action. What I was suggesting was that some additional method to tell the dataset I want to do something would be handy.

Again just talking of the grids I know they tend to respond to a title cell click. Either, for tables where the grid is aware of the specific table type, seeing if the column clicked is an index and if so changing to it for firing off an event so the programmer can do something, but necessitating an event for every grid instantiated. An event at the dataset level would allow me to subclass grid, table and query components to add specific behaviour for the easy cases whilst still having the option to handle the awkward ones.

Roy

Roy,

<< That rather baffles me. With the grids I know and understand the grid
isn't in control of an index change process. Its just acting as a notifier
to the table or query via some form of user action. What I was suggesting
was that some additional method to tell the dataset I want to do something
would be handy. >>

Yes, but given that it's next to impossible to inject such functionality
into the TDataSet hierarchy (if it isn't already there), the only other
option is having the grid control things via the title clicks, etc.

<< Again just talking of the grids I know they tend to respond to a title
cell click. Either, for tables where the grid is aware of the specific table
type, seeing if the column clicked is an index and if so changing to it for
firing off an event so the programmer can do something, but necessitating an
event for every grid instantiated. An event at the dataset level would allow
me to subclass grid, table and query components to add specific behaviour
for the easy cases whilst still having the option to handle the awkward
ones. >>

Yes, but the grids would *still* have to know about these dataset methods
that deal with the order changing, etc. and call them appropriately when the
titles are clicked.

If you want to see how it *should* be done, check out the way the sorting
works with the TGrid and TDataSet in EWB.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Yes, but given that it's next to impossible to inject such functionality
>into the TDataSet hierarchy (if it isn't already there), the only other
>option is having the grid control things via the title clicks, etc.

I know - that's what I was bemoaning.

>Yes, but the grids would *still* have to know about these dataset methods
>that deal with the order changing, etc. and call them appropriately when the
>titles are clicked.

Yes, but since I have a nice subclassed DBGrid that would be no problem.

>If you want to see how it *should* be done, check out the way the sorting
>works with the TGrid and TDataSet in EWB.

Hmm. I've been busy with my nlhSGTable and now this so I haven't looked at EWB for a while - I shall download and investigate over the weekend.

Roy Lambert