Re: [Lazarus] about infobuild form development
21-06-2014 02:43 tarihinde, Mattias Gaertner yazdı: Other people have already written similar tools. With selections for FPC version, CPU, OS, processor, LCL widgetset, defines, environment variables, etc. I Couldn't find, if have a link I be glad, I don't wanna discover america one more :) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] question and suggestion
21-06-2014 00:06 tarihinde, Martin Frb yazdı: If you want to share the same laz-install folder, for more than one build, you must make it read-only. I think this way will good for me, I'll try this, what has to be make param? this is my cmdline, lazarus folder is writable make PREFIX=/opt clean all OPT=-dUSE_QT_45 -dEnableCompInfoWnd LCL_PLATFORM=qt bigide for example OPT=-dpcp=~/mylazarus ? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Paint over TEdit control
Am 2014-06-20 20:47, schrieb Graeme Geldenhuys: On 2014-06-20 18:09, Jürgen Hestermann wrote: I am also fighting with multicolor text in TLabels etc. ... And another aim I am trying to achive is an edit compontent with (self drawn) multi color text. Is there one? You can try the LCL-CustomDrawn widgets, but last I checked they were still in alpha state, and not ready for prime usage. Thanks, I will have a look at it. If it's a new project, or you have the UI well abstracted, you could always give fpGUI Toolkit (see my signature) a go. Adding the functionality you require into fpGUI will take about 15 minutes. But that means that I have to abandon the LCL, correct? Or can I mix LCL and fpGUI? By the way, when you say multi-color text in a TEdit, do you mean some parts of the text is one color, and other parts another etc. Yes. I want to display file paths where the delimiters (\ or /) are displayed in a different color than the directory/file names between them. This works already fine when using LCLintf.drawtext and canvas.fillrect (at the end). Though it took me a while to find out that drawtext does not overwrite the whole rect area and I needed to place a fillrect in the paint routine of the form. And the handling when drawing directly on the form is arkward because I have to do everything on my own. No automatics like anchoring, repainting, etc. are available. What I need is a TLabel, where I can draw the text on my on (but everything else should be available) and an TEdit component where I can draw the text myself *and* I also want to do the keyboard handling myself (i.e., when typing backspace while the text is still highlighted it should *not* delete the whole highlight but only delete the last character). -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] nonlcl basic issue: is codetools LCL dependent?
Hi Lazarus wizards and magicians, I'm trying to figure how to face my nonlcl widgetset project. Before tampering with Lazarus code, I tried to gain a better understanding. My scenario: * a run-time package containing my non lcl widgets. Units are named after Kylix naming scheme, i.e. QForms, QButtons, etc. * a run-time package containing units lifted from Lazarus LCLBase and LazUtils to provide the required run-time functionalities without pulling in LCL (lresources, fileutils, etc.) With a minimal patch to lresources, in order to skip properties pulled in by Lazarus and unsupported by my widgets, I can compile an application using my widgets, run and debug it. If I try to access to a method already present in the lfm from the Object Inspector, I can see the available methods, and jump to the unit code. But if I attempt to add something, such as an OnClick Event to a button from the Object Inspector, I get the error Unable to create new method, and the reason given is: Codetools, Errors:1 unit1.pas Error: unit not found StdCtrls Of course my package doesn't have a StdCtrls unit, which would clash with Lazarus, but has a QStdCtrls unit. Now my question is: where does Codetools find the need for a specific unit? I gather that class, property, etc. names are loaded into the global LazarusResources list, but this involves also unit names? In order to support a nonlcl widgetset to what extent one should reinvent Codetools in his Mediator? Giuliano -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Paint over TEdit control
On 2014-06-21 11:01, Jürgen Hestermann wrote: But that means that I have to abandon the LCL, correct? Hence I asked if it is a new project or has a well abstracted user interface. Or can I mix LCL and fpGUI? No, not in the user interface. But you can use some base LCL (mainly non-GUI) units in a fpGUI application. Yes. I want to display file paths where the delimiters (\ or /) are displayed in a different color than the directory/file names between them. OK, that's what I thought you meant. And the handling when drawing directly on the form is arkward because I have to do everything on my own. No automatics like anchoring, repainting, etc. are available. You could always create your own widget - but sometimes that is also more work than expected. 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] nonlcl basic issue: is codetools LCL dependent?
On Sat, 21 Jun 2014 12:43:17 +0200 Giuliano Colla giuliano.co...@fastwebnet.it wrote: Hi Lazarus wizards and magicians, I'm trying to figure how to face my nonlcl widgetset project. Before tampering with Lazarus code, I tried to gain a better understanding. My scenario: * a run-time package containing my non lcl widgets. Units are named after Kylix naming scheme, i.e. QForms, QButtons, etc. * a run-time package containing units lifted from Lazarus LCLBase and LazUtils to provide the required run-time functionalities without pulling in LCL (lresources, fileutils, etc.) ok. With a minimal patch to lresources, in order to skip properties pulled in by Lazarus and unsupported by my widgets, I can compile an application using my widgets, run and debug it. If I try to access to a method already present in the lfm from the Object Inspector, I can see the available methods, and jump to the unit code. Yes. In this case the IDE uses only the names to find the methods. But if I attempt to add something, such as an OnClick Event to a button from the Object Inspector, I get the error Unable to create new method, and the reason given is: Codetools, Errors:1 unit1.pas Error: unit not found StdCtrls The IDE searches the declaration of TButton.OnClick. The TButton was registered from the LCL unit StdCtrls. That's why TButton.UnitName is 'stdctrls'. The IDE searches the unit in the project path and cannot find it. Of course my package doesn't have a StdCtrls unit, which would clash with Lazarus, but has a QStdCtrls unit. Now my question is: where does Codetools find the need for a specific unit? I gather that class, property, etc. names are loaded into the global LazarusResources list, but this involves also unit names? In order to support a nonlcl widgetset to what extent one should reinvent Codetools in his Mediator? Note: Codetools is a package for searching and editing Free Pascal sources. You don't need to reinvent Codetools. The problem is the IDE (i.e. form editor, designer) that drives Codetools. The IDE needs to be extended to solve the name clashes. There are at least two possible solutions: 1. The quick and dirty solution: You use the LCL forms and controls. The IDE is extended with some hooks, so you can redirect from the LCL to your units. Pro: Less work, you get some basic results quickly. Con: The RTTI is wrong. The Object Inspector cannot show your own properties. The property editors will show LCL values (e.g. TColor will show the list of LCL color constants). Icon and bitmap data are read/written in LCL format, which may be unreadable by your units. etc. 2. The clean solution: You write your own mediator component classes. For example a TButton, TForm, TPanel, TListBox, etc. Con: the IDE needs to be extended to handle multiple component classes with the same name (only one is active at a time, based on the project). You have to write painting code for the mediator TButton, TPanel, TListBox, etc. Pro: the RTTI is correct and so the Form/Source relation works, the Object Inspector shows all your properties and only your properties and you have full control. You can write good property and component editors. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] New feature: Auto complete class interfaces methods
Hi, The refactoring tool 'Abstract Methods' now supports 'class interfaces' too. For example: Add an interface like IUnknown to a class and position the source editor caret within the class. Then in the IDE menu: Source / Refactoring / Abstract Methods The appearing dialog will show the missing methods of IUnknown and with a further click it creates empty methods. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Paint over TEdit control
Krzysztof schrieb: I'm overriding protected PaintWindow method but seems that it is never called I had similar observations, when I wanted to paint borders around the control. It looks to me like the Windows EDIT control eats some messages :-( DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New feature: Auto complete class interfaces methods
On Sat, Jun 21, 2014 at 1:16 PM, Mattias Gaertner nc-gaert...@netcologne.de wrote: Hi, The refactoring tool 'Abstract Methods' now supports 'class interfaces' too. For example: Add an interface like IUnknown to a class and position the source editor caret within the class. Then in the IDE menu: Source / Refactoring / Abstract Methods The appearing dialog will show the missing methods of IUnknown and with a further click it creates empty methods. Great! Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
