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
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 -
--
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
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.
--
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
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
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 -
--
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
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 ?
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,
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
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
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
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
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
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
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
>> 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
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
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
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
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
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
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 -
--
___
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
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
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
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
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
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
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
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
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
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
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
35 matches
Mail list logo