Re: [Lazarus] Live Templates
Mattias Gärtner wrote: Zitat von Lee Jenkins l...@datatrakpos.com: Graeme's recent post made me wonder if there is been work or talk of work on implementing Live Templates like Delphi has? Yes. 1. Lazarus will not support the Delphi syntax, because Lazarus already supports code macros. There are already some code macros using the codetools. 2. auto complete without pressing a short cut already works for return, space and word end. Some code macros are needed to fine tune adding text if parts of the template already exists (for example auto complete 'begin' after pressing return). But this is stuff for another thread. 3. templates with parameters: editing the parameters directly in the source editor (synedit) without a dialog. synedit needs a further edit mode for marking and editing several places in parallel. Martin has already implemented marking several places. I guess he can also create a plugin/extension/mechanism for the needed edit mode. When this is done, I will be glad to implement the rest. This edit mode is also needed for in situ rename. Yep, it's on the list, but not yet sure when. For code Template there a 2 main targets: 1) Form mode - The code template defines several places (form-fields) where input is needed for [] := [] to [] do - the Editor the allows to navigate them using tab (or a user defined key shortcut 2) Sync Edit Actually this is a feature off it's own, but should work specially with templates: the form-fields from above could be linked, editing the content off 1, would update the other too. Example: check a variable is in range: (while you type in field 1, the same appears in field 2: if ([] = 10) and ([] 20) then I imagine that that kind of behavior is a bit of work to implement. Yes, but I bet Martin has already some ideas for synedit. Not exactly related to templates, but one feature, I like to add for myself. Motivated by commenting code. If you type (*, this will comment all of the remaining code, temporarily disabling all highlighting, and unfolding everything. A magic add cloisng bracket. If you type (* SynEdit inserts a virtual *). (Could be shown like a hint...) the closing *) follow sthe caret movement. So you can move the caret to the desired location and hit enter. It could be cancelled bey esc, it would also detect manually typing the *) sequence It could work for any other pair-construct, including begin/end ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] DisableWindowsUnicodeSupport
Vincent Snijders wrote: Bernd Mueller schreef: Hello, I would like to use Lazarus without Unicode support on Windows, as it was possible up to version 0.9.24. I took a recent 0.9.27 snapshot and compiled it with -dDisableWindowsUnicodeSupport. My old projects seem work well, but the editor does not show the german umlauts correct. I changed File Settings.../Encodings but this did not help. As for Synedit: 1) There may be code elsewhere, that detects the filetype while loading the file = in this case it should convert it to utf8. 2) If one doesn't happen. Try the following. (I have not tested it, but it *may* do the trick) open C:\lazarus_latest\components\synedit\syntextdrawer.pp line 889 function TheTextDrawer.GetUseUTF8: boolean; and make the function to always return False For sure, I belong to a minority which has no need for Unicode. For me, it would be great to have Unicode disabled in Lazarus. So what is the intention behind DisableWindowsUnicodeSupport in theses days? If it should work, I would make a bug report. My response can be seen as an addition to Paul's. As far as I am concerned, the dDisableWindowsUnicodeSupport does not need to be removed. OTOH working with -dDisableWindowsUnicodeSupport has no priority for me. If the Lazarus community does the testing and supplies patches, I don't mind committing them (much like I said about the fixes_0_9_26 branch, no effort form me, but willing to support the efforts of others). I am willing to accept bug reports, if it turns out that a regression was caused by on of my commits, i.e. it worked before with DisableWindowsUnicodeSupport, and after it didn't. Having said that, I fear that some incompatibilities remain, because the LCL (not the win32 interface) insert conversion to UTF8 when using RTL functions in for example the TFileListBox. Finding a solution for such issue is not a priority for me, but patches will be reviewed and accepted if ok. Vincent ___ 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] Watches/Local variables/Registers [Re: IDE UI consolidation (was: Re: lfm as pascal)]
Alexander Klenin wrote: On Thu, May 7, 2009 at 08:56, Martin Friebe laza...@mfriebe.de wrote: To heat the discussion up: From the wiki: Watches/Local variables/Registers All three are a lists of name/value pairs used at debug time. They should be merged together in a single list with appropriate filtering capabilities. another thing with combining them, is that the amount of Locals keeps changing (watches just display unavailable). This means that (unless locals are last in the list), everything keeps changing position, and you have to adjust where to look for it. (OT: Would be a great feature to bind watches to a stackframe, and have them changing automatically...) Still I often use watches to show local variables which have a very long value. In this case I can have a narrow Local window (left to the code), and a very wide (but only a few lines high / below the code) watches window. Of course, If I am the only one who uses this in such a way, then it's not a reason. Interesting, but I guess this is indeed rather rare case. What kind of long values do you watch? Mainly structures/records/classes... Of course that would be better solved, by having each member on a line of it's own. You also have to find a way how to deal with different properties that watches can have (not yet, but in future: mem-dump, hex, dec, ... hust see the property window). In princible they can be applied to locals, as long as you can find a way to match them, each time locals had been updated. Because if you change stack frame you may have a local with the same name, but it is a different variable. So how to you bind those properties to a local value? Not sure if those props make sense for registers Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] OT, search and highlight[Re: IDE UI consolidation (was: Re: lfm as pascal)]
Graeme Geldenhuys wrote: On Wed, May 6, 2009 at 2:44 AM, Alexander Klenin kle...@gmail.com wrote: FWIW, I often use Quick search (Ctrl+E) for code navigation, How does quick search work? I highlighted an identifier I want to seach for, pressed Ctrl+E. It showed seaching in the editor status bar, but nothing further. Sometimes it highlights a whole bunch of stuff like the letter e. I'm a bit lost. :-( Highlight (as in block-selection) and then search for it = use ctrl-f Quick search (or incremental search) (ctrl-e) means you start the search with an empty search-term, then as you type the editor searches for whatever fragment you typed ctrtl-e = status-bar displays searching b = status bar displays b / editor goes to the next b (b is highlighted, all other occurrences are highlighted in yellow) e = status bar shows be / editor goes to next be f = bef = backspace = be editor returns to be g, i, n = begin - while in quicksearch, pressing F3 or ctrl-e again = jump to the next search result of the same term - start quick search with ctrl-e, ctrl-e = resume with last search term Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE UI consolidation (was: Re: lfm as pascal)
Alexander Klenin wrote: I think that while Lazarus IDE has many great features, they are not well organized. Various Lazarus developers added convenience features with a separate user interfaces, so the features are dispersed all over UI and hard to discover. IMHO the good way forward is to consolidate some feature groups into a common UI, thus giving greater exposure to all included features. I realize that may be a controversial topic, as developers might defend their pet features from consolidation, stating that consolidated UI is less convenient than specialized ones, but I think there should be a balance of uniformity versus specialization, and right now this balance is tipped far on the specialization side. If there is a general agreement, I can prepare detailed proposal for consolidation, but as a quick sketch: 1) Find procedure should be merged into Code explorer Ok by me. (I never used it :) ) It's partly there anyway. 2) Find in files, Messages and Code observer should be merged together, with interface most resembling Find in files IMHO, this (point 2) would be even more a specialization. Also I can't see how those 3 relate at all. Anyway, for that lets wait for docking. 3) Unit list (Ctrl+F12) should be merged into Project Inspector 4) Find unused units should be merged into Unit dependencies I was thinking Unit dependencies could also be merged to Project Inspector ... and so on what about: - keybard layouts? - Menu layouts? Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE UI consolidation (was: Re: lfm as pascal)
Alexander Klenin wrote: 2009/5/7 Bogusław Brandys bran...@o2.pl: In fact we see here old problem of two rights - both groups are right , partially. While it would be nice to have as many nice features placed in one Code explorer as possible - that WILL double windows, because someone not using docking (due to limited free memory for example) will find faster to use Ctrl+F12 to show not bloated window with unit names then bloated code explorer. So what would show Ctrl+F12 shortcut in such case ? Ctrl+F12 is a shortcut for unit list, not procedure list Graeme was talking about. To me, this confusion is yet another argument that number of windows should be reduced ;-) 1) So when you say reduce number of windows: Does that imply reduction of shortcuts too. Or will all the shortcuts be kept, and just switch to the correct tab (including open the window, if not yet open)? 2) There also is an argument for not merging the windows. Someone might want to have both windows open, and see both lists at the same time. I don't use many of them, but it isn't totally unrealistic to assume that someone, might have unit and procedure windows both open? So once a unit was selected you can seltct procedures with no window switching. (Especially people who have 2 or more screens) ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Watches/Local variables/Registers [Re: IDE UI consolidation (was: Re: lfm as pascal)]
To heat the discussion up: From the wiki: Watches/Local variables/Registers All three are a lists of name/value pairs used at debug time. They should be merged together in a single list with appropriate filtering capabilities. That would make debugging so much harder. Let's assume merging those 3 does *not* mean a window with 3 tabs (as all 3 must be visible at once), but rather a window with splitters, so you can set how much of each you want to see... 1) Still I often use watches to show local variables which have a very long value. In this case I can have a narrow Local window (left to the code), and a very wide (but only a few lines high / below the code) watches window. Of course, If I am the only one who uses this in such a way, then it's not a reason. 2) 99% of the time I don't need the register window = with them all showing in the same window, I will be very busy hiding it (move the splitter to 0 size) And I really can't imagine, that everyone else is using the registers at all times. Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus ignores my breakpoints
Graeme Geldenhuys wrote:
On Tue, May 5, 2009 at 1:06 PM, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
Hi,
Why is Lazarus ignoring my breakpoint? If I put a writeln() statement
before line 1466, it is executed and I see console output. So that
I place the following writeln() statement before line 1466 and below
is some sample output, showing the writeln() is being run.
While it is not the answer to your question, I had a similar issue and
found, that breakpoints only worked, if they here set *before* I started
the application to debug. (This was on FreeBSD)
Maybe worth trying until the issue is fixed?
Martin
writeln('**');
==[ console output ]
/home/graemeg/programming/tiOPF2/UnitTests/Text/textrunner -p
--suite=TtiObjectTestCase
TtiObjectTestCase:
Owner: ... DONE
Parent_InheritsFromVsIs: ... DONE
Parent_TtiObject: ... DONE
Parent_TtiObjectList: ... DONE
OIDGenerator: ... DONE
GetOID: ... DONE
PropType: ... DONE
IsReadWriteProp: ... DONE
PropCount: ... DONE
SetPropValue: ... DONE
SetBooleanPropValue: ...**
ERROR
GetPropValue: ... DONE
SetPropValueNested: ... DONE
GetPropValueNested: ... DONE
Deleted_TtiObject: ... DONE
..
===
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
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] WSRegister error on console application
Paul Ishenin wrote: Andrea Mauri wrote: I tried it (replaced LCLType and LCLintf with Windows), now I got an error on these lines: NCB.ncb_command := Char(NCBENUM); NCB.ncb_command := Char(NCBRESET); NCB.ncb_command := Char(NCBASTAT); NCB.ncb_buffer := PChar(@Adapter); The error is: Error: Incompatible types: got Char expected Byte Well, you can replace Char by Byte. See yourself which solution is better for you. You could try smart-linking -CX -XX (You will have to build the LCL smartlinkable, and your app too) That should get rid of the error. If you really only use parts (such as type declarations) that do not need the interface, then smart lining should remove all those references (and that includes all of the WSRegister* too) Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Editor font disturbed after upgrading to r19705
Bart wrote:
On 4/30/09, Martin Friebe laza...@mfriebe.de wrote:
It looks to me like it uses a different font. certainly it looks like it
believes the font was proportional (that is why you get the odd spacing,
because SynEdit forces it into a grid).
The last font-related changes in synedit where in revision 185xx (so
before your last good revision).
Maybe you could put some debugln into Synedit.SizeOrFontChanged and see
which font is really used? Otherwise I have no idea.
I can certainly do so, but in which unit is this method?
I have attached a patch with a few debugln in it. I don't know if they
will show anything useful, since I have no idea what is going on.
If you apply it, you need to start lazarus with a logfile, to capture
the output. (There is a command line switch, but I have to find it
myself / I usually compile as none window app, which means my Lazarus
runs with a console-window showing all the output)
Also if you do this, test it with only one Synedit open. (You can
compile a standalone app, with one SynEdit, and set the font from inside
the app)
I wrote a small test program that has a synmemo and a memo
It sets the fonts of both the memo and synmemo the same
and then queries their names etc and writes them in the editcontrols
below (see attachments)
In r18956 when setting the font (via fontdialog) to Courier New 10
point normal you see that the fonts look exactly the same in synmemo
and memo (normal_couriernew.png).
In r19705 they look very different indeed (bug_couriernew.png).
Memos are native controls, so they are drawn differently.
If you use the same font, (and in normal, bold, italic) for Labels
and/or StaticText, does it look correct there?
Note, the spacing will be ok there, because neither of them forces the
mono-spacing. But does it actually look like the expected Courier New,
and is it truly monospaced?
So at least it looks like the synmemo thinks it's font is courier new...
I haven't got Win9x, so I can't test. On XP it looks fine.
I tested the compiled programs under XP and they behaved normally (and
absolutely the same): the courier new font looks OK and the same in
synmemo and memo.
So we have a win9x specific bug?
(Delphi with a tsynmemo and a tmemo behaves just fine on my win9x system)
Bart
Index: components/synedit/synedit.pp
===
--- components/synedit/synedit.pp (revision 19726)
+++ components/synedit/synedit.pp (working copy)
@@ -7529,6 +7529,7 @@
// TODO: Clear style only, if Highlighter uses styles
Style := [];// Reserved for Highlighter
end;
+ debugln(['RecalcCharExtend for font name=', Font.Name, ' / ',
fFontDummy.Name, ' mono=',fFontDummy.IsMonoSpace, '
Handle=',fFontDummy.Handle]);
with fTextDrawer do begin
//debugln('TCustomSynEdit.RecalcCharExtent A UseUTF8=',dbgs(UseUTF8),
// ' Font.CanUTF8='+dbgs(Font.CanUTF8)+' CharHeight=',dbgs(CharHeight));
Index: components/synedit/syntextdrawer.pp
===
--- components/synedit/syntextdrawer.pp (revision 19726)
+++ components/synedit/syntextdrawer.pp (working copy)
@@ -780,6 +780,10 @@
// clear styles
SetStyle(Value.Style);
end;
+if pInfo nil then
+ debugln(['SetBasefont name=', Value.Name, ' basefont.name=',
pInfo^.BaseFont.Name, ' Handle=',pInfo^.BaseFont.Handle])
+else
+ debugln(['SetBasefont name=', Value.Name, ' NO pinfo']);
end
else
raise EheFontStockException.Create('SetBaseFont: ''Value'' must be
specified.');
@@ -851,6 +855,7 @@
SelectObject(DC, hOldFont);
{$ENDIF}
InternalReleaseDC(DC);
+ debugln(['SetStyle created font for idx=',idx, ' name=',p^.Font.Name, '
handle=',p^.Handle]);
end;
procedure TheFontStock.UseFontHandles;
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Editor font disturbed after upgrading to r19705
Bart wrote: On 5/1/09, Martin Friebe laza...@mfriebe.de wrote: I have attached a patch with a few debugln in it. I don't know if they will show anything useful, since I have no idea what is going on. If you apply it, you need to start lazarus with a logfile, to capture the output. (There is a command line switch, but I have to find it myself / I usually compile as none window app, which means my Lazarus runs with a console-window showing all the output) Also if you do this, test it with only one Synedit open. (You can compile a standalone app, with one SynEdit, and set the font from inside the app) I applied the changes in sysnedit.pp and syneditextdrawer.pp then did a make clean all This happens when I build and start my test app. Does that test app use a syntax highlighter? From the output I would guess that it does not. (because the font is only recalculated in plain, but not in bold or italic / You compare app with memo in your 2nd mail shows plain style only.) Anyway, as long as it doesn't, the output looks good. One thing I noted in the pictures of your first mail (highlighted pascal before/after): In the after text the output of the bold text seems to use a different font than plain text. Compare the u. The plain u (and any u in the before pic) has serif/serif-like extensions. the bold u in the after pic, has not. Regards the output below: the default and courier are normal, SynEdit creates them during it's own creation, before you even have a chance to set the font. In OI the font is set to Verdanana, size -12 (height 16), pitch fpFixed F:\LazarusProjectentest SetStyle created font for idx=0 name=default handle=596 SetBasefont name=default basefont.name=default Handle=596 SetBasefont name=default NO pinfo SetStyle created font for idx=1 name=default handle=3364 RecalcCharExtend for font name=courier / courier mono=False Handle=2360 SetStyle created font for idx=0 name=courier handle=2360 SetBasefont name=courier basefont.name=courier Handle=2360 SetStyle created font for idx=1 name=courier handle=2492 RecalcCharExtend for font name=courier / courier mono=False Handle=2360 SetBasefont name=courier NO pinfo RecalcCharExtend for font name=courier / courier mono=False Handle=1760 SetStyle created font for idx=0 name=courier handle=1760 SetBasefont name=courier basefont.name=courier Handle=1760 Here you would have set Verdana RecalcCharExtend for font name=Verdana / Verdana mono=False Handle=1720 SetStyle created font for idx=0 name=Verdana handle=1720 idx=0 = plain, no-bold, no-italic SetBasefont name=Verdana basefont.name=Verdana Handle=1720 When I set the font (in my app) to Courier New, Normal, 10 pt, this is the output: RecalcCharExtend for font name=Courier New / Courier New mono=False Handle=2308 SetStyle created font for idx=0 name=Courier New handle=2308 SetBasefont name=Courier New basefont.name=Courier New Handle=2308 If I change the font in Lazarus IDE, I see no output on console, or on logfile (startlazarus --debug --pcp=bla) If you use the same font, (and in normal, bold, italic) for Labels and/or StaticText, does it look correct there? TLabel and TStaticText seems to work normally The best is probably to try and find the revision which broke it. Everything else is just blind search for a needle in a hay stack. But in case, what happens with labels/statictext, if you set pitch to variable/fixed? Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Editor font disturbed after upgrading to r19705
Bart wrote: Hi, I just upgraded my Lazarus from r18956 to r19705 on Win9x. When I started Lazarus the font in the code editor had become almost unreadable (too small, appr. 5 pt.) I tried to adjust the font in using the appropriate dialog, but I could not get it as it was before. I then copied the editoroptions.xml from what used to be my stable version and applied it to r19705, so I was sure they both used the same fonts. However the r19705 renders the chosen font very differently. It looks to me like it uses a different font. certainly it looks like it believes the font was proportional (that is why you get the odd spacing, because SynEdit forces it into a grid). The last font-related changes in synedit where in revision 185xx (so before your last good revision). I haven't got Win9x, so I can't test. On XP it looks fine. Maybe you could put some debugln into Synedit.SizeOrFontChanged and see which font is really used? Otherwise I have no idea. Regards Martin The editor r18956.png show how the editor font used to be, the editor r19705.png shows how it is rendered now. Here's the editoroptions.xml that both Lazarus' use: ?xml version=1.0? CONFIG EditorOptions Version=4 Display EditorFont=Courier New EditorFontHeight=-13 ExtraLineSpacing=0 ShowLineNumbers=False ShowOnlyLineNumbersMultiplesOf=1/ Color LangObjectPascal Version=4/ /Color KeyMapping default Version Value=5/ printselection Value=80,1,0,0,0,0,0,0/ jcfcurrenteditorwindow Value=68,1,0,0,0,0,0,0/ /default /KeyMapping CodeTools CodeTemplateFileName=H:\PROGRAMMAS\SVNLAZ\lazarus.dci/ /EditorOptions /CONFIG The fontheight of -13 looks strange, but Lazarus puts this value in when I choose the font directly from the font-dialog. I've tried changing the font-size to diffrent values (10 to 18) but nothing comes even close to what it used to be. The font is either too big, or too small, or the kerning (the space between individual characters) is too large. B.t.w. Yesterday I upgraded my Lazarus on Linux (GTK2) to r19690 and I noticed no fonts changes at all. Is this a bug, or is there something wrong with my system? Bart ___ 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] EXC_BAD_ACCESS, Could not access memory
Roland Turcan wrote:
Hello Bart and others,
Thanks for your kindness to test my test case, which works fine in my
case too, but I have found something what maybe more explain my
problem.
maybe? This does most certainly explain your problem, see below
TYPE TSomeItem = RECORD
First :single;
Second:Single;
Third :integer;
TYPE TSomethingArr = ARRAY OF TSomeItem;
TYPE TSomeHeader =RECORD
...
end;
TYPE TMyObject =class
private
FHeader:TSomeHeader;
FItems :TSomethingArr;
...
FUNCTION TMyObject.LoadFromStream (Stream:TStream):BOOLEAN;
...
SetLength (FItems, 0); //!! for testing only -- this line works fine
Stream.Read (FHeader, HeaderLen);
SetLength (FItems, 0); //!! for testing only -- this line raises an
exception
END;
If you see the declaration of TMyObject you will find that FHeader
declaration is followed by FItems and the length of read memory block
goes over size of FHeader and it affects FItems.
Hm?
Take a look of how thinks are organized in memory:
TMyObject allocates some memory. FHeaders (being a record) is embedded
into the same memory, it is part of TMyObjects memory.
But FItems (being an array) allocates it's own memory, somewhere
completely different. It only stores a pointer inside TMyObject.
This means when you write past FHeaders, then you but a random value
into the pointer. Next time you try to access the array it will try to
follow this random value. This means you try to access memory that
doesn't belong to the application. Even if the value pointed to an
address inside the apps accessible mem, you would still override random
other data and crash.
Best Regards
Martin
TRoland;
23.4.2009 17:19 - Bart bartjun...@gmail.com
B This code works perfectly fine (at least it does not crash) with fpc 2.2.2
B constructor TMyObject.Create;
B begin
B DebugLn('Create');
B FItem := nil;
B DebugLn('nil');
B SetLength(FItem,3);
B DebugLn('SetLength');
B FItem[0].First:= 1.0;
B DebugLn('FItem[0].First = ',DbgS(FItem[0].First));
B end;
B Bart
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] ide enhancement - method or cursor location belongs to what class?
Graeme Geldenhuys wrote:
On Sun, Apr 19, 2009 at 3:11 AM, Martin Friebe laza...@mfriebe.de wrote:
There is now revision 19499
you need the mouse (so it isn't as quick and convenient as a key-command
driven hint).
The Fold-Gutter part now has it's own Pop-up menu. (only at lines that
have folding present). And it shows all the nested levels.
It works on lines with code-folding present in gutter - I see the
popup menu appear. But as soon as I right-click on an area in the
gutter that doesn't have the code-folding, then I get an AV. I only
have code folding enabled for {%region} and {%ifdef}.
The AV is fixed in revision 19549. Thanks for the hint.
You will need to add folding at Procedure-level and Class-level (maybe
class-section too), in order to see where in the code you are...
There is a need to display that kind of info independent of folding, and
in a form that does not require the mouse (can be reached quicker), but
for now...
Best Regards
Martin
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New Lazarus IDE/LCL features since ...?
from the wiki: v0.9.18 (2006-11-22) block matching The IDE automatically highlights matching blocks - begin..end pairs. I think that was/will be 0.9.28. ? At least I couldn't fnd this in 0.9.24 / 0.9.26 Revision: 18436 Date: 13:36:29, 25 January 2009 Message: SynEdit: Highlight Begin/End pairs Graeme Geldenhuys wrote: Hi all, Seeing that CodeGear has this new ??? features since Delphi 7, why can't we start something like that for Lazarus as well. I don't really know why exactly the CodeGear guys decided since Delphi 7 and not another version though. When I look at the features listed in the links below, I am more and more impressed with Lazarus. (well done to all!) We have most of those features and more... Such a wiki page or two would be a nice one-stop show-off page like come see what Lazarus has to offer... :-) Your thoughts on such a wiki page idea? New IDE features since Delphi 7 http://edn.embarcadero.com/article/34323 New VCL features since Delphi 7 http://edn.embarcadero.com/article/34325 Enhancements since Delphi_7 http://delphi.wikia.com/wiki/Enhancements_since_Delphi_7 Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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] Figures in code explorer
Mattias Gaertner wrote: On Mon, 20 Apr 2009 12:14:18 +1100 Alexander Klenin kle...@gmail.com wrote: (4g) again seems simple, but 'auto-fixing' can in this can make things _worse_ by hiding the problem. Consider the code (idented by '~' characters): for i := 0 to High(A) do ~~if A[i] m then Writeln(A[i]); The actual error is a missing 'm := i' line after the if, but formatter would change it to for i := 0 to High(A) do ~~if A[i] m then Writeln(A[i]); Obtaining correctly formatted but semantically wrong code. Hint, on the other hand, will simply point programmer to the problematic location where he will hopefully notice and fix it. Ok, the above example is a good. I thought you meant showing wrong indentation in general. That would not make much sense, because the indentation rules belongs to the code formatter and makes only sense for units you wrote. So the code explorer can scan for lines 'do' and 'then' lines where the following line is indented less or equal. Of course some programmers will switch off the equal. while a nice idea, even this is not that easy ~~if a = 1 then ~~begin // if it should be on it's own line end; 1) the begin is *or* is not expected to be intended, so the rule above should carter for that? 2) the end should be aligned with the start of the line, that did have the begin ~~if (a = 1) and // some very long condition or comment ~(b=2) then writeln; Imho is correctly indented, because the then is already moved in. (in fact the 2nd condition line(5) is intended more (aligns the ( ) than the writeln line(4)) if a = 1 then b:=2; writeln(b); if a = 1 then b:=2; writeln(b); the line continues behind the then = no indent is expected. if a = 1 then b:=2 else writeln(b); = I had no idea what indent was expected here? ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Figures in code explorer
Alexander Klenin wrote: On Sun, Apr 19, 2009 at 22:02, Mattias Gaertner nc-gaert...@netcologne.de wrote: A few questions/suggestions for improvement: 1) Where did the name came from? It is totally meaningless for me. See http://www.askoxford.com/concise_oed/figure?view=uk Hm. I'll quote that: figure, noun: 1 a number or numerical symbol. 2 an amount of money. 3 a person’s bodily shape, especially that of a woman. 4 a person seen indistinctly. 5 an artistic representation of a human or animal form. 6 a shape defined by one or more lines. 7 a diagram or illustrative drawing. 8 (Music) a short succession of notes producing a single impression. Not one meaning correspond to 'a hint about possible problem in the code'. Hm, while some of them probably are most likely to be used to find possible issues, there is no need to see them as an problem indicator only. So point 1 is correct as they are a collecion of numbers figures Still, maybe they would be better named as statistics? (maybe analytics ?) Maybe 'Stylistic notes' or 'Style' or something along these lines? Not all are about style. At least it will give user a vague idea what it is ;-) How about simply 'hints'? ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] ide enhancement - method or cursor location belongs to what class?
Graeme Geldenhuys wrote: Hi, I often have large classes that are bigger than what the source editor can display at once. I'm mainly talking about tiOPF project here. Anyway, I receive patches for large methods and use the IDE 'goto line' command to maybe review or modify a received patch. Again, the IDE only shows me lines of code, I can't clearly see which class I am currently working in. Ctrl+Shift+UpArrow doesn't reveal this info either, because again the class declaration is large and doesn't fit into the source editor all at once. Is there a way to quickly see what class I am currently in without loosing my current position in the source code? I was thinking of maybe some editor shortcut that could display for a few seconds the classname in the top right corner of the editor and then simply fade away. Is this possible? Is there already something similar in Lazarus IDE or another way of know what class I am currently in? There is now revision 19499 you need the mouse (so it isn't as quick and convenient as a key-command driven hint). The Fold-Gutter part now has it's own Pop-up menu. (only at lines that have folding present). And it shows all the nested levels. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] OT [Re: Why we chose Object Pascal instead]
Giuliano Colla wrote: Felipe Monteiro de Carvalho ha scritto: And here is the best comment about it: Capt. Kirk: As a customer your choices are: 1. Hire an experienced competent developer who understands the library functions, knows how to write properly structured code with appropriate variable scope and data types, or 2. Hire someone who will produce what appears to be exactly the same output. As a customer who doesn't happen to be a developer himself, the above two options translate as: 1. Hire an expensive expensive expensive who expensive the expensive expensive, knows how to write expensive expensive code with expensive expensive expensive and expensive expensive, or 2. Save a bunch of money and get exactly the same thing. The funny thing is that whoever buys a car, a drill, a mobile phone, whatever, knows very well that what is visible doesn't tell what's inside, how reliable it is, and so on, and looks for expert advice. A lot of publishers make money printing magazines which provide a better insight on cars, cameras, phones etc. etc. Nonetheless, although everybody stumbles every day in the pitfalls of badly written software, it appears that very few apply to buying software the same kind of approach. :-( Yeah, but where is the magazine: The programmer's inside ? Which compares individual programmers, and gives tips, whom to use for which purpose? scnr Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Clear font backgrounds
Dave Coventry wrote: Hi, I'm using Image1.Convas.TextOut and I need the font background to be clear. Does anyone know how to achieve this? uses LCLType, LCLIntf; SetBkMode(Image1.Canvas.Handle, TRANSPARENT); You may have to use LCLIntf.ExtTextOut() Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Clear font backgrounds
Dave Coventry wrote: Hi Martin, Thanks for the response. 2009/4/13 Martin Friebe laza...@mfriebe.de: uses LCLType, LCLIntf; SetBkMode(Image1.Canvas.Handle, TRANSPARENT); Yes, I do seem to have these functions. You may have to use LCLIntf.ExtTextOut() I'm not sure I understand. Do you mean Image1.Canvas.LCLIntf.ExtTextOut()? Nope, After SetBKMode try to output text as usual, eg with: Image1.Canvas.TextOut(). (or whatever it is, I don't recall exactly) This may already work, I haven't tried it What I have used is: dc := Canvas.Handle; SetBkMode(dc, TRANSPARENT); LCLIntf.ExtUTF8Out(dc, X, Y, 0, @ARect, Text, Length, nil); ARect is a TRect thats specifies where the text goes. Unless you use clipping, only the top edge matters (since the background is transparent too) Example can be found in SynEdit: components\synedit\syntextdrawer.pp line 1175 (the line refers to the SVN version; use search otherwise); the BKMode is set in synedits main unit. Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] update [Re: Code Folding mess and Code Divider feature]
Alexander Klenin wrote: On Fri, Apr 10, 2009 at 22:10, Martin Friebe laza...@mfriebe.de wrote: 3) 'Folding'/'Divider' buttons are slightly confusing. Maybe it is better to make common list of language constructs with additional 'Fold' checkbox, and make it visible only when needed? Alternatively, how about at least using PageControl instead of two buttons? I don't like the page control to much, I tried it The more likely solution (and feedback shows it will be needed) is to have 2 complete independent pages in the tree on the left. Patches are welcome, I have some other stuff that I currently prioritise at a higher level Sorry, no patch from me, but I can create an issue if you want. I have no problems with a separate page, but why do you reject a common list? It seems the best solution to me. Dividers initially could only be set at places where a fold ended. Now they can be set at places, even if the place is not configured as the end of a fold. So they are a separate feature. Divider-Locations also is a different list than Fold-Locations, so sharing the same list, would be confusing. 4) Some combinations result in two dividers drawn separated by and empty line (e.g. after the last procedure and before the initialization section). IMHO in such cases only one divider should be drawn [skip] Simple drop them would not work for people who have them in different colors (ok ,I do not honestly believe this is an issue) BTW, don't you think that per-type divider coloring is an overkill? Perhaps a single color on Colors page would be sufficient? Not necessarily. For Example (I use this) I have a normal grey (same as right/80-column border) for procedures (procedures at top-level. But I use a lighter grey for nested procedures. So I can see the difference between nested and top level procs. Also I plan further extension which will make the colors more useful. Have to find the link again, I had it in a previous mail about the topic. Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] update [Re: Code Folding mess and Code Divider feature]
Alexander Klenin wrote: On Sat, Apr 11, 2009 at 01:56, Martin Friebe laza...@mfriebe.de wrote: Sorry, no patch from me, but I can create an issue if you want. I have no problems with a separate page, but why do you reject a common list? It seems the best solution to me. Dividers initially could only be set at places where a fold ended. Now they can be set at places, even if the place is not configured as the end of a fold. So they are a separate feature. Divider-Locations also is a different list than Fold-Locations, so sharing the same list, would be confusing. Well, there are already two divider sub-kinds -- nested and normal ones. They already display different controls (spin editor vs checkbox, second color picker). I suggest to add 'Fold' checkbox, in the same vein -- it will be displayed only for foldable locations. As I said there may be more oprtions in future, so better to keep them separated BTW, don't you think that per-type divider coloring is an overkill? Perhaps a single color on Colors page would be sufficient? Not necessarily. For Example (I use this) I have a normal grey (same as right/80-column border) for procedures (procedures at top-level. But I use a lighter grey for nested procedures. So I can see the difference between nested and top level procs. No problem, but how do I globally change divider color then? Do I have to change it for every kind of location? Leave them on default, and change the color of the right margin / 80 char indicator. They always used to follow the color of that, they still do. For all else, it would be cool to make the listbox multi-select = but that's a lot more work Anyway, thanks for the feedback, it goes into collected thought, until I decide to do something about it Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] How to compile lazarus from its SVN source in WinXP?
Leslie Kaye wrote: Popeye Spinach wrote: I have checked out latest lazarus from SVN using TortoiseSVN. I have also downloaded FPC 2.2.2 installer and fpcbuild2.2.2. What then now? I coudn't follow the instructions in http://wiki.lazarus.freepascal.org/Getting_Lazarusi http://wiki.lazarus.freepascal.org/Getting_Lazarusi. The information for compiling under WinXP seems has outdated. Please somebody here tell me how to do that? The idle way is to install a nightly build http://snapshots.lazarus.shikami.org/lazarus/ then SVN on top of your install directory (C:\lazarus ?) Run lazarus.exe then off the menu use Tools | Configure build Lazarus | Clean up and build all A bit cleaner (IMHO) Install a snapshot, with the desired FPC version, copy the fpc to a separate location. (Update the fpc.cfg file in the bin directory, so it has the new path info) - if you update fpc later, keep your fpc.cfg file Now check out Lazarus from SVN, copy the existing lazarus.exe, into your checkout. - Create a windows-shortcut, and edit the properties. Add a --primary-config-path (or -pcp) to the command line (so it doesn't interfere with any other install, it is much easier to create a new config once, than to sort the mess you get if 2 installations try to use the same config) - Start this lazarus, edit the config to point to your fpc - compile lazarus from the menu, and restart it Whatever you do, make sure you have no spaces in the path. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] update [Re: Code Folding mess and Code Divider feature]
Graeme Geldenhuys wrote: Hi, This relates to the new bug report: http://bugs.freepascal.org/view.php?id=13322 Code Folding seems to have gone way overboard! It simply makes the editor look like a mess at the moment (Lazarus svn trunk revision). What is the end goal of code folding? Maybe is in the middle of the overall goal and I am simply acting to quickly. Either way, I will voice my concerns... In older versions of Lazarus the Code Folding [+] was in logical places. begin..end blocks. Now they appear on Implementation sections, uses classes, procedure/function level, begin..end block of procedure/function, begin..end block of if statements, var blocks etc... You end up with code looking as follows (code folding plusses everywhere)! Configuration has now been added. So you can fine tune which element you like to be able to fold, and which elements you don't. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] About 0013268: SynEdit parses every li ne twice on load or paste (Attn: Flávio)
Flávio Etrusco wrote: On Wed, Mar 4, 2009 at 11:27 AM, Martin Friebe laza...@mfriebe.de wrote: Hi, To take the discussion of the bug tracker. My current intention on this issue would be to solve the additional issues, such as double scan on Paste, or ensuring LoadFromFile only does a single scan for all lines in one go) This would mean the only Problem remaining is: If a user writes his own code, calling Lines.Add (or even Lines.Insert) in a loop. And does so without calling Lines.BeginUpdate before. While I admit that such a behaviour would add a lot of calculation overhead, with the current SynEdit implementation, I would also see it partly as a user error, since other Components also provide BeginUpdate or similar Methods. Still it should be fixed. But other changes could affect it (scan only on demand), and the amount of work, and the risk of breaking thinks are IMHO outweighing the current benefits. So once the above is closed, I would target that as post 1.2 (simply meaning whenever some one has time to do it) Or do you think think this should be handled as a more severe issue? Best Regards Martin Calling BeginUpdate is not enough, they must disable/unset the highlighter to avoid the double parse. BeginUpdate is indeed broken for SynEdit... Good news is, that due to other requirements, the initial request/optimization to store ranges at the end of line has been implemented in SVN. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] About the Trim Spaces Style modes. Which one should be the default mode?
Flávio Etrusco wrote: Btw, I just checked turbo-delphi: It trims on leave line only. ___ I don't have Turbo Delphi, but Delphi 7 and Delphi 2009. My test show that both Delphi 7 and Delphi 2009 use Caret or Edit mode. Since there is a difference between those versions, I commend it to Lazarus Developers. Just the behavior name don't show the whole picture. The problem is Caret or Edit mode in SynEdit has the bug Martin said. Delphi7 worked-around it somehow (maybe saving the current cursor line in a field?) but D2007 has several minor bugs regarding it. Not sure which bug you refer too? (And which Lazarus Revision?) About the names, I am more than happy to accept some better proposals :) Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Easiest way to case strings
Marco van de Voort wrote: On Thu, Mar 26, 2009 at 10:28:50AM +1000, Alexander Klenin wrote: Since string was introduced as built-in scalar type with defined equality, lack of 'case' support can be viewed as a design bug. I don't see string as a scalar type. It is an array or complex type IMHO. True,... anyway, best argument(s) I think I saw for string case so far: 1) Readability. I think it is true, 10 or more lines of IF...ELSE IF ... can obscure readability. I wonder how many of the cases where this happens, actually are truly needed? How many of them could have used a simpler data-type, and how many of them would have wanted are more specialized approach such as LEX? 2) Optimizations: If string-case existed, the compiler could optimize the code, by using hashes or tree like lookup. While that's true, I wonder if that is really a good idea. It would be the first step of embedding LEX/YACC into the language. One may say this is of benefits for beginners, because the need to learn less about other tools; the truth is, discouraging a beginner from learning has no long time benefit. I think if you have large enough string casings and need the speed, you sghould use the tools specially made for this. Just some thoughts from me / Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] About the Trim Spaces Style modes. Which one should be the default mode?
Sayyid Ibnu Husein Al-'Aththÿe2s wrote: With regard to my 0013298 http://bugs.freepascal.org/view.php?id=13298#c26380 report ( http://bugs.freepascal..org/view.php?id=13298#c26380 http://bugs.freepascal.org/view.php?id=13298#c26380 ), this is my comment about the Trim Spaces Style located in the editor options. In my opinion, the Caret or Edit mode should be the default mode although each mode listed there is reasonable/logical to be the default. The reason is merely because of the objective of FPC Lazarus project. FPC is a multiplatform compiler which emulate Delphi, and Lazarus is a multiplatform IDE for FPC. Its consequence is that default behaviours of Lazarus editor should follow Delphi editor whenever possible, especially in basic functionalities. In fact, almost FPC/Lazarus users are either former or still Delphi users; and I tend to presume that at least a half of them (including me) are lazy in finding out and memorizing the default behaviour differences between those two editors. What do you think, guys? I have updated the wiki http://wiki.lazarus.freepascal.org/IDE_Window:_Editor_Options#Trim_trailing_spaces and put some explanations in what other issues there are with trimming http://wiki.lazarus.freepascal.org/AboutTrimTrailingSpaces (especially tabs, which previously did not work) Some previous discussion can be found here: http://www.lazarus.freepascal.org/pipermail/lazarus/2008-October/020466.html In general whatever expectation is made to Trimming spaces, have a thought about how it would work in a meaningful way with: - tabs (See wiki and previous discussion) they work, an exception was made for the all new position only mode added today ( this includes auto-indent, if it is set to copy tabs) - Caret Past EOL: trim trailing spaces works independent of this. (the new Position only mode, allows the caret to go Past EOL (even if the option is off). But it only does so using tab or space key. Since there have been various discussions by now, it crystallizes that there are 2 main groups of users: 1) People who do not use/need tabs, and don't want to see any trailing spaces (not even temporarily) 2) People who want to use tabs. And therefore have a need to have them temporarily added On 2: See the wiki about this behaviour. I think as long as they are present (until they get trimmed) they should affect all (caret; end; backspace and of course text typed behind them). Making (within the same settings) some parts of Synedit obey those temporary spaces/tabs and others not, does not seem a good idea to me. For the 2nd group all of the modes that were available worked. For the first group I have re-implemented the position only mode. (which attempts to be as close to the original mode as possible (but will convert tabs to spaces)) * As for the default. * Since indeed a few people got irritated by the temporarily inserted spaces, I have set it to leave or edit line. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] About the Trim Spaces Style modes. Which one should be the default mode?
Sayyid Ibnu Husein Al-'Aththÿe2s wrote: With regard to my 0013298 http://bugs.freepascal.org/view.php?id=13298#c26380 report ( http://bugs.freepascal..org/view.php?id=13298#c26380 http://bugs.freepascal.org/view.php?id=13298#c26380 ), this is my comment about the Trim Spaces Style located in the editor options. In my opinion, the Caret or Edit mode should be the default mode although each mode listed there is reasonable/logical to be the default. The reason is merely because of the objective of FPC Lazarus project. FPC is a multiplatform compiler which emulate Delphi, and Lazarus is a multiplatform IDE for FPC. Its consequence is that default behaviours of Lazarus editor should follow Delphi editor whenever possible, especially in basic functionalities. In fact, almost FPC/Lazarus users are either former or still Delphi users; and I tend to presume that at least a half of them (including me) are lazy in finding out and memorizing the default behaviour differences between those two editors. Btw, I just checked turbo-delphi: It trims on leave line only. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] codetools trying to keep track of renamed procedures
Codetools has a feature, that tries to keep track of renamed or altered declaration of procedures. If you change the name of a procedure inside the object declaration, and then press code-completion = Codetools will see the old method in the implementation.. It will detect that the old method no longer has a declaration, and assume it must have been renamed. It changes the old implementation to match the new declaration type TA = Class public //Procedure bar(a: Integer); procedure foo; virtual; end; implementation procedure TA.bar(a: Integer); begin end; In this example TA.bar will be updated to TA.foo. It would be create if it was possible to disable this feature. (I'll bring it up for discussion here, before filing a feature request) Personally I think this doubles the refactor/rename identifier tool. And I had several occasions where this feature did more harm than use. For example when I extract parts of a class, into another class, I have to remove a lot of methods and introduce some new ones. (For the new ones I use code-completion) Without this function, if I forget the body of an old/removed method, the compiler gives a warning. With it, code tools has renamed the not-deleted-implementation to one of the new methods; and I spend valuable time to find out where that code comes from. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Exception dialog
Michael Van Canneyt wrote: On Mon, 16 Mar 2009, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: Is there a reason why the default exception dialog has a cancel button to kill the application ? An unhandled exception IMO is due to some software bug, which the user cannot cure in any way. That's a very restrictive definition of exception. An exception is a way to stop the normal logic and flow of the program. In a GUI application, you rely on the program's event loop to catch the exception (so it is definitely handled) and to show it to the user. If you don't want it to be shown, use the Abort exception. there is a different between an unhandled exception and an exception An exception is indeed a very valid thing, that can and maybe should occur within many applications. But any exception should have some code, that handles it. And this handling code should not be the build-in Lazarus-exception dialog. Because the build-in dialog does not know what the exception meant and what should be done. It could not clean-up, it could not make sure that any memory allocated and referred only by local variables is freed. So an *unhanded* exception is a software bugs. an unhandled exception in most languages will simply crash the application. The fact that a Lazarus app does ask the user, if he wants to try and continue (and maybe be able to save his work) is a benefit. But never the less ending up there is a bug. The user doesn't know if he hit an exception for which the programmer intended to fall back on the build-in dialog (and therefore that the app will still run stable); or if this was an exception the programmer did not foresee, and the app will no be unstable, more exceptions may happen, data be corrupted. In a GUI application, you rely on the program's event loop Well, in my very personal opinion: This is just a bad design idea. If I throw an exception, I write a handler for it. Best regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Exception dialog
Michael Van Canneyt wrote: If a component throws an exception outside any call from your code (which you can place in a try except end), a place like OnDataReceived which is triggered automatically, then this component has a bug (IMHO). The component *should* have something like an OnError event on which it can call your code. Or it should have a flag/state, on which it said that an error occurred. An Exception may be, if an OnError event is provided, but not assigned. Why ? In the OnValidate event of a TField, you are supposed to throw an exception to stop the user from entering wrong data in the field. This exception can only be caught by the program event loop. This is so by design, and the recommended way by Borland. I have to admit, I have limited knowledge of the exact details of the data-aware components, and rather was making a general case about my perception of proper exception use. I just googled = can you point me to some documentation on it? Following you description, I have no problem if an OnValidate allows the code to use an exception to signal the component some-error state. IMHO the component should have a well defined behaviour on getting this exception. and IMHO the component should then handle it instead of passing it on (that may require the exception to be of a defined class, so the component knows that the exception is meant for the component) I wonder what the benefit of passing such an exception to the main-loop is? If I want to do anything else (anything except signalling the component / anything like informing the user): It would be far easier to do this where I detect the problem (in the OnValidate Method). Example: different TField.OnValidate may point do different onValidate handlers. each knows what to tell the user, and which options to present to the user. - If they throw an Exception to stop the Component from writing to the DB = fine - If they throw an exception, to have the mainloop handling the user-error = that would mean, they have to pack all the information required for error handling into the exception? Why bother, if you can handle the exception locally? There would be a benefit, if you want to handle exceptions from various OnValidate handlers in one place. Then you could use an exception-class that is not caught by the component. BUT then it was your decision that the exception should go to the main class. It would not be a default Anyway, the point is, if we are looking at the original source of the discussion (the build-in exception dialog) = that is at best the most limited case of handling an exception (It is simply displaying it). It does not check any need for cleanup, or other actions, or user-help .. So then you would want to use Application.OnException or similar. The point with the build in dialog is. that even for Exceptions that have otherwise been handled (like try/finally) and that only need to be displayed. This should be done by your own code, or the Exception should in some other way be marked as handled, display needed only. Otherwise if you relay on the build-in dialog to do this work for you, you mix up 2 crucially different cases: 1) The just described display-only exception = which wants an OK button only 2) Any exception that occurs, that was not expected, and eaves the application potentially unstable. = Which should warn the user, to save his work, and quit the app asap. And that should display a terminate app now button ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Exception dialog
Graeme Geldenhuys wrote: Please note, I don't use db-aware components, but here follows the help from Kylix 3. On Tue, Mar 17, 2009 at 3:46 PM, Martin Friebe laza...@mfriebe.de wrote: I have to admit, I have limited knowledge of the exact details of the data-aware components, and rather was making a general case about my perception of proper exception use. I just googled = can you point me to some documentation on it? Following you description, I have no problem if an OnValidate allows the code to use an exception to signal the component some-error state. IMHO the component should have a well defined behaviour on getting this exception. ==[ Kylix 3 help ] OnValidate event (TField) - Occurs just before the data is written to the record buffer. . To reject the current value of the field from the OnValidate event handler, raise an exception. Then to me the Delphi/Kylix implementation is flawed. Because it forces me to do TWO things, even if I want to do only one of them. There should be: - an ExceptionClass TDataValitaionException (or whatever) which can be used to abort writing the data, but not defer error handling to the mainloop - any other exception, that aborts the write, and transfers error handling to the main loop There are usages for both scenarios, so they should both be possible. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Code Folding mess and Code Divider feature
Graeme Geldenhuys wrote: Hi, This relates to the new bug report: http://bugs.freepascal.org/view.php?id=13322 Code Folding seems to have gone way overboard! It simply makes the editor look like a mess at the moment (Lazarus svn trunk revision). What is the end goal of code folding? Maybe is in the middle of the overall goal and I am simply acting to quickly. Either way, I will voice my concerns... There is a general plan/idea to add some configuration (have to see how much) to define what you want to have foldable and what not. It wasn't seen as urgent yet (at least not by me...) Most (if not all) of the places that allow folding now, do so in Delphi as well. this is part of why they have been added, to make it easier for (ex-) Delphi users. IMHO most of the new ones are reasonable? - Except maybe for: Program / Unit and Implementation / interface; but they don't occur very often in a normal unit. - Maybe discussable are var Canost type blocks? Think is they can be very useful for bigger var sections (but I agree they can be irritating with just on line in it) - Folding at class / private / public = IMHO should be ok? - Folding at procedure in addition to the begin = arguable, if it should be instead of the begin? Will be interested to see, if other people will voice opinions, which of the new foldings they like, which not In older versions of Lazarus the Code Folding [+] was in logical places. begin..end blocks. Now they appear on Implementation sections, uses classes, procedure/function level, begin..end block of procedure/function, begin..end block of if statements, var blocks etc... You end up with code looking as follows (code folding plusses everywhere)! . At the moment it is more like trying to spot a line of code that doesn't have a [+] in the gutter!! This is just causing clutter and not actually adding any value as far as I can see. Especially now that the code folding lines and +/- signs are inside the editor code area and not the gutter area. OK, so we all know synedit now supports code You can change this: The gutter divider line is moveable, and the code fold background color adjustable. Only the code-folding is now on the right side of the gutter (towards the text) rather than the left, as it used to be. Enviroment=options=editor=display= gutter separator index Enviroment=options=editor=color= code folding tree (3rd in box) folding, but we don't need it on every line. Maybe Lazarus should have a Code Folding verbosity level going from 'Normal Code Folding' to 'Insane Code Folding'. This brings me to another point. Initially the Code Folding was not as verbose, so I tied the Draw Code Divider feature into the Code Folding feature. But now that Code Folding is so verbose it now makes no more sense and seems to get broken quite often. Maybe the draw code divider should become a separate feature and not tied into the code folding. The idea of draw code divider was simply to draw a horizontal line at the end of each procedure or method (like visual basic 6 did). I have no interest in drawing horizontal divider lines wherever code folding can occur. And with the current verbose level of code folding and horizontal lines (if they work) you will actually struggle to see your code between the whole mess. That can be looked at / I can see the benefit of such a feature. Not sure where it gets broken? Are the pictures from different versions of lazarus? or are they with different settings? If you want then at begin/end level you need to set the divider draw level higher = the down side is, there will be additional dividers. This may not be the effect you desire, but it is the effect intended. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Code Folding mess and Code Divider feature
Graeme Geldenhuys wrote:
code folding. The idea of draw code divider was simply to draw a
horizontal line at the end of each procedure or method (like visual
basic 6 did). I have no interest in drawing horizontal divider lines
wherever code folding can occur. And with the current verbose level of
That can be looked at / I can see the benefit of such a feature.
Before horizontal line drawing between procedures / functions, I have
seen programmers add spaces to separate methods. Or use comments as
dividers. eg: {---}
Those are all waisted efforts and get in the way of coding and
programs such as 'pasdoc'. The visual effect of synedit drawing the
line (without anything actually being in the source code) is brilliant
and gives a much better look!
I think it will be worth having as a separate feature to code folding.
And at the moment I can only see it being useful between procedures,
functions and methods. I would ignore nested methods for now - it can
be added at a later date if the need arises.
If you set the draw level to 3 or maybe 4, you should get the correct
divider draw levels.
You will have to ignore the dividers drawn at the end of implementation
sections
Not sure where it gets broken? Are the pictures from different versions
of lazarus? or are they with different settings?
Nope, the screenshots in the bug report is all taken using the same
project, settings and Lazarus version. I simply switched tabs and took
screenshots.
so they are all with
Settings:
Code Folding: Enabled
Divider Draw Level: 1
?
In that case the first picture is wrong = with DDL=1 there should be no
line between procedures (it would be at the end of the unit level.)
Not sure if complete:
DDL 1: unit level
DDL 2: implementation/ interface
DDL 3: Procedure implementation / class declaration
since you only switched tabs = did you aybe change config in your
session? maybe the issue was that the config change was not set to all
editors?
If you want then at begin/end level you need to set the divider draw
level higher = the down side is, there will be additional dividers.
This may not be the effect you desire, but it is the effect intended.
I think my original idea or method dividers got lost somewhere. :-) I
only indented the feature to have dividers between procedures,
functions and methods. No nested methods and no other code folding
areas.
try level 3.
Best Regards
Martin
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Code Folding mess and Code Divider feature
Graeme Geldenhuys wrote: In that case the first picture is wrong = with DDL=1 there should be no line between procedures (it would be at the end of the unit level.) Not sure if complete: DDL 1: unit level DDL 2: implementation/ interface DDL 3: Procedure implementation / class declaration ah, nice to actually know what each level means. :-) Maybe that should be place in the options screen instead of just numbers. In a program it differs from a unit, because you do not have the implementation/interface section. Include files may differ again. Those differences were always present, even with the older folding. The level only represents how many nested folds you have Unit: is the top level fold; not nested implementation/ interface: is nested in the unit fold procedures are nested into the implantation fold .. since you only switched tabs = did you aybe change config in your session? maybe the issue was that the config change was not set to all editors? That seems to be the partial cause. Setting the level to 3 gives the most desirable outcome I wanted. But only after I restarted Lazarus, did all the editors update. So there is one bug - not all editors get updated. Ok, I will check this part: proper propagation of config changes, with regards to divider fold level I then played with the levels to see how they differ. After changing the level, i did a Lazarus restart. It seems at Level = 2, I again get the same behaviour as the bug report. Even with a restart. So that seems to be another bug. Are all 3 files units? with unit keyword at the start, and implementation/interface sections if you have an include file, with no unit, no interface / implementation = then procedure is the top level fold (divider level = 1) I will need some feedback to reproduce this. Or if the behaviour is due to differences in the nesting structure, then the bug breaks down into: - propagation (see above) - restore the old behaviour that procedure divider lines, can be drawn independent of the fold-nest level. (they used to be top level, which is why they used to be content independent = that has changed) Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Code Folding mess and Code Divider feature
Stephano wrote: Martin Friebe wrote: There is a general plan/idea to add some configuration (have to see how much) to define what you want to have foldable and what not. It wasn't seen as urgent yet (at least not by me...) Most (if not all) of the places that allow folding now, do so in Delphi as well. this is part of why they have been added, to make it easier for (ex-) Delphi users. Is it possible have folding or more specifically identification for case/end pairs? Not yet. this will at earliest be implemented, when individual folds can be configured. The same applies for repeat/until It may also have to wait fro some more/other refactoring on the folding. The highlighting currently depends on the detection for folding. So it will be a while till that is done. The problem is that there are already units, that take more than one second to parse, and that can behave sluggish if you insert words like begin. So implementing this must be done with care. If you have an idea how to patch this, please feel free to discuss. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] About 0013268: SynEdit parses every li ne twice on load or paste (Attn: Flávio)
Hans-Peter Diettrich wrote: Flávio Etrusco schrieb: Calling BeginUpdate is not enough, they must disable/unset the highlighter to avoid the double parse. I found it sufficient when the highlighter only parses the current line(s) while painting the text. When the highlighter information is reduced to a flag, indicating continuation lines in multi-line comments, this flag can be stored together with the informaton about the line begin in the text (line number table). Then the determination of the line positions can be done by the highlighter/parser base class. Later, when text is displayed, the continuation flag of the current line is passed to the highlighter, so that only the requested line has to be parsed. Things can become more complicated, of course, when e.g. matching pairs (begin-end, parentheses...) shall be highlighted dynamically. The SynHighlighterPas unfortenately needs to keep some state across lines = some of this is needed for folding. You can fold on a procedure, except if it is in: - interface (just the declaration) - type declaration: a = procedure of object There are many many other examples like this This may only be known if you know the state of the previous line(s). Actually in the worst case that can be a 100 lines above, if someone put as many empty, or comment lines in between. Yet I agree, the highlighter shouldn't scan on every change, it should scan only if the info is required = When a line is painted, all unscanned lines to this line must be scanned. That's a different issue from what we currently discuss. But it is also not that simple, because folding relies on highlighting. If the vertical scrollbar is painted, then all folding info down to the end of file is needed (to calculate the amount of actual visible lines). I have ideas how to still reduce scanning, but one step at a time.. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] About 0013268: SynEdit parses every li ne twice on load or paste (Attn: Flávio)
Flávio Etrusco wrote: *If* BeginUpdate works, then the content of my original mail should be applicable To avoid any misunderstanding: *If* / *Once* BeginUpdate works, then you can insert a batch of say 100 lines (with Lines.Add or Lines.Insert). It will scan 101 lines (because yes, 1 line needs to be rescanned) I do not think we need to worry about the performance between 100 or 101 Lines? (Not saying this may not be fixed, but it would have a very low priority post 1.2) If you insert a single line, it will scan 2 Lines. True that is not good neither. But it will still be so fast that no human can tell the difference. So I will fix BeginUpdate, *if* it is broken (and I will try to get that done for 0.9.28) But making the changes according to the original description will be deferred for later (unless a nice clean patch comes along). It may also be that it will become unnecessary due to other changes that may be made in future. Do you think fixing BeginUpdate will improve the Situation enough for now? Best Regards Martin IMO this is pretty good enough, yes. (Not sure it's possible, though) The important thing is to fix the paste performance; I didn't mean to be pedantic with the code ;-) No problem, it is always good to sort out any doubt. From your description your problem may be something different though Do you refer to paste, as done by SynEdit internally (not by externally calling lines.Insert) ? Because the current paste (if you press ctrl-v in the IDE, having 10 lines in the Clipboard) isn't affected by this bug. (I looked at it in the debugger) It is affected by 2 other things: 1) A bug, that paste insert 10 empty lines, sans 10 empty lines, puts the content in, scans the content. - The 10 lines Content a scanned in a single call to ScanFrom = so ScanFrom needs only once to rescan a single known line, and then does 10 lines without any duplication scanning. - The same applies to scanning the 10 empty lines. It is *one* extra call to ScanFrom (which should be avoided) 2) A problem in the design of SynEdit's Ranges If the code you insert has unbalanced keyword pairs (begin without end / (* without *) / sometimes normal ( without ) / ) then each call to ScanFrom (the good one, that scans the content) will always Scan to the very end of file!!! This is because The Ranges, contain info how many open begins there are. If that info changes, then all Ranges to the end of File must be updated (Folding needs this info, too) I do have ideas on how I may be able to improve that, so I haven't verified they will work as expected. = and it will be a lot of work to fix this kind of thing. So that is definitely an item for post 1.2 The best way to experience is MacOSAll.pp ( in the FPC source dir packages\univint\src\MacOSAll.pas) and type on the top of file (outside any comment of course) begin (not the time it takes for the n) :( :( :( The only good news in this is, that I believe the it can be partly improved by refactoring the highlighter itself = I think I can implement a faster Scanning. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] About 0013268: SynEdit parses every li ne twice on load or paste (Attn: Flávio)
Martin Waldenburg wrote: Hans-Peter Diettrich schrieb: I found it sufficient when the highlighter only parses the current line(s) while painting the text. By the original design the highlighter parses only more than one line if the Range is changed by typing. There is no logical reason to change this behavior, folding or not doesn't matter. But a lot of people have been made changes, which never understood nor even have tried to understood how the editor is working. One can only wonder why people are so reluctant to use their brain for what it has been created, thinking. That (AFAIK) is again different from the issue at hand. If you modify a line by inserting text into the line, then the highlighter should scan based on the stored info what the range was at the start of line (*). The Range found after Highligher did scan, is compared with the Range on the next Line, and scanning stops. Some of the highlighting (actually folding) added (by me) needed more complexity. I understood (or believe I did) the existing scheme, but had to break it. As a consequence, at the End of the Range an extra line may have to be checked. The cost on normal operation can be ignored. (No one can type this fast / any code calling functions like this in a loop, should do BeginUpdate) (*) For this it does not matter, if Ranges[LineIndex] is: - the Range as on the Start of this line - the Range as on the end of this line (because if you need the start-range you get it from the previous line) -- The issue at hand was originally described as: The Range at the end of the very last line is not stored. If you add a line below the end of file, you must scan both lines: - the old last line to get the range for the start of the next (new) line - the new line (and actually there is no reason to scan that new line, the result is discarded = yet currently it is scanned) According to the submitter Lines.BeginUpdate doesn't work (I have not verified this). *IF* that is the case the currently the following BeginUpdate for a := 1 to 100 do Lines.Add( x ); EndUpdate would scan each line twice. = It should not. If BeginUpdate works, they are all scanned once in a single go. So in truth the problem at hand is/are: - if BeginUpdate does work or does not work. - Scanning the last line and the discarding the result (see my next mail) Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] About 0013268: SynEdit parses every li ne twice on load or paste (Attn: Flávio)
Martin Waldenburg wrote: Martin Friebe schrieb: Some of the highlighting (actually folding) added (by me) needed more complexity. I doubt, that more complexity is needed. Actually you are right. The problem lies in the folding module. But anyway, even on a low power computer, scanning just one line more will not be noticeable. That is why (until folding gets improved) the ScanFrom does a tiny bit more work. The problem is that some folds end in the previous line;= that means the token indicating the end, is in the line *below* the folds end. Yes it still can (and will) be solved in a better way. But as I said, it shouldn't have an impact. It is still way faster than a person can ever type. Of course I don't know the original, I only looked at it during the past 6 month, and can only comment on the impat changes in that time have made The cost on normal operation can be ignored. A highlighter should be lightning fast even on an underpowered netbook, as it was designed to work fast on far weaker computers.. As far as I can see it still is. And while I can follow the theoretical point of the issue, I don't see a practical case where it would make a difference. Anyway, some parts of this issue are easy to fix (if they are broken at all, which I still haven't checked). Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] About 0013268: SynEdit parses every li ne twice on load or paste (Attn: Flávio)
Martin Waldenburg wrote: Martin Friebe schrieb: It is still way faster than a person can ever type. if one does things more complicated as needed one will also likely introduce more bugs. A few minutes more thinking often saves hours of work, in my experience. Martin You seem to have misread me. There is a diff between doing things more complicated than needed and adding more complex functionality than previous present. (I don't want to go down the road and start arguing which functionality is needed or useful, or ) The fact is, that I choose an implementation that was simpler (in design and implementation), so it had a lower risk of being buggy, and was quicker to implement. But the reason was not that it was simpler to do, the reason was that the propper solution will become easier, once some of the refactoring (next sentence) has been done. It goes against the good principle of do it right or not at all. But SynEdit as it stands for now, has become so far a way from good design, that it will take a long time to change this (I am in the process of trying). I simply decided, that this should not stop me from also adding features. Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] About 0013268: SynEdit parses every li ne twice on load or paste (Attn: Flávio)
Martin Friebe wrote:
Martin Waldenburg wrote:
Martin Friebe schrieb:
It is still way faster than a person can ever type.
if one does things more complicated as needed one will also
likely introduce more bugs.
A few minutes more thinking often saves hours of work,
in my experience.
Martin
You seem to have misread me. There is a diff between doing things
more complicated than needed and adding more complex functionality
than previous present.
(I don't want to go down the road and start arguing which
functionality is needed or useful, or )
The fact is, that I choose an implementation that was simpler (in
design and implementation), so it had a lower risk of being buggy, and
was quicker to implement. But the reason was not that it was simpler
to do, the reason was that the propper solution will become easier,
once some of the refactoring (next sentence) has been done.
It goes against the good principle of do it right or not at all. But
SynEdit as it stands for now, has become so far a way from good
design, that it will take a long time to change this (I am in the
process of trying). I simply decided, that this should not stop me
from also adding features.
Slightly different answer:
I do not only spent minutes, but probably even hours on thinking. Yet I
am aware that I can never explore all tought alone. I can not even
explore a sufficient percentage of the available thought as long as I do
this on my own.
Hence I will always read, and think about any constructive critic.
As for the issue at hand, here are my thought (up till now), and feel
free to add any input, which may improve them.
Currently FoldInfo (referring to available FoldPositions) is stored on
the ranges. (I do not know who introduced it, or if it was right at the
time, nor does it make sense for me now, to try and judge this). If
carefully done FoldInfo could be stored outside the Ranges (on an AVL
tree similar to the one that stores which folds are collapsed). The
highlighter may still be an appropriate place to detect them, Since it
does already do some scanning. (Yet that is an isue of it's own,
deserving it's own thoughts)
- This could reduce the amount of different Ranges, and therefore reduce
the likelihood of having to Scan many lines before getting in Sync with
existing ranges.
- this would also allow for separate FoldTrees for pascal begin/end; for
{$SECTION} user defined (which can overlap); for {$IFDEF}
This hasn't been started yet. I am still thinking about it.
Best Regards
Martin
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] implicit undo (attn Flávio) [Re : Code Structure / SourceEdit and SyneEdit]
Flávio Etrusco wrote: 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. 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. Just read this, I had the same idea, and am in progress with something like this. I needed it to abstract layers of functionality. for example trimming trailing spaces. If it should work as a transparent plugin it needs access to undo/redo. My current approach is: - I separated SynEdit.Lines from the internal textbuffer (so textbuffer has no longer a need to be TStrings based (it still is, because i didn't take the time to change it)) - I add a few basic methods such as InsertText(x,y, substring); DeleteText,(x,y, len) ; BreakLine, JoinLine (maybe InsertNewLine, DeleteEntireLine) [*] - they can deal with undo and redo - In SynEdit all operations can be reduced to the above (and don't care about undo/redo) Since TrailingSpaces is already a wrapper around the TextBuffer, it can simply intercept those methods, and deal with them. The only flaw I still have with this is, that currently all the SynEditText* (wrappers around the actual textbuffer, doing, spaces, tabs, folding) are combining Display and Edit functionality. It would be nice to be able to write a TSynDisplay class first, and inherit the editor from it Best Regards Martin [*] of course insertText could detect newlines, but it adds complexity. It will be simpler if SynEdit keeps control of this level, and InsertText, only operates on the current line ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] About 0013268: SynEdit parses every li ne twice on load or paste (Attn: Flávio)
Hi, To take the discussion of the bug tracker. My current intention on this issue would be to solve the additional issues, such as double scan on Paste, or ensuring LoadFromFile only does a single scan for all lines in one go) This would mean the only Problem remaining is: If a user writes his own code, calling Lines.Add (or even Lines.Insert) in a loop. And does so without calling Lines.BeginUpdate before. While I admit that such a behaviour would add a lot of calculation overhead, with the current SynEdit implementation, I would also see it partly as a user error, since other Components also provide BeginUpdate or similar Methods. Still it should be fixed. But other changes could affect it (scan only on demand), and the amount of work, and the risk of breaking thinks are IMHO outweighing the current benefits. So once the above is closed, I would target that as post 1.2 (simply meaning whenever some one has time to do it) Or do you think think this should be handled as a more severe issue? Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Cannot build lazarus anymore
David B Copeland wrote: How do you fix it? Dave. On Wed, 2009-03-04 at 15:00 +0200, A.J. Venter wrote: on svn revision 18887. Thanks, That fixed it. Ciao A.J. There was an error if you did make all (command line), this was fixed in revision 1 = So just upgrade If you are trying to build from within the IDE (Menu = tools = Build) then look here http://www.lazarus.freepascal.org/pipermail/lazarus/2009-February/023100.html Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] implicit undo (attn Flávio) [Re : Code Structure / SourceEdit and SyneEdit]
Hans-Peter Diettrich wrote: Martin Friebe schrieb: Since TrailingSpaces is already a wrapper around the TextBuffer, it can simply intercept those methods, and deal with them. Such a wrapper IMO disallows to change the trim option at runtime. I'd implement it only in the display code. Synedit has such a wrapper, and it can be configured, or switched off at run time. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] About 0013268: SynEdit parses every li ne twice on load or paste (Attn: Flávio)
Flávio Etrusco wrote: On Wed, Mar 4, 2009 at 11:27 AM, Martin Friebe laza...@mfriebe.de wrote: Hi, To take the discussion of the bug tracker. My current intention on this issue would be to solve the additional issues, such as double scan on Paste, or ensuring LoadFromFile only does a single scan for all lines in one go) This would mean the only Problem remaining is: If a user writes his own code, calling Lines.Add (or even Lines.Insert) in a loop. And does so without calling Lines.BeginUpdate before. While I admit that such a behaviour would add a lot of calculation overhead, with the current SynEdit implementation, I would also see it partly as a user error, since other Components also provide BeginUpdate or similar Methods. Still it should be fixed. But other changes could affect it (scan only on demand), and the amount of work, and the risk of breaking thinks are IMHO outweighing the current benefits. So once the above is closed, I would target that as post 1.2 (simply meaning whenever some one has time to do it) Or do you think think this should be handled as a more severe issue? Best Regards Martin Calling BeginUpdate is not enough, they must disable/unset the highlighter to avoid the double parse. As I said, I need to check, if BeginUpdate currently works(I haven't verified, so I don't know if it does). Until that is done the bug stays as it is. *If* BeginUpdate works, then the content of my original mail should be applicable. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] About 0013268: SynEdit parses every li ne twice on load or paste (Attn: Flávio)
Martin Friebe wrote: Flávio Etrusco wrote: On Wed, Mar 4, 2009 at 11:27 AM, Martin Friebe laza...@mfriebe.de wrote: This would mean the only Problem remaining is: If a user writes his own code, calling Lines.Add (or even Lines.Insert) in a loop. And does so without calling Lines.BeginUpdate before. While I admit that such a behaviour would add a lot of calculation overhead, with the current SynEdit implementation, I would also see it partly as a user error, since other Components also provide BeginUpdate or similar Methods. Still it should be fixed. Calling BeginUpdate is not enough, they must disable/unset the highlighter to avoid the double parse. As I said, I need to check, if BeginUpdate currently works(I haven't verified, so I don't know if it does). Until that is done the bug stays as it is. *If* BeginUpdate works, then the content of my original mail should be applicable. To avoid any misunderstanding: *If* / *Once* BeginUpdate works, then you can insert a batch of say 100 lines (with Lines.Add or Lines.Insert). It will scan 101 lines (because yes, 1 line needs to be rescanned) I do not think we need to worry about the performance between 100 or 101 Lines? (Not saying this may not be fixed, but it would have a very low priority post 1.2) If you insert a single line, it will scan 2 Lines. True that is not good neither. But it will still be so fast that no human can tell the difference. So I will fix BeginUpdate, *if* it is broken (and I will try to get that done for 0.9.28) But making the changes according to the original description will be deferred for later (unless a nice clean patch comes along). It may also be that it will become unnecessary due to other changes that may be made in future. Do you think fixing BeginUpdate will improve the Situation enough for now? Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] To all SVN-followers = incompatible change
Any one who uses SVN, you may encounter a problem if updating to Version 18829 or above. This applies if: - you build Lazarus from within the IDE - have the new SynEdit-design package installed The make bigide should not be effected. Here is how to solve the issue: - Uninstall SynEdit-design *before* upgrading (it has been merged into SynEdit) If you have already upgraded you can also do this at the end. - You can build Lazarus via make bigide OR - Inside the IDE: check make clean build only LCL, Package-Registration, IDE-Interface UNcheck make clean build the remaining package (make sure you do not clean or rebuild the packages you have build above) restart the ide now you can uninstall SynEdit-design This is because the build-order has changed (you will notice this, once you restarted the IDE) -- sorry for the trouble Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] GUI frontend to a console application
Graeme Geldenhuys wrote: Hi, This is probably more related to unix systems... Has anybody got a small sample application, some documentation or is a sample included in Lazarus that shows how to go about writing a GUI frontend to a console application? While it isn't a small example. The IDE itself contains such code wrapping gdb. debugger\cmdlinedebugger.pp It will be similar (probably easier) if the command line app is *not* interactive. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Hans-Peter Diettrich wrote: Martin Friebe schrieb: The effect is boring, even if I only navigate through the source code with the cursor keys :-( This bit sounds like a problem with painting the window. Moving the cursor should not require much repaint. And after startup it works fine, so that I suspect a problem with the information collected over time. yes and no: - vertical moves do repaint the gutter always, in case that the every nth line number is used. - Any caret move that goes across a word boundary triggers the highlight-current-word (but it only set the timer, and only if you wait it does a search in the source), unless you checked disable timer (but this feature has only been added in 2009, hence my question) - If you hit a bracket, there is a quick search for the matching one. and if you are on a begin or end there is a search for the matching word (but if you are not on a begin or similar, this should not affect you). Otherwise: it is true that moving the caret should cost no time. And I can't see where it would relay on anything that could amount over time. I'll keep it in the back of my head, in case I see anything. Maybe I find some time to but some time measuring in. You remember my suggestion, to use an line-cache in the SynEdit component? Such a cache allows to bypass the block folding and other possibly time consuming actions, while only navigating through an file without editing. Still having plans for that. (I also need to start working on a better data-model, for multi view stuff / since you progress on the docking :) ) Yet the current implementation of folding is very quick, and the risk to run out of memory, rather than CPU-time exists too. I think the problem that is bigger than such a cache is mem management. SynEdit keeps allocating/deallocating a lot = that leads to fragments in the fpc mem-mgmt = and that could cause a slow down.. Which OS / Widgetset are you using? Windows 32 bit. Hm, Windows should be the most efficient. GTK has a lot of code to the in grid drawing of the chars. Windows does it natively. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Hans-Peter Diettrich wrote: Martin Friebe schrieb: Moving the cursor should not require much repaint. And after startup it works fine, so that I suspect a problem with the information collected over time. yes and no: - vertical moves do repaint the gutter always, in case that the every nth line number is used. Okay, but it would be sufficient to repaint only the old and new line's numbers. Which is what it does, just 2 line numbers. - Any caret move that goes across a word boundary triggers the highlight-current-word (but it only set the timer, and only if you wait it does a search in the source), unless you checked disable timer (but this feature has only been added in 2009, hence my question) - If you hit a bracket, there is a quick search for the matching one. and if you are on a begin or end there is a search for the matching word (but if you are not on a begin or similar, this should not affect you). I think that I should disable all that eye-candy. Let me know, if any of that makes a diff. I think the problem that is bigger than such a cache is mem management. SynEdit keeps allocating/deallocating a lot = that leads to fragments in the fpc mem-mgmt = and that could cause a slow down.. Maybe, yes. DoDi ___ 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] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Hans-Peter Diettrich wrote: Martin Waldenburg schrieb: - Memory management. SynEdit uses a TStrings attempt (IMHO a gaped-buffer would be more efficient). that's some kind of an urban legend. But anyway I could cry aloud looking at what mwEdit became. Nobody seems to know anymore how to write efficient code. Martin Hi Martin, you're still around? :-) yea. You're right, the LCL became utterly bloated, without a good (discussed and documented) concept. But fortunately it doesn't contain assembler code :-) Efficiency is not normally required in a GUI, the current machines have enough power for themes, transparent windows, and more. But the behaviour of LazSynEdit actually feels a bit like the initial RAD-Studio editor, which also tended to slow down, until a freeze. Check the mem consummation, and swapping (page faults) when it slows. The think is, even if no memory is needed, if it indeed is fragmented, then a lot of the allocate mem may be unusable small, and more be allocated. This also would mean that data that should be together may be located across several pages, forcing more swapping. there are some settings in fpc, top affect the mem mgmt . not sure Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Hans-Peter Diettrich wrote: Graeme Geldenhuys schrieb: I can not work efficiently with Lazarus, due to two problems with the editor (LazSynEdit): it can become dead slow, needing seconds of computation for a single key stroke, and it doesn't support multiple edit windows. This is why I want to contribute to these issues, starting with a working docking manager for multiple edit and explorer windows. Where exactly do you experience those speed issues? If you use GTK1 or 2 you should use a font that is monospaces, and exists in this size for bold and italic too. (And you must not use ExtraCharSpacing). Otherwise there may be a slow down in painting. Yet this can not be compared to other Editors, unless they allow the usage of proportional fonts too, and they too force those into a grid. If it turns out that the slowdown is in code tools, no matter which editor it will be slow (maybe http://bugs.freepascal.org/view.php?id=13039 ?) Is it slow, with none pascal files too? However there is one known problem in SynEdit. The highlighter (turn it off, and see if thinks get faster). The good part is, it does have potential to be improved. Also it should rarely matter. It only happens, if you enter a word that opens, or closes a new fold block (like begin) For me it is not noticeable on 1 Lines file like SynEdit.pp. I can notice it on a 300k Lines file, if I go all to the top, and type begin. There is a delay of a bit over a second, if I press the n. The rest of the typing is not slowed down. If you have any other examples of slowness, please let me know. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Hans-Peter Diettrich wrote: Martin Friebe schrieb: If you use GTK1 or 2 you should use a font that is monospaces, and exists in this size for bold and italic too. (And you must not use ExtraCharSpacing). Otherwise there may be a slow down in painting. Yet this can not be compared to other Editors, unless they allow the usage of proportional fonts too, and they too force those into a grid. The effect is not related to any settings, after startup the editor works fast. It may depend on the number of applied changes or jumps across files or bookmarks, or on the number of symbols in the units, i.e. size of the according (history) lists. If it builds up over time, I am a bit clueless. 2 things I can thing off: - Codetools (but that should not affect scrolling), but Codetools can collect more and more info, using more memory. (AFAIK) - Memory management. SynEdit uses a TStrings attempt (IMHO a gaped-buffer would be more efficient). So it may re allocate a lot of Memory. That could upset the memory management. Both are *not* very likely candidates... You can try to reduce the amount of undo steps. Or compile with/withou heaptrc (leak checker) = some people reported that other apps gained speed *with* heaptrc. (But I don't really think it's memory mgmt) The effect is boring, even if I only navigate through the source code with the cursor keys :-( This bit sounds like a problem with painting the window. Which OS / Widgetset are you using? You have not mentioned anything, so I just verify, it is nothing that has become worse since 0.9.26 (or within 2009) ? Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] some workarounds [Re: Debugger problems]
Graeme Geldenhuys wrote: On Sat, Feb 21, 2009 at 12:49 AM, Hans-Peter Diettrich drdiettri...@aol.com wrote: In most cases I cannot inspect local variables, due to no such symbol in context errors, even with fully disabled optimizations. This is exactly the errors I get. I develop under Linux only, so it doesn't seem to be a platform issue. I gave up trying the integrated debugger and simply use Log(..) or Writeln(...) calls now It is true that there are cases where GDB does not find Symbols, until this can be fixed in a better way, here are a few cases and workarounds 1) properties This is apparently the most common case? GDB has no concept of properties. Also properties can refer to functions. Possible workarounds: a) if a property refers to a Variable, use CodeTools to find the variable name, and expect the Variable. Usually property abc, will point to variable Fabc b) if the property refers to a method, there is no workaround, since currently you can not force GDB to execute any method. Executing the Method could also change the state of the debugged application. 2) Nested Procedures GDB does only see the current stack frame. Procedure SomeObject.ABC var x: integer; Procedure Nested begin end begin end While in Nested gdb can NOT see anything that belongs to ABC. (this is it can not see x, and it can not see self (the object), or any variable on the object) Possible Workaround: Open the Stack Window, and change the current frame. I know this is a bit dull, because you have to change it after each execution step. 2a) The same applies to hints in the source window. *Variables* will only show if the stackframe is correct 3) Sometimes Variables are pointers in GDB, where they are not in Pascal. if you type SomeObject as a watch it may just say TSomeClass 0x23ab76 = try typing SomeObject^ 4) Dynamic arrays See the following post for a workaround (again it is too complex for every day use, but it may help for desperate occasions) http://forum.lazarus.freepascal.org/index.php/topic,4763.msg22954.html#msg22954 ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugger problems
Hans-Peter Diettrich wrote: Marc Weustink schrieb: tooltip on identifiers don't work, Always, unless used on properties. In that case I use the Evaluation dialog to inspect the membervar. Sorry, Graeme is right :-( In most cases I cannot inspect local variables, due to no such symbol in context errors, even with fully disabled optimizations. Is this a platform issue? (I'm primarily using Windows) Check my other post, in case you have nested procedures, check the stackframe Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Problem using the SVN program: source files mutilated
Bart wrote: Hi, I'm experiencing a problem using SVN. When I have written patches for Lazarus, then do an svn update (after the patches have been committed), the sourcefiles that I have altered are not updated correctly. For instance. I recently made changes to lcl\include\dbedit.inc These changes have been committed. Today I did an svn update. In lcl\include\dbedit.inc SVN has inserted lines like: .mine procedure TDBEdit.KeyPress(var Key: char); function CanAcceptKey: boolean; (^^ this line above is also inserted) (And yes, this is exactly the procedure I changed) To make sure I understood correctly: You write a patch, submit it (mantis or otherwise), some one else is adding the patch to SVN. Then you download upgrade you source (containing the patch to the version of SVN that contains the (same) patch committed by that some one else? Then it will depend: If the commit to SVN was 100% identical (probably including spaces, white char, newline) SVN should recognize this, and silently merge it. But, if whoever committed it to SVN did make changes (spaces?) then merging may fail resulting in the above. Because the code you have differs from the code in SVN and the SVN software does not know which version you like to keep. If you have no other changes in your file, you can simply revert it. Now of course make fails on that line. I'm using the commandline SVN (not the tortoisesvn windows client) on Win9x. F:\LazarusProjectensvn --version svn, version 1.4.3 (r23084) compiled Jan 18 2007, 07:47:40 Copyright (C) 2000-2006 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). I have done a svn cleanup, but that made no difference. Has anyone any idea why this happens, and how I can cure this? Bart ___ 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] Define Symbols in SynEdit
saeka wrote:
Hello, developers.
SynEdit.pp source code has a lot of 'SYN_MBCSSUPPORT','SYN_LAZARUS'.
It seems to be SynEdit was compiled by defines SYN_MBCSSUPPORT originaly
but now, that is undefined by SYN_LAZARUS. (in SynEdit.inc)
SYN_MBCSSUPPORT is defined by supporting MultiByteCharacterSystem on
FarEastAsian Windows, but MBCS is not equal to UNICODE.
Now, SynEdit in Lazarus is working at UNICODE, ( Its very nice for us.)
and SynEdit in Lazarus is highly customized for Lazarus and FreePascal.
I have created patch on released version 0.9.16-0.9.24 to Japanese Community
in which enabling SYN_MBCSSUPPORT.
(http://sourceforge.jp/projects/freepascaljp/releases/?package_id=5278)
Now, that is not smart way after 0.9.26, I think.
In Unicode, no additional defines needed in handling character.
How about delete symbols, and delete IFDEF codings , if it will not be
used in the future ?
(SYN_MBCSSUPPORT, SYN_LAZARUS, and defines about delphi version)
That has to be decided on a case by case base. (per symbol).
A start has been made, and some of the {$IFDEF SYNLAZARUS} have been
removed. More to follow. It is done while work is in progress. Removing
all at once has a higher risk of accidental removing the wrong block
(especially with ifNdef), and sometime those still compile, and bugs
would be introduced.
For other ifdef it has to be seen, how badly broken the alternative code
is, and if it is easy to support it or better to trash it. There seems
no need to rush. Only issue is that if you search for reference to some
method, it returns matches in the dead code too.
For making modifications or providing patches, you only need to look at
supporting the SYNLAZARUS version. You can completely ignore the none
SYNLAZARUS code. As far as I am aware much of it does not compile anyway.
You should keep IFDEFs that relate to the compiler used, such as
{$IFDEF f...@{$endif}methodname. Also keep IFDEFs for compiler
versions. Some of those may have lack of testing, but their presence
will make fixing easier, if bugs a reported by people using older/other
versions of fpc/delphi.
As for 0.9.26 and Japanese (or any other Language). The primary support
is and will be on UTF8.
- UTF8 support for wide char display has just been fixed, and as of now
can be build from SVN. As of tomorrow 12th Feb it will be in the daily
snapshot too.
- Support for MBCS is currently not maintained. If you wish to keep it,
patches will be welcome.
Best Regards
Martin
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] new editor feature in Lazarus SVN
Ah, good... I need to update the trailing spaces section too. and the indent section, dmitry boyarintsev wrote: Martin, I've copy-pasted your email to the wiki: http://wiki.lazarus.freepascal.org/IDE_Window:_Editor_Options imho, it's necessary to add Default Lazarus like settings and Delphi 7 like settings for the editor, just like Paul added for the object inspector :) Thanks, Dmitry ___ 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] new editor feature in Lazarus SVN
I know SyncEdit, and got it on my list, for now it's display only. In order to do SyncEdit, SynEdit will need to get a concept of different States (at the moment this is handled by SourceEditor for things like incremental search). This will also be useful for templates, that can automatically invoke SyncEdit: for i := low([]) to high([]) do = when you start editing the low[] placeholder, the same text appears in the high placeholder. Martin Graeme Geldenhuys wrote: On Mon, Feb 2, 2009 at 10:53 AM, Paul Ishenin i...@kmiac.ru wrote: It can be used to highlight your identifiers. Martin will probably explain more if you will ask further. Ah, I thought it might be the start to something like SyncEdit - similar to what the post-Delphi7 IDE's include. See the following page for a SyncEdit demo. http://dn.codegear.com/article/34323 Thanks for the info though. I'll play with the settings. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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] C++ syntax highlighting not working
you are righjt, I also found where it was introduced. I will fix it tonight. In the meantime Synedit.pp ;line 3309 if (FFoldedLinesView.Ranges[CurLine] = nil) then begin DrawHiLightMarkupToken(nil, PChar(Pointer(sLine)), Length(sLine)); end You may simply remove the surrounding if condition Lord Satan wrote: As the subject says. See Environment-Options-Editor-Colors. Set Language to C++ and no highlighting at all (the same is true for Python, Unix Shell Script, PHP, Perl, SQL), but only for C++ I know that it used to work. Just wanted to verify that it is not only my problem before filing a bug report. Ubuntu 8.10 64-Bit, Laz svn version 18505, fpc 2.3.1 ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Error building last SVN
Should be fixed in SVN now. Sorry the Example wasn't updated before. Andrea Mauri wrote: I got the same error, both on win xp and ubuntu 8.04. fpc 2.2.2 lazarus svn. Lazarus rebuilds properly if example are excluded from rebuilding. andrea Guadagnini David ha scritto: An error appeare building last SVN (18393) into the IDE on Windows XP Pro (service pack 2) with FPC 2.2.2 The error is: C:\lazarus\examples\edittest.pp(83,12) Error: identifier idents no member GutterPartVisibleByClass C:\lazarus\examples\edittest.pp(111) Fatal: There were 1 errors compiling module, stopping Note: no error if I use MAKE CLEAN ALL into DOS prompt David ___ 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] Where to place definition of a record?
Howard Page-Clark wrote: On Sun, 25 Jan 2009 00:22:09 +0200 Dave Coventry dgcoven...@gmail.com wrote: type TNameValueRecord = record private FNames: array of string; FTypes: array of string; function GetCount: integer; inline; ... end; Delphi 2006 introduced new Pascal syntax - the possibility that records can contain methods and properties in addition to the data fields records have always had. This makes such 'advanced records' a sort of pseudo-class construct. FreePascal/Lazarus does not support this language extension. try type foo = Object a : integer; Procedure b; end; ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] is it me or a bug that i ve been fighting?
waldo kitty wrote: Martin Friebe wrote: but a couple of thinks that come to mind: 1) What version of FPC are you using (you only said you updated Lazarus); you refer to FPC 2.2.2, have you tried the fixes branch (2.2.3)? or trunc(2.3.1)? i'm using whatever comes with lazarus... i started with laz 0.9.26 and then completely removed it to install 0.9.27 because i found that some config settings are evidently hardcoded or shared in a/the registry when a dual install of 0.9.27 still had some things pointing to the old 0.9.26 stuffs :? :( On the daily snapshot page, you get a windows build with fpc 2.2.2 and another one with 2.2.3 (eq fixes branch of fpc) lookup -pcp (--primar-config-path) Lazarus does what a windows app should do, it stores setting in you users home director (depends on windows version) Then if you installed Lazarus (incl fpc) in one directory = do not rename the directory; otherwise you must update you fpc.cfg file (windows search to locate) If you have multiply installations, you may have to go to environment-options, and adapt the path to fpc (once you use -pcp) and that might be another bug or something where one can't install laz 0.9.26 to one directory and 0.9.27 to another and have each come out of the box without sharing any config settings or something... i dunno, as i'm still trying to come to grips with the whole GUI interface and drop this here and that there to create a hello world! GUI app that's 10Meg (tongue in cheek!) in size compared to a textmode version that's only 2K ;) :lol: use strip to get rid of the symbols (or compiler options dialog, unclick all the debug info) But leave it in while looking for a bug 2) You say you do not know the exact error: because the popup box doesn't state it = Try running the exe in the debugger, make sure you compile with debug symbols for gdb (-g, maybe also -gl). i've not changed any settings from the defaults on install... i have, a few times, run some stuff directly from the GUI in the debugger but even with 256Meg of RAM in this box, it gets a bit on the tight side at times which is why i switched over to simply building the apps and then shutting down laz and running the built code outside on its own... maybe that wasn't/isn't such a good idea? why not, but it doesn't help debugging (unless you do gdb by hand) ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] is it me or a bug that i ve been fighting?
waldo kitty wrote: Martin Friebe wrote: 2) You say you do not know the exact error: because the popup box doesn't state it = Try running the exe in the debugger, make sure you compile with debug symbols for gdb (-g, maybe also -gl). just following up on this (as my other reply hasn't srrived back from the list yet) but i have just attempted to, with laz 0.9.27 fpc 2.2.3, run my app from the laz gui via F9... i got a box stating Project raised exception class 'External SIGSEGV' at which point i could only click on the [OK] button in that box... then it appeared that my box was locked up but it took a minute or so and another box appeared titled Assembly with what appeared to be a list of addresses but i farkled things up by attempting to scroll the box to see what may have been listed and i lost the starting point that it gave me... Yes the assembly window, ignore that (and yes if you close it to early, it does mind that sometimes) Open view-debug-stack window (alt-ctrl-s) That will show you where in the Lazarus code the exception happened. Problem: Likely it is in the fpc part, which will be useless numbers. Or even in the mysql library. Anyway, unless you are willing to spent time on debugging the issue your self, and go into the depth of the Connector code, this will probably be of little help. If you get the stack backtrace you can mail it and hope some one knows about... . ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Few features for Lazarus editor
ik wrote:
Hello,
There are few features that I would like to see in the Lazarus editor:
1. Multiple spliting (and close the split) the editor to horizontal
and vertical views
2. VIM keyboard support
3. Ability to have a way to fold code by using comments with special
chars (like (* {{{ *) (* }}} ) that VIM allows)
4. Multi linguistal spell checkers for strings and comments
5. Color code with errors with special underline or some color that
the user can select that will help to locate where the problem is.
6. Ability to keep the string mark (that added to 0.9.27) as permanent
with a toggle of a menu item/key/toolbar
If you talk about the highlight of the current-word-under-caret: try ALT-M
or configure your keyboard, it's in the section with the selection-commands
7. Inline help for a command/reserve word that the mouse
cursor/keyboard caret are under that word (not instead of the
tooltip).
8. When pressing on CTRL above a file/variable/type etc.. that we are
trying to load, it will place a tooltip telling what is going to be
opened (the file + the line number)
What do you think on this features ? Should I add them to mantis as a
wishlist ?
Thanks,
Ido
___
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] Passing an array to a function
Not sure, but I would try something like FS.ReadBuffer(fsbuffer[0],recordsize); The function is declared as ReadBuffer(var Buffer; So in reality a pointer to the variable is passed to the function. Your dyn-array is already a pointer. You are passing in a pointer to the internal pointer, and not to the bytes you allocated. Martin Dave Coventry wrote: I have a function that I'm trying to pass an array to. function FieldValueAsString(fsbuffer: array of Byte; fitype,fisize: integer): string; Calling the function: setlength(fsbuffer,recordsize); FS:=TFileStream.Create(fname, fmshareDenyWrite); FS.Seek(seekpos,soFromBeginning); FS.ReadBuffer(fsbuffer,recordsize); dfstring:= FieldValueAsString(fsbuffer,fitype,fisize); Generates the error Project raised exception class SIGSEGV ___ 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] Few features for Lazarus editor
On 0.9.27, if you activate a new feature, and you stand on a string, it marks all of the matching strings in the same file. It can be very helpful if I could fixate such string when I'm looking at the code and moving to see where the string in my context appears without the need to use search. It also works with the block selection. And they key to toggle it is Alt-M (configurable in the options) more options under Automatic Features in the option dialog ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Saving user created component structure to LFM file
Thierry Coq wrote: Dear Martin, In Delphi, I frequently used the mecanism you described, but I had to use the root WriteComponentRes procedure, not the WriteComponent one, which is only available for subcomponents. I did not use TCollection, which is capable of writing components (too complex for my usage). What I did do, was create container classes with TComponent as Parent. By default, TComponent stores all children. The root component must also give a name to each component, or the storage will not work. The end result is the capability to store a hierarchy of objects in a consistent manner. You should look for WriteComponentResFile in classes.inc and see how this work, with a few tries. Hope this helps, Thierry Thanks, I think I found a better way. The outer container has no nested components of it's own. It seems I can hook into (override) TComponent.WriteState which is calling WriteComponentData (properties, then Children). Since no children are there, I can make my own calls to WriteComponent from there, supplying all the components, of all the helper objects. On Read, I can Hook into ReadState. I can let the reader add them normally, and sort them out/once they have been read by the reader. The remaining question is: Does that look like something that will stay compatible with future code? The generated LFM file definitely looks like any LFM file (it has a component, with properties first then other nested Components) Thanks Martin Martin Friebe wrote: Hi, I have a problem saving a certain component struicture to an LFM (lazarus) file and read it back. since a good amount of code is in FPC, I am not sure which list to go to? There is classes/writer.inc with has TBinaryObjectWriter. This is where things go first. Then, later this gets translated into text. This translation seems to be stricter in terms of what can be nested. Anyway the problem is, that if I want to save a component (that can be of different class/classes) then I can use WriteComponent. But only if I am in a Component that is itself written with WriteComponent. In the final LFM it seems a Component can only be nested in an other component. It does not seem to be possible to put it in: - Not in a subcomponent (because a subcomponent does not write it's class, but just the properties that are visible for the class given by the property property Foo: TPanel read .. write ... writes Foo.Name = 'abc' Foo.Top = 1 ... - Not in a TCollection, or at least I havent managed. Also again a TCollection is restricted to one classs for all Items - Not Using DefineProperties All propwerties with define property are of the kind Name = Value I can add a list, but even inside the list I can not write a component What I want to archive is theFollowing. I have TMainComponent = class (foo) property Options : TPersitentBar read x write x; end If It has to be it can be a TComponent, with SubComponent in TComponentStyle. Problem 1) Options is always created in the constructor, it can not be stored as a nested Component in the LFM. If it was, it would exist twice (once created in the constructor, and once loaded from the lfm) TPersitentBar should have a list of components, variable number, and different subclasses (could inherit from TPersistent, only Component if it makes it easier) How can I get this list saved into the lfm? Each item has a diff class, and diff properties, so they must saved via WriteComponent. (Which does not work for DefineProerties) And of course a default list of items is created in the constructor, so I need to detect if they are loaded, and remove the defaults. Any Idea? Example of the final structure (if only it was valid) object MainComp1 : TMainComponent Options.AllowFoo = 1 Options.AllowABC = 2 object Options.SubOptionsForCars : TCarOptions MAxCar = 4 end object Options.SubOptionsForTrains : TTrainOptions MAxTrain = 1 end end Best Regards Martin ___ 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] Saving user created component structure to LFM file
Mattias Gaertner wrote: [...] Thanks, I think I found a better way. The outer container has no nested components of it's own. It seems I can hook into (override) TComponent.WriteState which is calling WriteComponentData (properties, then Children). Since no children are there, I can make my own calls to WriteComponent from there, supplying all the components, of all the helper objects. On Read, I can Hook into ReadState. I can let the reader add them normally, and sort them out/once they have been read by the reader. The remaining question is: Does that look like something that will stay compatible with future code? The generated LFM file definitely looks like any LFM file (it has a component, with properties first then other nested Components) To store a property that is a component and which is not owned by the Lookuproot (form, datamodule, frame) you must set the csSubComponent flag in ComponentStyle. yes, I found the csSubComponent. But it stores the only the properties of the SubComponent, not the Component's Class. SubComponent does (Within the list of properties of the actual component): MySubCompProp.Value1 = 120 MySubCompProp.Foo = 'abc' And also subcomps, look (correctly) at the definition of the property. It the Property is defined as TFoo ( property mySubCompProp: TFoo reads FMyFoo write FMyFoo; , then all properties known by this class (TFoo) are stored. In My case the actual Object may be a descend and of TFoo (that is the objects stored in FMyFoo), and have additional Properties (This additional Properties would be lost) My Components are in a TList, the have different classes, so I need to save them the same way like nested components: object MySubCompFromListClassABC: TSubCompClassABC Value1 = 120 end; The Real Background is SynEdits Gutter. The Gutter, I have managed to get saved. (via csSubComponent). But then the Gutter has a list of GutterParts (all of them Objects (and I can/will make them Components)). I need to save all those GutterParts. [ I know, I will also need a Property Editor for the object inspector, but that's not the issue ] If A Gutter is created, with a new SynEdit, and *not* loaded from LFM; then it creates a default set. If it is loaded, it needs to remove the default set (can be done in ReadState of SynEdit (SynEdit can inform the gutter) / Can depend on The LCL Version, so loading a 0.9.26 form, will keep the defaults, as no saved parts can exist) To store a list use TCollection. If you can not use TCollection please explain why not. Because All collection Items a of the same class. If I make that TGutterPartBase, then only properties exposed by TGutterPartBase are saved. but each GutterPart has additional published properties. (Same applies, if I make the CollectionItem a wrapper class with a property property TheRealGutterPart: TGutterPartBase = because as csSubComponen it does not save the class-info) Also even If I manage to get this subclasses into the collection (which is hard enough, as it is not supposed to be), If the collection is loaded, it restores them all to the base class, because it never saved the class-info To store data of arbitrary length/format, use DefineProperties. This has a drawback: In case of an error the IDE can not help fixing it. DefineProperties only takes simple values. Because in define properties I must give it the name. Then In Read/WriteProc I deal with the value. So define Property will always create an LFM entry like: MyDefinedPropertyName = xxx xxx Comes from the writecallback. If the write callback attempts to do WriteComponent, then this will fail later, when the binary format is translated into text-lfm-format (because MyDefinedPropertyName = MyObject: TMyClass is not allowed That is even, if the WriteCallback starts a list first, it will still fail. MyDefinedPropertyName = ( MyObject: TMyClass With DefineProperties I have 2 (undesirable) possibilities: 1) use DefineBinarryProperties = and write my own format, no one can edit it, and why invent the wheel again? 2) use DefineProperties and define a large set of properties: - define a classname property for each of my objects - and define a property for each value that each of my objects needs to store. Again there is code (WriteComponent) that does streaming of objects including class info; why invent the wheel again? --- So as I see it I found 2 possibilities 1) The GutterParts are created as components owned by the SynEdit (or does it have to be the form; if it does have to be the form then there will be issues if there is more than one synedit ). that will be a lot of easy to break maintenance work. because you need to search through the component list to find the Objects. And when loading I still need to remove the Objects created in Synedit.Create or I get double entries. - Also I tried it,
Re: [Lazarus] Saving user created component structure to LFM file
Leonardo M. Ramé wrote: In Delphi you have to explicitly set the subcomponent: Example: constructor TMyComponent.create begin ... FSubComponent := TSubComponent.Create(Self); ... FSubComponent.SetSubComponent(True); ... end; Same here, just yopu can modify the flag directly: include(ComponentStyle, csSubComponent); But that only streams the properties, and does assume a specific class. It doesn't work for Anything that can change it;'s class. In fact in Lazarus you can skip this, IF the property has write access. There are 2 conditons that will save the valuse of a Class-property 1) property is TPersistend or descendant, and has both read and write access (write can end up in assign) 2) property is TComponent or descendant, and has csSubComponent (in this case it does not need a write access method) Martin Friebe escribió: Mattias Gaertner wrote: [...] Thanks, I think I found a better way. The outer container has no nested components of it's own. It seems I can hook into (override) TComponent.WriteState which is calling WriteComponentData (properties, then Children). Since no children are there, I can make my own calls to WriteComponent from there, supplying all the components, of all the helper objects. On Read, I can Hook into ReadState. I can let the reader add them normally, and sort them out/once they have been read by the reader. The remaining question is: Does that look like something that will stay compatible with future code? The generated LFM file definitely looks like any LFM file (it has a component, with properties first then other nested Components) To store a property that is a component and which is not owned by the Lookuproot (form, datamodule, frame) you must set the csSubComponent flag in ComponentStyle. yes, I found the csSubComponent. But it stores the only the properties of the SubComponent, not the Component's Class. SubComponent does (Within the list of properties of the actual component): MySubCompProp.Value1 = 120 MySubCompProp.Foo = 'abc' And also subcomps, look (correctly) at the definition of the property. It the Property is defined as TFoo ( property mySubCompProp: TFoo reads FMyFoo write FMyFoo; , then all properties known by this class (TFoo) are stored. In My case the actual Object may be a descend and of TFoo (that is the objects stored in FMyFoo), and have additional Properties (This additional Properties would be lost) My Components are in a TList, the have different classes, so I need to save them the same way like nested components: object MySubCompFromListClassABC: TSubCompClassABC Value1 = 120 end; The Real Background is SynEdits Gutter. The Gutter, I have managed to get saved. (via csSubComponent). But then the Gutter has a list of GutterParts (all of them Objects (and I can/will make them Components)). I need to save all those GutterParts. [ I know, I will also need a Property Editor for the object inspector, but that's not the issue ] If A Gutter is created, with a new SynEdit, and *not* loaded from LFM; then it creates a default set. If it is loaded, it needs to remove the default set (can be done in ReadState of SynEdit (SynEdit can inform the gutter) / Can depend on The LCL Version, so loading a 0.9.26 form, will keep the defaults, as no saved parts can exist) To store a list use TCollection. If you can not use TCollection please explain why not. Because All collection Items a of the same class. If I make that TGutterPartBase, then only properties exposed by TGutterPartBase are saved. but each GutterPart has additional published properties. (Same applies, if I make the CollectionItem a wrapper class with a property property TheRealGutterPart: TGutterPartBase = because as csSubComponen it does not save the class-info) Also even If I manage to get this subclasses into the collection (which is hard enough, as it is not supposed to be), If the collection is loaded, it restores them all to the base class, because it never saved the class-info To store data of arbitrary length/format, use DefineProperties. This has a drawback: In case of an error the IDE can not help fixing it. DefineProperties only takes simple values. Because in define properties I must give it the name. Then In Read/WriteProc I deal with the value. So define Property will always create an LFM entry like: MyDefinedPropertyName = xxx xxx Comes from the writecallback. If the write callback attempts to do WriteComponent, then this will fail later, when the binary format is translated into text-lfm-format (because MyDefinedPropertyName = MyObject: TMyClass is not allowed That is even, if the WriteCallback starts a list first, it will still fail. MyDefinedPropertyName = ( MyObject: TMyClass
Re: [Lazarus] Saving user created component structure to LFM file
So as I see it I found 2 possibilities 1) The GutterParts are created as components owned by the SynEdit (or does it have to be the form; if it does have to be the form then there will be issues if there is more than one synedit ). that will be a lot of easy to break maintenance work. because you need to search through the component list to find the Objects. And when loading I still need to remove the Objects created in Synedit.Create or I get double entries. - Also I tried it, and SynEdit did not seem to stream them (MyGutterPart := TcomponentBasedClass.Create(TheSynEditAsOwner);) = nothing in the lfm 2) Maintain the objects as they are, but use SynEdit.WriteState to append them to the lfm (They can easily be caught, if they get read (by the default reader) during loading There may be a 3rd way. Inside TWriter.WriteChildren is a call to TComponent.GetChildren(RefToWriteComponetn, RootComponnet) This is used in TControl and TFrame and others to return (one by one, via callback) all the children that should be written. That is probably the best place to go; Only I was/am not sure, if this is used explicitly for the Component serialization? Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Saving user created component structure to LFM file
Hi, I have a problem saving a certain component struicture to an LFM (lazarus) file and read it back. since a good amount of code is in FPC, I am not sure which list to go to? There is classes/writer.inc with has TBinaryObjectWriter. This is where things go first. Then, later this gets translated into text. This translation seems to be stricter in terms of what can be nested. Anyway the problem is, that if I want to save a component (that can be of different class/classes) then I can use WriteComponent. But only if I am in a Component that is itself written with WriteComponent. In the final LFM it seems a Component can only be nested in an other component. It does not seem to be possible to put it in: - Not in a subcomponent (because a subcomponent does not write it's class, but just the properties that are visible for the class given by the property property Foo: TPanel read .. write ... writes Foo.Name = 'abc' Foo.Top = 1 ... - Not in a TCollection, or at least I havent managed. Also again a TCollection is restricted to one classs for all Items - Not Using DefineProperties All propwerties with define property are of the kind Name = Value I can add a list, but even inside the list I can not write a component What I want to archive is theFollowing. I have TMainComponent = class (foo) property Options : TPersitentBar read x write x; end If It has to be it can be a TComponent, with SubComponent in TComponentStyle. Problem 1) Options is always created in the constructor, it can not be stored as a nested Component in the LFM. If it was, it would exist twice (once created in the constructor, and once loaded from the lfm) TPersitentBar should have a list of components, variable number, and different subclasses (could inherit from TPersistent, only Component if it makes it easier) How can I get this list saved into the lfm? Each item has a diff class, and diff properties, so they must saved via WriteComponent. (Which does not work for DefineProerties) And of course a default list of items is created in the constructor, so I need to detect if they are loaded, and remove the defaults. Any Idea? Example of the final structure (if only it was valid) object MainComp1 : TMainComponent Options.AllowFoo = 1 Options.AllowABC = 2 object Options.SubOptionsForCars : TCarOptions MAxCar = 4 end object Options.SubOptionsForTrains : TTrainOptions MAxTrain = 1 end end Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Loading an integer into a byte array
Bernd Mueller wrote: Dave Coventry wrote: I have a file into which I want to put a long integer: 00 00 19 7A The file expects the value in the form: buffer[0]:=122; buffer[1]:=25; buffer[2]:=0; buffer[3]:=0; I am then intending to write this buffer to the file FS.Writebuffer(buffer,4); Is there a way of loading the buffer directly before writing? You could use the Absolute directive to map a longint variable to your buffer. Not pretty, but fast ;-) procedure LoadBuffer; var Buffer: Array[0..127] of Byte; l: Longint Absolute Buffer; begin l:= 6522; end; Or you can use pointer operation. Someting like type PLongint = ^Longint; PLongint(@Buffer[0])^ = 6522; But be aware: Neither this nor Bernd's way are portable. The order of byte will depend on the architecture your application runs on. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus have sizer or layout objects?
Vincent Snijders wrote: 2009/1/7 David W Noon david.w.n...@ntlworld.com: Hi, Some C++ class libraries have object classes that automatically resize widgets when a form is resized by the user. For example, wxWidgets calls them sizers, and Qt calls them layouts. I have perused the LCL documentation and have found nothing that quite meets the bill. I tried a TPanel object, but it did not have anywhere near that functionality; in fact, it seemed to do very little. So, as the subject line says, does Lazarus have such classes? No, there are no such classes. A control has anchors, and a number of a controls can autosize (i.e. adjust size accoding to their contents). For anchoring, see wiki: http://wiki.lazarus.freepascal.org/IDE_Window:_Anchor_Editor and http://wiki.lazarus.freepascal.org/Anchor_Sides Forms/Panels... also have ChildSizing, which comes close to a grid-layout Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] pointer to int/other 32/64 bit?
Hi I know there are issues becuse on 64 bity systems pointer are 8 byte. And I know there is PTRInt / PTRUInt. An integer of the correct size. But how much casting is needed? if I have an integer, word, or byte do I need to go via PTRInt? That is if I know the data is only 4 or less bytes. So what happens if I do SomeInt = Pointer(foo); Will that compile on 64 bit, or do I need SomeInt = PTRInt(Pointer(foo)); In both case the data must be truncated, so the question is not will it work (the data is small enough). the question is will it compile. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] test
just a test ___ 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)]
In some places below, I am unsure what you meant by component: - the view (as in MVC) - the overall editor (as in SynEdit) Hans-Peter Diettrich wrote: Martin Friebe schrieb: Model shall contain - the raw text - bookmarks, and other marks - foldable secitions - ... Other information can be local to a specific Component (in case multiply component display the same model in more than one window). An example would be which sections are folded. This info may or may not be part of the model Right. We should start with the persistent information, stored together with the text on disk, then add all information that is common to all (multiple) Views. Serializing the Model for storage purposes (such as saving to a file or many files) for me comes after the decision how the model looks. There may be more than one way to serialize the model. As there are many ways to use SynEdit. - In Lazarus it is used a SourceEditor, so serializing should write the Text information into one file, and other information into another file. - In User Applications, people may wish to serialize the model into just one file (which can not be edited by other editors) We could differ between a public and a private model. (Probably not needed) Most probably not needed in this form, default is the public Model. Actually we may need. Example folding. Having the same model displayed in many Windows, the user may want to fold different nodes in each Window. Or even use different highlighters, leading to different nodes being available. The design of this must leave the choice to the user, which information is hold in the public, and which in the private model. The private Model can store the same info as the public. The private model only stores info the user whises to be different from the public model, all other info will be forwarded. However concerning the design of the other Classes (Controller/View), the differentation between private or public model is not relevant. They access one Model. This Model knows what to do. Folding has to be reflected in a component, both as a structure (block tree in the gutter) and as currently visible lines (for the text painter), so that a helper object/class is appropriate for retrieving all the information in an synchronized way. Then one instance can reside in the Model, holding the shared definition of the blocks, and another instance can be part of the Views, doing individual folding - that's only a matter of how a new View is initialized. Ack View.Folding := Model.Folding; //object reference if FoldingPerView then begin PrivateFolding := TFoldingState.Create(View.Folding); View.Folding := PrivateFolding; end; [This is what you would consider as pushing another item on the stack, see below] My implementation probably looks slightly different. There will be no dedicated properties (on the View) for dedicated features. View.Model := TheModel; Then the View can internally distribute this. The Model can be a Private Model, which acts as a wrapper to the public Model. This way it is easier to add features, without the need to change the way the view is set up. In this terms if you wish to implement new feature (which are not covered by the set of existing properties), an component that inherits from the original is the most likely way. This inherited component can either implement the features itself, or create additional ( or substitute existing) helper classes to archive the new functionality Isn't LazSynEdit such a customized version of a SynEdit? yes and no. SynLazarus is a fork off, of an early Synedit. Not done by inheritance. But in the following I would like to look at the details of a Component that provides the following functionality (and can be used by any editor, Memo or anything else): A component that has: - a Model (was: RawSource) property - For ease of access an extended TStrings interface can be assumed (this simplifies the case, as it already implements the text to be organized into lines) ACK. UTF-8 encoding, I suppose? Access should be routed through the folding object. For SynEdit in Lazarus, currently UTF8. Ideally most of the code should be agnostic to the encoding, and the remainder exchangeable. The design of the Classes involved most not be based on an encoding. (except maybe the design of the model) - A Tab is a normal character that does has no information about it's later display properties. - Highlighting information is not part of the model. (Displaying the same model in 2 windows can be done with different Highlighters selected) - Markup (such as the selected block, if any) is not part of the model - This Text has information where it can be folded, but is *not* yet folded or wrapped Wordwrap should be implemented in the component, because it depends on the width of the window. Folding should
[Lazarus] The Data-Model for SynEdit / The Data Model for Lazarus [Code Structure / SourceEdit and SyneEdit]
Currently SynEdit handles a lot of different DataSources. Such as: - The raw text - Bookmark - folded/unfolded nodes - ... All of this should be collected into a single access point (Model). Such a Model could then be shared between 2 or more SynEdits (to view the same data, in more than one window). - For the Viewing in different Windows there may be a need for individual SynEdits to have privatized parts of the public/shared Model. Such as different nodes may be folded. - The public/shareable model would have to be ref-counted. Or explicit ownership would need to be assigned and the owner would need to keep track of all Shareholders. - The Model can be serialized. Special classes would to this work. Therefore a model can be saved to one file, or to a set of files Those are just a few points to start looking at design details for such a model. So far this only concerns SynEdit. But for Lazarus a benefit could be, that such a model could also contain data, on top of the information hold for synEdit. The Lfm (FormDesigner) info could become part of this. The it would only need an appropriate serialize class to save all of them. This may simplify the current implementation (even so I admit much based on assumption on fragmented knowledge) which has to retrieve this info from the various components. (the need for the source-editor or main ide to fetch the text from SynEdit) The Model could also carry callback lists, so the anybody who needs to know that it was loaded or saved could register a callback Model.AddOnSerailizedCallback( AMethod ) AMethod may be called with the reason, why serialization took place (e.g saved to file) Just starting some basic thought on it. It will be a very long way, and a very long time before any of this goes into implementation. Best regards Martin In some places below, I am unsure what you meant by component: - the view (as in MVC) - the overall editor (as in SynEdit) Hans-Peter Diettrich wrote: Martin Friebe schrieb: Model shall contain - the raw text - bookmarks, and other marks - foldable secitions - ... Other information can be local to a specific Component (in case multiply component display the same model in more than one window). An example would be which sections are folded. This info may or may not be part of the model Right. We should start with the persistent information, stored together with the text on disk, then add all information that is common to all (multiple) Views. Serializing the Model for storage purposes (such as saving to a file or many files) for me comes after the decision how the model looks. There may be more than one way to serialize the model. As there are many ways to use SynEdit. - In Lazarus it is used a SourceEditor, so serializing should write the Text information into one file, and other information into another file. - In User Applications, people may wish to serialize the model into just one file (which can not be edited by other editors) We could differ between a public and a private model. (Probably not needed) Most probably not needed in this form, default is the public Model. Actually we may need. Example folding. Having the same model displayed in many Windows, the user may want to fold different nodes in each Window. Or even use different highlighters, leading to different nodes being available. The design of this must leave the choice to the user, which information is hold in the public, and which in the private model. The private Model can store the same info as the public. The private model only stores info the user whises to be different from the public model, all other info will be forwarded. However concerning the design of the other Classes (Controller/View), the differentation between private or public model is not relevant. They access one Model. This Model knows what to do. [.] ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] The Data-Model for SynEdit / The Data Model for Lazarus [Code Structure / SourceEdit and SyneEdit]
Mattias Gärtner wrote: Zitat von Martin Friebe laza...@mfriebe.de: [...] But for Lazarus a benefit could be, that such a model could also contain data, on top of the information hold for synEdit. The Lfm (FormDesigner) info could become part of this. What has synedit to do with the form designer? I'm not sure how synedit should handle the unit concept. The lfm is associated with the unit. A unit has a starting file (e.g. unit1.pas) and an arbitrary list of include files, plus the po file of the project/package, the fpdoc xml file and .res files. Each of them work together and need very different code. The other way round. Synedit has no interest in the other structures. But the IDE may have an interest in a structure holding the combined data. As I said, I have not looked at how this is currently handled. Or if there is a common DataStructure for a pascal Unit. I will inform my self (by reading up the source) when I have the time. There was a discussion between you and Paul on the dev-list: doable except one thing. I dont know where to hook before unit save event. We just dont have it. Moreover unit save is not that plain as one can expect. At least I expected sourceeditor have something like Save method. No, because the source editor is only one part of the IDE, so a save must be handled one level higher saving is not as plain as one can expect the Ide will or should have some structure holding the combined data. But at current it appears it has to go down to code-tools and/or SynEdit (or SynEdit via code-tools) to get the actual Text. Synedits Data holding structure could either be more integrated into that IDE structure (if that is there, I will look for it later). Or It could be subclassed, extended and used for a higher purpose than just SynEdit. I will have to look at the current structures to see if that makes any sense at all. I just threw it in as an Idea, seeing if I get some feedback. The it would only need an appropriate serialize class to save all of them. This may simplify the current implementation (even so I admit much based on assumption on fragmented knowledge) which has to retrieve this info from the various components. (the need for the source-editor or main ide to fetch the text from SynEdit) synedit is the 'lines' view of the sources. Most of the lazarus code don't work with lines, but with whole files or absolute positions. So what if SynEdit could have a model (An object exposing it's data) in both ways? This is not a proposal to throw over all the working code. This is first to see which directions make sense inside SynEdit, and maybe SourceEditor at some stage. Once that has developed into a more modular form, and gained the ability to provide that functionality, it can be reviewed, if any other code could benefit from it. Best regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] The Data-Model for SynEdit / The Data Model for Lazarus [Code Structure / SourceEdit and SyneEdit]
Hans-Peter Diettrich wrote: Martin Friebe schrieb: - The public/shareable model would have to be ref-counted. Or explicit ownership would need to be assigned and the owner would need to keep track of all Shareholders. The latter. The model must know about all views, to be notified of changes. This suggests a viewer chain, as used e.g. for Windows clipboard viewers. That are 2 different things. Explicit Owner or ref-counting, both was about creation, and destruction of the model. You are talking about notification on changes. Each Synedit that uses the model becomes an observer of it. For this it can either enter itself on a list of known observers, or leave a callback reference (a reference to an object-method technically contains the reference to the object). Notifying all observers will then be easy. It can be decided, if the Model should detect changes and trigger the notifications (after EndUpdate), or if the current Actor on the Model retrieves the List and sends the Notifications. - The Model can be serialized. Special classes would to this work. Therefore a model can be saved to one file, or to a set of files A separation in multiple classes is dangerous, because changes to the model (number or type of values) had to be reflected in all related classes, in every project using that model. IMHO an addition to the model does not need to be reflected in all Classes dealing with it. Take the idea where you can build your SynEdit with different plugins from the Component palette. You build two SynEdits that should display the same Model. One of the SynEdits is build with folding the other one is not. - The one that is not will simply ignore the Folding Data in the model. That will be no problem at all. - The model will allow to register additional sub-models such as folding. therefore the Synedit with the folding will have no issue working with this model. It will simply create the sub-model (if not existent) and register it. The it would only need an appropriate serialize class to save all of them. Or an accordingly overwritten virtual method. I prefer an extra class. It will be more flexible The Model could also carry callback lists, so the anybody who needs to know that it was loaded or saved could register a callback Model.AddOnSerailizedCallback( AMethod ) The beforementioned list of view(er)s. When actions shall be monitored, then an implementation in the controller seems to make more sense to me. Sorry not exactly sure if I follow? an implementation in the controller? An implementation of what? To make sure I am speaking of notifications between multiply SynEdits. Not between parts within one SynEdit. - so the list of Callbacks must be on the model, as it is to be shared. - the action of triggering the sending of the notifications? (happy to have it in the controller, but not seeing a problem with having them triggered by the model in some cases) - the implementation of what happens as reaction to the notification? Yes that needs to be in the cotroller Best Regards Martin ___ 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)]
Hans-Peter Diettrich wrote: Martin Friebe schrieb: Maybe for clarifications. I started this using the word "view". But I can see there are 2 ways to read this word. - "physical view": Like a painter. The final output of the combined text/style information. Most common drawing it to a canvas. But it could be a reader too. - "logical view": (I guess what you called the grid?). A module that takes the raw-text, and converts it into a structure suitable for the "physical view", applying style/highlight info on the way. In the model-view-controller context, the view is the logical aspect. Best to always specify the context (logical / physical ). The painter is no separate itme in MVC, so it resides within the "View" too. You also pointed out correctly (at the end of the mail) that TextBuffer/lineBuffer/SourceText/etc are inappropriate names. (Unfortunately I came to read this after I wrote most of my response) I will revise my text to use Model instead. In cases were I overlooked the old term, please assume it as a reference to Model. Model shall contain - the raw text - bookmarks, and other marks - foldable secitions - ... Other information can be local to a specific Component (in case multiply component display the same model in more than one window). An example would be which sections are folded. This info may or may not be part of the model Information like the (logical) caret position are specific to each Component. This information is not part of the model. We could differ between a public and a private model. (Probably not needed) Let me add another clarification: My primary viewpoint is that of an component writer, designing components for general use, i.e. not bound to a specific application or context, unless specific to the functionality of the component itself. Consequently my CharGrid is a general component, whose use in Lazarus may deserve extensions to the general functionality. The basic component has certain capabilities, and a specific implementation. Take it both as a general model, and a specific implementation as a proof of the concept. This should apply to both (your grid and LazSynEdit). To the user it will present itself as one whole component. It should not expose it's inner structure. In the case where it is implemented using a structure of internal classes, it will act as Facade and have a single interface. In this terms if you wish to implement new feature (which are not covered by the set of existing properties), an component that inherits from the original is the most likely way. This inherited component can either implement the features itself, or create additional ( or substitute existing) helper classes to archive the new functionality The original class could also expose some of it helper classes (in the same way that a data aware class depends on a data-provider), and allow the end user to provide a class with the desired functionality. This I believe can be discussed in implementation details. Now we can discuss in general, *whether* it's possible to achive the Lazarus-specific functionality, based on the given component design. This was my context in the preceding discussion. I wanted to prove that my approach is suitable for that specific use, and find out where the implementation may deserve a redesign. The result only can be go/nogo. Let's try to stick to the abstracts in this part. We may open a new subthread to this mail and discuss implementation details in parallel. I would also try to stick to the "display/presentation" part of the discussion here. For the edit part a new sub thread may be created? So the below will concern itself with the View of the MVC I do use the word "view" to describe the logical-view of a source-file transformed into a grid. I do not use the word "view" to describe the painter. ( I propose "physical view") I do not use the word "view" to describe the high level dual visibility of the same source-file in 2 windows (or a splitted window) ( I propose "user view" ?? imho a weak description, not good) When it comes to implementation details, like painting, then I'd prefer "component" for the overall (TLazEdit or TCharGrid) component. That component can consist of, or use, dedicated sub-components, wich we should address as text and gutter painters, syntax highlighters etc. We roughly look at a component (I call it TextDrawer to avoid confusion with the word View), that will cover the following functionality: - access to a model - logical presentation of this model (folding, tabs, grid) - painter (gutter, text area, possible others) I believe we can leave details such as scrollbars for a higher level? This could be done using a decorator. [.] [ discussion about double-display-width and multi-code-point chars ] Le
Re: [Lazarus] Code Structure / SourceEdit and SyneEdit [Re: Mouse Link in SynEdit (only link-able items)]
There are several meanings by the word view I have tried to put some clarification into this. Having finished this mail, I thought I copy 2 fragments up here to the top. If they are not clear in itself, please read on first. And let us find a common approach to name those things Maybe for clarifications. I started this using the word view. But I can see there are 2 ways to read this word. - physical view: Like a painter. The final output of the combined text/style information. Most common drawing it to a canvas. But it could be a reader too. - logical view: (I guess what you called the grid?). A module that takes the raw-text, and converts it into a structure suitable for the physical view, applying style/highlight info on the way. I do use the word view to describe the logical-view of a source-file transformed into a grid. I do not use the word view to describe the painter. ( I propose physical view) I do not use the word view to describe the high level dual visibility of the same source-file in 2 windows (or a splitted window) ( I propose user view ?? imho a weak description, not good) Some of the answers where given before I understood that view in your text sometimes refers to multi window display. I tried to amend them in a 2nd run through my answer. I hope I didn't miss any. If my answers do not seem to match your text, I probably read view in a different way from what you meant Hans-Peter Diettrich wrote: Martin Friebe schrieb: Then how to you handle double width chars? This si one of the problems I still have to address. Even in a proportional font, some chars (Chinese, and other) have twice the width of a normal char. They will 2 positions in the grid. Actually it is the same issue as tabs. Are these characters inside the Unicode BMP? Yes, and there are quite a few Lazarus users waiting for a solution. In utf16 they occupy 1 code point ( they are encoded in a single 16 bit word), but need display twice the display width. Actually it seems they are called full width, while all others (like western chars) are called half width. Full Unicode requires assistance by some sophisticated library, that can deal with all the oddities of character sequences (ligatures...), and True, and so far we only talk about the display, it also needs to be edited. Anyway there is much other work before I get there, so I think I defer the details on this part. Column Blocks, as well as horizontal caret movement have to deal with this anyway, since you may allow to be in the middle of a tab. But you can not permit to have the caret in the middle of a chinese char. No problem, my tabs have a special display encoding, that forces the caret to move to the next ordinary character cell. Is it really still a column block, when a double-width character hangs out on it's right boundary? Well it is the users option (with tabs) to either have ragged column blocks, or cut tabs into spaces or With Chinese (and I believe Arabic, and a few other language) there are no options (the char can not be cut). The question still is how do your painters to all that. IMHO the mapping into a grid requires a lot of info (folded/ word wrapped/ tabs,...) as well as highlighting info. The painter as I see it collects all this info, but the info is provided by other objects. Right, I left the implementation of the highlighters and folding to dedicated objects. The classes have to implement only the very slim interface of the base class, everything else is open end. Right that sounds similar to my plans. The folded info is stored in a FoldTree (well at the moment it is split, and some is still stored on the raw-text-lines, work in progress) The mapping is done in FoldedView. From all I read the difference is, that I put a viewer-class into a stack. You seem to have this in your grid-class, or a specialized inherited grid-class. Probably both approaches have their benefits. In order to compare them we would have to deeply analyse both of them. BTW, I stored characteristic info in fixed size records, which can easily saved and exchanged together with the source file or the global settings. No encapsulation, but easy to use, and little chances for coding errors. You are speaking of the highlighting info? Maybe easiest to give a usecase or example? Also when you say characteristic, do you mean: the details of the characteristics (e.g. numbers are blue or comments are bold), or do you mean whih characteristic apply to a char/group of chars (e.g. format the next 3 chars with the format for numbers). The View port for example does not do the painting, it is a helper class to map the right code into the grid. It is used by the painters, but also used outside. It allows (without accessing the painter) to check if a char or the caret is in the visible area. ( There still is the question
Re: [Lazarus] Code Structure / SourceEdit and SyneEdit [Re: Mouse Link in SynEdit (only link-able items)]
Hans-Peter Diettrich wrote: Martin Friebe schrieb: The only reason I did skip the grid in the name is that a generic painter base class will not define a griod (or maybe it will but based on pixels). So it does not block anyone from implementing a proportional painter Okay, but a proportional representation will have a very different coordinate mapping, so that most of the basic functions (mouse, cursor movements) are very different. My approach addressed exactly those low level tasks, with the CharGrid already being a specialized grid class, with cells containing characters, and added font and text properties. My primary goal was a stable base component, that can be turned into any text viewer or editor, by adding specialized document interfaces in derived classes. For a proportional representation the design will have to be turned upside down, and the base class will have to be specialized and follow the design of the related content handler(s). Then how to you handle double width chars? This si one of the problems I still have to address. Even in a proportional font, some chars (Chinese, and other) have twice the width of a normal char. They will 2 positions in the grid. Actually it is the same issue as tabs. Each char needs to have an info, how many cells it will allocate. Now if that is the case then to display proportional fonts, all I need to to make the grid size 1 pixel. -- I do *not* encourage that. I do not say this is a good thing for a source editor. But given how close SynEdit comes to proportional display anyway, I keep at least an open mind about a structure that would allow to implement it. -- Column Blocks, as well as horizontal caret movement have to deal with this anyway, since you may allow to be in the middle of a tab. But you can not permit to have the caret in the middle of a chinese char. That canvas/handle holder does not replace the (Grid)Painter. It is used by the GridPainter(s), and used by the GutterPainter(s). It may even be thyat it does not need to exist, and canvas and handle can be passed to all the Painters in Form of their LCL classes. Then my CharGrid is kind of a canvas holder, which performs the mapping between document (content) and viewport (painting) space. The painters do not have to know about the organization of the canvas, they only have to paint given information within their actual clipping area (part of a display line). The content holder (source file) can be switched at any time, whereupon the CharGrid adjusts the viewport (window) to the new content extent. The question still is how do your painters to all that. IMHO the mapping into a grid requires a lot of info (folded/ word wrapped/ tabs,...) as well as highlighting info. The painter as I see it collects all this info, but the info is provided by other objects. The View port for example does not do the painting, it is a helper class to map the right code into the grid. It is used by the painters, but also used outside. It allows (without accessing the painter) to check if a char or the caret is in the visible area. ( There still is the question if it will be the painter or the viewport who defines the size of each grid cell (basically the font size)) As It currently stands all the info about everything is hold by the Main SynEdit Class, and all other classes need to ask the central SynEdit Class. That is undesirable. ACK. A MVC (model-view-controller) approach migth be better. The model holds the source files, the view manages painting and user interface (mouse and keyboard), and the controller updates the document upon input or other commands, and synchronizes the related view(s) afterwards. The view IMHO is more than one class, that gradually apply the mapping from a Source-Holder (TStringList) to a char-grid. The Painter then transfers each char to from the grid to the canvas. That is what I am currently trying to do the painter looks at a grid-provider, a grid provider may read either the source or another grid-provider as input. I currently call those grid-provider View. One thing must change, currently the PaintLines code, combines the highlight info with the grid-view result. But that means mapping the highlight info. The highlight info must be applied to the unmodified source, and then share the way through the grid-providers (That's actually something I realized from this discussion = good) So If I display a text that has no tabs, no double width chars, no folds, no , then all I need is: -source-buffer -highlight info (does not re-organize the layout) -viewport-grid -painter The view port grid, selects the correct lines, and within each line the correct substring. So if the text is horizontaly scrolled it cuts the beginning of each line, and in any case, it cuts any line that is to long. There a 2 objects: - The TViewPort = which defines the corner points
Re: [Lazarus] Code Structure / SourceEdit and SyneEdit [Re: Mouse Link in SynEdit (only link-able items)]
Hans-Peter Diettrich wrote: Martin Friebe schrieb: A couple of remarks: -Individual drawer objects fro Gutter and TextArea (I will avoid Grid in the name, Grid is a specialization) The Grid is a hint on the organisation of the canvas, in rectangular cells. I've spent a lot of time in the various coordinate systems and their mapping, for drawing purposes (relative to the window), document view (rows/columns, scrolling, line wrapping), and document storage (folding, tab expansion, UTF encoding). The need for properly anchored bookmarks was a big challenge. Similar, but finally easy to implement, was the preservation of the cursor column, when scrolling across lines of shorter lenght. The only reason I did skip the grid in the name is that a generic painter base class will not define a griod (or maybe it will but based on pixels). So it does not block anyone from implementing a proportional painter This has been started for the Gutter. It does need a lot of clean up still. It would also benefit from the Os-Handle and canvas being moved into a wrapper class. This would: - avoid the need to callback synedit for Invalidates - allow a Handle/Canvas of another Component being passed to SynEdit, and SynEdit painting the other component (e.g. SourceEditor) Here we may have quite different viewpoints, on the delegation of the responsibilities. That canvas/handle holder does not replace the (Grid)Painter. It is used by the GridPainter(s), and used by the GutterPainter(s). It may even be thyat it does not need to exist, and canvas and handle can be passed to all the Painters in Form of their LCL classes. As It currently stands all the info about everything is hold by the Main SynEdit Class, and all other classes need to ask the central SynEdit Class. That is undesirable. I extracted 2 classes already (but the ove isn't complete) - TSynEditCaret: Storing all info about the caret. It will obviously need help from other modules, to deal with tabs, double-width chars, wrapped lines (that will probably be a specialized subclass, completely replacing the original), and other things -TSynEditSelection: To deal with the selected block. This one is not very related to this discussion. But it has the same needs as the Caret I will have to add a TSynEditViewPortClass: This will at least store the Coordinates of the screen in the text (as in TopLine/LeftChar - LinesInWindow/CharWidthOfScreen), maybe a bit more. To do so, it will need access to the Painter to get information about the grid (LineHeight, SingleCharWidth) Similar considerations for the Textarea. However the textdrawer will have to access a lot of other objects, and need ways to merge the result. there are - the highlighter - the MarkUpManager In my solution the highlighting (including hyperlinks) is implemented in derived classes, by overriding the line-painting method. I ended up in a single array, holding the scanner start state for every line - required If I understand your description correct: This special array is currently part of SynEditCodeBuffer? In any case this is information for the highlighter. The (Grid)Drawer should never access this info directly. The grid drawer will ask the highlighter (In the current Synedit there may be a need to clean up the way the Highlighter is handled...) for proper handling of multi-line comments. Hyperlinks are implemented as special highlighting information. When the mouse pointer moves, the according characters and attributes are obtained for the current line, from the document, then the line eventually is repainted when the active state of a hyperlink has changed. For Hyper links, had you have a look at the MarkUp class? (SynEditMarkupCtrlMouseLink in components\synedit\syneditmarkupctrlmouselink.pp; there is stil some remains in central Synedit that need moving) Again this class does not replace the GridDrawer. It is to be used as a helper class by any GridDrawer. I have no information about the internals of you r grid drawer, and how it delegates work and responsibilities, so I can not really comment on it. I don't know how your grid drawer deals with all the different tasks/responsibilities, it has to meet (especially within the LineDrawing Class). You talk a lot of sub classes that implement the individual bits. This may be needed (and probably is at least for WordWrapping). But I believe that the Griddrawer (and it's LineDrawer) should solve a lot by delegate to helper classes? Of course this is easily said. And I haven't yet got the full design for how I will/would do the GridDrawer. - The TextLines itself (e.g. Highlighter token will return a tab as a tab, but the TestLines need to translate this into displayable chars. Either -- spaces -- show special chars (and if tab is only one char, then maybe there is only one followe by spaces? Right, tab expansion
Re: [Lazarus] Mouse Link in SynEdit (only link-able items)
Hans-Peter Diettrich wrote: 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 IMHO the first consideration would be that if you have multiply windows, or split windows allowing more than one source viewed; you must also take care what happens if 2 views, display the same source. Of course restrictions could be put in place to prevent this, but in the end, I guess it wil be wanted, and will have to be done. therefore: 1) Allow 2 SynEdits to be able to share a textbuffer. Then depends, if you display them in one window, or multiply windows. (in the later you need to add managment for the extra windows) 2) you have to find where the actual visual TNoteBook component (with the tabs) is created (either main-ide or SourceNotebook). To clarify SourceNotebook is not a visible component.It is a class that controls the (visible) TNoteBook 3) Make SourceNotebook able to have more than one TNotebook in it's control. 4) Fix all the code using this (things like find active editor, find active notebook-page This is only a brief overview, I havent looked through all requirement yet. Best Regards Martin ___ 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)]
Hans-Peter Diettrich wrote: Martin Friebe schrieb: 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 I've a TCharGrid component, developed in the time when the SynEdit was too instable and unreliable. It handles all cursor moves, scrolling, selecting text (also in columns), tab widths, (syntax) coloring, and also has provisions for both vertical and horizontal gutters. It was intended as a more reliable base for e.g. SynEdit, in general for representing text in a monospaced font, as is convenient for source code. It was developed and tested with Delphi 7, i.e. for Windows, but should be widely platform independent. If somebody is interested in the source code... DoDi Looking at your signature, you are the Author of http://wiki.lazarus.freepascal.org/Redesign_of_the_SynEdit_component ? A couple of remarks: -Individual drawer objects fro Gutter and TextArea (I will avoid Grid in the name, Grid is a specialization) This has been started for the Gutter. It does need a lot of clean up still. It would also benefit from the Os-Handle and canvas being moved into a wrapper class. This would: - avoid the need to callback synedit for Invalidates - allow a Handle/Canvas of another Component being passed to SynEdit, and SynEdit painting the other component (e.g. SourceEditor) Similar considerations for the Textarea. However the textdrawer will have to access a lot of other objects, and need ways to merge the result. there are - the highlighter - the MarkUpManager - The TextLines itself (e.g. Highlighter token will return a tab as a tab, but the TestLines need to translate this into displayable chars. Either -- spaces -- show special chars (and if tab is only one char, then maybe there is only one followe by spaces? This can only be done by the Lines, as they know the layout/tabwidth (see concept of Views/ TabView below) The storage and view of the TextLines: I think TSynEditCodeBuffer is a good start for this. Yet tabs are a specialisation, that should go into a ViewClass. ViewClasses TSynEditStrings themself, that will modify how the stored text is seen. (TrimTrailingSpaces is an example. FoldedView too, so FoldedFiew does not yet fully follow the concept) The following Views (and others) can apply to the text - WordWrapView - FoldView - TabView or ElasticTabView (http://bugs.freepascal.org/view.php?id=9650) modifies Logical(byte) to Phisical (char on screen) calculations. probably still returns tabs, but offers conversation methods. - replacing tabs with spaces in the Strings[] property, may complicate Highlighting and MarkUp and show special chars It would also impact the ability of keeping the caret from being placed in the middle of a tab (which currently can be done) - TrimSpaceView - TSynEditStringBuffer (holding the actual text) 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)
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
[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] 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] 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
[Lazarus] SynEdit patches [Re: TAChart: Request to review/apply patch 12758]
Alexander Klenin wrote: and yet another one for patches to SynEdit (both stalled for about a month now), etc I just saw this, and consequently found your patches on this mailing list too. As for the SynEdit patches (is-link-able), If you can submit them to mantis, I will take them and look at them. I had a quick, yet not complete look at them. One thing I can already tell is the way you check if it is a number: not (Lines[Y - 1][X1] in ['0'..'9']) and It is incomplete. $ABCD is a number in hex. Best would be to introduce a IsNumber in the highlighter (pascal, and baseclass), and check there. This would also keep synedit itself more agnostic to pascal specifics (even so, codetools only work on pascal source) IsNumber has to deal with 1.99e3 being cut into 2 words, so 99e3 is a number. Not sure what to do with 1.e2, but imho it wouldn't hurt to ignore this and have e2 linkable. Also you may need to check the list again, against context sensitive keywords. A procedure self; seems to compile. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Mouse Link in SynEdit (only link-able items)
I am opening a new mail thread, otherwise it will be mixed with the TAChart topic in the archives. Alexander Klenin wrote: On Thu, Dec 11, 2008 at 23:49, Martin Friebe [EMAIL PROTECTED] wrote: Alexander Klenin wrote: and yet another one for patches to SynEdit (both stalled for about a month now), etc I just saw this, and consequently found your patches on this mailing list too. As for the SynEdit patches (is-link-able), If you can submit them to mantis, I will take them and look at them. Ok, see http://bugs.freepascal.org/view.php?id=12785 Note that I posted two patches, and apparently you only found the older one ;-) My initial approach was not optimal, as you noted, but neither is the second one, and my questions about the best route were not answered. 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). GetHighlighterAttriAtRowColEx could be used to identify numbers. - The highlighter is overall not the best solution to find linkable text. Because even a valid bit of code, may be unresolvable to codetools. If using the Highlighter, I would propose to check for text/words that can definitely be excluded. (Numbers, certain keywords). 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; ) Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Stretching Antialiasing in win32
Felipe Monteiro de Carvalho wrote: Hello, When I execute the StretchBlt windows API in the magnifier I get different results in Delphi and in Lazarus: Windows.StretchBlt(DestCanvas.Handle, drawGlassRect.Left, drawGlassRect.Top, drawGlassWidth, drawGlassHeight, bmpDisplay.Canvas.Handle, viewRect.Left, viewRect.Top, viewRectWidth, viewRectHeight, dwROP); In Lazarus there is notice some anti-aliasing. When magnifying the same synedit text in delphi and lazarus, after 14x or so I start to see grey dots near the text and in Delphi I don't. Actually the grey dots are also square, so they actually look like as if they were part of the text, but they cannot be, because I saw the same text with delphi. Setting the canvas Antialiasingmode property has no effect. Any ideas why this happens? It's not necessarely bad, but I would like to control this via the antialiasing property. Your font may be drawn using anti-aliasing before you magnify/stretch the bitmap, so you would see the grey areas caused by the anti aliasing. If it is synedit, check either the font antialiasing/quality property in object inspector (if you use synedit as component). Or Environment=options=Editor=Display there is a checkbox Disable anti aliasing Best regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] user defined code folding regions using $REGION comments
Gerard N/A wrote: I have a rough implementation that seems to work Ok (I'm cautious because the synedit highlighter is a scary piece of code). If there is interest, I can post a patch to the bug tracker or here. Hi Gerard, I saw the patch you uploaded to the bug system. As indicated the user-token must not interfere with real compiler directives. This should still be easy to solve. Instead of looking for a directive named $REGION, you would look for a comment with special content. The 2nd issue requires more work. consider this: [EMAIL PROTECTED] 'for relesae builds' fold } If IsRelease then begin [EMAIL PROTECTED] a:= foo(b); writeln(a); [EMAIL PROTECTED] 'for relesae builds' fold } end; [EMAIL PROTECTED] This should work. The begin should still match the end FoldedView has *some* (but completely untested) preparation for this. The big task is, that this kind of fold info can not be stared in a single combined list of the current type (FoldMinLevel / FoldEndLevel ) - The Highlighter needs to keep/calculate the info independent of the current FoldLevel - Current folds, have some info at *every* line in SynEditTextBuffer. User folds are likely to be less in count. So I would suggest *not* to add info to every line. SynEditTextBuffer could have a TAVLTree storing info about each known userfold. - SynEdit.ScanFrom = would need to update the additional fold info - TFoldedView would have to obey the additional FoldInfo If you have a different idea, how the problem could be solved, please feel free to explain, and we can discuss it. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
