Re: [Lazarus] Leakview+lazarus 0.9.26+WinXP
dmitry boyarintsev escribió: The solution is even simplier: heaptrc doesn't handle quoted parameters correctly. You can solve the problem by specifying file log parameter WITHOUT quotes, i.e.: C:\ set HEAPTRC=log=myheap.log C:\ application.exe Thanks you a lot, exactly without the quotes it works like a charm. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart: Request to review/apply patch 12758
Alexander Klenin schrieb: On Fri, Dec 12, 2008 at 11:39, Paul Ishenin i...@kmiac.ru wrote: Same for Alexander Klenin - if you need to update TAChart very often then ask about write access to svn/lazarus/trunk/components/tachart Yes, it can be a workaround for my particular case, so whom should I ask? For FPC ask me ;) ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Mouse Link in SynEdit (only link-able items)
Zitat von Alexander Klenin kle...@gmail.com: On Fri, Dec 12, 2008 at 02:12, Martin Friebe laza...@mfriebe.de wrote: Alexander Klenin wrote: So if you have time and expertise, please read the mail threads mentioned in the bug report and provide me with insight ;-) I'll look further into it. A few things: - GetHighlighterAttriAtRowColEx may not be the best idea. It can be quite useful to be able to click on words in comments to. (Which works at current). Indeed, I missed that. - The highlighter is overall not the best solution to find linkable text. Because even a valid bit of code, may be unresolvable to codetools. Another way would be to ask codetools them self. Similar like SynEdit calls SourceEditor, which calls SourceNoteBook and then MainIDE.OnSrcNoteBookClickLink line 2952 in ide/main.pp ( see also line 1778: SourceNotebook.OnClickLink := @OnSrcNoteBookClickLink; ) Now _that_ is what I wanted to hear when I started the original thread ;-) Good idea, I attached a new version of patch to the http://bugs.freepascal.org/view.php?id=12785. I should note that I was horrified by the amount of glue code needed to route an event through main form, source notebook, source editor and SynEdit. The IDE is structured in a hierarchy. mainide: the top level of the IDE and the central nerve system. Because of its size it's splitted into several units. This is the 'integrated' in IDE. It connects the various modules like debugger, package system, codetools, designer, etc. source notebook: the whole source editor source editor: one single editor (at the moment in the same unit with source notebook, but should eventually split up) synedit: visual control Mattias ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Mouse Link in SynEdit (only link-able items)
On Fri, Dec 12, 2008 at 18:41, Mattias Gärtner nc-gaert...@netcologne.de wrote: Zitat von Alexander Klenin kle...@gmail.com: I should note that I was horrified by the amount of glue code needed to route an event through main form, source notebook, source editor and SynEdit. The IDE is structured in a hierarchy. mainide: the top level of the IDE and the central nerve system. Because of its size it's splitted into several units. Oh, hierarchy is good in itself -- it is not what I am ranting about. (Although I'd say that main.pp, at 15000 lines, is in dire need of further splitting). However, to add another event to SynEdit, I had to add two useless events and two useless event handlers, totally containing more code then the original event -- simply to marshal the call through the hierarchy (see patch in the issue for details). This is IMHO not optimal design ;-) -- Alexander S. Klenin Insight Experts Ltd. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] TAChart: double-buffering (issue 0012377) questions
In issue http://bugs.freepascal.org/view.php?id=12377, reporter said:
Painting to an Bitmap and paint this on the Canvas would be much faster
This assertion is, of course, incorrect. I assume that the reporter's problem is
actually that the TChart flickers when repainted.
The flickering is caused by two sources:
1) The TChart is TGraphicControl, so Parent control erases chart's background
before every repaint.
2) TChart itself draws directly to screen, first clearing the canvas.
First source obviously needs fixing, and I attached to the issue a
patch which fixes it.
The only caveat is that TChart is now TWinControl -- can it lead to some
undesirable consequences I am not aware of?
The second source can also easily be fixed by double-buffering, but
before I do that,
I have two questions:
1) TWinControl.WMPaint already contains double-buffering code, but it
is protected
by {$ifdef BUFFERED_WMPAINT}. What is the reason of this? Is there some
ongoing work to implement double-buffering globally?
2) If double-buffering will be implemented in TAChart itself, it will
have some negative
performance impact. So, should I make it optional via DoubleBuffer property?
--
Alexander S. Klenin
Insight Experts Ltd.
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Mouse Link in SynEdit (only link-able items)
Alexander Klenin wrote: Zitat von Alexander Klenin kle...@gmail.com: I should note that I was horrified by the amount of glue code needed to route an event through main form, source notebook, source editor and SynEdit. The IDE is structured in a hierarchy. mainide: the top level of the IDE and the central nerve system. Because of its size it's splitted into several units. Oh, hierarchy is good in itself -- it is not what I am ranting about. (Although I'd say that main.pp, at 15000 lines, is in dire need of further splitting). However, to add another event to SynEdit, I had to add two useless events and two useless event handlers, totally containing more code then the original event -- simply to marshal the call through the hierarchy (see patch in the issue for details). This is IMHO not optimal design ;-) I haven't seen the patch? Can you check you really attached it. As for the events... There is probably (I haven't seen the code) another way: Pass the callback through to synedit. IDE gives a callback to SourceNotebook. But that does not mean that SourceNotebook has to be the one who calls it. It can just pass the Method-Reference to SourcEditor, which passes it to SynEdit. Source Notebook still needs to keep a copy, as it may open further SourceEditors. Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Mouse Link in SynEdit (only link-able items)
On Fri, Dec 12, 2008 at 20:38, Martin Friebe laza...@mfriebe.de wrote: I haven't seen the patch? Can you check you really attached it. Sorry, attached now. It is a pity Mantis does not allow to attach a patch and add a note within a single operation. As for the events... There is probably (I haven't seen the code) another way: Pass the callback through to synedit. IDE gives a callback to SourceNotebook. But that does not mean that SourceNotebook has to be the one who calls it. It can just pass the Method-Reference to SourcEditor, which passes it to SynEdit. Source Notebook still needs to keep a copy, as it may open further SourceEditors. Yes, this would be slightly better way. Since I am not familiar with this part of code, I just implemented it the same way other similar calls work. -- Alexander S. Klenin Insight Experts Ltd. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Mouse Link in SynEdit (only link-able items)
Op vrijdag 12-12-2008 om 21:14 uur [tijdzone +1000], schreef Alexander Klenin: On Fri, Dec 12, 2008 at 20:38, Martin Friebe laza...@mfriebe.de wrote: I haven't seen the patch? Can you check you really attached it. Sorry, attached now. Nope, still no attachment. Maybe that it's too big. There's a limit of the filesize of attachments on this list. Joost. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Code Structure / SourceEdit and SyneEdit [Re: Mouse Link in SynEdit (only link-able items)]
Mattias Gärtner wrote: Zitat von Alexander Klenin kle...@gmail.com: I should note that I was horrified by the amount of glue code needed to route an event through main form, source notebook, source editor and SynEdit. The IDE is structured in a hierarchy. mainide: the top level of the IDE and the central nerve system. Because of its size it's splitted into several units. This is the 'integrated' in IDE. It connects the various modules like debugger, package system, codetools, designer, etc. source notebook: the whole source editor source editor: one single editor (at the moment in the same unit with source notebook, but should eventually split up) synedit: visual control Reading this, I just had an idea. (Nothing that would be done anytime soon, as it would be a major project) In The current structure SynEdit is the Visual control, and therefore also the control that takes all events such as mouse/key down/up/move. Often it is SynEdits work to react to this, but often it also needs to call back to SourceEditor. It is at least worth reviewing if this order could/should be changed (I am not sure about it): - SourceEditor could be a visual component with all the Key/Mouse event handlers. - It would *not* inherit from SynEdit, but same as now it would have a SynEdit instance that it can make calls to. This SynEdit would not paint on it's own canvas, but rather paint on the SourceEditors canvas - Instead of SynEdit making all the callbacks to SourceEditor, now all events go to SourceEditor first, and SourceEditor can decide what to forward. On the other hand, it is probably not worth the amount of work. Well the future will show, if there is a use case for it... Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Mouse Link in SynEdit (only link-able items)
On Fri, Dec 12, 2008 at 21:36, Joost van der Sluis jo...@cnoc.nl wrote: Nope, still no attachment. Maybe that it's too big. There's a limit of the filesize of attachments on this list. I meant attached to an issue: http://bugs.freepascal.org/view.php?id=12785 Anyway, I'll attach it to this message too, just in case ;-) -- Alexander S. Klenin Insight Experts Ltd. synedit_mouselink_allowed_only.patch Description: Binary data ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Code Structure / SourceEdit and SyneEdit [Re: Mouse Link in SynEdit (only link-able items)]
On Fri, Dec 12, 2008 at 21:37, Martin Friebe laza...@mfriebe.de wrote: In The current structure SynEdit is the Visual control, and therefore also the control that takes all events such as mouse/key down/up/move. Often it is SynEdits work to react to this, but often it also needs to call back to SourceEditor. It is at least worth reviewing if this order could/should be changed (I am not sure about it): - SourceEditor could be a visual component with all the Key/Mouse event handlers. - It would *not* inherit from SynEdit, but same as now it would have a SynEdit instance that it can make calls to. This SynEdit would not paint on it's own canvas, but rather paint on the SourceEditors canvas - Instead of SynEdit making all the callbacks to SourceEditor, now all events go to SourceEditor first, and SourceEditor can decide what to forward. Sigh, if we are dreaming anyway, here is my dream: 1) Logic should be separated from the presentation, so first there should be 'TAbstractSynEdit' class, concerning itself purely with text manipulations, such as text insertion/deletion, cursor position changes, text attribute calculation, save/loading, codetools etc. TAbstractSynEdit should not depend on any visual code, in partucular it should descend from TObject/TPersistent, not TControl. 2) Logic should be covered by automated tests, e.g. using fpcunit framework. 3) Presentation and user interaction should be the concern of TSynEdit class, aggregating TAbstractSynEdit and delegating all actual logic to the latter. 4) SourceEditor should be removed (or converted into a trivial wrapper), TSourceNotebook should reference TSynEdit directly. On the other hand, it is probably not worth the amount of work. Well the future will show, if there is a use case for it... True. Proper design requires lots of effort, and (especially short-term) benefits might not outweight the costs. -- Alexander S. Klenin Insight Experts Ltd. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] KOL-CE and TKOLMainMenu
From: User Hi, I dropped a TKOLMainMenu into a KOLForm and I added several menus with submenus but they are not shown in WinCE. I use KOL CE 2.80.2 and Lazarus 0.9.27 beta FPC 2.2.3. What is the problem? Your form or project can be locked. It prevents autogeneartion of .inc files. Check Locked property for TKOLProject and TKOLForm components. Also use release version of Lazarus 0.9.26. I do not test KOL-CE with trunk version of Lazarus and it can be incompatible... Yury Sidorov. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] KOL-CE and TKOLMainMenu
Hi again, the Locked property for TKOLProject and TKOLForm components is established to False and now I use a Lazarus 0.9.26 beta FPC 2.2.2 but the submenus are not shown under WinCE but they are shown under Win32, this is very strange... 2008/12/12 Yury Sidorov j...@cp-lab.com From: User Hi, I dropped a TKOLMainMenu into a KOLForm and I added several menus with submenus but they are not shown in WinCE. I use KOL CE 2.80.2 and Lazarus 0.9.27 beta FPC 2.2.3. What is the problem? Your form or project can be locked. It prevents autogeneartion of .inc files. Check Locked property for TKOLProject and TKOLForm components. Also use release version of Lazarus 0.9.26. I do not test KOL-CE with trunk version of Lazarus and it can be incompatible... Yury Sidorov. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Code Structure / SourceEdit and SyneEdit [Re: Mouse Link in SynEdit (only link-able items)]
Alexander Klenin wrote: On Fri, Dec 12, 2008 at 21:37, Martin Friebe laza...@mfriebe.de wrote: In The current structure SynEdit is the Visual control, and therefore also the control that takes all events such as mouse/key down/up/move. Often it is SynEdits work to react to this, but often it also needs to call back to SourceEditor. It is at least worth reviewing if this order could/should be changed (I am not sure about it): - SourceEditor could be a visual component with all the Key/Mouse event handlers. - It would *not* inherit from SynEdit, but same as now it would have a SynEdit instance that it can make calls to. This SynEdit would not paint on it's own canvas, but rather paint on the SourceEditors canvas - Instead of SynEdit making all the callbacks to SourceEditor, now all events go to SourceEditor first, and SourceEditor can decide what to forward. Sigh, if we are dreaming anyway, here is my dream: 1) Logic should be separated from the presentation, so first there should be 'TAbstractSynEdit' class, concerning itself purely with text manipulations, such as text insertion/deletion, cursor position changes, text attribute calculation, save/loading, codetools etc. TAbstractSynEdit should not depend on any visual code, in partucular it should descend from TObject/TPersistent, not TControl. Well I am in the process of breaking it up into smaller bits. - The gutter drawing moved to its own class. - Folding is partly abstracted - Trim Trailing spaces has been abstracted into a class of its own. (a view of SynEditLines) - Caret and block have been started Of course, they do still have heavy dependencies. But those can not easily be removed yet, other parts have to be broken free first. 2) Logic should be covered by automated tests, e.g. using fpcunit framework. Also started (mainly folding), so they need heavy cleanup. I cam from other test frame-works and forcefully attempted to abuse fpcunit... But as far as I am concerned, you can not write code without having automated tests. 3) Presentation and user interaction should be the concern of TSynEdit class, aggregating TAbstractSynEdit and delegating all actual logic to the latter. 4) SourceEditor should be removed (or converted into a trivial wrapper), TSourceNotebook should reference TSynEdit directly. On the other hand, it is probably not worth the amount of work. Well the future will show, if there is a use case for it... True. Proper design requires lots of effort, and (especially short-term) benefits might not outweight the costs. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] unusable/endlessly reloading mainIDE
Try again with: sudo make clean all LCL_PLATFORM=gtk2 OPT=-va This should say exactly why compilation fails PS: Don't answer only to me, but to the whole list The error message remains. The Windows version of Lazarus under Wine seems to be useable, so I will use that. Thx for the help. -- Pécsi István This message was sent using IMP, the Internet Messaging Program. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Terminal window, workaround
Mattias Gaertner wrote: On Thu, 11 Dec 2008 09:39:38 +0100 svaa s...@ciberpiula.net wrote: Hello: I've decide to use the this work around. I write to filetext and in a terminal I use tail -f file. It lets me stop in a breakpoint from the IDE and watch in the terminal the current value with a writeln. It's not the best, but it works for what I need. May be later I will learn how to use the gdb from command line. By the way, I thought gdb was unable to display Pascal variables, but if gdb is able to display the value of any variable in Pascal, what's the problem of Lazarus's IDE in displaying the value? It uses gdb as debugger backend. doesn't it? Yes. But not every variable has a simple mapping in the debugging info. MSEGui does some more tricks to fill some gaps. The codetools can probably provide enough information to map. Marc can probably give more details. The current debugger should be able to display all variable values (except those defined with absolute and maybe those in procedures defined within procedures) So please let me know in what situation it fails (if gdb is able to show them) Properties are a different beast. Marc ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Code Structure / SourceEdit and SyneEdit [Re: Mouse Link in SynEdit (only link-able items)]
Martin Friebe wrote: Mattias Gärtner wrote: Zitat von Alexander Klenin kle...@gmail.com: I should note that I was horrified by the amount of glue code needed to route an event through main form, source notebook, source editor and SynEdit. The IDE is structured in a hierarchy. mainide: the top level of the IDE and the central nerve system. Because of its size it's splitted into several units. This is the 'integrated' in IDE. It connects the various modules like debugger, package system, codetools, designer, etc. source notebook: the whole source editor source editor: one single editor (at the moment in the same unit with source notebook, but should eventually split up) synedit: visual control Reading this, I just had an idea. (Nothing that would be done anytime soon, as it would be a major project) In The current structure SynEdit is the Visual control, and therefore also the control that takes all events such as mouse/key down/up/move. Often it is SynEdits work to react to this, but often it also needs to call back to SourceEditor. It is at least worth reviewing if this order could/should be changed (I am not sure about it): - SourceEditor could be a visual component with all the Key/Mouse event handlers. - It would *not* inherit from SynEdit, but same as now it would have a SynEdit instance that it can make calls to. This SynEdit would not paint on it's own canvas, but rather paint on the SourceEditors canvas - Instead of SynEdit making all the callbacks to SourceEditor, now all events go to SourceEditor first, and SourceEditor can decide what to forward. On the other hand, it is probably not worth the amount of work. Well the future will show, if there is a use case for it... It would make the design more pure then as it is now. I have too been wondering why synedit needs all the knowledge of ide events. Marc ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] KOL-CE and TKOLMainMenu
I think that the problem resided in the inc files, I solved it and now the project run correctly. Best regards! 2008/12/12 Yury Sidorov j...@cp-lab.com Menus works well on wince. Nobody ever compined about that. If something do not work on your project, try to create new project and test it. Yury. - Original Message - *From:* User usuarioanonimomy...@gmail.com *To:* General mailing list lazarus@lazarus.freepascal.org *Sent:* Friday, December 12, 2008 2:55 PM *Subject:* Re: [Lazarus] KOL-CE and TKOLMainMenu Hi again, the Locked property for TKOLProject and TKOLForm components is established to False and now I use a Lazarus 0.9.26 beta FPC 2.2.2 but the submenus are not shown under WinCE but they are shown under Win32, this is very strange... 2008/12/12 Yury Sidorov j...@cp-lab.com From: User Hi, I dropped a TKOLMainMenu into a KOLForm and I added several menus with submenus but they are not shown in WinCE. I use KOL CE 2.80.2 and Lazarus 0.9.27 beta FPC 2.2.3. What is the problem? Your form or project can be locked. It prevents autogeneartion of .inc files. Check Locked property for TKOLProject and TKOLForm components. Also use release version of Lazarus 0.9.26. I do not test KOL-CE with trunk version of Lazarus and it can be incompatible... Yury Sidorov. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Italian users
On Fri, Dec 05, 2008 at 08:58:59PM +0100, Giuseppe Fava wrote: hi everybody, I'm thinking about to create an italian lazarus community and I'd like to know how many Italians are reading this list and how many of these are interested... Giuseppe Why not using this list? http://www.freelists.org/list/fpc-pascal-it only for italian speakers... bye -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Mouse Link in SynEdit (only link-able items)
Thanks for the patch, looks good to me. A few things: - Originally you had the condition NewX1NewX2 moved into IsLinkable. Now it is omitted? May be right, because codetools may (or may not) return false for those. Yet it means an unnecessary call to code tools. - You probably accidentally included changes to the lfm file of source-editor? (I can both fix them in the current patch, no issue) - The unlucky bit is that your patch gets affected by a known bug. if you got a string with multibyte utf8 chars (like german umlauts) then anythink behind the umlauts is not linkable. This is already the case now (SynEdit does currently not follow valid links, behind umlauts), so you patch isn't wrong. The issue is, I can not test it, until I fixed the umlauts. I will see, if I can look at this during the weekend. - And last not least (not a stopper, but would be nice), the current solution does call Codetools each time you move the mouse. It may be possible for UpdateControlMouse to cache the boundaries of the current linkable word, and trust this cache instead of calling codetools from CalculateCtrlMouseLink again? Best Regards Martin Alexander Klenin wrote: On Fri, Dec 12, 2008 at 21:36, Joost van der Sluis jo...@cnoc.nl wrote: Nope, still no attachment. Maybe that it's too big. There's a limit of the filesize of attachments on this list. I meant attached to an issue: http://bugs.freepascal.org/view.php?id=12785 Anyway, I'll attach it to this message too, just in case ;-) ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] correction [Re: Mouse Link in SynEdit (only link-able items)]
Martin Friebe wrote: - The unlucky bit is that your patch gets affected by a known bug. if you got a string with multibyte utf8 chars (like german umlauts) then anythink behind the umlauts is not linkable. This is already the case now (SynEdit does currently not follow valid links, behind umlauts), so you patch isn't wrong. The issue is, I can not test it, until I fixed the umlauts. I will see, if I can look at this during the weekend. I am sorry, please ignore the above. It works absolutely perfect with umlauts, as well as with real-tab chars. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Mouse Link in SynEdit (only link-able items)
Hi Alexander, Mattias did apply your patch (since I am restricted to the synedit folder). If you feel like doing the optimization, it will always be welcome, but is no must. Martin Friebe wrote: Thanks for the patch, looks good to me. ... - And last not least (not a stopper, but would be nice), the current solution does call Codetools each time you move the mouse. It may be possible for UpdateControlMouse to cache the boundaries of the current linkable word, and trust this cache instead of calling codetools from CalculateCtrlMouseLink again? Best Regards Martin Alexander Klenin wrote: On Fri, Dec 12, 2008 at 21:36, Joost van der Sluis jo...@cnoc.nl wrote: Nope, still no attachment. Maybe that it's too big. There's a limit of the filesize of attachments on this list. I meant attached to an issue: http://bugs.freepascal.org/view.php?id=12785 Anyway, I'll attach it to this message too, just in case ;-) ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart: double-buffering (issue 0012377) questions
On Fri, 12 Dec 2008 19:38:55 +1000
Alexander Klenin kle...@gmail.com wrote:
In issue http://bugs.freepascal.org/view.php?id=12377, reporter said:
Painting to an Bitmap and paint this on the Canvas would be much
faster
This assertion is, of course, incorrect. I assume that the reporter's
problem is actually that the TChart flickers when repainted.
The flickering is caused by two sources:
1) The TChart is TGraphicControl, so Parent control erases chart's
background before every repaint.
2) TChart itself draws directly to screen, first clearing the canvas.
First source obviously needs fixing, and I attached to the issue a
patch which fixes it.
The only caveat is that TChart is now TWinControl -- can it lead to
some undesirable consequences I am not aware of?
All direct TWinControl descendants must be implemented in all
widgetsets.
You can use TCustomControl.
The second source can also easily be fixed by double-buffering, but
before I do that,
I have two questions:
1) TWinControl.WMPaint already contains double-buffering code, but it
is protected
by {$ifdef BUFFERED_WMPAINT}. What is the reason of this? Is there
some ongoing work to implement double-buffering globally?
It was an idea to implement double buffering, but it does not work on
all platforms. Gladfully most widgetsets have double buffering
themselves.
2) If double-buffering will be implemented in TAChart itself, it will
have some negative
performance impact. So, should I make it optional via DoubleBuffer
property?
Please try first TCustomControl.
Mattias
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart: double-buffering (issue 0012377) questions
On Sat, Dec 13, 2008 at 09:57, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Fri, 12 Dec 2008 19:38:55 +1000
Alexander Klenin kle...@gmail.com wrote:
The only caveat is that TChart is now TWinControl -- can it lead to
some undesirable consequences I am not aware of?
All direct TWinControl descendants must be implemented in all widgetsets.
You can use TCustomControl.
Sorry, I mixed up the mail (but not the patch). I already used TCustomControl.
1) TWinControl.WMPaint already contains double-buffering code, but it
is protected
by {$ifdef BUFFERED_WMPAINT}. What is the reason of this? Is there
some ongoing work to implement double-buffering globally?
It was an idea to implement double buffering, but it does not work on
all platforms. Gladfully most widgetsets have double buffering themselves.
But, apparently, not Win32, at least on WindowsXP.
2) If double-buffering will be implemented in TAChart itself, it will
have some negative
performance impact. So, should I make it optional via DoubleBuffer
property?
So this question remains. Or should I protect double-buffering with
{$IFDEF WIN32}?
--
Alexander S. Klenin
Insight Experts Ltd.
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Mouse Link in SynEdit (only link-able items)
On Sat, Dec 13, 2008 at 05:20, Martin Friebe laza...@mfriebe.de wrote: Thanks for the patch, looks good to me. A few things: - Originally you had the condition NewX1NewX2 moved into IsLinkable. Now it is omitted? May be right, because codetools may (or may not) return false for those. Yet it means an unnecessary call to code tools. I agree. - You probably accidentally included changes to the lfm file of source-editor? Not quite so. The lfm change I included was, IIUC, done by IDE automatically simply because I opened and saved SourceEditor unit. This happens often for me, usually since lfm format changed slightly since the last time anybody touched the lfm in question. I see three ways to deal with this: 1) Include such changes in commits, since they will inevitably show up later. 2) Ignore them, and let them pile up, and then either 2a) Include them all in bulk when some essential changes to the lfm is needed 2b) Periodically (and automatically, if possible) open and re-save all lfm's and commit the result. I do not know what the policy in Lazarus is [judging by my previous policy questions, there is probably no policy ;-)]. So I opted for (1). - The unlucky bit is that your patch gets affected by a known bug. if you got a string with multibyte utf8 chars (like german umlauts) then anythink behind the umlauts is not linkable. This is already the case now (SynEdit does currently not follow valid links, behind umlauts), so you patch isn't wrong. The issue is, I can not test it, until I fixed the umlauts. I will see, if I can look at this during the weekend. I see that you already committed some fix. FWIW, I tested with Russian characters in comments -- it works for me. - And last not least (not a stopper, but would be nice), the current solution does call Codetools each time you move the mouse. It may be possible for UpdateControlMouse to cache the boundaries of the current linkable word, and trust this cache instead of calling codetools from CalculateCtrlMouseLink again? Good idea, I was concerned with the speed too, but testing showed it to be ok (maybe my PC is too fast). So for now I filed an issue http://bugs.freepascal.org/view.php?id=12790 -- Alexander S. Klenin Insight Experts Ltd. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Code Structure / SourceEdit and SyneEdit [Re: Mouse Link in SynEdit (only link-able items)]
On Sat, Dec 13, 2008 at 06:26, Flávio Etrusco flavio.etru...@gmail.com wrote: My vision deviates a bit from this in the sense that TAbstractSynEdit would just be an abstraction (or dedicated implementation) of a cleaner text manipulation interface (as TStrings won't cut it), which would also implement transparent/automatic/implicit 'undo' handling. Then each command would be a class, probably inheriting from TAction. It is not a deviation as much as detalization ;-) However, it is also important not to overdo abstractions -- perhaps a separate class for every command is too much. Anyway, I am glad that you (and Martin) agree with the general concept. -- Alexander S. Klenin Insight Experts Ltd. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Drag, Dock and Layout
Paul Ishenin schrieb: Thanks for your hints on the platforms :-) It is a problem to understand your idea at first :) Right, I'm just what is possible, and how it could be done without restriction to my only well known platform (Windows). 3. Dock zones - ... 3.1 Dock sites IMO dock sites could be implemented in dedicated container controls, which react on docking events at all. These controls also can implement support for floating themselves, e.g. as detachable frames or toolbars. Delphi compatibility will not be affected, but a choice of ready-to-use docking components can simplify the design of new Lazarus applications. Mattias already tried to do this with anchor-docking? To some degree (no drag-dock...), and I do not yet like that layout model, because it looks too irregular to me. From my experience with layouts (and Oberon) I prefer strict horz/vert arrangement with a transparent management with regards to resizing etc. I also don't understand why every TWinControl should have docking capabilites, and prefer a strict separation of dedicated container controls (forms, panels...) from other controls. But okay, if somebody has other ideas, I'll not block additional implementations... 3.2 Dockable components IMO the docking of simple components is useful only at design time, when components are dropped from the toolbar onto a form. Docking at runtime can be restricted to forms and other floatable components, like toolbars or frames. Undocking of docked components requires that the structure of the docked components stays intact, i.e. forms or frames must be undocked in their original composition and framing. This forbids unpacking the components of a form, when the form is docked. When a form or frame instead is docked entirely, including a (small) title bar as in Delphi, every docked item can be restored exactly into it's previous appearance and behaviour, what currently simply is impossible. When the form is docked - it stay as form but loses titlebar and has parent - nothing else happen with it. On different platforms this achieved using different means. Dont understand what is currently imposible. In my docking experiments with Lazarus I found no way to undock a docked form again :-( Also I couldn't make properly work docking of multiple forms into a single dock site. Does there exist a working demo project for drag-dock? I'd be interested in a program that allows to create and drag-dock forms into the main form, and then allows to undock the forms again. If somebody already made that work, then there's not much left to do for me :-) [If you have Delphi at hand, try to make the Demo\Docking sample work with Lazarus, somehow. Then you'll see yourself what remains to do :-] 3.3 Determination of the docking position. I'll not go into details here, it's mostly a matter of implementation of the an docking manager. The default (tree) docking manager implementation lacks many docking features which can hardly be added, or even be made work, without a deep redesign of all related classes and other data types. What does it miss? Have you seen TLazDockTree class? Yes, and it looks like overkill to me and, if you look into the source code, it is not really used at all :-( I'd use a list of docking planes (or levels), where the planes have alternating horizontal (alLeft/alRight) and vertical (alTop/alBottom) arrangement. Or the site contains only one docked client without an arrangement (alClient), or it is/contains a tabbed control or other layout (alCustom), like anchored docking. Every plane is represented by an according container control (e.g. TPanel), which already implements what currently should go into the DockTree. I also feel a need for centralized handling of drag operations. A static singleton would perfectly fit all requirements, since only one drag operation (mouse capture...) can be active at any time. All mouse messages could be routed through that singleton, when it signals a drag operation in progress. Such an implementation should make Lazarus and the applications much more stable... Therefore I'd suggest a separation of any but the abstract TDockManager from the Controls unit, eliminating the need for a rebuild of the IDE after every change to the Controls unit. It also will show up the undocumented dependencies between controls, messages, and the code that implements the details of dragging and docking. I'm willing to perform that separation myself, if no official developer is willing to do so - but I'm not willing to spend much time when afterwards the new structure doesn't become part of the trunk. Dont see why it will not be commited if you improve current code and break nothing? Lazarus and LCL is always open for improvements. (Not) breaking existing code is one of my problems, since I cannot test the changes on all platforms. Another problem is the
Re: [Lazarus] Changed Compilers Options, Run, Build versus Build All
Tom Verhoeff schrieb:
[...]
Here is another issue. When working on a program involving multiple
units, it may turn out that the Use AnsiStrings was not set
consistently.
Students are advised to enable this globally in the Compiler Options,
but they sometimes forget. Some (given/generated) units also contain
their own {$H+}, others don't.
Is this a student bug or an IDE bug?
Neither, it is a fact of life :-). It is a consequence of the fact
that units from different authors may have been made under different
assumptions. Some units are written with the assumption that they will
be compiled with -Sh, others do not make that assumption and include {$H+}
in the source.
I'd go the Delphi way, and make string dependent on global settings
only. If somebody wants specific Ansi- or ShortStrings, s/he should use
the according types, in favor of the generic string type. Such strict
typing will make even legacy code better reusable. I dunno about the
perfomance of ShortString with FPC, but I don't think that there exist
many cases, where ShortString really provides any advantage over AnsiString.
A hint for students and teachers: *generic* data types, like integer
or string, should only be used when *all* operations with such
variables will work with any current or future implementation of these
generic types. Consider what will happen when string becomes a
WideString, or the like, as recently happend in RAD Studio (Delphi)...
DoDi
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Mouse Link in SynEdit (only link-able items)
Mattias Gärtner schrieb: The IDE is structured in a hierarchy. mainide: the top level of the IDE and the central nerve system. Because of its size it's splitted into several units. This is the 'integrated' in IDE. It connects the various modules like debugger, package system, codetools, designer, etc. source notebook: the whole source editor source editor: one single editor (at the moment in the same unit with source notebook, but should eventually split up) synedit: visual control Interesting information. Where would I have to start implementing multiple source editors (notebooks)? DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
