Re: [Lazarus] fpGUI Toolkit v1.4.1 released
Happy new version Graeme. Ara -- http://www.fastmail.com - mmm... Fastmail... -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI Toolkit v1.4 release
If you have their links please share them. Any way thank you for fpGUI ;) Regards, Ara -- http://www.fastmail.com - Same, same, but different... -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI Toolkit v1.4 release
Congratulate dear Graeme. I hope in this release you will add more complicated demos. Regards, Ara -- http://www.fastmail.com - A fast, anti-spam email service. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI Toolkit v1.4 release
On 2015-04-09 09:14, aradeonas wrote: I hope in this release you will add more complicated demos. As I mentioned before, the demos are simplistic by design. Each one demonstrates one thing to make its topic easier to grasp. For more advanced usage of fpGUI, take a look at DocView, UI Designer, Maximus IDE - all included in the code repository. Other applications like FPTest GUI Runner, C/S 3-tier Address Book, MRI Scan Viewer, Media Player, Total Commander clone and many more also exist on the internet. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI Toolkit v1.2 release
Where is the Changelog for v1.2? El 19/08/2014 a las #4, Graeme Geldenhuys escribió: fpGUI v1.2 is available I'm glad to announce the 1.2 release of fpGUI. This has been over a years worth of development, so a complete list of changes will be to big to list here. For more details, run any of the following commands: git log --oneline v1.0..v1.2 (console viewer) or gitk v1.0..v1.2(gui viewer) Downloads - An archived source download of fpGUI, and pre-built binaries for DocView (fpGUI's Documentation Viewer) can be found at the following URL: http://sourceforge.net/projects/fpgui/files/fpGUI/1.2/ ...or clone the source code repository by using any of the following commands: from SourceForge: git clone git://git.code.sf.net/p/fpgui/code fpgui from GitHub: git clone git://github.com/graemeg/fpGUI.git The 'master' branch contains the latest released fpGUI (v1.2), and the 'develop' branch contains the latest development work on fpGUI. Documentation - Pre-built documentation in the highly optimized INF file format (for use with DocView) will be available for download shortly. A single archive of around 2MB in size. The documentation archive will contain the following help files: - Class documentation for fpGUI Toolkit - The Free Pascal Language Reference - FPC Runtime Library (rtl) help - FPC Free Component Library (fcl) help The download URL is: http://sourceforge.net/projects/fpgui/files/fpGUI/Documentation/ If you want integrated help in your IDE or Programmer Editor of choice, the following URL describes how to do it: http://fpgui.sourceforge.net/docview_ide_integration.shtml For more details, please visit the fpGUI home page: http://fpgui.sourceforge.net Regards, - Graeme - -- Lic. Liyuán García Caballero Esp. B Ciencias Informáticas Excelencia en Software Desoft en Ciego de Avila. Joaquin de Aguero Esquina Calle 2. Ciego de Avila. Cuba. Telfs.: (53 33) 266200 ext. 105. Telefax: (53 33) 22 8792. e_mail: liy...@cav.desoft.cu jabber: liy...@jabber.cav.desoft.cu -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI Toolkit v1.2 release
On Wednesday 03/09/2014 at 16:51, Liyuan García Caballero wrote: Where is the Changelog for v1.2? Like I mentioned, it is a year's worth of work, so it is an extensive list. 'git diff --name-status v1.0..v1.2' will give you a complete list of modified or added files. A very brief summary: - Obviously lots of improvements and bug fixes to existing widgets - Many improvements to RichView - new RichView sample editor application - Massive speedup of RichView component, thus huge benefit to DocView help rendering - Experimental MDI support - new ScrollFrame widget - fpGUI Debug Server improvements (live view etc) - various new community widgets - Maximus IDE improvements - UIDesigner updates (new widgets registered, localization etc) - VLC (video player) integration - AggPas and Agg2D improvements - More documentation added - 6 new built-in themes ...and lots more. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Fpgui directory errors
On 2013-04-17 11:53, Santiago A. wrote: I don't know if this is the right place to ask about fpgui, but I don't know any other ;-) No, this is the Lazarus mailing. fpGUI Toolkit support is via the fpGUI support newsgroups. You can use a NNTP News Client or the Web Interface. See this URL for more details: http://fpgui.sourceforge.net/support.shtml I'll answer your question there. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI Widget Type: TTimer fix
On 08/31/2011 10:09 AM, michael.vancann...@wisa.be wrote: THandle has a 'windows-only' ring to it. I'm not a native speaker but AFAIK, a handle is just something you can grasp some object at. So a handle (type THandle) might be something to denote a certain object without forcing to have it a known memory address (such as Pointer or a TObject sibling would need) . Thus I feel that it might not be such a bad idea to use THandle in a non-windowish Widget Type code. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI Widget Type: TTimer fix
On Wed, 31 Aug 2011, Michael Schnell wrote: (using Linux X86 32 Bit): Initiating TTimer with fpGUI Widget Type issues a Range check error: Project eventtest raises exception class 'RunError(201)' line 153 is Result := PtrInt(Timer); PtrInt in fact is LongInt. When stepping my example the value for the Timer variable is $B761AA00. So the Longint will be negative and as THandle is PtrUInt which again is DWord, a range check exception is raised. Changing the line to Result := THandle(Timer); makes the Timer work in my example I don't know if this is appropriate for all Archs I think Result := PtrUint(Timer); is better and safer. THandle has a 'windows-only' ring to it. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI Widget Type: TTimer fix
line 153 is
line 153 of which files?
On Wed, Aug 31, 2011 at 10:09 AM, michael.vancann...@wisa.be wrote:
I think
Result := PtrUint(Timer);
is better and safer. THandle has a 'windows-only' ring to it.
From LCLType.pas:
{$ifndef WINDOWS}
THandle = type PtrUInt; // define our own, because the
SysUtils.THandle = System.THandle is a longint
HANDLE = THandle;
PHandle = ^THandle;
Although there is also:
unit WSReferences;
...
type
// use TLCLHandle instead of THandle since THandle = longint under 64bit linux
TLCLHandle = PtrUInt;
PLCLHandle = ^TLCLHandle;
The comment seams to ignore the existence of LCLType.THandle.
--
Felipe Monteiro de Carvalho
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI Widget Type: TTimer fix
On 08/31/2011 10:09 AM, michael.vancann...@wisa.be wrote: I think Result := PtrUint(Timer); is better and safer. THandle has a 'windows-only' ring to it. I suppose you are correct, but the source code of the function in fact is function TFpGuiWidgetSet.CreateTimer(Interval: integer; TimerFunc: TWSTimerProc): THandle; var Timer: TFPGUITimer; begin Timer := TFPGUITimer.Create(Interval, TimerFunc); Result := THandle(Timer); end; So if appropriate, it would be better/necessary to eliminate the THandle type in a more general context. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI Widget Type: TTimer fix
On 08/31/2011 10:15 AM, Felipe Monteiro de Carvalho wrote: line 153 is line 153 of which files? Ooops. fpguiobject.inc. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI, OpenGL, WebGL
On 06/20/2011 06:57 PM, Vincent Snijders wrote: Then I suggest that you contact the maintainers of fpgui directly or use the Lazarus-other mailing list for these off topic posts. While I do know that fpGUI itself is not distributed within the Lazarus svn, Lazarus can provide the fpGUI Widget type selectable in the project options (and as said in the original message I only refer to this Lazarus- Type of fpGUI, not the stand-alone version. That (and the fact that I esteem fpGUI a very decent (work in progress) part of Lazarus, I did suppose that further viable extensions of same should be discussed here. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI, OpenGL, WebGL
On 06/20/2011 09:55 PM, Marco van de Voort wrote: When will you have it ready? The basis for this would be an at least partly decently working Lazarus- version of fpGUI for X11. Unfortunately right now I'm not even able to compile it. (I keep trying with each update in either svn.) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI, OpenGL, WebGL
On 21/06/2011 12:40, Michael Schnell wrote: While I do know that fpGUI itself is not distributed within the Lazarus svn, Lazarus can provide the fpGUI Widget type selectable in the project options (and as said in the original message I only refer to this Lazarus LCL-fpGUI widgetset discussions are indeed on-topic here. I guess your original message just wasn't that clear. And just to be clear, fpGUI Toolkit discussions (non LCL-xxx related) must indeed be done in the fpGUI newsgroups, or you can email me directly. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI, OpenGL, WebGL
Michael Schnell mschn...@lumino.de hat am 21. Juni 2011 um 12:40 geschrieben: On 06/20/2011 06:57 PM, Vincent Snijders wrote: Then I suggest that you contact the maintainers of fpgui directly or use the Lazarus-other mailing list for these off topic posts. While I do know that fpGUI itself is not distributed within the Lazarus svn, Lazarus can provide the fpGUI Widget type selectable in the project options (and as said in the original message I only refer to this Lazarus- Type of fpGUI, not the stand-alone version. That (and the fact that I esteem fpGUI a very decent (work in progress) part of Lazarus, I did suppose that further viable extensions of same should be discussed here. You can discuss how to use the opengl backend of gtk2, fpgui, etc with the LCL on this list. But it makes no sense to discuss the implementation of the opengl backend for gtk2, fpgui, etc here. Mattias-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI, OpenGL, WebGL
On 06/21/2011 01:06 PM, Graeme Geldenhuys wrote: I haven't tried to compile LCL-fpGUI in a while. What is the exact error message that you get, then I'll take a quick look. Great ! Thanks ! === PPU Loading /home/mschnell/Downloads/svn/lazarus/trunk/lcl/units/i386-linux/fpgui/fpg_impl.ppu PPU Invalid Version 128 fpgui/corelib/fpg_base.pas(27,3) Fatal: Can't find unit fpg_impl used by fpg_base == -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI, OpenGL, WebGL
On 21/06/2011 13:27, Michael Schnell wrote: On 06/21/2011 01:06 PM, Graeme Geldenhuys wrote: I haven't tried to compile LCL-fpGUI in a while. What is the exact error message that you get, then I'll take a quick look. Great ! Thanks ! Patch supplied in Mantis report #19603. http://bugs.freepascal.org/view.php?id=19603 Attached is a screenshot showing a test LCL-fpGUI project running. PS: Wow, the whole compiling of LCL has changed a lot in Lazarus Trunk! Even changing the target widgetset in a project is now very different. Took a while to figure it out, but not too bad. Just another thing I'll have to get used too. ;-) === PPU Loading /home/mschnell/Downloads/svn/lazarus/trunk/lcl/units/i386-linux/fpgui/fpg_impl.ppu PPU Invalid Version 128 fpgui/corelib/fpg_base.pas(27,3) Fatal: Can't find unit fpg_impl used by fpg_base == I didn't get that error. I got a compiler error due to class name changes in fpGUI itself. Anyway, your problem looks like there are multiple copies of *.ppu files lying around or something. I would recommend you clear out the lcl/units/i386-linux/fpgui/ directory, and make sure your symlinks to fpGUI are setup correctly. Attached is a listing of my lcl/interfaces/fpgui/ directory. NOTE the two symlinks pointing to the actual fpGUI repository. To test, I used the latest Lazarus Trunk r31315, and latest fpGUI 'master' branch. Compiled with 64bit FPC 2.4.5 under Ubuntu 11.04. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ attachment: lcl-fpgui_test.pngtotal 380 -rw-rw-r-- 1 graemeg graemeg 463 2011-05-26 08:40 alllclintfunits.pas lrwxrwxrwx 1 graemeg graemeg43 2010-05-14 13:33 corelib - /home/graemeg/programming/fpgui/src/corelib -rw-rw-r-- 1 graemeg graemeg 4378 2011-05-26 08:40 fpguiint.pp -rw-r--r-- 1 graemeg graemeg 3602 2010-03-10 12:27 fpguilclintfh.inc -rw-r--r-- 1 graemeg graemeg 2397 2010-01-18 14:37 fpguilclintf.inc -rw-rw-r-- 1 graemeg graemeg 11973 2011-06-21 13:17 fpguiobject.inc -rw-rw-r-- 1 graemeg graemeg 17180 2011-05-26 08:40 fpguiobjects.pas -rw-rw-r-- 1 graemeg graemeg 7317 2011-05-26 08:40 fpguiproc.pas -rw-rw-r-- 1 graemeg graemeg 12726 2011-05-26 08:40 fpguiwinapih.inc -rw-rw-r-- 1 graemeg graemeg 17143 2011-06-21 13:23 fpguiwinapi.inc -rw-r--r-- 1 graemeg graemeg 2435 2010-01-18 14:37 fpguiwsarrow.pp -rw-r--r-- 1 graemeg graemeg 2356 2010-01-18 14:37 fpguiwsbuttons.pp -rw-r--r-- 1 graemeg graemeg 2462 2010-01-18 14:37 fpguiwscalendar.pp -rw-rw-r-- 1 graemeg graemeg 4343 2011-05-26 08:40 fpguiwscomctrls.pp -rw-rw-r-- 1 graemeg graemeg 10223 2011-05-26 08:40 fpguiwscontrols.pp -rw-r--r-- 1 graemeg graemeg 5831 2010-11-02 10:41 fpguiwsdialogs.pp -rw-rw-r-- 1 graemeg graemeg 6284 2011-05-26 08:40 fpguiwsextctrls.pp -rw-r--r-- 1 graemeg graemeg 3892 2010-01-18 14:37 fpguiwsextdlgs.pp -rw-rw-r-- 1 graemeg graemeg 12954 2011-05-26 08:40 fpguiwsfactory.pas -rw-r--r-- 1 graemeg graemeg 6427 2010-11-02 10:41 fpguiwsforms.pp -rw-r--r-- 1 graemeg graemeg 2458 2010-01-18 14:37 fpguiwsgrids.pp -rw-r--r-- 1 graemeg graemeg 2493 2010-01-18 14:37 fpguiwsimglist.pp -rw-rw-r-- 1 graemeg graemeg 9866 2011-05-26 08:40 fpguiwsmenus.pp -rw-r--r-- 1 graemeg graemeg 2724 2010-01-18 14:37 fpguiwspairsplitter.pp -rw-rw-r-- 1 graemeg graemeg 47261 2011-06-21 13:31 fpguiwsprivate.pp -rw-r--r-- 1 graemeg graemeg 19551 2010-11-02 10:41 fpguiwsstdctrls.pp lrwxrwxrwx 1 graemeg graemeg39 2010-05-14 13:33 gui - /home/graemeg/programming/fpgui/src/gui -rw-r--r-- 1 graemeg graemeg 1513 2010-01-18 14:37 interfaces.pp -rw-rw-r-- 1 graemeg graemeg 99198 2011-05-26 08:40 Makefile -rw-rw-r-- 1 graemeg graemeg 331 2011-05-26 08:40 Makefile.compiled -rw-rw-r-- 1 graemeg graemeg 1271 2011-05-26 08:40 Makefile.fpc -rw-rw-r-- 1 graemeg graemeg 843 2011-05-26 08:40 README.txt -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI, OpenGL, WebGL
On Mon, Jun 20, 2011 at 2:17 PM, Michael Schnell mschn...@lumino.de wrote: Any thoughts ? Yes, please discuss fpgui in the fpgui newsgroup: http://opensoft.homeip.net:8080/webnews/ -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI, OpenGL, WebGL
On Mon, 20 Jun 2011 14:17:41 +0200, Michael Schnell mschn...@lumino.de wrote: FPgui can create a GUI directly using a graphic subsystem without needing an external Widget Set. Right now it can use X11. Maybe it can be made using OpenGL. This has been already done earlier. With quite good results actually. The basics are implemented it's just a matter of resolving the dirty details one by one and getting the behaviour exactly the same as on the other backends. http://scandraid.svn.sourceforge.net/viewvc/scandraid/src/branches/fpgui/ Regards, Darius -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI, OpenGL, WebGL
On 06/20/2011 02:38 PM, Felipe Monteiro de Carvalho wrote: Yes, please discuss fpgui in the fpgui newsgroup: http://opensoft.homeip.net:8080/webnew Sorry but impossible. homeip.net is blocked by our firewall :( -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI, OpenGL, WebGL
2011/6/20 Michael Schnell mschn...@lumino.de: On 06/20/2011 02:38 PM, Felipe Monteiro de Carvalho wrote: Yes, please discuss fpgui in the fpgui newsgroup: http://opensoft.homeip.net:8080/webnew Sorry but impossible. homeip.net is blocked by our firewall :( Then I suggest that you contact the maintainers of fpgui directly or use the Lazarus-other mailing list for these off topic posts. Vincent -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI, OpenGL, WebGL
On Mon, Jun 20, 2011 at 02:17:41PM +0200, Michael Schnell wrote: FPgui can create a GUI directly using a graphic subsystem without needing an external Widget Set. Right now it can use X11. Maybe it can be made using OpenGL. This done it maybe can be made using WebGL and with that it could create a remote GUI on a (Firefox or Chrome) browser (which, IMHO, would be a very desirable feature). Any thoughts ? When will you have it ready? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Sun, Feb 20, 2011 at 08:45:59PM +0100, Sven Barth wrote: Of course this is not an official statement from Microsoft, but the article on WinForms on Wikipedia ( http://en.wikipedia.org/wiki/Windows_Presentation_Foundation ) writes this: Windows Forms has been in effect superseded by Windows Presentation Foundation That's because WPF is the base of Silverlight, which they wanted to push, also for applications. As far as I know it only grabbed a small market share. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Tue, 22 Feb 2011, Marco van de Voort wrote: On Sun, Feb 20, 2011 at 08:45:59PM +0100, Sven Barth wrote: Of course this is not an official statement from Microsoft, but the article on WinForms on Wikipedia ( http://en.wikipedia.org/wiki/Windows_Presentation_Foundation ) writes this: Windows Forms has been in effect superseded by Windows Presentation Foundation That's because WPF is the base of Silverlight, which they wanted to push, also for applications. Just like .NET (and so Windows Forms) superseded Win32. Meanwhile, Win32 is still around and functioning just fine. And as long as Microsoft supports Visual C++, win32 will be around. It's mostly about marketing; very little about technology. Microsoft needs to make money, as any commercial enterprise. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 21.02.2011 04:21, waldo kitty wrote: On 2/20/2011 14:45, Sven Barth wrote: On 20.02.2011 19:29, Marco van de Voort wrote: Huh? WPF has been advocated for ages (and is indeed Microsofts prefered technology), but afaik WinForms 2.0 is still the more used tech? Of course this is not an official statement from Microsoft, but the article on WinForms on Wikipedia ( http://en.wikipedia.org/wiki/Windows_Presentation_Foundation ) writes this: Windows Forms has been in effect superseded by Windows Presentation Foundation [OS/2 experience rearing its ugly head] i have to wonder if and how much of the above may be related to the original OS/2 Presentation Manager stuffings or if it is simply a name that is close to what was once shared by m$ and IBM ;) [\OS/2 experience rearing its ugly head] I'd say that Microsoft has long forgotten its OS/2 past with IBM... after all they've removed the OS/2 subsystem from Windows after Windows 2000. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Sun, Jan 16, 2011 at 02:34:40PM +0100, Sven Barth wrote: That was WinForms which is basically deprecated today. In contrary to the C WinAPI world the .NET GUI world changes very fast and very radically ^^ Huh? WPF has been advocated for ages (and is indeed Microsofts prefered technology), but afaik WinForms 2.0 is still the more used tech? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Wed, Jan 19, 2011 at 12:02:09PM +0100, Michael Schnell wrote: Although I'm not that a big fan of the move, I won't be pessimistic about it. :P For e.g. webapps it is IMHO perfectly fine. But Delphi Prism would be just as fine and still be preserve some Object Pascal competence. Prism is such a small market, and it would require much more than a little dialect similarity to go there. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Wed, Jan 19, 2011 at 12:47:33PM +0100, Andreas Schneider wrote: But what about new employees? What if you need external consultants etc.? It's a *lot* easier to find C# (Java, C++ ... even Python) developers than Delphi developers. We always target both C++ and Delphi devels. In our experience you can easier retrain a good C++ programmer than have a beginning programmer with delphi knowledge gain experience. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 20.02.2011 19:29, Marco van de Voort wrote: On Sun, Jan 16, 2011 at 02:34:40PM +0100, Sven Barth wrote: That was WinForms which is basically deprecated today. In contrary to the C WinAPI world the .NET GUI world changes very fast and very radically ^^ Huh? WPF has been advocated for ages (and is indeed Microsofts prefered technology), but afaik WinForms 2.0 is still the more used tech? Of course this is not an official statement from Microsoft, but the article on WinForms on Wikipedia ( http://en.wikipedia.org/wiki/Windows_Presentation_Foundation ) writes this: Windows Forms has been in effect superseded by Windows Presentation Foundation Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 2/20/2011 14:45, Sven Barth wrote: On 20.02.2011 19:29, Marco van de Voort wrote: Huh? WPF has been advocated for ages (and is indeed Microsofts prefered technology), but afaik WinForms 2.0 is still the more used tech? Of course this is not an official statement from Microsoft, but the article on WinForms on Wikipedia ( http://en.wikipedia.org/wiki/Windows_Presentation_Foundation ) writes this: Windows Forms has been in effect superseded by Windows Presentation Foundation [OS/2 experience rearing its ugly head] i have to wonder if and how much of the above may be related to the original OS/2 Presentation Manager stuffings or if it is simply a name that is close to what was once shared by m$ and IBM ;) [\OS/2 experience rearing its ugly head] NOTE: i smile and wink all the time... emoticons or their lack in my messages are not to be used to convey any quantity of seriousness... almost everything i post is serious with some humor and joking also conveyed... i think ;) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Op 2011-01-20 15:17, Sven Barth het geskryf: But it isn't that easy if you don't want to outsource something, but need a new employee in the company... I worked for a long time as a fulltime employee for a small company (20 employees), yet I lived in a different country. I didn't see a problem with that, neither did the company. That same company had developers based in Canada, UK, South Africa and Thailand. The owner of that company thought it was GREAT, because that meant he had 24hrs a day, developers working on the projects. So turn-around time for anything was really quick! Client reports a bug at 15:00, company schedules the task for the employee where the sun is rising and by 08:00 the next morning, the client has the bug solved. :) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Thu, Jan 20, 2011 at 2:17 PM, Sven Barth pascaldra...@googlemail.com wrote: But it isn't that easy if you don't want to outsource something, but need a new employee in the company... A good developer can learn the appropriate language. It should be easy for C and C++ developers to migrate to Object Pascal because the paradigm is similar, just Pascal is easier to read. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Am 20.01.2011 15:31, schrieb Felipe Monteiro de Carvalho: On Thu, Jan 20, 2011 at 2:17 PM, Sven Barthpascaldra...@googlemail.com wrote: But it isn't that easy if you don't want to outsource something, but need a new employee in the company... A good developer can learn the appropriate language. It should be easy for C and C++ developers to migrate to Object Pascal because the paradigm is similar, just Pascal is easier to read. But if the company searches for Delphi developers then nearly no one will answer... sigh... (well... I'm still working on a Windows Mobile application using Lazarus at work, so it will take some time till I'm not getting money for developing Pascal anymore :P ) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Thu, Jan 20, 2011 at 4:00 PM, Sven Barth pascaldra...@googlemail.com wrote: But if the company searches for Delphi developers then nearly no one will answer... sigh... (well... I'm still working on a Windows Mobile application using Lazarus at work, so it will take some time till I'm not getting money for developing Pascal anymore :P ) They can hire someone who is good at C/C++ and then train the guy to use Object Pascal. When searching for a developer they should make it clear that they accept people with experience in C/C++ if they are willing to learn Object Pascal. In other words they should search for a developer. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Am 20.01.2011 16:16, schrieb Felipe Monteiro de Carvalho: On Thu, Jan 20, 2011 at 4:00 PM, Sven Barthpascaldra...@googlemail.com wrote: But if the company searches for Delphi developers then nearly no one will answer... sigh... (well... I'm still working on a Windows Mobile application using Lazarus at work, so it will take some time till I'm not getting money for developing Pascal anymore :P ) They can hire someone who is good at C/C++ and then train the guy to use Object Pascal. When searching for a developer they should make it clear that they accept people with experience in C/C++ if they are willing to learn Object Pascal. In other words they should search for a developer. could, should, might... The decision was done and part of our development team is happy about that move (myself not included). So this says it all... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 01/17/2011 08:07 PM, Marco van de Voort wrote: Although I'm not that a big fan of the move, I won't be pessimistic about it. :P For e.g. webapps it is IMHO perfectly fine. But Delphi Prism would be just as fine and still be preserve some Object Pascal competence. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Wed, Jan 19, 2011 at 12:02:09PM +0100, Michael Schnell wrote: Although I'm not that a big fan of the move, I won't be pessimistic about it. :P For e.g. webapps it is IMHO perfectly fine. But Delphi Prism would be just as fine and still be preserve some Object Pascal competence. IMHO .NET is all about conforming to what clients/market/industry demands. And the bit resemblance that Prism offers is not worth explaining each time again to a client why you use it. To make it worse, I'm actually a Prism licensee. Twice even (at work and my license at home) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Op 2011-01-19 13:47, Andreas Schneider het geskryf: But what about new employees? What if you need external consultants etc.? It's a *lot* easier to find C# (Java, C++ ... even Python) developers than Delphi developers. [off-topic to the thread, but relevant to your comment] I used to think the same as you described. But a few months ago, we needed to outsource the beginning development work of a new product, and it had to be written in Object Pascal. I also thought we were going to strugle to find developers for Object Pascal. I posted the ads in the FPC and Lazarus mailing lists. I got about 30 responces in 3 days, and about another 20 or so over another 7 day period. I could pick and choose who I wanted. There is NO shortage of Object Pascal developers as far as I'm concerned. We are living in a global environment, where you can outsource work to anywhere, or work remotely with no hassles. It's time HR starts thinking outside the box (or should I say outside the Office)! Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Am 17.01.2011 07:43, schrieb Graeme Geldenhuys: Op 2011-01-17 04:50, Hans-Peter Diettrich het geskryf: In fpGUI there is no new AutoSize and also there is no FormCreate, because in fpGUI the convention is to create controls in AfterCreate which is a virtual method and not an event. So fpGUI has no Delphi compatible FormCreate handlers? By FormCreate, I assume you mean TForm.OnCreate event and FormCreate (which can actually have any name) being the event handler for OnCreate? Is so, obviously yes, fpGUI does have the OnCreate event. Also fpGUI does not rely on component streaming and thus the visibility of component fields can be as low as private without problems. This is what FPC disallows. When the code in AfterCreate sets a property of a child control, then that property must be at least public. I think he worded it wrong. I assume he meant that component fields being the componens dropped on a designer form. Under Delphi and Lazarus those field variables must be located in the Published section of a Form. In fpGUI they are by default Private and in fact can be in any visibility section of a Form. Thanks for explaining my bad wording. :) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Op 2011-01-17 09:33, Martin Schreiber het geskryf: Graeme, - please, no offending meant - None taken. fpGUI has implemented at the moment probably less than 50% of a good RAD development environment like Lazarus, Delphi or MSEide+MSEgui. RAD is overrated (marketing speak) and only good for prototyping. And no, the difference is that the fpGUI project is focused on the GUI toolkit itself, not on the whole development toolchain (ie: IDE etc...). When using fpGUI, you are free to use whatever development toolchain you prefer. The only requirement for using fpGUI thus far, is FPC itself. As for the UI Designer - that was a quick fix for myself, because it's quicker to put together a form layout visually, than writing everything by hand. Once I completed the port of the MiG layout manager to fpGUI, a visual form designer will probably not even be needed any more (try the MiG Java demo to see why I say that) - bringing me back to focusing more on the GUI toolkit itself. production there will be many, many wishes, nobody will understand and accept the limitations. I know what I write about, I encounter it daily. ;-) I think we should rather say different designs than limitations. If not, then any VCL or LCL developer will say MSEgui is very limited - simply because they are _not used to_ how MSEgui works, or lack of understanding your thinking behind its design. Hell, I couldn't even figure out how to use the StringGrid component in MSEgui - and I would like to think of myself as an experienced desktop application developer. That doesn't mean MSEgui is limited, just that I don't understand your design and thinking - thus MSEgui is not logical for me. [no offence meant, simply pointing out the different design ideas] Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 01/16/2011 01:21 AM, Marcos Douglas wrote: Is it more easy code with .lfm files? I suppose when a huge lot of controls are to be created in a large application, storing streams of control codes and handling them by a single central interpreter would result in smaller files and memory footprint than controls each having its own creation code sequence. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 01/16/2011 11:16 AM, Michael Van Canneyt wrote: There are others: * VB * XUL * Windows itself. (prior to .Net) HTML :) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 01/16/2011 02:34 PM, Sven Barth wrote: switching slowly from Delphi to .NET :( ) Delphi and .NET is not a contradiction. .Net does not force and programming language. There are lots of .NET (and/or Mono, Silverlight, Moonlight, etc) enabled languages / IDEs.Delphi Prism being one of them. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Am 17.01.2011 10:05, schrieb Michael Schnell: On 01/16/2011 02:34 PM, Sven Barth wrote: switching slowly from Delphi to .NET :( ) Delphi and .NET is not a contradiction. .Net does not force and programming language. There are lots of .NET (and/or Mono, Silverlight, Moonlight, etc) enabled languages / IDEs.Delphi Prism being one of them. Let me rephrase that a bit: switching slowly from Delphi to C# Is now my :( reasonable? :D Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 01/16/2011 02:37 PM, Graeme Geldenhuys wrote:
The fpGUI UI Designer *only* parses and edits the code between the
comment markers. That's those comments that start with {@VFD_xxx}
So it looks like a very small step on top ff this to (optionally) move
the Delphi code interpreting these into the the runtime executable, too,
and manage just theses lines in the designer files and for runtime
compilation load them in a resource.
FWIW:
I shortly explained the ifi idea ( (c) Martin ) in another message.
Here a remote GUI for an (locally headless) embedded would be provided
by a Lazarus program (or - in an even more far fetched design a
Silverlight/Moonlight application done in Delphi Prism) that allows for
all necessary controls to be displayed. A stream of control codes is
sent from the embedded application to the remote head for creating
and managing the controls. This - at best - could be designed in sync
with the control code stream used for form creation.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI for the LCL on x86 Linux, and standalone on SPARC Solaris 10
On 01/15/2011 10:18 PM, Graeme Geldenhuys wrote: How stable is ReactOS these days? Last time I use it, was over a year ago, and then not all Windows apps functioned correctly either. I d/lded and tried the ReacOS life CD some months ago. It did not start on any of the PCs I tried to boot it on (Intel and AMD). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Am 17.01.2011 10:18, schrieb michael.vancann...@wisa.be: On Mon, 17 Jan 2011, Graeme Geldenhuys wrote: Op 2011-01-17 09:33, Martin Schreiber het geskryf: Graeme, - please, no offending meant - None taken. fpGUI has implemented at the moment probably less than 50% of a good RAD development environment like Lazarus, Delphi or MSEide+MSEgui. RAD is overrated (marketing speak) and only good for prototyping. I beg to differ. When used properly, RAD is just that: RAD. But it takes someone who knows what he's doing to properly set it up. Out of the box, Delphi (or lazarus) needs a lot of work if you want to use it for large applications. But with the right subclasses, properties, wizards and component editors, RAD is the best you can do to create applications quickly. Doubly so if your development team consists of people of various skill levels. Out of curiosity: what would Lazarus need according to you to be a good RAD IDE? Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Mon, 17 Jan 2011 04:13:46 +0100
Hans-Peter Diettrich drdiettri...@aol.com wrote:
Mattias Gaertner schrieb:
On Sun, 16 Jan 2011 17:18:57 +0100
Hans-Peter Diettrich drdiettri...@aol.com wrote:
Graeme Geldenhuys schrieb:
Lets say the Form unit is called frm_main.pas, it will have a structure
as follows:
[...]
This code is not very compatible with the new AutoSize,
?
Provided that we want to use such a model in the LCL...
constructor TForm1.Create(TheOwner: TComponent);
begin
inherited Create(TheOwner);
{%region 'Auto-generated GUI code' -fold}
{%formdata automatically added by Lazarus}
...
{%formdata}
{%endregion}
end;
...I wonder how much of the AutoSize and AnchorDocking related
properties must be implemented in a designer and the generated code, in
order to make the forms behave reasonably realistic at both design and
run time.
Nothing.
...When we now have CreateNew and DisableAutoSize everywhere, then the
code generators/parsers of separate designers must be updated with every
such change in the LCL.
The constructor is already enclosed in Disable/EnableAutoSizing.
...I just try to imagine how somebody sits and makes the IDE and
designers work again, when some such change prevents the old forms from
working properly ;-)
It will be optionally.
Mattias
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 01/17/2011 08:33 AM, Martin Schreiber wrote: the bigest difficulties are in the step from 90% to 100% AKA version 0.9x to version 1.0 ;-) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 01/17/2011 10:13 AM, Sven Barth wrote: switching slowly from Delphi to C# I already saw such projects fail ;-) . -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 01/16/2011 02:37 PM, Graeme Geldenhuys wrote: Maybe some code example will help reduce confusion with what fpGUI's UI Designer does. I found that fpGUI _can_ be used with the Lazarus GUI designer. How does this work related to your explanation here. Seemingly fpGUI already does include the possibility to interpret resource based Form design control codes (I supposed this is streamed components). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Mon, 17 Jan 2011 10:35:03 +0100, Michael Schnell wrote: On 01/16/2011 02:37 PM, Graeme Geldenhuys wrote: Maybe some code example will help reduce confusion with what fpGUI's UI Designer does. I found that fpGUI _can_ be used with the Lazarus GUI designer. How does this work related to your explanation here. Seemingly fpGUI already does include the possibility to interpret resource based Form design control codes (I supposed this is streamed components). You still/again confuse or mix up fpGUI and LCL-fpGUI. The last one is still 100% LCL, just using fpGUI for actual controls, just like it does for GTK, GTK2, QT, Win32, etc. So in other words: fpGUI couldn't care less how the controls are streamed, managed, whatever. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Mon, 17 Jan 2011 09:59:56 +0100 Michael Schnell mschn...@lumino.de wrote: On 01/16/2011 01:21 AM, Marcos Douglas wrote: Is it more easy code with .lfm files? I suppose when a huge lot of controls are to be created in a large application, storing streams of control codes and handling them by a single central interpreter would result in smaller files and memory footprint than controls each having its own creation code sequence. True. But so far no one has measured how much. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 01/17/2011 10:42 AM, Andreas Schneider wrote: You still/again confuse or mix up fpGUI and LCL-fpGUI. I just try to learn more about the differences and this is why I) asked this question. As the same fpGUI name is used I suppose that at least _some_ code is shared. The last one is still 100% LCL, just using fpGUI for actual controls, just like it does for GTK, GTK2, QT, Win32, etc. I (think I) do understand this. So in other words: fpGUI couldn't care less how the controls are streamed, managed, whatever. Obviously. My interpretation is that the two GUI designers, that of course manage different types of control files and use different ways to include the GUI design information in the runtime executable, in the end use the same backend to paint the control elements. I understand that the different provenience of the two legacy GUI designers can/needs to be handled when integrating fpGUI into Lazarus. And I feel that in the end both should result in a similar level of perfection. This might mean that a rather large integration of them could be desirable. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Monday, 17. January 2011 10.18:02 michael.vancann...@wisa.be wrote: It takes good care of the boilerplate work for you, and leaves you to concentrate on the actual business logic. Exactly. And for often used tasks there can be made components or component families which integrate into the existing framework, later this tasks are boilerplate work done by the framework for you too. :-) Martin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Am 17.01.2011 10:31, schrieb Michael Schnell: On 01/17/2011 10:13 AM, Sven Barth wrote: switching slowly from Delphi to C# I already saw such projects fail ;-) . Although I'm not that a big fan of the move, I won't be pessimistic about it. :P Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Mon, 17 Jan 2011, Sven Barth wrote: Am 17.01.2011 10:18, schrieb michael.vancann...@wisa.be: On Mon, 17 Jan 2011, Graeme Geldenhuys wrote: Op 2011-01-17 09:33, Martin Schreiber het geskryf: Graeme, - please, no offending meant - None taken. fpGUI has implemented at the moment probably less than 50% of a good RAD development environment like Lazarus, Delphi or MSEide+MSEgui. RAD is overrated (marketing speak) and only good for prototyping. I beg to differ. When used properly, RAD is just that: RAD. But it takes someone who knows what he's doing to properly set it up. Out of the box, Delphi (or lazarus) needs a lot of work if you want to use it for large applications. But with the right subclasses, properties, wizards and component editors, RAD is the best you can do to create applications quickly. Doubly so if your development team consists of people of various skill levels. Out of curiosity: what would Lazarus need according to you to be a good RAD IDE? Nothing. It has all it needs. Maybe more controls in the style of TButtonPanel: specialized controls. Each project/firm/team has its own design goals. Lazarus (or Delphi) cannot cater for all these goals. But they do allow you to extend the IDE so you can keep working in a RAD way and still follow your design goals with a minimum of effort. I have an application with 1500 forms. It would be madness to have to set over and over again the same set of properties and event handlers to save/restore formlayout, ask to save unsaved data, sort grids and whatnot. So - You create a descendent of TForm (or TCustomForm) - You add all 'common' functionality to this descendant, plus lots of extra properties to control this functionality. - You register this form in the IDE under File/New - You do the same for common controls. Grids, date edits, whatnot. You register them on the component palette. - Create a wizard that creates an initial layout for the form, based on the data you'll be editing in that form. (we use 3-tier data, but you can do exactly the same for a persistence framework) After that, you create new forms extremely fast without losing RAD functionality: a pure point-and-click environment, which is always faster than coding, and which is understood by people of many skill levels. Many forms in my applications don't have any form-specific code associated with them whatsoever: just the class declaration and form file. Yet they offer a lot of functionality out of the box. Since it is simply OOP, You could do all of this in code, but code is slower to create and is more error-prone. Hence RAD and point-and-click. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Mon, 17 Jan 2011 08:33:50 +0100 Martin Schreiber mse00...@gmail.com wrote: [...] There is a limitation in Delphi, it is not possible to add components to submodules. In MSEide I was able to overcome that limitation with some hacks. It also works in Lazarus, but is disabled, because of TWriter. Why does TWriter forbid it? [...] Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 01/16/2011 10:19 AM, Graeme Geldenhuys wrote: Huh? The code describing the UI is just that UI code. My businsess objects and businesses rules are not located in Form units either. One of Borlands bad design ideas with RAD - as far as I'm concerned. +1 There should be an automated way to create calls and properties in a Form unit to have external business units attach to it. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Mon, 17 Jan 2011, Martin Schreiber wrote: On Monday, 17. January 2011 10.18:02 michael.vancann...@wisa.be wrote: It takes good care of the boilerplate work for you, and leaves you to concentrate on the actual business logic. Exactly. And for often used tasks there can be made components or component families which integrate into the existing framework, later this tasks are boilerplate work done by the framework for you too. :-) Exactly, 100% agreed ! ... And all this without compromising on the RAD aspect. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Am 17.01.2011 10:57, schrieb Michael Schnell: On 01/17/2011 10:42 AM, Andreas Schneider wrote: You still/again confuse or mix up fpGUI and LCL-fpGUI. I just try to learn more about the differences and this is why I) asked this question. As the same fpGUI name is used I suppose that at least _some_ code is shared. The last one is still 100% LCL, just using fpGUI for actual controls, just like it does for GTK, GTK2, QT, Win32, etc. I (think I) do understand this. So in other words: fpGUI couldn't care less how the controls are streamed, managed, whatever. Obviously. My interpretation is that the two GUI designers, that of course manage different types of control files and use different ways to include the GUI design information in the runtime executable, in the end use the same backend to paint the control elements. I understand that the different provenience of the two legacy GUI designers can/needs to be handled when integrating fpGUI into Lazarus. And I feel that in the end both should result in a similar level of perfection. This might mean that a rather large integration of them could be desirable. Let me explain this a bit differently. When using fpGUI as a LCL widgetset the flow is like this: 1. LFM files contain streamed LCL controls (TButton, TLabel, etc) 2. LCL controls are created according to the LFM files and their properties are populated 3. those LCL controls now create fpGUI controls (TfpgButton, TfpgLabel, etc) and convert there own properties and assign them to the fpGUI controls in a way that the fpGUI controls behave as expected by the user of the LCL When you use the designer of Lazarus you design LCL controls, not fpGUI controls. The fpGUI controls are created at runtime by the widgetset glue code. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI for the LCL on x86 Linux, and standalone on SPARC Solaris 10
Michael Schnell wrote: On 01/15/2011 10:18 PM, Graeme Geldenhuys wrote: How stable is ReactOS these days? Last time I use it, was over a year ago, and then not all Windows apps functioned correctly either. I d/lded and tried the ReacOS life CD some months ago. It did not start on any of the PCs I tried to boot it on (Intel and AMD). I've had it working after a fashion in a Qemu guest, but it gave odd problems like not being able to write to some files- problems I also see with NT in a similar environment so I suspect that Qemu's emulation is imperfect in some areas. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Mon, 17 Jan 2011, Michael Schnell wrote: On 01/16/2011 10:19 AM, Graeme Geldenhuys wrote: Huh? The code describing the UI is just that UI code. My businsess objects and businesses rules are not located in Form units either. One of Borlands bad design ideas with RAD - as far as I'm concerned. +1 There should be an automated way to create calls and properties in a Form unit to have external business units attach to it. Check out the FormMediator in tiOPF. Designed with RAD in mind. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Mon, 17 Jan 2011 11:03:00 +0100 (CET) michael.vancann...@wisa.be wrote: [...] I have an application with 1500 forms. Every time you mention this application the number of forms grows by hundreds. I wonder, do you add one form per day? Are these normal forms, each with a whole unit of code? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Mon, 17 Jan 2011 10:57:57 +0100, Michael Schnell wrote: Obviously. My interpretation is that the two GUI designers, that of course manage different types of control files and use different ways to include the GUI design information in the runtime executable, in the end use the same backend to paint the control elements. It's not about what the GUI designers manage. In both cases, they work with completely different frameworks. If you use the LCL, you are working with LCL controls (TWinControl etc.) no matter what backend/widgetset is used. You will always work directly with the LCL which essentially is just another abstraction layer. If you use the fpGUI Designer, you work with fpGUI as framework. In that particular case, you directly interact with the fpGUI controls, something you don't do when working with the LCL. I understand that the different provenience of the two legacy GUI designers can/needs to be handled when integrating fpGUI into Lazarus. And I feel that in the end both should result in a similar level of perfection. This might mean that a rather large integration of them could be desirable. Eventually the LCL only uses widgetsets as a means to an end. It uses widgets from a widgetset to build its own controls. That may be by completely integrating a certain widget or by using other means, depending on what a specific widgetset offers (for example a TLabel could be a real widget on GTK and maybe owner drawn on Win32). It may also be, that a widgetset provides for example a TreeView that could be used to realize TTreeView, but doesn't offer all the features necessary so you still end up building it from a bunch of simpler widgets and owner drawing. So no, in the end you have two completely different results/goals depending on what framework you use: fpGUI or LCL - no matter if the widgetset you choose is fpGUI again. You will still end up with different controls, different structure and different functionality. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Am 17.01.2011 11:03, schrieb michael.vancann...@wisa.be: On Mon, 17 Jan 2011, Sven Barth wrote: Am 17.01.2011 10:18, schrieb michael.vancann...@wisa.be: On Mon, 17 Jan 2011, Graeme Geldenhuys wrote: Op 2011-01-17 09:33, Martin Schreiber het geskryf: Graeme, - please, no offending meant - None taken. fpGUI has implemented at the moment probably less than 50% of a good RAD development environment like Lazarus, Delphi or MSEide+MSEgui. RAD is overrated (marketing speak) and only good for prototyping. I beg to differ. When used properly, RAD is just that: RAD. But it takes someone who knows what he's doing to properly set it up. Out of the box, Delphi (or lazarus) needs a lot of work if you want to use it for large applications. But with the right subclasses, properties, wizards and component editors, RAD is the best you can do to create applications quickly. Doubly so if your development team consists of people of various skill levels. Out of curiosity: what would Lazarus need according to you to be a good RAD IDE? Nothing. It has all it needs. Maybe more controls in the style of TButtonPanel: specialized controls. Each project/firm/team has its own design goals. Lazarus (or Delphi) cannot cater for all these goals. But they do allow you to extend the IDE so you can keep working in a RAD way and still follow your design goals with a minimum of effort. I have an application with 1500 forms. It would be madness to have to set over and over again the same set of properties and event handlers to save/restore formlayout, ask to save unsaved data, sort grids and whatnot. So - You create a descendent of TForm (or TCustomForm) - You add all 'common' functionality to this descendant, plus lots of extra properties to control this functionality. - You register this form in the IDE under File/New - You do the same for common controls. Grids, date edits, whatnot. You register them on the component palette. - Create a wizard that creates an initial layout for the form, based on the data you'll be editing in that form. (we use 3-tier data, but you can do exactly the same for a persistence framework) After that, you create new forms extremely fast without losing RAD functionality: a pure point-and-click environment, which is always faster than coding, and which is understood by people of many skill levels. Many forms in my applications don't have any form-specific code associated with them whatsoever: just the class declaration and form file. Yet they offer a lot of functionality out of the box. Since it is simply OOP, You could do all of this in code, but code is slower to create and is more error-prone. Hence RAD and point-and-click. Thank you for the extensive explanation. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 01/16/2011 10:34 PM, Graeme Geldenhuys wrote: Even Lazarus's form designer chokes on differing dpi values. What is the dpi value useful for ? If you want to deal with screen dpi, you also need to know the physical monitor size and the eye-screen distance to do any useful calculations on it. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Mon, 17 Jan 2011, Mattias Gaertner wrote: On Mon, 17 Jan 2011 11:03:00 +0100 (CET) michael.vancann...@wisa.be wrote: [...] I have an application with 1500 forms. Every time you mention this application the number of forms grows by hundreds. I wonder, do you add one form per day? It depends. Adding a simple form costs at most 2 hours, so I alone could do 4 a day. Often this happens exactly so. Depending on the form of course, there are also complex forms which take much more time, up to a week. I ran a quick count: The exact count of client-side forms is currently 1566. The server contains 450 datamodules, and over 2300 'exposed' queries. (there are 400 tables in the database). A second application has 1359 client-side form files, and 216 server datamodules. Both counts are without counting the 134 'framework' forms, common to all our applications. Are these normal forms, each with a whole unit of code? Yes. But as said, many simple forms need almost no code. All do need a single line to register them in the form factory. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 01/10/2011 07:27 PM, Andreas Schneider wrote: On Mon, 10 Jan 2011 13:26:03 +0100, Michael Schnell wrote: On 01/10/2011 12:56 PM, Sven Barth wrote: This approach is only needed if you want to design pure fpGUI applications (and don't want to use the external designer provided by fpGUI). This is not needed when using fpGUI as a LCL widgetset. Right now (not having done any testing) I don't see for what a mixed fpGUI and - say- gtk would make sense. What are you talking about? In fact I don't yet fully understand the two different incarnations of fpGUI. (Seeming one supported by the Lazarus GUI designer, one coming with it's own GUI designer) but I'm learning. ( In fact the LCL is lots of different things at the same time :). ) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 01/17/2011 11:05 AM, Sven Barth wrote: Let me explain this a bit differently. When using fpGUI as a LCL widgetset the flow is like this: ... Thanks. That exactly matches what I hoped I had learned in the last few days. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Op 2011-01-17 12:03, michael.vancann...@wisa.be het geskryf: I have an application with 1500 forms. It would be madness to have to set over and over again the same set of properties and event handlers to save/restore formlayout, ask to save unsaved data, sort grids and whatnot. So [...snip...] After that, you create new forms extremely fast without losing RAD functionality: a pure point-and-click environment, which is always faster than coding, and which is understood by people of many skill levels. And our company does exactly that, but without the need of a specific IDE's RAD functionality. Every heard of code templates? ;-) I'm a self-confessed code templates junkie! There, I said it! :) I can slap together stax of usable forms or code, with functionality like mediators, auto save/restore form positioning, localization etc all enabled, simply by using a few of our designed code templates - and a lot faster than anybody can drop components on a form double clicking to set event handlers etc. Clearly each development team has their own way of working. There is no right or wrong. I'm simply stating that RAD can mean many things to many development teams. And the RAD Borland was marketing, by writing a crap load of business logic inside form units, is NOT the way our company works. I learnt my lesson at a previous employer, after having to help maintain a *huge* Delphi RAD based project. See my favourite URL of that brilliant Borland RAD idea in action. http://opensoft.homeip.net:8080/~graemeg/datamodule.png Just looking at it, makes my eyes tear. :) Since it is simply OOP, You could do all of this in code, but code is slower to create and is more error-prone. Why error-prone? If you use well tested and developed code templates, you end up with having consistent looking and tested code. eg: Taking the tiOPF's MGM functionality as an example: We use StringGrid's a lot in our products, but all the developer needs to do is drop a grid on a form. No need for tweaking the grid's property settings etc. Then simply create an instance of our StringGrid mediator, and the grid is done. Instantly that grid gets all our preferred settings and event handlers setup, plus customized painting etc... all my hooking up one mediator to a stock standard grid component. Now if we wanted to update the look of all our grids in our project, we simply have to modify our base stringgrid mediator class, and recompile our project. Quick, easy and consistent! Hence RAD and point-and-click. Which could result in one form's Grid not quite behaving like the other form's grid in the same application - because the developer forgot to set all the right properties for the 100th time. So RAD can have many meanings and implementations, depending on the team. The mouse-style developer is not the begin-all, end-all of software development. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 01/17/2011 11:15 AM, Andreas Schneider wrote: Eventually the LCL only uses widgetsets as a means to an end. Yep. The Lazarus GUI designer (based on the set of GUI controls (might be called Lazarus internal widget set) the LCL provides) only allows to design according to the material included in the LCL, that for portability is required to be compatible with all decent Widget Types implemented. An external GUI designer can do more, as it uses and know an external widget set it attaches or internally does all widgets at its own will. So I myself am more interested in an fpGUI Widget Type that is as much compatible / portable regarding the other decent widget Type, but I do see that the other fpGUI incarnation might be very viable, as well. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Mon, 17 Jan 2011, Graeme Geldenhuys wrote: Hence RAD and point-and-click. Which could result in one form's Grid not quite behaving like the other form's grid in the same application - because the developer forgot to set all the right properties for the 100th time. Exactly not. That's why I subclass and re-register each control on the component palette, and this subclass has set all relevant properties correct in advance. No need for code templates at all. Drop the grid, and it's correctly configured for 99,99% of all cases. If, additionally, you set the 'Default' modifier for these properties to these values, nothing is stored in the .LFM/.DFM either, keeping size small. RAD works, if done right. Someone putting more than 50 datasets on a Datamodule is clearly doing something wrong and needs to rethink his design. Such a person will equally well manage to mess up things when creating code. (and is likely to create wrong code, to boot). Any system can be abused. That says little about the system, but lots about the abuser. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Hello Lazarus-List, Monday, January 17, 2011, 11:28:25 AM, you wrote: What are you talking about? MS In fact I don't yet fully understand the two different incarnations of MS fpGUI. (Seeming one supported by the Lazarus GUI designer, one coming MS with it's own GUI designer) but I'm learning. There aren't two different ones, only one fpGUI. Lazarus LCL can use fpGUI as a backend. LCL does not known which engine draws controls, or how they are being painted, it only request some operations to be performed and the backend is performing them (fpGUI, Windows, GTK, ...). There is a widgetset glue code API that both, the backend and the LCL must conform as a common language. When you are in a conversation with another people of other country you may need a translator, so in example, you speaking english wish to talk with smoebody that speak spanish so hire a translator which speaks both of them so: You (english) - Translator (English/Spanish) - Other (Spanish) Or in Lazarus fpGUI terms: LCL (LCL) - LCLfpGUI (LCL/fpGUI) - fpGUI (fpGUI) In Windows terms: LCL (LCL) - LCLWin32 (LCL/Win32) - Win32 (Win32) In Linux/GTK2 terms: LCL (LCL) - LCLGTK (LCL/GTK2) - Linux (GTK2) In Windows/GTK2 terms LCL (LCL) - LCLGTK2 (LCL/GTK2) - Win32 (GTK2) In MacOS terms: LCL (LCL) - LCLCocoa (LCL/Cocoa) - MacOSX (Cocoa) The man in the middle just translates the requested operations by the LCL to the desired widgetset. -- Best regards, José -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Mon, Jan 17, 2011 at 7:03 AM, michael.vancann...@wisa.be wrote: [snip] I have an application with 1500 forms. It would be madness to have to set over and over again the same set of properties and event handlers to save/restore formlayout, ask to save unsaved data, sort grids and whatnot. So - You create a descendent of TForm (or TCustomForm) - You add all 'common' functionality to this descendant, plus lots of extra properties to control this functionality. - You register this form in the IDE under File/New - You do the same for common controls. Grids, date edits, whatnot. You register them on the component palette. - Create a wizard that creates an initial layout for the form, based on the data you'll be editing in that form. (we use 3-tier data, but you can do exactly the same for a persistence framework) [snip] You have some problems with this approach: - You can not predict functionalities for ALL forms decendents; - If you try predict all, you will have a BIG class (Custom Form); - The Forms decendents not will use all features of the CustomForm; - Imagine you have a CRUD Custom Form. You have buttons to insert, update, delete, save, cancel, whatever. You decide make a new Form (inherite of YourOwnCustomForm). Every thing works, but you need 2 news buttons... The buttons shoud be sincronized with the buttons state of CustomForm. But the method that make this is in CustomForm. What you do? The method is modified to 'virtual' and you add more code lines in NewForm to treat 2 new buttons... because the CustomForm not predict everything... Exists others examples: the Save method should do more things in the NewForm, before save data... you have to create, in CustomForm, the BeforeSave method (as virtual and your implementation is nothing) just to have a entry point to descendent classes make your own configurations... at the end, you have a BIG CustomForm class, don't you? Since it is simply OOP, You could do all of this in code, but code is slower to create and is more error-prone. Hence RAD and point-and-click. Slower? Not realy. You take a time to developer all widgets in your company... so, the same time would be used to developer all code without widgets, as Graeme did, e.g. Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Op 2011-01-17 12:58, michael.vancann...@wisa.be het geskryf: RAD works, if done right. Fair enough. That then tells me that 99% of the developers using Delphi (and probably Lazarus) are doing it wrong - your team being in that 1% exception. I'm basing this on my work experience in multiple companies over the years. It seems Borland's RAD marketing was so good, most developers are now mouse click junkies, and forget to think about design. Someone putting more than 50 datasets on a Datamodule is clearly doing As bad as that screenshot looks, and considering the size and complexity of that product, I was incredibly impressed at how stable it was. Needless to say, the company in question had some of the best QA I have seen. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI for the LCL on x86 Linux, and standalone on SPARC Solaris 10
Michael Schnell wrote: On 01/15/2011 10:18 PM, Graeme Geldenhuys wrote: How stable is ReactOS these days? Last time I use it, was over a year ago, and then not all Windows apps functioned correctly either. I d/lded and tried the ReacOS life CD some months ago. It did not start on any of the PCs I tried to boot it on (Intel and AMD). I've used the QEmu download in the past and the VMware download recently which worked for me. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Op 2011-01-17 13:08, José Mejuto het geskryf: You (english) - Translator (English/Spanish) - Other (Spanish) Or in Lazarus fpGUI terms: LCL (LCL) - LCLfpGUI (LCL/fpGUI) - fpGUI (fpGUI) Excellent explanation, you should add this to the wiki. :) And here are the various layers in a vertical form. application code -- LCL -- LCL widget type (LCL-GTK2, LCL-fpGUI) -- vs application code toolkit (GTK2, Qt, Cocoa, fpGUI) fpGUI -- Windowing system Windowing system -- OS OS Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Mon, 17 Jan 2011, Marcos Douglas wrote: On Mon, Jan 17, 2011 at 7:03 AM, michael.vancann...@wisa.be wrote: [snip] I have an application with 1500 forms. It would be madness to have to set over and over again the same set of properties and event handlers to save/restore formlayout, ask to save unsaved data, sort grids and whatnot. So - You create a descendent of TForm (or TCustomForm) - You add all 'common' functionality to this descendant, plus lots of extra properties to control this functionality. - You register this form in the IDE under File/New - You do the same for common controls. Grids, date edits, whatnot. You register them on the component palette. - Create a wizard that creates an initial layout for the form, based on the data you'll be editing in that form. (we use 3-tier data, but you can do exactly the same for a persistence framework) [snip] You have some problems with this approach: - You can not predict functionalities for ALL forms decendents; I don't have to. But 80% of the functionality returns. This 80% is taken care of. The rest is business logic. - If you try predict all, you will have a BIG class (Custom Form); Not really. - The Forms decendents not will use all features of the CustomForm; - Imagine you have a CRUD Custom Form. You have buttons to insert, update, delete, save, cancel, whatever. You decide make a new Form (inherite of YourOwnCustomForm). Every thing works, but you need 2 news buttons... The buttons shoud be sincronized with the buttons state of CustomForm. But the method that make this is in CustomForm. What you do? The method is modified to 'virtual' and you add more code lines in NewForm to treat 2 new buttons... because the CustomForm not predict everything... Exists others examples: the Save method should do more things in Totally wrong approach. You create a form Save() method, NOT virtual, and add a OnSave event. That is the RAD way. If you add hooks in the right places, there is no need for endless descendants. We have 2 forms: TAppForm TDBAppForm (DB-Aware) That's it. 95% of all forms descend from TDBappform. The rest descends from TAppForm. the NewForm, before save data... you have to create, in CustomForm, the BeforeSave method (as virtual and your implementation is nothing) just to have a entry point to descendent classes make your own configurations... at the end, you have a BIG CustomForm class, don't you? That depends on your definition of big. The form class together with all it's 8 auxiliary classes takes 2300 lines. I don't think this is big. And you make a common mistake: you try to do everything in OOP in the parent class. I don't propose to do that at all. I take the recurring tasks, and make sure we don't need to spend time on them, so we can focus on the tasks which are specific in each form. Furthermore, each of these tasks can be customized by some event handlers to take care of special situations. Since it is simply OOP, You could do all of this in code, but code is slower to create and is more error-prone. Hence RAD and point-and-click. Slower? Not realy. You take a time to developer all widgets in your company... so, the same time would be used to developer all code without widgets, as Graeme did, e.g. Never. Not with 4000+ form files. I suggest you try it. What is more, if now we need a new functionality in all our forms, I introduce it in the form class, and all our forms now automagically have this functionality. This has happened numerous times in our application. If your application has only 20 forms, all this is not worth it. But when I started, I knew that there would be lots of forms, and an application that would evolve over 10 years. I did as I described here, and this has saved us huge amounts of time. The whole team and management here agree on that. (one of the few things management and developers agree on ;-) ) Michael.-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Mon, 17 Jan 2011, Graeme Geldenhuys wrote: Op 2011-01-17 12:58, michael.vancann...@wisa.be het geskryf: RAD works, if done right. Fair enough. That then tells me that 99% of the developers using Delphi (and probably Lazarus) are doing it wrong - your team being in that 1% exception. I'm basing this on my work experience in multiple companies over the years. It seems Borland's RAD marketing was so good, most developers are now mouse click junkies, and forget to think about design. Not only Borland. RAD was the word at the beginning of the 90-ies. VB, WinDev, Forte: you name it. All RAD. RAD is generally very good for small apps, quickly thrown together. (less than 20 forms) But before starting on a large project, think first. Don't start blindly using RAD. I said it: Any technology can be abused. This does not mean the technology is bad. Someone putting more than 50 datasets on a Datamodule is clearly doing As bad as that screenshot looks, and considering the size and complexity of that product, I was incredibly impressed at how stable it was. No doubt. One does not exclude the other. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 17/01/2011 10:22, Michael Schnell wrote: On 01/16/2011 10:34 PM, Graeme Geldenhuys wrote: Even Lazarus's form designer chokes on differing dpi values. What is the dpi value useful for ? If you want to deal with screen dpi, you also need to know the physical monitor size and the eye-screen distance to do any useful calculations on it. -Michael AFAIK and IIRC, there is means to get that information under Windows/Delphi, some WinAPI calls do it. And this can matter because in the times of CRT monitors, you'd get situations like a 150dpi setting on the developers' machine and 72 dpi on customers' machine. (hint: I was once in a team writing an app for touchscreen POS terminals, with cheap LCD screens). That information can be fetched from the monitor (provided it has EDID) by the system automatically. It matters e.g. for a full-screen application that needs to have all its labels in the correct places when run on different screens, without recompiling. (not that I particularly love that kind of usage but I can understand where it's come from) Lukasz -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Michael Schnell schrieb: On 01/16/2011 02:34 PM, Sven Barth wrote: switching slowly from Delphi to .NET :( ) Delphi and .NET is not a contradiction. .Net does not force and programming language. There are lots of .NET (and/or Mono, Silverlight, Moonlight, etc) enabled languages / IDEs.Delphi Prism being one of them. The breaking difference is the object model, including memory management, that makes Delphi (or C++) different from .NET, Java etc. Furthermore .NET (or Java...) come with their own widgetset (and RTL), which are incompatible with the VCL. Look how badly VCL.Net failed, after years of development - a .NET widgetset for Lazarus would fail for the same reasons. BTW I gave up my second try with .NET, after I couldn't find an equivalent for ShowMessage after searching for several hours. This shows that a language (syntax) is the least important part of a development system. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Mattias Gaertner schrieb: I suppose when a huge lot of controls are to be created in a large application, storing streams of control codes and handling them by a single central interpreter would result in smaller files and memory footprint than controls each having its own creation code sequence. True. But so far no one has measured how much. The absolute amount can be reduced by subclassing or similar means (mediators?). As already mentioned, a consistent look across many forms requires identical settings of common properties, what discourages any repetition in either explicit code or streams. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Michael Schnell schrieb: On 01/16/2011 10:34 PM, Graeme Geldenhuys wrote: Even Lazarus's form designer chokes on differing dpi values. What is the dpi value useful for ? If you want to deal with screen dpi, you also need to know the physical monitor size and the eye-screen distance to do any useful calculations on it. All that is included in the single dpi value. But AFAIK (from Windows) the dpi factor only affects font sizes, while graphics still are bound to the physical screen resolution. That's why VS measures everything in twips, not in pixels as Delphi does. On my CRT monitors I used this Windows model to shrink graphical items down to a minimum, by specifying a high screen resolution, and then adjusted the text size for readability, by increasing the dpi value above the 96 dpi standard. On nowadays digital monitors this is no more an option :-( Other screen managers (Ubuntu...) may have a different idea of the use of the dpi value, of course. But all models should result in equivalent text/graphics proportions, when a document is output to an printer, with a much higher dpi resolution. This certainly is not the case with pixel-based coordinates and image sizes in forms, and may explain the text size jumps as recently reported by Linux users. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
2011/1/17 michael.vancann...@wisa.be: I don't have to. But 80% of the functionality returns. This 80% is taken care of. The rest is business logic. Business logic in the Form class? Totally wrong approach. You create a form Save() method, NOT virtual, and add a OnSave event. That is the RAD way. If you add hooks in the right places, there is no need for endless descendants. We have 2 forms: Okay, the RAD way is create Save() method and OnSave event, to configurations of child Forms... These are beautiful and organized names... but is the same what I said, no? TAppForm TDBAppForm (DB-Aware) That's it. 95% of all forms descend from TDBappform. The rest descends from TAppForm. Never happen to you have a child form (inherited of TDBAppForm) but with special features such that it did not fit well with the routines of TDBAppForm? So what did you do? Maybe you skipped some TDBAppForm's methods having to implement them again, otherwise, only for this particular Form, no? That depends on your definition of big. The form class together with all it's 8 auxiliary classes takes 2300 lines. I don't think this is big. Well... 2300 is not so big. And you make a common mistake: you try to do everything in OOP in the parent class. Just when I use OOP. I have Forms RAD and Forms OOP (but just in Delphi... in FPC, I'm a newbie for now). What is more, if now we need a new functionality in all our forms, I introduce it in the form class, and all our forms now automagically have this functionality. This has happened numerous times in our application. If your application has only 20 forms, all this is not worth it. But when I started, I knew that there would be lots of forms, and an application that would evolve over 10 years. I did as I described here, and this has saved us huge amounts of time. The whole team and management here agree on that. (one of the few things management and developers agree on ;-) ) I believe, sure. But my point is that can be done with code/classes without RAD approach too. Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI for the LCL on x86 Linux, and standalone on SPARC Solaris 10
Sven Barth wrote: On 16.01.2011 14:58, Sven Barth wrote: On 16.01.2011 05:11, Paul Breneman wrote: On the ReactOS forums there have been a few discussions (long ago) of being able to strip away the GUI. I think that would be a great option but it seems the developers are trying to duplicate NT and they have little interest in such an option. At least according to the source code ReactOS should be capable of booting into a Console only mode. Adding the option /CONSOLE to the command line in freeldr.ini should be sufficient as HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\ConsoleShell is set to cmd.exe by default... I couldn't get it working in 0.3.12 though... According to this thread ( http://www.reactos.org/forum/viewtopic.php?f=2t=8925 ) from Friday on the ReactOS forum that is a bug. They are working to get the OS text mode only bootable again. Thanks Sven for that info! -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Sun, 16 Jan 2011 13:31:04 +0100 Sven Barth pascaldra...@googlemail.com wrote: Ehm... in Windows Presentation Foundation (WPF) for .NET you use XML files... and that is the current standard for Windows .NET applications. Android uses xml, too. R. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On 1/17/2011 05:28, Michael Schnell wrote: In fact I don't yet fully understand the two different incarnations of fpGUI. (Seeming one supported by the Lazarus GUI designer, one coming with it's own GUI designer) but I'm learning. IIUC, there is only one fpGUI... the LCL-fpGUI is only a wrapper to convert LCL data to fpGUI data... i use the term data to cover all possibilities of components, controls, the settings for each and anything else that has to pass from LCL based to fpGUI based... -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Mon, 17 Jan 2011, Marcos Douglas wrote: 2011/1/17 michael.vancann...@wisa.be: I don't have to. But 80% of the functionality returns. This 80% is taken care of. The rest is business logic. Business logic in the Form class? We work 3 tier. Most important business logic is on the application server. Clients contain mostly presentation logic. That's it. 95% of all forms descend from TDBappform. The rest descends from TAppForm. Never happen to you have a child form (inherited of TDBAppForm) but with special features such that it did not fit well with the routines of TDBAppForm? So what did you do? Maybe you skipped some TDBAppForm's methods having to implement them again, otherwise, only for this particular Form, no? No. The 'extra' functionality is just never used in such a case. (in 3000 forms, there are 2 such cases) And remember: I do not try to foresee all possible situations. I try to make sure that 99% of all cases are covered. The remaining 1%, the programmer is free to use his imagination. That depends on your definition of big. The form class together with all it's 8 auxiliary classes takes 2300 lines. I don't think this is big. Well... 2300 is not so big. And you make a common mistake: you try to do everything in OOP in the parent class. Just when I use OOP. I have Forms RAD and Forms OOP (but just in Delphi... in FPC, I'm a newbie for now). What is more, if now we need a new functionality in all our forms, I introduce it in the form class, and all our forms now automagically have this functionality. This has happened numerous times in our application. If your application has only 20 forms, all this is not worth it. But when I started, I knew that there would be lots of forms, and an application that would evolve over 10 years. I did as I described here, and this has saved us huge amounts of time. The whole team and management here agree on that. (one of the few things management and developers agree on ;-) ) I believe, sure. But my point is that can be done with code/classes without RAD approach too. I know that, I do not dispute this. I just want to point out that RAD does not mean one has to make compromises. It is a good concept, which really allows to work fast. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Mon, Jan 17, 2011 at 1:28 PM, michael.vancann...@wisa.be wrote: We work 3 tier. Most important business logic is on the application server. Clients contain mostly presentation logic. What protocol they do use? JSON? No. The 'extra' functionality is just never used in such a case. (in 3000 forms, there are 2 such cases) And remember: I do not try to foresee all possible situations. I try to make sure that 99% of all cases are covered. The remaining 1%, the programmer is free to use his imagination. Ok. I agree. I know that, I do not dispute this. I just want to point out that RAD does not mean one has to make compromises. It is a good concept, which really allows to work fast. So, I think everything depends of the good programmers! =) Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
Am 17.01.2011 11:48, schrieb Graeme Geldenhuys: I learnt my lesson at a previous employer, after having to help maintain a *huge* Delphi RAD based project. See my favourite URL of that brilliant Borland RAD idea in action. http://opensoft.homeip.net:8080/~graemeg/datamodule.png Just looking at it, makes my eyes tear. :) Not only yours O.o Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Mon, Jan 17, 2011 at 10:58:50AM +0100, Sven Barth wrote: Am 17.01.2011 10:31, schrieb Michael Schnell: On 01/17/2011 10:13 AM, Sven Barth wrote: switching slowly from Delphi to C# I already saw such projects fail ;-) . Although I'm not that a big fan of the move, I won't be pessimistic about it. :P For e.g. webapps it is IMHO perfectly fine. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Sat, 2011-01-15 at 22:24 -0200, Marcos Douglas wrote: But Graeme do that in fpGUI project. What about Graeme help Lazarus team about that? =) My code is not based on the TWriter or TPersistent (streaming classes) and neither does it use the passrc FPC parser. I have implemented my own basic parser and code writer. This gives me the ability to support components or property types the fpGUI UI Designer doesn't know yet - without raising any errors. -- Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Sat, 2011-01-15 at 22:21 -0200, Marcos Douglas wrote: I do not understand why Delphi and Lazarus were made like this. Would be more easy to write Forms and Widgets just with Pascal code... Maybe it has to do with coding styles. Borland would have had to force there coding style into non-Borland applications. Just a guess, though I don't think that would have been the end of the world. -- Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Sun, 2011-01-16 at 07:29 +0100, Martin Schreiber wrote: The separation of code and user interface definitions has advantages. Huh? The code describing the UI is just that UI code. My businsess objects and businesses rules are not located in Form units either. One of Borlands bad design ideas with RAD - as far as I'm concerned. Embedded business logic inside form units - something Delphi and Lazarus IDE's promote. Graeme probably will encounter the limitations of his approach when he tries to implement more sophisticated RAD possibilities into fpGUI. Visual form inheritance and submodules (TFrame) come to mind for example. I already support the frame idea without problems. I can even have multiple forms in a single unit - something neither Delphi, Lazarus or MSEide can do. So there is [as usual] pros and cons for each design. -- Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Sun, 2011-01-16 at 01:43 +, Paulo Costa wrote: Because: - A lfm parser can be easier to code/maintain than a pascal code parser. - It is easier to deal with properties appearing and disappearing. - It just works (tm) (there are other brands using this slogan with great success :) Same with fpGUI UI Designer's design. Also, if it was such a great idea to separate the UI code into another file, why is Borland the only company to do that. .NET, Qt GTK etc all use embedded source code describing the UI. :) -- Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Sun, 16 Jan 2011, Graeme Geldenhuys wrote: On Sun, 2011-01-16 at 07:29 +0100, Martin Schreiber wrote: The separation of code and user interface definitions has advantages. Huh? The code describing the UI is just that UI code. My businsess objects and businesses rules are not located in Form units either. One of Borlands bad design ideas with RAD - as far as I'm concerned. Embedded business logic inside form units - something Delphi and Lazarus IDE's promote. Graeme probably will encounter the limitations of his approach when he tries to implement more sophisticated RAD possibilities into fpGUI. Visual form inheritance and submodules (TFrame) come to mind for example. I already support the frame idea without problems. I can even have multiple forms in a single unit - something neither Delphi, Lazarus or MSEide can do. This is not inherent to using resources, that is simply a design decision. Keep it simple is a good thing. What makes resources a good idea is - Easy Visual Form Inheritance. - Translation. - Memory use. When translating, you typically not only translate strings, but also shift controls (texts in dutch tend to be longer than their english equivalents). When using resources, this is done in 1 go, and you overload the original resource with the new one. The code to construct the form is always in memory as soon as the binary is loaded. Resources are left on disk till you explicitly need them. They can even be in a DLL that is loaded on the go (as done for translations). You cannot do this with code constructed forms. (maybe it could be done with packages). All design decisions have their reasons. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Sun, 16 Jan 2011, Graeme Geldenhuys wrote: On Sun, 2011-01-16 at 01:43 +, Paulo Costa wrote: Because: - A lfm parser can be easier to code/maintain than a pascal code parser. - It is easier to deal with properties appearing and disappearing. - It just works (tm) (there are other brands using this slogan with great success :) Same with fpGUI UI Designer's design. Also, if it was such a great idea to separate the UI code into another file, why is Borland the only company to do that. .NET, Qt GTK etc all use embedded source code describing the UI. :) It is not correct that they are the only one. There are others: * VB * XUL * Windows itself. (prior to .Net) And maybe Borland is the only one to have done it right. They don't need to change, why would they ? The system as it is works just fine. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpGUI
On Sun, 16 Jan 2011 07:29:56 +0100 Martin Schreiber mse00...@gmail.com wrote: On Sunday, 16. January 2011 01.21:01 Marcos Douglas wrote: I do not understand why Delphi and Lazarus were made like this. Would be more easy to write Forms and Widgets just with Pascal code... The separation of code and user interface definitions has advantages. For example it is possible to edit and update the form layout without touching and parsing the code. The form layout can be modified language specific by resource dll's/so's. There is no danger that one destroys the the definition structure in source by accident. There is no danger that the IDE destroys the source code by accident. With a streaming mechanism the components have better possibilities to specialize and optimize their behaviour without aid of the IDE. True. Although these points are valid for both formats: lfm and pascal. I think the advantages of the lfm format are: - the format is very simple, everyone immediately knows what it does and how to edit it. AFAIK the only questions about its format were about encoding of strings. - they are stored compressed in the executable - allows to hook into the string reading, so that translations can be loaded automatically while reading I think the important point for the stream pascal is that it makes it possible to run without the streaming code, so smart linking could produce smaller executables. Graeme must write for every component dedicated IDE integration code AFAIK. Not dedicated IDE, but dedicated streaming code. The LCL must do the same, for example TBitmap.Data. Graeme probably will encounter the limitations of his approach when he tries to implement more sophisticated RAD possibilities into fpGUI. Visual form inheritance and submodules (TFrame) come to mind for example. The complicated part of VFI/frames and modules is the writer and the reading at design time. The runtime reader is pretty simple, except for circle dependencies. Graeme, how does the fpgui writer support circles? For example: object Edit1: TEdit AnchorSideLeft.Control = Label1 end object Label1: TLabel AnchorSideTop.Control = Edit1 end Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
