Is there a way to have an LCL widgetset outside of the Lazarus tree? I'm considering writing one for my Little Forms C toolkit at some point but i don't think it would be very useful to others so i don't think there is much of a value in having it as part of the Lazarus codebase (and TBH i cannot guarantee i wont abandon it). Even better if it is possible for it to exist as a package.

My main motivation is wanting to get away from the modern madness of GTK3+/Qt5+/Wayland and all that stuff and their dependencies but i'd rather not rewrite in C all the tools and library code i wrote in Lazarus, so a custom widgetset that relies only on Little Forms (which itself makes an effort to rely only on libX11 with an optional Xft dependency) sounds ideal.

However i'm not sure how extensible the LCL widgetset backend is and from a quick look it seems like there is a ton of manual work just to introduce a new one. Am i missing something?

Worst case, i'll maintain it as a patchset that needs to be updated with the main code, but i'd rather not if there is a cleaner way (or can be easily introduced, after all this isn't something i need immediately :-P and i think there is value on this being a standard feature). -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171123/e034109a/attachment.html>

Hello,

You could give a try to fpGUI Toolkit :

http://fpgui.sourceforge.net/

Regards,

Stéphane Aulery wrote

Hello, On Thu, Nov 23, 2017 at 04:23:19AM +0200, Kostas Michalopoulos via Lazarus

or MSEide+MSEgui:
https://sourceforge.net/projects/mseide-msegui/
Just released version 4.6.

Martin

Am 26.11.2017 14:23 schrieb "Kostas Michalopoulos via Lazarus" <

:

Is there a way to have an LCL widgetset outside of the Lazarus tree? I'm considering writing one for my Little Forms C toolkit at some point but i don't think it would be very useful to others so i don't think there is much of a value in having it as part of the Lazarus codebase (and TBH i cannot guarantee i wont abandon it). Even better if it is possible for it to exist as a package.

My main motivation is wanting to get away from the modern madness of GTK3+/Qt5+/Wayland and all that stuff and their dependencies but i'd rather not rewrite in C all the tools and library code i wrote in Lazarus, so a custom widgetset that relies only on Little Forms (which itself makes an effort to rely only on libX11 with an optional Xft dependency) sounds ideal.

However i'm not sure how extensible the LCL widgetset backend is and from a quick look it seems like there is a ton of manual work just to introduce a new one. Am i missing something?

Worst case, i'll maintain it as a patchset that needs to be updated with the main code, but i'd rather not if there is a cleaner way (or can be easily introduced, after all this isn't something i need immediately :-P and i think there is value on this being a standard feature).

Lazarus already contains a custom drawn widgetset that supports X11. I don't know its current state, but maybe it would be best to bring that up to speed and form instead of starting a new one.

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

@Stephane:
@Sven:
I know about fpGUI (Sven i assume you mean that), but i am already working on a widget toolkit for a few years now which is written in C and if i'm going to work on a custom widgetset might as well make it target the one i'm already working on which is used by some other stuff i am doing to keep things consistent.

Also AFAIK fpGUI doesn't use the native window system beyond the toplevel windows, which i think would make OpenGL support and interfacing with external stuff (e.g. calling an external library where you pass a HWND/X11 Window directly) harder.

As i said, i do not think this would be useful enough to others to be part of the Lazarus tree. I ask because i remember a few months ago someone having an Amiga widgetset pretty much in working condition and that was something he worked on for a while, so i wondered if there was some mechanism for that. I suppose just having a big patch would also work, although it is kind of inconvenient.

@Martin:
AFAIK MSEgui doesn't have an LCL widgetset. Most of my code is LCL specific and my concern is to keep using that code. If i am to rewrite it, might as well rewrite it in C.

On Sun, Nov 26, 2017 at 6:13 PM, Sven Barth via Lazarus <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171126/d9291682/attachment.html>

Am 26.11.2017 18:32 schrieb "Kostas Michalopoulos via Lazarus" <

:

@Stephane:
@Sven:
I know about fpGUI (Sven i assume you mean that), but i am already working on a widget toolkit for a few years now which is written in C and if i'm going to work on a custom widgetset might as well make it target the one i'm already working on which is used by some other stuff i am doing to keep things consistent.

No, you assume incorrectly. The custom drawn widget set is independent of the fpgui widgetset and completely resides inside the LCL.

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

MSEgui has TWindowWidget (has a window handle) and TOpenglWidget for that purpose.
I am sure fpGUI also could introduce such widgets. There is also a fpGUI version with windowhandle per widget.
[...]

I doubt it. ;-)
If the "business logic" is well separated solely the forms must be reverse engineered with MSEgui which often is possible with managable time and effort.

Martin

Sven Barth wrote

Lazarus already contains a custom drawn widgetset that supports X11. I don't know its current state, but maybe it would be best to bring that up to speed and form instead of starting a new one.

Some time ago I did play with the custom drawn Widget Type. I found that it was not yet complete but rather promising. AFAIK, not much has changed since then .

Anyway I also would suggest to use this to build on. This will be a lot easier that do something completely new.

In fact, Widget Types need to be known to the Lazarus IDE, as same is able to have the user select them and force them via definition of conditionals fed to the compiler.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171127/fa28ab2a/attachment.html>

Kostas Michalopoulos wrote

i am already working on a widget toolkit for a few years now which is written in C ... Most of my code is LCL specific

This seems like a very peculiar combination to me.

-Michael

On Sun, 26 Nov 2017 19:32:21 +0200

The Amiga widgetset is the 'mui'.

You can add a new widgetset in folder lcl/interfaces/yourws and use it in your project.

For some nicer integration you can add an enum to
lcl/lclplatformdef.pas.

The IDE checks only the sources listed in the lcl.lpk. Since your files are not listed there, changing any of your widgetset sources will not trigger building the LCL package automatically. So you have to click on the 'Compile' button in the LCL package.

Mattias

@Sven:
Ah, i thought the custom drawn was built on top of LCL. Hm, regardless, it doesn't solve my concern, since what i want is to reuse my widget toolkit. Otherwise i'd probably work on fpGUI's Lazarus bindings since fpGUI seems to be more mature.

@Martin:
No, it is tied to LCL :-P a lot of code uses LCL classes and i don't really separate the "business logic" since i never planned (nor plan) to use that code outside of LCL/Lazarus. This is mostly library code for graphics-related utilities, common code for UI stuff like adjustments, etc. Some code could work outside of LCL, but it is mixed with code that relies on LCL and separating the two isn't worth the effort.

@Michael:
The "most of my code is LCL specific" part is about the code i work with on Lazarus. Overall my code is pretty much even between Lazarus and C (with a very tiny bit of LCL-free Free Pascal code). Generally for GUI heavy desktop stuff i use Lazarus (and LCL) and for everything else i use C. For some newer GUI stuff (currently light in GUI) i also use C with my toolkit.

@Mattias:
Thanks for the information. So in theory i could write a shell script that creates a symbolic link lcl/interfaces/wsfoo that points to some external (from Lazarus' source code dir) directory and adds (via sed, awk or whatever) wsfoo to lcl/lclplatformdef.pas and then projects that override the target widgetset (via the LCLWidgetType:=foo IDE macro) would work?

Kostas

On Mon, Nov 27, 2017 at 1:36 PM, Mattias Gaertner via Lazarus <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171127/58b38337/attachment.html>

On Mon, 27 Nov 2017 19:45:42 +0200

Yes.

Mattias

Kostas Michalopoulos wrote

My main motivation is wanting to get away from the modern madness of GTK3+/Qt5+/Wayland and all that stuff and their dependencies

Then my I suggest you take a look at the LCL-fpGUI widgetset. It has all the basic components working (except for TLabel), and many of the other Windows like API's and dialogs etc. It desperately needs a maintainer - I don't have the time, and rather spend my time improving fpGUI directly, than maintain a LCL widgetset.

Either way, it would save you a ton of time and effort - plus it will check off some of your requirements like no large toolkit dependency hell like GTK3 and QT introduces. Plus, everything is implemented in Object Pascal.... LCL and fpGUI Toolkit.

Regards,
Graeme

Kostas Michalopoulos wrote

Also AFAIK fpGUI doesn't use the native window system beyond the toplevel windows, which i think would make OpenGL support and interfacing with external stuff (e.g. calling an external library where you pass a HWND/X11 Window directly) harder.

Just so inform everybody. fpGUI has the ability to switch between "alien windows" (only a top level window handle) or "each widget has a handle" during compile time. I've been a huge supported of the latter for many years, but in the last year or two I've seen first hand the benefits of the "alien windows" style and want performances it brings.

Implementing OpenGL inside a fpGUI application (where alien windows is enabled by default) shouldn't be a problem at all, as any fpGUI widget can specify if it needs its own window handle or not.

Regards,
Graeme

Sven Barth wrote

The custom drawn widget set is independent of the fpgui widgetset and completely resides inside the LCL.

It's state is also way worse than the LCL-fpGUI widgetset. It is still in a very early Alpha state as far as I'm concerned. Either way, it would be nice to see LCL-CustomDrawn and LCL-fpGUI widgetsets get some more attention. In they were usable, I would instantly switch to either of them over the Qt or GTK widgetsets.

Regards,
Graeme

Graeme Geldenhuys wrote

Just so inform everybody. fpGUI has the ability to switch between "alien windows" (only a top level window handle) or "each widget has a handle" during compile time.

I forgot to mention, the latest stable release of fpGUI Toolkit (v1.4.x) is still based on the each-widget-has-its-own-window-handle design.

Regards,
Graeme

Graeme Geldenhuys wrote

 Either way, it would be nice to see LCL-CustomDrawn and LCL-fpGUI widgetsets get some more attention.

Is there any chance to unify them to a single Widget Type implementation that uses a low level graphics API (without an external Widget Set) ?

AFAI understand, MSE-Gui does this very successfully. They even provide a functionality called "IFI" that allows for remoting the interface between the RTL (and the MSE-variant of the LCL) and the "custom drawn" library via a stream interface.

IMHO this is a highly attractive way to provide an optional remote GUI to otherwise headless applications, while still providing portability and  support for Delphi-typical RAD-style development.

-Michael

Graeme Geldenhuys wrote

 (except for TLabel)

????

To me TLable seems like very important to allow easy "porting" of applications from an other widget Type to fpGUI/LCL. Is implementing TLabel really that hard ?

-Michael

Am 28.11.2017 10:02 schrieb "Michael Schnell via Lazarus" <

:

Graeme Geldenhuys wrote

Either way, it would be nice to see LCL-CustomDrawn and LCL-fpGUI widgetsets get some more attention.

Is there any chance to unify them to a single Widget Type implementation that uses a low level graphics API (without an external Widget Set) ?

Why should they? They are two completely different projects. From the LCL's point of view fpGui is a black box like GTK, Qt or the Windows API.

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

Sven Barth wrote

Why should they? They are two completely different projects. From the LCL's point of view fpGui is a black box like GTK, Qt or the Windows API.

OK, so in the end fpGUI *is* an external Widget set, only that it comes more independent of the OS distribution than WinXX, GTK, QT or Apple variants.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171129/47c5f0bd/attachment.html>

Am 29.11.2017 09:41 schrieb "Michael Schnell via Lazarus" <

:

On 28.11.2017 11:28, Sven Barth via Lazarus wrote:

Why should they? They are two completely different projects. From the LCL's point of view fpGui is a black box like GTK, Qt or the Windows API.

OK, so in the end fpGUI *is* an external Widget set, only that it comes more independent of the OS distribution than WinXX, GTK, QT or Apple variants.

Correct (though GTK and Qt are also rather OS independent).

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

Hello,

I can spend some time, again, improving LCL-fpGUI but I need the help of somebody expert in fpGUI, as I'm not a fpGUI user at all, and one with good skills in the LCL widget bindings internals, because the last update was stopped because I found unsolvable (by myself alone) problems trying to implement maybe TLabel (I can not remember).

When I say help I mean a way to communicate quite fast (maybe direct email) as waiting 2 or 3 days for an answer is frustrating when working with a widgetset as quite sure that missing knowledge is stopping the code write completely.

If somebody wish to help I would try again to implement more controls.

Michael Schnell wrote

and support for Delphi-typical RAD-style development.

RAD style development is highly overrated - I wish you can see the mess I'm looking at (not my code). Each form are 1000's of lines long with tons of database logic hard-coded, business logic etc. The business rules are scattered between data modules, UI forms and stored procedures. Solving a bug - a needle in a very large haystack.

Regards,
Graeme

Sven Barth wrote

Correct (though GTK and Qt are also rather OS independent).

The plus point of fpGUI is that when you compile LCL-fpGUI, you compile (or could recompile) the underlying toolkit too. So bug fixes or improvements can be applied instantly (to LCL or fpGUI). When you build LCL-QT or LCL-GTK3, you don't normally recompile Qt or GTK3 - instead you wait for when those toolkits release a new version and that filters to the next release of your Linux distro.

Regards,
Graeme

Michael Schnell wrote

Is implementing TLabel really that hard ?

In LCL yes, because it isn't a widget in the normal sense (unlike in fpGUI). Instead LCL uses Windows-like API calls to render what TLabel represents. The LCL-fpGUI widgetset doesn't have all those Windows-like API's implemented yet.

There is actually a whole wiki page dedicated purely to "how to implement TLabel in a new LCL widgetset". That just goes to show how different and difficult it is to implement - compared to all the other widgets.

Regards,
Graeme

José Mejuto wrote

I can spend some time, again, improving LCL-fpGUI but I need the help of somebody expert in fpGUI, as I'm not a fpGUI user at all, and one with good skills in the LCL widget bindings internals, because the last

I'll gladly help where I can, regarding fpGUI. See my private reply for details on how to contact me faster.

Regards,
Graeme

Graeme Geldenhuys wrote

RAD style development is highly overrated...

I do know that very exactly, been there often enough.

RAD is great to create "small" applications, but with huge projects, you will very likely hit a limit where you wish you would not have started the project in an RAD manner.

Nonetheless there are lots of 3rd party components for Delphi (and Lazarus if you can get them in source code) that prevent to do your projects using them in a non-RAD manner, as they provide or organize business logic but their components need to be "dragged on a form" and create some user interface there, instead of just providing hooks to have the user do his own GUI for them if appropriate.

Porting originally RAD crafted projects to a headless environment (e.g. a small embedded device or to allow running them as a service) is possible (did that multiple times) but a real PITA.

That is why a long standing wish is a fully fledged LCL Widget Type (just swap the Widget Type in the project's configuration in Lazarus and press compile), that provides no local GUI but some hook to optionally attach a remote GUI. MSE can do something like this via "ifi" (i.e. an external fpc program connected via some stream interface), more "generally usable" would be an application running in a browser (e.g. Pascal compiled Java script or WebAssembly) connected via HTTP/WebSocket, and a decently prepared way to use such "nearly remote" GUI for a Linux/Windows/Mac "service".

-Michael

Michael Schnell wrote

e.g. a small embedded device or to allow running them as a service..

Of course another important "headless environment" is server applications with built-in Web server or sitting behind a standard WebServer.

-Michael

It is not easy to break free from old, procedural programming practices especially that one of the 'best books' at the time did actively encourage this kind of programming (Delphi 'Bible', around the time of D7, I'm looking at ya)

Heck, even the quasi-gui systems of old (Clipper, anyone?) were not emphasizing that.

(or just did not erect the business <-> GUI code barrier high enough for people to notice... or even state what it is or where it is supposed to be, or how it's supposed to be organized. There is a sore lack of mid-grade non-trivial examples of that... when most examples for D you can find are 'slap a button on the form and then paste this code to OnClick procedure', it starts inevitably to look like a hammer, to invoke the age-old pun ).

This may be 'obvious' to born and bred programmers ...

... but may not be not so for someone who just picked the Delphi for Beginners, and tried to learn from that. Or just carried over their experience from Fortran, or Matlab, of all things.

Regards, Graeme

/rant ;)

-L.

el es wrote

It is not easy to break free from old, ... programming practices

Nonetheless, IMHO RAD is a great way to start programming, as you immediately and painlessly can see (visualize) what your "business logic" software does and easily set parameters and triggers for your business logic. So you are not that likely to jump off the ship at an early stage.

But education needs to make clear the limitations of this proceeding strong enough.
-Michael

Michael Schnell wrote

Nonetheless, IMHO RAD is a great way to start programming, as you immediately and painlessly can see (visualize) what your "business

RAD should only be used for prototyping. ie: once the prototype is done and not needed, bin the code. And don't be fooled thinking small utility apps are great for RAD too. Once that utility get traction, feature get added, the thing grows like wild-fire and you are in a sh*t storm once again. Even "small" utilities can do with a good design and business logic separation.

It might sound harsh, but boy will you save yourself from headaches years down the line when your application has grown to multi-million lines of code.

[done ranting for now]

Regards,
Graeme

That is your opinion, my opinion is that RAD is the most productive development technology for most of the projects if done right, separating of GUI and business logic is perfectly possible with RAD. For me MSEide+MSEgui doubled the productivity compared with other tools. It seems to me because you repeat your statement over and over again you never made a RAD development "right" with the right tools. ;-) And the often heard statement that RAD should not be used because it is possible to write bad applications with RAD applies to every other design methology too.

Martin

Martin Schreiber wrote

That is your opinion, my opinion is that RAD is the most productive development technology for most of the projects if done right,

And your last 3 words is the most important part - "if done right". In my 20+ years of using Delphi, I can count of one hand how many company products I've seen "done right" using the RAD style approach. And I've worked at plenty of companies in that 20+ years. It seems "if done right" is a near impossibility for most Delphi developers.

So I'm not saying its impossible, just very very unlikely. Using non-RAD approaches seems to guide the developer in better design, but yes, they could still screw that up too (without leadership guidance).

Regards,
Graeme

For me Delphi is not the best RAD environment and therefore developments made with Delphi should not be used to disqualify RAD as a whole.

Martin

Martin Schreiber wrote

separating of GUI and business logic is perfectly possible with RAD.

Yep. But you need to apply this discipline to yourself right from start of the project, as doing this afterwards is tedious.

Unfortunately many projects arise from sloppy prototypes necessary as a proof of concept before officially starting the project.

-Michael

Martin Schreiber wrote

For me Delphi is not the best RAD environment and therefore developments made with Delphi should not be used to disqualify RAD as a whole.

Which are there other than Delphi and its siblings ?

-Michael

Il 01/12/2017 08:01, Graeme Geldenhuys via Lazarus ha scritto:

I don't believe you can give a general rule. The tool must be appropriate for the application. The word "programming" includes an universe of non compatible things. Something like "mechanical design". Designing a watch is something completing different than designing a monorail train.

We used Delphi, and now use Lazarus to design the human interface for automatic machines, where the visual part is the most important one. The RAD approach is the most efficient and productive. But when we had to interface the production data generated with company database, it turned out that one had to write a lot of non-visual code, and we found that RAD approach would just have confused things, leading to unreadable and inefficient code.

Just my 2 cents.

Giuliano

I had the same experience working in some companies.

So I'm not saying its impossible, just very very unlikely. Using non-RAD approaches seems to guide the developer in better design, but yes, they could still screw that up too (without leadership guidance).

+1
I agree.

Best,
Marcos Douglas

I agree Delphi, nowadays, is not the best RAD environment.

Best,
Marcos Douglas

Apparently MSEide+MSEgui which is no Delphi sibling. ;-)

Martin

I believe RAD is the best way to code a GUI, but not to write the business rules.
As you said, "...RAD approach would just have confused things, leading to unreadable and inefficient code".

Best regards,
Marcos Douglas

Marcos Douglas B. Santos wrote

I believe RAD is the best way to code a GUI....

I'll even disagree with that - somewhat. :)

http://geldenhuys.co.uk/articles/model-gui-mediator.pdf

With Model-GUI-Mediator (think MVC or MVP design patterns but for modern GUI toolkits) you use RAD style to drop components on a form, but you DON'T hook into any events or Dataset properties using the form designer. Also, you DON'T use data-aware controls.

Instead you use Mediators - a very thin layer of non-gui code (reusable and only implemented once) that links widgets and business objects. Bi-directional updates occur automatically via the Objserver design pattern. MGM was the reason FPC now has Observers built into classes like TStringList etc.

The MGM implementation I described in the article is very basic - to get the idea across much easier. The MGM implementation inside tiOPF is *much* more advanced and improved - requiring *much* less boiler-plate coding too.

MGM also allows you to switch your application from LCL to fpGUI to VCL in a blink of an eye. The mediators for all these toolkits are already written - so nothing new to implement. Switching a form design from using a TListView to TStringGrid (or vice-versa) is also a 2 second job.

Creating mediators for new components....For example TChart ora DevExpress QuantumGrid is a 5 minute suddenly you can use any of the free or paid for components - not just db-aware components.

I've used MGM in multiple commercial projects for about 6 years now - it works brilliantly. You UI form units are almost empty, and good separation of UI, business rules and persistence. Plus I can use OOP and real "objects" in my code, not SQL queries and TField instances.

Regards,
Graeme

In my personal experience the "RAD" approach used by Delphi, Lazarus and old VB (i'm not sure if proper RAD really was about what you see in those products and not something Borland and Microsoft's marketing departments decided to use because it was cool at the time) is the fastest and often best way to create desktop applications. Yes, it can end up messy for larger applications if you are not careful and i've written my share of things i'd rather rewrite than fix (although they are fixable with the right amount of effort), but i still consider it worth it and i see any other approach as going backwards.

To put it simply, the only reason i use Lazarus and the only reason i recommend it to others (mainly programmers who want to make desktop applications) is its "RAD" features (and cross platform support, of course). Creating a form, dropping a field and a button and double clicking on the button to type something like "ShowMessage(Edit1.Text);" and press Run to run it has been for many years my first test for separating Bad vs Good desktop GUI development environments - and the one most fail at. Simple things must be simple, complex things must be possible and Lazarus allows for both.

On Fri, Dec 1, 2017 at 9:43 PM, Graeme Geldenhuys via Lazarus <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171202/e4076e97/attachment-0001.html>

I am aware of MVC, MVP, MVVM, and now MGM.
I agree with you but, they represent almost the same thing.

Unfortunately, it was implemented in a wrong way, using classes instead of interfaces instances.

That is interesting.

I think you misunderstand me. I said "RAD is the best way to code a GUI", the visual part, not the business rules.
I don't use db-aware — well only TDBGrid just to show data — and I don't have any business rules using TFields, Before|After Post, etc.

Best regards,
Marcos Douglas

The article starts :

After mastering OOP and Object Persistence, the next thing developers need to conquer is how to present their business objects in the GUI ...

IMHO this is the best way to threaten away would be software developers from even starting to try to do any programming but have them do their living as windows cleaners.

When (as a newcomer) starting to do any "business logic", it's essential to have a toolbox that allows for testing your work on the fly. And this (at best) does include a really simple way to add a GUI (this is called RAD), even if intending to use this only for your own purpose and deactivate it in any final version of the product.

-Michael

Marcos Douglas B. Santos wrote

I think you misunderstand me. I said "RAD is the best way to code a GUI", the visual part, not the business rules.

For that you just need a visual form designer. RAD normally entails a whole lot else like hooking into events (in the UI), live view of data in form designer (using eg: a TDBGrid) etc.

I don't use db-aware — well only TDBGrid just to show data

And DBGrid behaves slightly different to TStringGrid, and is slow. Many DB-aware components behave slightly different to the non DB-aware versions. Why two sets of basically the same component? Yet another layer of components that can contain bugs. With Model-GUI-Mediator you use the standard components only, and the mediators are literally just a few lines of code. The rest of MGM (at least the implementation in tiOPF) is all non-GUI and well unit tested.

Regards,
Graeme

This also is your opinion, I don't think you are so absolutely right as your statements allways sound. :-)
In MSEgui the DB-components work very well, are convenient and fast and provide much more possibilities than a TStringGrid. And there is no overhead and limitations and additional complexity by an additional layer like tiOPF. ;-)

Martin

Graeme Geldenhuys wrote

DBGrid behaves slightly different to TStringGrid, and is slow.

While for perfect performance / clearness / portability / ... , DBGrid supposedly should not be used in a production release, it might be very helpful when designing an application.

Maybe the way to go is to do an RAD form with Debug I/O when drafting an application and in the process move any tested business logic code in non-visual units, and when deciding how the final GUI should work and look like do this in another Form, e.g. using "GUI-Mediator". Finally deactivate the RAD form, but keep it for reference.

-Michael

What is wrong with TDBGrid???

Martin

Martin Schreiber wrote

What is wrong with TDBGrid???

As I quoted, Graeme claims it's slow.

-Michael

I doubt it. At least the MSEgui DB-grids are not slow. DB-grids get the data from dataset field buffers for the visible rows only, for strings it means to fetch a UnicodeString by copying a pointer.
TDBWidgetGrid has columns where the placed TDB*EditWidget defines the colum data type and edit functionality of the column. Any edit widget can build a data column, also data-buttons, lookup-dropdown-widgets, images, sliders, dialog widgets...
TStringGrid on the other hand needs a local copy of the whole recordset which looks suboptimal and it has limited functionality without additional programming and endless StrTo*() and *ToStr() conversions.

Martin

Martin Schreiber wrote

This also is your opinion, I don't think you are so absolutely right as your statements allways sound.:-)

At least I sound good. ;-)

In MSEgui the DB-components work very well, are convenient and fast and

I'll have to take your word for it. I've never used MSEgui for any real work. I've only used MSEide - that works well.

provide much more possibilities than a TStringGrid.

TStringGrid was just an example - it can be any widget representing complex data.

and limitations and additional complexity by an additional layer like tiOPF.;-)

tiOPF is not a requirement for Model-GUI-Mediator. tiOPF simply contains the best MGM implementation I know.

I'm actually continuing work on something Michael van Canneyt started very long ago but got lost over time. MGM for LCL with design time support (optional). All without requiring tiOPF, and can totally replace DBAware components.

Regards,
Graeme

Michael Schnell wrote

After mastering OOP and Object Persistence, the next thing developers need to conquer is how to present their business objects in the GUI ...

Quoted out of context. That article was part of a series on Design Patterns published in a programming magazine. It was meant to follow on after many other design pattern articles, but I got a request to bump it up sooner.

even if intending to use this only for your own purpose and deactivate it in any final version of the product.

It seems that step NEVER happens.

Regards,
Graeme