[SOLVED] Responding to Afterscrole events outside of data module

[Tomu]

If I put the TQuery, and other non-visual data widgets in a data module, how can a TForm know when the user has moved in the dataset. There won’t be an AfterScrole event to attach code to. All I can think of is to for the data module to have a property/event handler that code could be assigned to. Any other suggestions?

[dseligo]

What is TQuery? Do you mean TSQLQuery?

Create a method in your form like this:

Code: Pascal  [Select][+][-]

1. procedure TForm1.MyAfterScroll(DataSet: TDataSet);
2. begin
3.   // code you want to run when dataset is scrolled
4. end;

You can attach this method to SQLQuery in OnCreate event of your form:

Code: Pascal  [Select][+][-]

1. procedure TForm1.FormCreate(Sender: TObject);
2. begin
3.   DataModule1.SQLQuery1.AfterScroll := @MyAfterScroll;
4. end;

You need to add unit DB to uses in your form unit (and of course, your datamodule unit).

[Tomu]

Thanks dseligo!

That should do it.
Something more elaborate might be needed if mode than a single form wants to respond to the event.

[dseligo]

Thanks dseligo!

That should do it.
Something more elaborate might be needed if mode than a single form wants to respond to the event.

Maybe something like this can help you: https://www.freepascal.org/docs-html/rtl/classes/ifpobserved.html

[CharlyTango]

I don't quite understand the problem.

The data that I make available for editing on a form can be covered by one, or at most two, TSQLQueries in at least 80% of cases. If there are more, you should rethink your design and move parts of the form to a TFrame, for example.
Ultimately, this means that there is one data module in the application that is responsible for the database connection, and the combination of TSQLQuery/TDatasource ( along with the associated data-sensitive controls) are located on the forms.

And if I then have to respond to a scroll event, I use the OnAfterScroll event directly in TSQLQuery. To do this, I neither don't need to assign any functions that may differ for different forms and purposes nor use any observer construction. That would only get me into trouble and can be done easier.

[Tomu]

Suppose I have a single data-module containing a TSQLQuery.
I also have 2 Forms. Each form has a non-data-aware widget (like a synedit for example), and a DBGrid and Navigator widget  connected to the  TSQLQuery in the data-module.
When the used scrolls with the  Navigator, I want to load a non-data aware synedit from a field in the TSQLQuery.

I could get around this by adding a TSQLQuery to one or both forms, but that breaks the advice to put all the non-visual database stuff in a data-module.

[Tomu]

Thanks dseligo,

I finally got around to implementing the Observer pattern. That seems like the right way to go.
Although, in a smaller project, just moving the TSqlQuery out of the data-module and onto the form is simpler.

Although it took me a while to overcome my laziness and implement the Observer pattern, I'm glad I did. It's a great tool to have access to.