Re: [Lazarus] Search dialog scope

2016-04-07 Thread wkitty42
On 04/07/2016 01:07 PM, Graeme Geldenhuys wrote: On 2016-04-07 17:42, Ondrej Pokorny wrote: another place is that the text is inserted into the IDE editor with a keyboard Oh wow - I haven't seen one of those in years. My computer uses mind control - I think of code and it appears (coffee is

Re: [Lazarus] Search dialog scope

2016-04-07 Thread Graeme Geldenhuys
On 2016-04-07 17:42, Ondrej Pokorny wrote: > another > place is that the text is inserted into the IDE editor with a keyboard Oh wow - I haven't seen one of those in years. My computer uses mind control - I think of code and it appears (coffee is my fuel). ;-) Regards, - Graeme - --

Re: [Lazarus] Search dialog scope

2016-04-07 Thread Ondrej Pokorny
On 07.04.2016 17:17, Graeme Geldenhuys wrote: On 2016-04-07 10:43, Ondrej Pokorny wrote: But the dialog's behaviour has always been 'as in delphi' (or at least as long as I remember) No, it wasn't. Since when is Lazarus design goal now "Delphi IDE compatible"? The LCL yes, the IDE no! At

[Lazarus] Extend unit path

2016-04-07 Thread Michael Van Canneyt
Hi, When adding unit files from disk to a package, the IDE asks to extend the unit path with '.'. I understand why it needs to ask to extend the unit path, but for '.' this is not necessary, I think. I always click no, and I didn't get in trouble yet :) Michael. --

Re: [Lazarus] Search dialog scope

2016-04-07 Thread Sven Barth
Am 07.04.2016 17:18 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2016-04-07 10:43, Ondrej Pokorny wrote: > >> > But the dialog's behaviour has always been 'as in delphi' (or at least > >> > as long as I remember) > > No, it wasn't. > > > > > Since when is Lazarus design

Re: [Lazarus] PDF generator, try 2

2016-04-07 Thread Sven Barth
Am 07.04.2016 14:58 schrieb "Martin Schreiber" : > > On Thursday 07 April 2016 13:49:06 Graeme Geldenhuys wrote: > > I was about to mention that. This was discussed before, and there was a > > reason (which eludes me now) why FillChar() will not be changed. > > Because out

Re: [Lazarus] Search dialog scope

2016-04-07 Thread Graeme Geldenhuys
On 2016-04-07 10:43, Ondrej Pokorny wrote: >> > But the dialog's behaviour has always been 'as in delphi' (or at least >> > as long as I remember) > No, it wasn't. > Since when is Lazarus design goal now "Delphi IDE compatible"? The LCL yes, the IDE no! Regards, - Graeme - --

Re: [Lazarus] German umlauts in component names

2016-04-07 Thread Andreas Schneider
Am 2016-04-02 14:38, schrieb Graeme Geldenhuys: On 2016-04-02 13:16, Santiago A. wrote: similar should be done. You would need to make compulsory a command in source code to tell which code set is using. As a contract programmer I already struggle working on code where identifiers, Class

Re: [Lazarus] Cant compile the IDE with the most recent fpc (3.1.1)

2016-04-07 Thread Mattias Gaertner
On Thu, 07 Apr 2016 16:25:26 +0200 Michael Schnell wrote: > On 04/07/2016 04:19 PM, Mattias Gaertner wrote: > > What -Fu paths do you have in your fpc.cfg? > I did suppose something like this. > > Am I supposed to manually edit this file even for the unmodified svn d/l ?

Re: [Lazarus] Cant compile the IDE with the most recent fpc (3.1.1)

2016-04-07 Thread Michael Van Canneyt
On Thu, 7 Apr 2016, Michael Schnell wrote: On 04/07/2016 04:19 PM, Mattias Gaertner wrote: What -Fu paths do you have in your fpc.cfg? I did suppose something like this. Am I supposed to manually edit this file even for the unmodified svn d/l ? Normally not. I have this in my fpc.cfg,

Re: [Lazarus] Cant compile the IDE with the most recent fpc (3.1.1)

2016-04-07 Thread Michael Schnell
On 04/07/2016 04:19 PM, Mattias Gaertner wrote: What -Fu paths do you have in your fpc.cfg? I did suppose something like this. Am I supposed to manually edit this file even for the unmodified svn d/l ? -Michael -- ___ Lazarus mailing list

Re: [Lazarus] Cant compile the IDE with the most recent fpc (3.1.1)

2016-04-07 Thread Mattias Gaertner
On Wed, 06 Apr 2016 09:47:34 +0200 Michael Schnell wrote: > It happened to me (again) :(. > > After upgrading fpc to the latest svn version, I can't compile the > latest svn version of Lazarus. > > The problem (first) occurs with RegisterFCL. > > (Currently the error is

Re: [Lazarus] Cant compile the IDE with the most recent fpc (3.1.1)

2016-04-07 Thread Michael Van Canneyt
On Thu, 7 Apr 2016, Michael Schnell wrote: On 04/06/2016 09:47 AM, Michael Schnell wrote: It happened to me (again) :(. I resolved a lot of unit referenced to fpc RTL units by defining links for the files in /usr/lib/fpc/3.1.1/units/i386-linux/rtl (I suppose I should not do that this

Re: [Lazarus] Cant compile the IDE with the most recent fpc (3.1.1)

2016-04-07 Thread Michael Schnell
On 04/06/2016 09:47 AM, Michael Schnell wrote: It happened to me (again) :(. I resolved a lot of unit referenced to fpc RTL units by defining links for the files in /usr/lib/fpc/3.1.1/units/i386-linux/rtl (I suppose I should not do that this way, but I don't know another :( ) But later in

Re: [Lazarus] PDF generator, try 2

2016-04-07 Thread Martin Schreiber
On Thursday 07 April 2016 13:49:06 Graeme Geldenhuys wrote: > I was about to mention that. This was discussed before, and there was a > reason (which eludes me now) why FillChar() will not be changed. Because out parameters are finalised on caller side: " Procedure FillChar1(out

Re: [Lazarus] PDF generator, try 2

2016-04-07 Thread Sven Barth
Am 07.04.2016 13:49 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2016-04-07 12:25, Martok wrote: > > If Move+FillChar would use out instead of var (as they should - they don't read > > the dest value, that's the whole point), that would be fixed once and for all. > > But I

Re: [Lazarus] PDF generator, try 2

2016-04-07 Thread Graeme Geldenhuys
On 2016-04-07 12:25, Martok wrote: > If Move+FillChar would use out instead of var (as they should - they don't > read > the dest value, that's the whole point), that would be fixed once and for all. > But I remember having this discussion before and apparently it was like this > for > some

Re: [Lazarus] PDF generator, try 2

2016-04-07 Thread Martok
>> You will get the hint here then, no ? > > No. Seems the compiler is more lenient with pointer types. That's a bug then, isn't it? After all, it's about the var parameter, not what is passed into it... The variable that is passed into FillChar is not yet initialized, but it could be read

Re: [Lazarus] Search dialog scope

2016-04-07 Thread Michael Van Canneyt
On Thu, 7 Apr 2016, Ondrej Pokorny wrote: I fixed it in r52143. But the behavior is not like it was before. It's now: scope: selected text, *origin: from beginning.* for search on selection. (it was scope: selected text, origin: from cursor. before). Please test, it should fulfill your

Re: [Lazarus] PDF generator, try 2

2016-04-07 Thread Graeme Geldenhuys
On 2016-04-07 11:37, Michael Van Canneyt wrote: > You will get the hint here then, no ? No. Seems the compiler is more lenient with pointer types. Regards, - Graeme - -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org

Re: [Lazarus] Search dialog scope

2016-04-07 Thread Zeljko
On 04/07/2016 09:34 AM, Michael Van Canneyt wrote: Hello, Did something change in the search() dialog scope handling ? Since some time, I must alwas set the scope to "selection", and the origin to 'beginning' manually. No matter where my cursor is. I am pretty sure that before, if there is

Re: [Lazarus] PDF generator, try 2

2016-04-07 Thread Michael Van Canneyt
On Thu, 7 Apr 2016, Graeme Geldenhuys wrote: On 2016-03-31 16:48, silvioprog wrote: +{$IFDEF VER3} + Buffer := Default(TBuffer) +{$ELSE} + FillChar(Buffer,SizeOf(TBuffer),0) +{$ENDIF}; Just thought I would mention, I've seen the above code listed a few times now to remove the

Re: [Lazarus] PDF generator, try 2

2016-04-07 Thread Graeme Geldenhuys
On 2016-03-31 16:48, silvioprog wrote: > +{$IFDEF VER3} > + Buffer := Default(TBuffer) > +{$ELSE} > + FillChar(Buffer,SizeOf(TBuffer),0) > +{$ENDIF}; Just thought I would mention, I've seen the above code listed a few times now to remove the famous "Local variable does not seem to be

Re: [Lazarus] PDF generator, try 2

2016-04-07 Thread Graeme Geldenhuys
On 2016-04-07 07:36, Michael Van Canneyt wrote: > > This should not exist to begin with, I think. > The UTF8Decode function of the system unit performs the same function. Indeed, you are correct. I'll make the change. Regards, - Graeme - -- ___

Re: [Lazarus] Search dialog scope

2016-04-07 Thread Ondrej Pokorny
I fixed it in r52143. But the behavior is not like it was before. It's now: scope: selected text, *origin: from beginning.* for search on selection. (it was scope: selected text, origin: from cursor. before). Please test, it should fulfill your and my needs ;) Thanks for reporting! Ondrej

Re: [Lazarus] Search dialog scope

2016-04-07 Thread Ondrej Pokorny
On 07.04.2016 11:12, Michael Van Canneyt wrote: But the dialog's behaviour has always been 'as in delphi' (or at least as long as I remember) No, it wasn't. so I don't understand what you changed or why you thought it was necessary ? Read the issue report. Lazarus picked scope "from

Re: [Lazarus] Search dialog scope

2016-04-07 Thread Michael Van Canneyt
On Thu, 7 Apr 2016, Martok wrote: Hello, Since some time, I must alwas set the scope to "selection", and the origin to 'beginning' manually. No matter where my cursor is. I am pretty sure that before, if there is a nonempty selection, the dialog would set these settings correct for me. I

Re: [Lazarus] Search dialog scope

2016-04-07 Thread Michael Van Canneyt
On Thu, 7 Apr 2016, Ondrej Pokorny wrote: On 07.04.2016 9:34, Michael Van Canneyt wrote: Did something change in the search() dialog scope handling ? I changed it a little bit to match Delphi's behavior. The reason is described here: http://mantis.freepascal.org/view.php?id=27039 Since

Re: [Lazarus] Search dialog scope

2016-04-07 Thread Martok
Hello, > Since some time, I must alwas set the scope to "selection", and the origin to > 'beginning' manually. No matter where my cursor is. > > I am pretty sure that before, if there is a nonempty selection, the dialog > would set these settings correct for me. I can confirm this behaviour, and

Re: [Lazarus] Search dialog scope

2016-04-07 Thread Ondrej Pokorny
On 07.04.2016 9:34, Michael Van Canneyt wrote: Did something change in the search() dialog scope handling ? I changed it a little bit to match Delphi's behavior. The reason is described here: http://mantis.freepascal.org/view.php?id=27039 Since some time, I must alwas set the scope to

[Lazarus] Instalation on win10

2016-04-07 Thread Pedro Albuquerque
Hi, thank you all that answered my question. Loved your comments :-)) +1 for everybody. I'll just use it for gamming. ;-) And most likely a dual boot with linux. Thank you again, Pedro. Qui, 2016-04-07 às 09:46 +0200, lazarus-requ...@lists.lazarus.freepascal.org escreveu: > Send Lazarus

Re: [Lazarus] {$warn 5023 off: No warning about unused units}

2016-04-07 Thread Mattias Gaertner
On Wed, 6 Apr 2016 22:53:43 +0100 Graeme Geldenhuys wrote: >[...] > I see the same thing here with Lazarus v1.7. It is annoying for the SCM, > but I think I figured out the reasoning for that line. Lazarus packages > have somewhere a setting that says the unit

Re: [Lazarus] {$warn 5023 off: No warning about unused units}

2016-04-07 Thread Mattias Gaertner
On Wed, 6 Apr 2016 23:31:32 +0200 Werner Pamler wrote: > Since some time, the TurtoiseSVN overlay icons of some of the packages > which I loaded from svn have become practically useless. It is always > the autogenerated package unit which is marked by a red overlay

[Lazarus] Search dialog scope

2016-04-07 Thread Michael Van Canneyt
Hello, Did something change in the search() dialog scope handling ? Since some time, I must alwas set the scope to "selection", and the origin to 'beginning' manually. No matter where my cursor is. I am pretty sure that before, if there is a nonempty selection, the dialog would set these

Re: [Lazarus] PDF generator, try 2

2016-04-07 Thread Michael Van Canneyt
On Thu, 7 Apr 2016, Sven Barth wrote: the SetMultiByteConversionCodePage(CP_UTF8) call makes DefaultSystemCodePage=CP_UTF8 which matches UTF8String and so in fpc_ansistr_to_ansistr no conversion is performed. And so that is why SetMultiByteConversionCodePage(CP_UTF8) is needed when