Hi,

I'm just curious. Kylix and Delphi (at least v7) comes with excellent documentation and quite a few example projects. But not a single DB example shows a multi-form database application. They are all just a single main form demo. I couldn't even find examples of such demos on the internet, and I've spent more time searching than what I intended.

Does the Lazarus community have such a demo?

What I'm looking for is a typical "Address Book" or "Shopping/Ordering" example which has multiple forms where each form edit's a different business object. In the tiOPF project we have such an Address Book example - as can be seen in the screenshot attached. But I need an example that use the traditional "prototype" (aka RAD) style development of Delphi and Lazarus.

Anybody know of such an example or article explaining the concept (best practices).

Regards,
Graeme

-------------- next part --------------
A non-text attachment was scrubbed...
Name: addressbook.png
Type: image/png
Size: 26412 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171005/64582f1f/attachment-0001.png>

Graeme Geldenhuys wrote

I couldn't even find examples of such demos on the internet, and I've spent more time searching than what I intended.

What I meant to add to that is that I find it very strange that no such demos are available. After all, in a real-world business case (and even personal) you would hardly ever write a single form database app.

Regards,
Graeme

What I meant to add to that is that I find it very strange that no such

demos are available. After all, in a real-world business case (and even personal) you would hardly ever write a single form database app.

Because that defeats the purpose of a demo project: to introduce a feature in as simple as possible way (although some demos like the openglcontrol one is indeed quite complex, but the complexity comes from the opengl code, not how to use the control).

After all, single or multi form doesn't differ much, it's just the way you structure your project. Rather than searching for demo, you can just search for a real application using queries like: "(written OR created OR made OR programmed OR coded) (in OR using OR with) lazarus" (quotes included).

leledumbo wrote

Because that defeats the purpose of a demo project:

A "real world" example (or close to it) would also be a very valuable source of information. Education for the masses. In the tiOPF project we stuck to small-and-to-the-point demos for many years, and was constantly bombarded with requests to make more real-world like examples, so they can see how it all fits together.

After all, single or multi form doesn't differ much, it's just the way you structure your project.

And that is exactly my issue... What are the best practices? I haven't done "prototype" (aka RAD) style development with Delphi or Lazarus in over 10 years. I've long moved to a more OOP approach where I work with actual business/entity objects. eg: AddressList.Load(), lPerson.Address.Country = xyz etc, and not directly working with raw table data in my applications.

Last night I played with the prototype/RAD style development and found in so frustrating - having things hard coded everywhere (eg: fields for a DBGrid) etc and then when I change the data source my whole program bombs out because now the DBGrid is referencing columns that don't exist, and then I have to recreate the DBGrid columns and resize them again to fit the UI etc. And then there is the matter of having your User Interface layer chock full of business logic because I hooked into the various events of the DB controls, DataSource, ClientDatset. Yes - I've tried to place as much as possible in a Data Module, but it seems I'm fast heading to the same issue I had 15 years ago....

http://geldenhuys.co.uk/~graemeg/datamodule.png

I've been using tiOPF for so long, I've forgotten what a pain (nightmare) RAD style development can be. Has nobody to this day come up with a simple set of steps on how to implement more maintainable RAD style projects? I have always been told by others that an OPF framework isn't needed, and you can have clean / maintainable RAD style projects with Delphi/Lazarus.... I'm looking hard, but I can't find any such examples, or steps to follow. :-/

Any such help would be much appreciated.

Regards,
Graeme

The same is true in tiOPF, when using mediators:

Listview mediator
     constructor CreateCustom(AModel: TtiObjectList; AView: TListView; ADisplayNames: string; AIsObserving: Boolean = True); reintroduce; overload;
     constructor CreateCustom(AModel: TtiObjectList; AView: TListView; AOnBeforeSetupField: TtiOnBeforeSetupField; ADisplayNames: string; AIsObserving: Boolean = True); reintroduce; overload;
grid mediator:
    constructor CreateCustom(AModel: TtiObjectList; AGrid: TStringGrid; ADisplayNames: string; AIsObserving: Boolean = True); reintroduce; overload;

If the underlying object changes, and ADisplayNames still contains an old property name, then you get an error as well (or worse, no error, but missing columns)

In one case you must change the code, in the other, you use the point-and-click paradigma of RAD to correct things...

And then there is the matter of having your User Interface layer chock full of business logic because I hooked into the various events of the DB controls, DataSource, ClientDatset.

Business logic should never be in DB controls events, only in field/dataset events.

Using only 1 datamodule is of course doomed to fail.

Not sure if it helps, but see

https://www.freepascal.org/~michael/articles/

The series "Large database applications in delphi". The strategy described there is used in a set of applications in which the main one has over 2000 forms.

Michael.

Michael Van Canneyt wrote

The same is true in tiOPF, when using mediators:

At least I get a compile time error (most of the times), not a runtime error. And with tiOPF there was only one location to fix.

With the code I played with last night (where the table columns changed), I had to fix/recreate the columns in the DBGrid component and in the ClientDataSet component. Maybe I'm doing something wrong - like I said, I have used RAD style development in years, but the DBGrid did not pick up the fields, field widths etc I set up in the ClientDataSet.

Playing around I set the DisplayName and DisplayWidth on the fields in the ClientDataset, but the DBGrid is only picking up the field DisplayName's, it is not adhering to the DisplayWidth settings. So that is why I had to right-click the DBGrid, Columns Editor... and Add the required fields there too, and then set the column widths on the DBGrid. So this is why I had two placed to fix when the underlying database table changed. How do I get the DBGrid to take note of the ClientDataset's DisplayWidth values? I have the same issue in Lazarus - DisplayWidth is ignored by the DBGrid.

ps:
Does Lazarus have a TClientDataset component? I don't see anything on the component palette.
I'm using Lazarus 1.9.0 r54792 FPC 3.0.2 x86_64-freebsd-gtk2

   I normally use TClientDataset to get local changes with a undo
   option in the UI. Or if the end-user wanted those changes, then
   I simply call ApplyUpdates(). What is the equivalent in FPC/Lazarus?

In one case you must change the code, in the other, you use the point-and-click paradigma of RAD to correct things...

The other problem I'm experiencing is that all these settings are done via point-and-click. If I delete a component, all those settings disappear and I have to revert my code changes with Git, or recreate all settings. At least with tiOPF (where I chose to use code), I can delete and recreate components with ease in the UI, but never loose my custom settings (code).

Business logic should never be in DB controls events, only in field/dataset events.

I'll make sure - thanks.

The series "Large database applications in delphi". The strategy described there is used in a set of applications in which the main one has over 2000 forms.

Thanks Michael, I'll browse through that now.

Regards,
Graeme

Here is a Free Pascal RAD-style multi-form DB project for Firebird 3: https://gitlab.com/mseide-msegui/mseuniverse/tree/master/tools/kicad/bom

It strictly separates GUI and business logic, in practice one probably would be less strict...

Martin

Michael Van Canneyt wrote

The series "Large database applications in delphi". The strategy described there is used in a set of applications in which the main one has over 2000 forms.

Thank you Michael, that set of articles were immensely useful - as all your articles always are. Thanks again for pointing me to that.

I think Lazarus could actually take some tips from those and implement those TDBForm etc classes you mention. Be a step or two ahead of Delphi. ;-)

Regards,
Graeme

Am 05.10.2017 13:33 schrieb "Graeme Geldenhuys via Lazarus" <

via point-and-click. If I delete a component, all those settings disappear and I have to revert my code changes with Git, or recreate all settings. At least with tiOPF (where I chose to use code), I can delete and recreate components with ease in the UI, but never loose my custom settings (code).

I might be wrong, but wasn't undo support added to the form designer? Or is that merely a feature request in the bug tracker I had seen...

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171005/c903cebb/attachment-0001.html>

[...] I might be wrong, but wasn't undo support added to the form designer?

Yes, some years ago.

Mattias