Re: [Lazarus] Search dialog scope
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
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
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
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
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
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
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
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)
On Thu, 07 Apr 2016 16:25:26 +0200 Michael Schnellwrote: > 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)
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)
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)
On Wed, 06 Apr 2016 09:47:34 +0200 Michael Schnellwrote: > 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)
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)
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
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
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
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
>> 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
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
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
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
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
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
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
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
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
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
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
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
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
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}
On Wed, 6 Apr 2016 22:53:43 +0100 Graeme Geldenhuyswrote: >[...] > 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}
On Wed, 6 Apr 2016 23:31:32 +0200 Werner Pamlerwrote: > 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
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
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