Re: [Lazarus] Search dialog scope

[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 my fuel). ;-)


ROTFL!

PS: you misspelled c0ffee ;) O:)

--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list* unless
   private contact is specifically requested and granted.

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

Re: [Lazarus] Search dialog scope

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


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

Re: [Lazarus] Search dialog scope

[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 some places the Lazarus IDE has to be Delphi-compatible. E.g. another 
place is that the text is inserted into the IDE editor with a keyboard 
and it prints its contents on the screen. I hope you are not against 
this compatibility :P

We are really not your enemies, Graeme.

Ondrej

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

[Lazarus] Extend unit path

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

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

Re: [Lazarus] Search dialog scope

[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 goal now "Delphi IDE compatible"?  The LCL
> yes, the IDE no!

The linked report also mentions other editors, so it's more like "common
sense compatible" than "Delphi compatible" ;)

Regards,
Sven
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] PDF generator, try 2

[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 parameters are finalised on caller side:

Ah, yes, that was the subtle point I mentioned :)

Regards,
Sven
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Search dialog scope

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


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

Re: [Lazarus] German umlauts in component names

[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 names, methods, code comments etc are written in
non-English [I fully agree its their right to do so, as it is not
feasible to think everybody can speak or write English]. But adding
different character sets to the mix will massively increase that 
hurdle.


I used to strictly oppose non-english code as well. A colleague actually 
managed
to convince me that there are indeed reasons for "localized" 
identifiers:
in some projects the customers (usually with some industrial background) 
have pretty
specific wordings or use of the language. If developers now start 
introducing

their own wording (due to translating back and forth) you complicate the
communication and synchronization between business unit and development 
team.
In such special cases I now "accept" said code style. (Although I still 
don't

like it ;-))

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

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

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

FPC does not care where the sources are coming from.
You need a valid fpc.cfg, usually /etc/fpc.cfg .

Mattias

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

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

[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, it is 2 lines long:

-Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget/*
-Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget/httpd22

That is all. (on windows the path will look somewhat different)
It has not been changed in years and I use it to compile everything.

Michael.

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

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

[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
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

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

[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 "Can't find unit db used by RegisterFCL", but 
> there had been other units before it did not find. For a test I moved 
> two of the to the dir it in fact searches for fpc units: 
> -Fu/usr/lib/fpc/3.1.1/units/i386-linux/rtl  )
> 
> 
> Seemingly a unit search dir for some of the fpc stuff is missing.
> 
> How to tell the Lazarus make process about those  ?

What -Fu paths do you have in your fpc.cfg?

Mattias

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

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

[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 way, but I don't know another :( )

But later in the make process LCL units and resource files are requested. I 
could resolve a lot of references creating links in some LCL directory, but 
at some point this stopped working.


Is it even possible to compile Lazarus with fpc 3.1.1 ?


I do it almost daily.

Michael.

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

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

[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 the make process LCL units and resource files are 
requested. I could resolve a lot of references creating links in some 
LCL directory, but at some point this stopped working.


Is it even possible to compile Lazarus with fpc 3.1.1 ?

-Michael

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

Re: [Lazarus] PDF generator, try 2

[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 x;count:SizeInt;Value:Byte);
begin
 fillchar(x,count,value);
end;

procedure tmainfo.exe(const sender: TObject);
type
 testty = record
  a: int32;
  b: string;
 end;
 ptestty = ^testty;
var
 po1: ptestty;
begin
 getmem(po1,sizeof(testty));
 pointer(po1^.b):= pointer(123467); //random value
// fillchar(po1^,sizeof(testty),0); //OK
 fillchar1(po1^,sizeof(testty),0); //crash because out paramters are 
   //finalized on caller side
 po1^.b:= 'abc';
 finalize(po1^);
 freemem(po1);
end;
"

Martin

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

Re: [Lazarus] PDF generator, try 2

[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 remember having this discussion before and apparently it was like
this for
> > some compatibility reason...
>
> 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. And
> that is also when I came up with the FillMem() solution.
>

"out" and "var" behave different in rather subtle points and thus code that
would currently work with FillChar would no longer work then or have subtle
errors.

> If FPC starts nagging about uninitialised pointer parameters (as in the
> usage by FillMem(...) ), then I am afraid there is *no solution* to get
> rid of that compiler hint for FPC 2.6.4.

There is no warning/hint/whatever because a parameter is always assumed to
be initialized (except it's am "out" one).

> I haven't looked at what FPC 3.0's Default() function does yet, but
> maybe FPC could implement a FillMem() exactly like FillChar() but with
> an out parameter instead. So then FillChar() is there for whatever
> backward compatibility, and FillMem() could be used going forward to get
> rid of that compiler hint.  Then again, I probably made this suggestion
> in our previous discussions on this topic. ;-)

Default() essentially creates a variable of the given type and sets it to
zero (there are optimizations for simple types).

Regards,
Sven
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] PDF generator, try 2

[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 compatibility reason...

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. And
that is also when I came up with the FillMem() solution.

If FPC starts nagging about uninitialised pointer parameters (as in the
usage by FillMem(...) ), then I am afraid there is *no solution* to get
rid of that compiler hint for FPC 2.6.4.

I haven't looked at what FPC 3.0's Default() function does yet, but
maybe FPC could implement a FillMem() exactly like FillChar() but with
an out parameter instead. So then FillChar() is there for whatever
backward compatibility, and FillMem() could be used going forward to get
rid of that compiler hint.  Then again, I probably made this suggestion
in our previous discussions on this topic. ;-)

Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

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

Re: [Lazarus] PDF generator, try 2

[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 inside FillChar, which is why the compiler 
nags.

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 compatibility reason...

There are a few places in API imports as well where a "_Out_ FOO * pBar" was
imported as "var bar: FOO" but it is actually only used for output, with the
same technically useless hints. But that's getting off-topic, sorry.


Regards,
Martok


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

Re: [Lazarus] Search dialog scope

[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 and my needs ;) Thanks for reporting!


Yay !

It works correctly now, thank you very much for the quick fix !!

Michael.

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

Re: [Lazarus] PDF generator, try 2

[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
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Search dialog scope

[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 a nonempty selection, the dialog
would set these settings correct for me.

Did something change in this regard ? What is the 'rule' that is
followed by the dialog ?

If something changed, can we please get the old behaviour back somehow ?

(this is since some time, but I verified with yesterday's version)


Same thing is killing me. Always have to check "Selection" manually :(

zeljko

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

Re: [Lazarus] PDF generator, try 2

[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 famous "Local variable does not seem to be
initialized" compiler hint.

Well, it might work on FPC 3.0 (not test), but it does nothing for FPC
2.6.4 - the hint is always there. I know it is a harmless hint, if the
code was correct to start work.

Either way, I found a solution for that, which I used in fpGUI's DocView
help viewer application too.

Implement the following:

procedure FillMem(Dest: pointer; Size: longint; Data: Byte );
begin
 FillChar(Dest^, Size, Data);
end;


You will get the hint here then, no  ?

Michael.

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

Re: [Lazarus] PDF generator, try 2

[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
initialized" compiler hint.

Well, it might work on FPC 3.0 (not test), but it does nothing for FPC
2.6.4 - the hint is always there. I know it is a harmless hint, if the
code was correct to start work.

Either way, I found a solution for that, which I used in fpGUI's DocView
help viewer application too.

Implement the following:

procedure FillMem(Dest: pointer; Size: longint; Data: Byte );
begin
  FillChar(Dest^, Size, Data);
end;

Then write your code as follows:

  FillMem(@Buffer, SizeOf(TBuffer), 0);


Now the compiler hint is gone under both FPC 2.6.4 and FPC 3.0 - and no
ugly IFDEF's required.  And as a bonus the name FillMem() is more
descriptive and technically accurate of what the code does than FillChar()


Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

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

Re: [Lazarus] PDF generator, try 2

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


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

Re: [Lazarus] Search dialog scope

[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
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Search dialog scope

[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 cursor" when executing 
search on a selection. Delphi picks up "from beginning" in this case.



Well. You definitely broke it, from my point of view. It used to work 
correct :)


Well yes, if you search with single-line selection, it works as expected 
(I fixed this). I forgot to test multi line selection. I'll fix that as 
well.




Tried again, but select five lines with shift-up.
So the cursor is at the start of the selection.
Same result.

I undid your revision, and then it works correct:

Dialog opens,
  scope: selected text,
  origin: from cursor.


Exactly this is wrong behavior what I wanted to fix. It should be
  scope: selected text,
*origin: from beginning.*
Because if you select with shift-down, you get nothing in the search.

Lazarus does it correctly after r51697 for single line selection but not 
multi-line. I'll fix it.


Ondrej
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Search dialog scope

[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 can confirm this behaviour, and also that it confused the hell out of me when
it first appeared, but I just thought I was being stupid.

Just did a bit of testing, and it seems everything works fine (sets From
Start/Selected) if the selection is on a single line only. Have more than one
line selected, and From Cursor/Global is set.


Phew !!

I thought I was being stupid too, but I am not alone :)

Michael.

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

Re: [Lazarus] Search dialog scope

[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 some time, I must alwas set the scope to "selection", and the origin 
to

'beginning' manually. No matter where my cursor is.


Strange.


I am pretty sure that before, if there is a nonempty selection, the dialog
would set these settings correct for me.


Yes, I remember that I changed the behavior so that scope is "selection" and 
origin "from the beginning" if there is a selection in the editor.

So exactly what you want to achieve.


But the dialog's behaviour has always been 'as in delphi' (or at least as long 
as I remember)
so I don't understand what you changed or why you thought it was necessary ?



Did something change in this regard ? What is the 'rule' that is followed 
by the dialog ?


If something changed, can we please get the old behaviour back somehow ?


Hmmm, for me it works exactly what you want to have (I changed to this 
desired behavior).


Well. You definitely broke it, from my point of view. It used to work correct :)



Can you be more specific about what you are doing and what the IDE does?


- Select 5 lines. (it could be 10) (shift-down, 5 times)
- Press ctrl-q a (classic shortcut for search & replace.)
- Dialog opens.
  Scope: global
  Origin: from cursor.
Just tested (again).

Tried again, but select five lines with shift-up.
So the cursor is at the start of the selection.
Same result.

I undid your revision, and then it works correct:

Dialog opens,
  scope: selected text,
  origin: from cursor.

Michael.

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

Re: [Lazarus] Search dialog scope

[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 also that it confused the hell out of me when
it first appeared, but I just thought I was being stupid.

Just did a bit of testing, and it seems everything works fine (sets From
Start/Selected) if the selection is on a single line only. Have more than one
line selected, and From Cursor/Global is set.


Regards,

Martok

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

Re: [Lazarus] Search dialog scope

[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 "selection", and the 
origin to

'beginning' manually. No matter where my cursor is.


Strange.

I am pretty sure that before, if there is a nonempty selection, the 
dialog

would set these settings correct for me.


Yes, I remember that I changed the behavior so that scope is "selection" 
and origin "from the beginning" if there is a selection in the editor.

So exactly what you want to achieve.

Did something change in this regard ? What is the 'rule' that is 
followed by the dialog ?


If something changed, can we please get the old behaviour back somehow ?


Hmmm, for me it works exactly what you want to have (I changed to this 
desired behavior).


Can you be more specific about what you are doing and what the IDE does?

Ondrej

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

[Lazarus] Instalation on win10

[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 mailing list submissions to
>   lazarus@lists.lazarus.freepascal.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
> or, via email, send a message with subject or body 'help' to
>   lazarus-requ...@lists.lazarus.freepascal.org
> 
> You can reach the person managing the list at
>   lazarus-ow...@lists.lazarus.freepascal.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Lazarus digest..."
> 
> 
> Today's Topics:
> 
>1. Re: {$warn 5023 off: No warning about unused units}
>   (Vojt?ch ?ih?k)
>2. Re: PDF generator, try 2 (Jesus Reyes A.)
>3. Re: PDF generator, try 2 (Sven Barth)
>4. Re: PDF generator, try 2 (Michael Van Canneyt)
>5. Search dialog scope (Michael Van Canneyt)
>6. Re: {$warn 5023 off: No warning about unused units}
>   (Mattias Gaertner)
> 
> 
> --
> 
> Message: 1
> Date: Thu, 07 Apr 2016 02:00:59 +0200
> From: Vojt?ch ?ih?k 
> Subject: Re: [Lazarus] {$warn 5023 off: No warning about unused units}
> To: Lazarus mailing list 
> Message-ID: <20160407020059.7b424...@atlas.cz>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
> 
> Here:
> ?
> http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packager/packagesystem.pas?root=lazarus=51771=51770=51771
> ?
> V.
> __
> > Od: Maxim Ganetsky 
> > Komu: Lazarus mailing list 
> > Datum: 07.04.2016 01:13
> > P?edm?t: Re: [Lazarus] {$warn 5023 off: No warning about unused units}
> >
> 07.04.2016 0:31, Werner Pamler ?:
> > 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 icon as
> > being out of date. When I open the unit I see that the line
> >
> > {$warn 5023 off : no warning about unused units}
> 
> Which file gives you this warning?
> 


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

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

[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 managing the package must
> (or mustn't) be added to the program using that package. I guess it
> helps with forcing FPC to compile all units in question. I always delete
> that, as I like my uses clause clean.

You are confusing things here.
A package needs a unit, that has a uses clause to let the compiler
compile all units of the package. A design time package also needs to
register its Register procedures.
By default this is done by an auto generated unit. You can do this
with an unit of your own if you prefer.
This unit can also be added automatically to the program, to make sure
that all initialization sections of the package are called.
This is what you mean with "the unit managing the package must (or
mustn't) be added to the program using that package". By default
this is not done and this setting has nothing to do whether the unit is
compiled aka the $warn.

 
>[...]
> Project templates and macros in settings have simplified my life a lot.
> My hard drives have plenty of space for non-shared [between projects]
> compiled units too. 

Sharing ppu can be done easily with macros too and packages can
compile ppu for each project as well. You are missing the point of
packages.
The purpose of packages is to make sharing code easier by separating
the compilation of program and package sources. For example you can add,
rename directories in a package without affecting all programs. You can
play around with compiler flags in your program with less worrying that
packages are affected.
Using macros requires good knowledge of every package you use. As far
as I know you, Graeme, created or maintain all packages you use. In that
case packages are indeed just shared directories of your own sources
and macros might be the better solution.


> Lazarus simply has too many "automated functionality" these days that simply 
> annoy.

... and always lacking this particular feature I need. ;)

Mattias

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

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

[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 icon as 
> being out of date. When I open the unit I see that the line
> 
> {$warn 5023 off : no warning about unused units}

The IDE automatically adds this line to the auto generated package unit.

I changed it now, so it if this $warn is the only difference it does not
update the file.

 
> has been added to the unit header. Deleting the unit, updating it from 
> the svn repository fixes it for the moment,

Hint: You can use the TortoiseSVN 'revert' function for that.


Mattias

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

[Lazarus] Search dialog scope

[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 settings correct for me.

Did something change in this regard ? 
What is the 'rule' that is followed by the dialog ?


If something changed, can we please get the old behaviour back somehow ?

(this is since some time, but I verified with yesterday's version)

Michael.

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

Re: [Lazarus] PDF generator, try 2

[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

compiling in windows

:)


UTF8ToUTF16 should best take a UTF8String then. It would fit the purpose of
the function better anyway...


This should not exist to begin with, I think. 
The UTF8Decode function of the system unit performs the same function.


Jesus, thank you for looking into this, we'll get to work with it !

Michael.

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