Re: [Lazarus] Live Templates

[Martin Friebe]

Mattias Gärtner wrote:
> Zitat von Lee Jenkins :
>   
>> 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

[Martin Friebe]

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)]

[Martin Friebe]

Alexander Klenin wrote:
> On Thu, May 7, 2009 at 08:56, Martin Friebe  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] Watches/Local variables/Registers [Re: IDE UI consolidation (was: Re: lfm as pascal)]

[Martin Friebe]

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] IDE UI consolidation (was: Re: lfm as pascal)

[Martin Friebe]

Alexander Klenin wrote:
> 2009/5/7 Bogusław Brandys :
>   
>> 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

Re: [Lazarus] IDE UI consolidation (was: Re: lfm as pascal)

[Martin Friebe]

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

[Lazarus] OT, search and highlight[Re: IDE UI consolidation (was: Re: lfm as pascal)]

[Martin Friebe]

Graeme Geldenhuys wrote:
> On Wed, May 6, 2009 at 2:44 AM, Alexander Klenin  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] Lazarus ignores my breakpoints

[Martin Friebe]

Graeme Geldenhuys wrote:
> On Tue, May 5, 2009 at 1:06 PM, Graeme Geldenhuys
>  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

[Martin Friebe]

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

[Martin Friebe]

Bart wrote:
> On 5/1/09, Martin Friebe  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:\LazarusProjecten>test
> 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

[Martin Friebe]

Bart wrote:

On 4/30/09, Martin Friebe  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

[Martin Friebe]

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:
>
> 
> 
>   
>  ExtraLineSpacing="0
> " ShowLineNumbers="False" ShowOnlyLineNumbersMultiplesOf="1"/>
> 
>   
> 
> 
>   
> 
> 
> 
>   
> 
> 
>   
> 
>
>
> 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

[Martin Friebe]

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] New Lazarus IDE/LCL features since ...?

[Martin Friebe]

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] ide enhancement - method or cursor location belongs to what class?

[Martin Friebe]

Graeme Geldenhuys wrote:
> On Sun, Apr 19, 2009 at 3:11 AM, Martin Friebe  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] "Figures" in code explorer

[Martin Friebe]

Mattias Gaertner wrote:
> On Mon, 20 Apr 2009 12:14:18 +1100
> Alexander Klenin  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

[Martin Friebe]

Alexander Klenin wrote:
> On Sun, Apr 19, 2009 at 22:02, Mattias Gaertner
>  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?

[Martin Friebe]

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]

[Martin Friebe]

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

[Martin Friebe]

Dave Coventry wrote:
> Hi Martin, Thanks for the response.
>
> 2009/4/13 Martin Friebe :
>   
>> 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] Clear font backgrounds

[Martin Friebe]

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] update [Re: Code Folding mess and Code Divider feature]

[Martin Friebe]

Alexander Klenin wrote:
> On Sat, Apr 11, 2009 at 01:56, Martin Friebe  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] update [Re: Code Folding mess and Code Divider feature]

[Martin Friebe]

Alexander Klenin wrote:
> On Fri, Apr 10, 2009 at 22:10, Martin Friebe  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]

[Martin Friebe]

Alexander Klenin wrote:
> On Mon, Apr 6, 2009 at 08:45, Martin Friebe  wrote:
>   
>> 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.
>> 
>
> I played with it, and it generally works very well, thanks ;-)
>
> Some minor issues:
> 1) When 'Code folding' is unchecked, other controls should probably be 
> disabled.
>  Also, 'Enable code folding' is IMO a better name.
>   
True, but that will be a lot easier, if folding and dividers are more 
separated (see item 3)

Dividers need a global switch too.

> 2) Language dropdown should probably have a label.
>   
Hm, yes, "sugar" as far as I am concerned. But easy if the 2 buttons 
disappear (so it will be done together with the item 3)

> 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

> 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
>   
Hm yes and no.

This happens with var/type and unit-sections. The reason:
 Those end before the next section, potentially including empty lines at 
their end.
 All others end before the empty lines.
So they can be separated by any amount of empty lines

Simple drop them would not work for people who have them in different 
colors (ok ,I do not honestly believe this is an issue)

An other way, would be not to determine if we already drawn some other 
divider, but instead to end those blocks always in front of any empty 
lines (as long as those empty lines are at the end of this block). It 
would however mean that (if differently colored)  the end of a 
type-block is drawn over the end of a class-block, hiding the end of the 
class

I am not yet sure, If, when or which way I will do that.


Best Regards
Martin
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Large program size - 1.8 MB for empty GUI project (uses clause in initialization vs implementation?)

[Martin Friebe]

Alexey S. Smirnov wrote:
> Vincent Snijders ?:
>> Can somebody explain to me why smartlinking works better when a unit
>> is in the implementation section than when it is in the interface
>> section? I thought for smartlinking it doesn't make a difference, the
>> unit is used anyway.
>>   
> The Smart Link process should check what 
> variables/functions/definitions are used in your project to cut off 
> unused code. It is really simple to do so, if some units are listed in 
> Implementation section - linker will only add unit functions that are 
> mentioned in you code, not more.
> If units are listed in Interface section - it mean that potentially 
> all code from that particular unit should be included. Because your 
> global variable/class should have access to all provided 
> code/procedures/properties.
>
Is this documented somewhere? I can't follow the logic anyway, the scope 
how much my code uses of another unit can not be predicted, simply by 
where I include the other code?

Actually, I do believe I have seen examples where code form units used 
in the interface was successfully smart-linked.

However there is a differentiation what can be smart linked and what 
not. If a class has RTTI information, then methods from it can not be 
removed by smart-linking. Classes with RTTI (afaik) are either included 
as a whole or not at all. (And that make sense, because RTTI allows to 
access any method by finding it from a resource or literal string; which 
are both not parsed by the compiler, and therefore not determinable)

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?

[Martin Friebe]

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 
>> . 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]

[Martin Friebe]

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] Large program size - 1.8 MB for empty GUI project

[Martin Friebe]

Vincent Snijders wrote:
> Igor Tkachenko schreef:
>   
>> Does this mean that 1.8 MB is the size of empty Lazarus application now? 
>> 
>
> Yes. For an application that includes the LCL.
>
>   
>> Or I do something wrong?
>> 
>
> No.
>
> I think the size of 500 kB was too high from the beginning, I never saw 
> it smaller than 1 or 1.2 MB, but the size has grown since that article 
> was written.
>
>   

Try building your app with:
-O2 -Os -XX  -CX -OpPENTIUM

gives 1.5 MB (you also need to recompile the LCL with those options)

or look at http://wiki.freepascal.org/Whole_Program_Optimization

Best Regards
Martin
___
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?

[Martin Friebe]

ik wrote:
> Why not to use the Status bar for that ? It also can remain there as 
> long as you inside the method etc..
>
> I suggested an idea that was rejected by most people on this list: 
> have an ability to split the editor, I use it in VIM for example when 
> I need to see additional information without loosing my main work area.
Me too. I think the status bar will be a good place.

I don't see a problem with splitting in general, but it depends on the 
way it will be implemented. IMHO It is a case of adding 2 things:
- Allowing several instances of SynEdit to show the same source
- Docking. so you can choose between multi-window and single/slitted window.

Btw, the best you can do for now is to disable the "Caret always 
visible". then the caret will keep it's position, even if scrolled out 
of the visible area.
It allows you to scroll (mouse only) and once you found what you where 
looking for, just type caret-left-key and you are back (well one 
position to the left)

>
> On Thu, Apr 2, 2009 at 12:42 PM, Graeme Geldenhuys 
> mailto:graemeg.li...@gmail.com>> 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?
>
> I remember in the VB6 days, there was two edit fields above the
> editor. One listed the module or class (I think) and the other listed
> the procedure you were in. So clearly knowing where you are is handy
> to more than just me. :-)
>
> Regards,
>  - Graeme -
>
>
___
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]

Flávio Etrusco wrote:
> On Wed, Mar 4, 2009 at 11:27 AM, Martin Friebe  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?

[Martin Friebe]

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] About the "Trim Spaces Style" modes. Which one should be the default mode?

[Martin Friebe]

Sayyid Ibnu Husein Al-'Aththÿe2s wrote:
> With regard to my 0013298 
>  report ( 
> 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

Re: [Lazarus] About the "Trim Spaces Style" modes. Which one should be the default mode?

[Martin Friebe]

Sayyid Ibnu Husein Al-'Aththÿe2s wrote:
> With regard to my 0013298 
>  report ( 
> 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] Easiest way to "case" strings

[Martin Friebe]

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

[Lazarus] codetools trying to keep track of renamed procedures

[Martin Friebe]

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

[Martin Friebe]

Michael Van Canneyt wrote:
> On Tue, 17 Mar 2009, Martin Friebe wrote:
>   
>>> 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.
>> 
>
> This may be so, but given the implementation as it is in Delphi, 
> hopefully you can now understand my problem with the Lazarus
> exception dialog :-)
>
>   
Yes, and no:

Yes I can, if you leave those exception to be handled by the build-in 
dialog.
  Which means that you do not intend to provie any helps or options to 
the user, but only want to display the message and leave it to the user.

No,
 because IMHO you still want to handle it in OnException or similar, and 
it would therefore be easy to write your own MessageDlg

 leaving it to the build-in means you assume it is *impossible* that any 
other exception can ever occur in your app, and also end up with the 
same dialog => because if that happens, the user of your application has 
no way to tell, which of the exceptions are "ok" ; and which indicate 
that the app just had an internal crash and will now be unstable and 
data may be lost


In other words: I believe the build-in dialog should feature the text: " 
The application has just crashed. You may press continue and try to save 
any data before you quit the application."

Best Regards
Martin

___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Exception dialog

[Martin Friebe]

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  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] Exception dialog

[Martin Friebe]

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

[Martin Friebe]

Luca Olivetti wrote:
> En/na Hans-Peter Diettrich ha escrit:
>
>   
>> Insert your exception handler in an more appropriate place, depending on 
>> the concrete application. The user can expect a diagnosis of what went 
>> wrong, and a chance for correcting his preceding input.
>> 
>
> For data aware components (and probably for others too), 
> Application.OnException is the only place, otherwise you cannot trap 
> exception that are no caused by your program flow but by intrinsic 
> processing by the component (e.g. during post the database could reject 
> the data due to failed constraints, you could trap BeforePost or 
> AfterPost but not DuringPost).
>   
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.

Best Regards
Martin

___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Exception dialog

[Martin Friebe]

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] Smarter Text Highlighter in SynEdit?

[Martin Friebe]

Reenen Laurie wrote:
(This email doesn't make 100% sense if you read your emails in 100% 
text -- no formatting)


Hi

I really like the Text Highlighter in SynEdit, although there is a 
quirk that sometimes gets to me...


In the following code:

procedure loop(t : Tstringlist);
var
  i : integer;
  NewList : TStringlist;
begin
  i := 0;


If I hover on i (in i := 0), then all the i's are highlight...  
TStringList...


Can't it just highlight the i variables?  As indicated by the yellow 
highlighted parts, not the Pink highlighted parts.


As discussed on the chat, but for anyone else who may have the issue. 
this can be configured:


http://wiki.lazarus.freepascal.org/IDE_Window:_Editor_Options#Automatic_features


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

[Martin Friebe]

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] Code Folding mess and Code Divider feature

[Martin Friebe]

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

[Martin Friebe]

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

[Martin Friebe]

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] About 0013268: SynEdit parses every li ne twice on load or paste (Attn: Flávio)

[Martin Friebe]

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

Re: [Lazarus] About 0013268: SynEdit parses every li ne twice on load or paste (Attn: Flávio)

[Martin Friebe]

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]

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 Friebe]

Flávio Etrusco wrote:
> On Wed, Mar 4, 2009 at 8:04 PM, Martin Friebe  wrote:
>   
>> 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 ;-)
>
>   

There is another way to avoid double scanning of the last line.

- Allow the (current/old) last line to be scanned, if a line is appended
- But Do not scan the last line of the text, on normal Scans (since the 
result is not used anyway)


 From ScanFrom
fHighlighter.SetLine(FTheLinesView[Result], Result);
fHighlighter.NextToEol;
inc(Result);
if Result = FTheLinesView.Count then
  break;

As you can see if Result hits Count, the result of NextToEOL is never used

fHighlighter.SetLine(FTheLinesView[Result], Result);
inc(Result);
if Result = FTheLinesView.Count then
  break;
fHighlighter.NextToEol;

There are still cases where this is less good than, storing the EndRange 
instead of the StartRange. but anyway ...


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]

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 Friebe]

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 Friebe]

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)

[Martin Friebe]

Martin Friebe wrote:
> Flávio Etrusco wrote:
>   
>> On Wed, Mar 4, 2009 at 11:27 AM, Martin Friebe  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

Re: [Lazarus] About 0013268: SynEdit parses every li ne twice on load or paste (Attn: Flávio)

[Martin Friebe]

Flávio Etrusco wrote:
> On Wed, Mar 4, 2009 at 11:27 AM, Martin Friebe  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] implicit undo (attn Flávio) [Re : Code Structure / SourceEdit and SyneEdit]

[Martin Friebe]

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] Cannot build lazarus anymore

[Martin Friebe]

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

[Lazarus] About 0013268: SynEdit parses every li ne twice on load or paste (Attn: Flávio)

[Martin Friebe]

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

[Lazarus] implicit undo (attn Flávio) [Re : Code Structure / SourceEdit and SyneEdit]

[Martin Friebe]

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] To all SVN-followers => incompatible change

[Martin Friebe]

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

[Martin Friebe]

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]

[Martin Friebe]

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

Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]

[Martin Friebe]

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]

[Martin Friebe]

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]

[Martin Friebe]

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] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]

[Martin Friebe]

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] Debugger problems

[Martin Friebe]

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

[Lazarus] some workarounds [Re: Debugger problems]

[Martin Friebe]

Graeme Geldenhuys wrote:
> On Sat, Feb 21, 2009 at 12:49 AM, Hans-Peter Diettrich
>  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] Problem using the SVN program: source files "mutilated"

[Martin Friebe]

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:\LazarusProjecten>svn --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

[Martin Friebe]

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

[Martin Friebe]

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

[Martin Friebe]

Hi,

there are a couple of options to control the current-word-markup 
feature. They are on the "Automatic feature" page of the editor option 
(plus color settings on the color page)

Note: If you have a block selected, the selected block will be used as 
term to highlight, rather than the word under caret.
Some settings are only for block, others only for current-word

1) You can change the time after which highlighting kicks in. You can 
also disable the Timer completely, in which case you can still toggle 
Highlighting by Keyboard

2) Toggle by Keyboard (default Alt-M)
You can toggle the highlight to any chosen word, or selection by 
pressing Alt-M while at the word, or while having selected the desired 
block.
Pressing Alt-M again will set the "fixed" word to the word at your new 
location. To untoggle, press Alt-M twice at the same location
(The exact behaviour is: If your current selected block, or (if no block 
selected) the current word under cursor is the same term as the word you 
toggled-fixed, this will clear the fixed word. Otherwise the fixed word 
will be set)

3) You can ignore Keywords. This is a hardcoded list of Keywords, and 
will ignore them even if they are used in a context where they would not 
be seen as Keyword. The list comes from the highlighter, so this only 
works together with the highlighter.

4) for current-word only:
You can choose to only highlight exact matches(match word boundaries) 
instead of any occurrence including occurrences in other words. By 
Default this applies to words shorter than 3 chars.

5) blocks only:
by default leading/trailing spaces are ignored/stripped from the search term



To disable the feature completely:
Set all colors (FG,. BG and Frame) to default (check the tickbox); make 
sure no Styles (bold, italic) are selected.

This will be regognied, and the Editor is clever enough and will not 
even trigger the search for other words.


Best Regards
Martin


Graeme Geldenhuys wrote:
> Hi,
>
> I'm catching up on new Lazarus IDE features since mid December - you
> guys have been busy I see!  ;-)
>
> I noticed that if I place the cursor on begin..end pair or on a
> property like "Width", similar properties are highlighted all over the
> code. What is this used for?  The screenshot shows what I mean.
>
>
> 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] new editor feature in Lazarus SVN

[Martin Friebe]

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  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

[Martin Friebe]

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] Where to place definition of a record?

[Martin Friebe]

Howard Page-Clark wrote:
> On Sun, 25 Jan 2009 00:22:09 +0200
> Dave Coventry  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] Error building last SVN

[Martin Friebe]

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] Few features for Lazarus editor

[Martin Friebe]

> 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] Passing an array to a function

[Martin Friebe]

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

[Martin Friebe]

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] is it me or a bug that i ve been fighting?

[Martin Friebe]

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] is it me or a bug that i ve been fighting?

[Martin Friebe]

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?

[Martin Friebe]

Hi,

let me start with "No I have not executed the demo code";

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)?

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).
Or try to compile "not" as a windows app (switch off -WG) then you get a 
console window, and a lot of output.
(Both options are in Project->compiler options->tab: linking)

It could be in the RTL, in which case it would be helpful to rebuild 
this with debug support


Good Luck

waldo kitty wrote:
> thanks for your response, reenen... it does tend to make sense on the one 
> hand 
> but on the other i "must" ask if you have looked at and/or run the demo code 
> i 
> pointed to?
>
> it does check if the connection is open ;)
>
> procedure TFormTryMySQL.ConnectButtonClick(Sender: TObject);
> begin
>// Check if we have an active connection. If so, let's close it.
>if MySQLConnection1.Connected then begin
>  SQLTransaction1.Active := False;
>  MySQLConnection1.Close;
>end;
> blahfooblah...;
>
> when i place logging lines in the above, the last logging line that executes 
> is 
> the one right above "MySQLConnection1.Close;" which indicates the error in is 
> the "MySQLConnection1.Close;" library code...
>
> i can see where what you are saying may be possible but it doesn't make sense 
> because the next time the above is executed, it works "properly" (ie: there's 
> no 
> error)..
>
> what it almost sounds like is that in closing the connection object, 
> something 
> was not created during the open which somehow does get created during the 
> close...
>
> again, i dunno and that's why i'm here... one would think that demo code 
> should 
> work and work properly (ie: without error) out of the box... i won't point 
> back 
> to my comment about having problems with several other of the wiki demo apps 
> not 
> working for some reason or another :?
>
>
>
> Reenen Laurie wrote:
>   
>> I am very uninformed when it comes to databases, but access violations 
>> happens when you do stuff to stuff that's not there.
>>
>> My guess is that for some reason your "close" code gets fired twice, and 
>> thus it's already closed by the time you get there the second time.
>>
>> So if there's a way to check if it's open, before you close it, I'd 
>> suggest try to close it inside an if open...
>>
>> Regards,
>> -Reenen
>>
>> On Sun, Jan 18, 2009 at 9:39 PM, waldo kitty > > wrote:
>>
>>
>> history: i'm a long time pascal coder... since TP3 first appeared on the
>> market... then to TP5 and most of my time with TP6/BP6 and numerous
>> commercial
>> apps under my belt... i've dabbled with OOP stuffs, TP7/BP7 and even
>> have a copy
>> of delphi6-personal that i've not been able to wrap my head
>> around... since my
>> delphi was a downloaded copy from Inprise, it is also a bit harder
>> to work with
>> since i've no real documentation that i can lay in my lap to look
>> over while
>> working on code :? :(
>>
>> in any case, i've been fighting a battle with mysql50conn for a few
>> weeks,
>> now... i started with Lazaruz 0.9.26 and last night installed
>> Lazarus 0.9.27 to
>> see if the problem i'm facing may have been fixed in there but it
>> has not and
>> i'm not even certain if the problem is in the library code or
>> possibly something
>> on this old win98SE box :?
>>
>> ok, enough of the history and story telling...
>>
>> the details: with the tutorial DB code on the wiki (yeah, i was
>> /finally/ able
>> to get two or three of those working after some starts, stops and
>> fits :P),
>> there's several that check to see if the connection to the database
>> is active
>> and if it is, they attempt to close it... my problem is that the
>> first attempt
>> to close the connection _always_ throws an error... i don't know
>> what specific
>> error code because the popup box doesn't state it... the box only says
>>
>>   Access violation.
>>
>>   Press Ok to ignore and risk data corruption.
>>   Press Cancel to kill the program.
>>
>>   [OK] [Cancel]
>>
>> i'm triggering my initial connection to the database via a button. i
>> click the
>> button, the connection takes place, data is retrieved, and the
>> connection is
>> attempted to close... that's when the error is thrown... however, if
>> i hit the
>> [OK] button to ignore the error then i can open and close the
>> connection to the
>> database with no problems... at least it appears that way because
>> other routines
>> gather other data from other tables and they all connect, gather

Re: [Lazarus] Saving user created component structure to LFM file

[Martin Friebe]

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

Re: [Lazarus] Saving user created component structure to LFM file

[Martin Friebe]

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 
>&

Re: [Lazarus] Saving user created component structure to LFM file

[Martin Friebe]

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

Re: [Lazarus] Saving user created component structure to LFM file

[Martin Friebe]

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

[Lazarus] Saving user created component structure to LFM file

[Martin Friebe]

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

[Martin Friebe]

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?

[Martin Friebe]

Vincent Snijders wrote:
> 2009/1/7 David W Noon :
>   
>> 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?

[Martin Friebe]

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

[Martin Friebe]

just a test
___
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]

[Martin Friebe]

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] The Data-Model for SynEdit / The Data Model for Lazarus [Code Structure / SourceEdit and SyneEdit]

[Martin Friebe]

Mattias Gärtner wrote:
> Zitat von Martin Friebe :
>
>   
>> [...]
>> 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

[Lazarus] The Data-Model for SynEdit / The Data Model for Lazarus [Code Structure / SourceEdit and SyneEdit]

[Martin Friebe]

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] Code Structure / SourceEdit and SyneEdit [Re: Mouse Link in SynEdit (only link-able items)]

[Martin Friebe]

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.

Re: [Lazarus] Code Structure / SourceEdit and SyneEdit [Re: Mouse Link in SynEdit (only link-able items)]

[Martin Friebe]

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 m

Re: [Lazarus] Code Structure / SourceEdit and SyneEdit [Re: Mouse Link in SynEdit (only link-able items)]

[Martin Friebe]

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/

Re: [Lazarus] Code Structure / SourceEdit and SyneEdit [Re: Mouse Link in SynEdit (only link-able items)]

[Martin Friebe]

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, 

Re: [Lazarus] Code Structure / SourceEdit and SyneEdit [Re: Mouse Link in SynEdit (only link-able items)]

[Martin Friebe]

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 T

Re: [Lazarus] Code Structure / SourceEdit and SyneEdit [Re: Mouse Link in SynEdit (only link-able items)]

[Martin Friebe]

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)

[Martin Friebe]

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