On Sat, Mar 18, 2017 at 1:07 PM, Alexey via Lazarus
wrote:
> At picture i see now "lblSelect" name on right
Fixed in r54443.
Juha
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus
Please test with r54447.
Juha
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus
31.3.2017 22.38 "Alexey via Lazarus"
kirjoitti:
IMO benefit will be. it is "easier to maintain". Each developer which wants
to send json,
makes GH acc, then clones OPM repo, then sends pull req. No emails. Zip can
be send in GH post.
I don't think so. There is lot's of unjustified hype around G
On Mon, May 1, 2017 at 12:30 PM, Tony Whyman via Lazarus
wrote:
> When I originally created the Firebird Pascal API package,
Now I realize your code may have been for FPC but not for Lazarus.
Even then the solution provided by LazUtils (2 files there) is good
because it allows compatible and port
On Mon, May 1, 2017 at 12:30 PM, Tony Whyman via Lazarus
wrote:
> When I originally created the Firebird Pascal API package, I wrote it with
> FPC as the only intended target ...
I guess you used the old Unicode support with explicit UTF-8
conversion functions.
Things have improved a lot since th
On Mon, May 1, 2017 at 7:40 PM, Tony Whyman via Lazarus
wrote:
> I am not sure how much your second post rows back from this but I do think
> that false is a bit harsh.
Yes, sorry, it was correct when using the default types in FPC 3.
However making it compatible with Delphi requires some effort,
On Tue, May 2, 2017 at 2:30 AM, Marcos Douglas B. Santos via Lazarus
wrote:
> So, as Mattias said, we should code using ANSI chars and everything will be
> Ok.
No, you can use all the Unicode freely.
The source files are saved as UTF-8 by default. Delphi does the same,
this detail is also compat
On Sun, Apr 30, 2017 at 7:37 PM, Marcos Douglas B. Santos via Lazarus
wrote:
> If Delphi sources don't use UTF8, how is the best way to mantain sources
> that need to work in both compilers?
I wonder if I have misunderstood something about your questions.
What means "Delphi sources don't use UTF8
Marcos Douglas B. Santos wrote:
> I am develop on Windows. What problems do you mean?
Unicode is recommended also on Windows. No worries. You don't need to
use the old system codepages.
People who need them must convert them explicitly because the Unicode
system of Lazarus does not support them di
On Wed, May 3, 2017 at 11:52 AM, Graeme Geldenhuys via Lazarus
wrote:
> At least EMBT is heading in the right direction with their
> Linux Delphi compiler - they completely removed AnsiString.
I must agree with you. I hope it will be removed in (far) future when
nobody uses the old Windows system
On Wed, May 3, 2017 at 12:13 PM, Ondrej Pokorny via Lazarus
wrote:
> Not if you need pre-unicode Delphi support :)
Ok, true. IMO such old Delphi versions should not be used any more for new code.
Maintenance tasks only I think.
Fortunately there is again a free Delphi Starter edition. It means
a
On Wed, May 3, 2017 at 2:43 PM, Mattias Gaertner via Lazarus
wrote:
> First it did not compile in Delphi, because of an unsupported inline. I
> fix that with an IFDEF FPC.
Right, I had added that after testing with Delphi.
The inline looks good to me, don't know why Delphi does not like it.
> Th
On Wed, May 3, 2017 at 12:03 PM, Juha Manninen
wrote:
> Marcos Douglas B. Santos wrote:
>> But if I put theses constants as resourcestrings, it's Ok as Mattias
>> told me, right?
>
> I don't think it makes any difference. You can use the full Unicode in
> both cases.
I stand corrected.
If you sha
On Thu, May 4, 2017 at 12:55 AM, Graeme Geldenhuys via Lazarus
wrote:
> On 2017-05-03 20:47, Juha Manninen via Lazarus wrote:
>> If you share and edit the sources between Delphi and Lazarus then you
>> cannot use the full Unicode.
>
> Quite comical considering that the FPC t
On Thu, May 4, 2017 at 2:47 PM, wkitty42--- via Lazarus
wrote:
> On 05/03/2017 05:21 AM, Juha Manninen via Lazarus wrote:
>> Encoding does not matter any more, as long as it is Unicode.
>
> reminds me of a saying that is attributed to Henry Ford...
> Any customer can have a car
On Thu, May 4, 2017 at 8:53 PM, Graeme Geldenhuys via Lazarus
wrote:
> You made me curious, so I want to take a look. Hopefully it doesn’t
> depend too heavily on the rest of LCL, so I’ll be able to use it in
> other projects of mine.
It has no dependency for LCL, it is part of LazUtils package j
On Fri, May 5, 2017 at 9:43 AM, Michael Van Canneyt via Lazarus
wrote:
> What tricks do you still need in 3.0.x ?
The annoying tricky part with our UTF-8 solution is the assignment of
Unicode string literals.
With UTF-8 BOM it does not work at all, as discussed here.
Without BOM it depends on str
On Fri, May 5, 2017 at 1:20 AM, Graeme Geldenhuys via Lazarus
wrote:
> A case in point. Looking at the Wiki page you listed, I read the following:
> "
> Since FPC 3.0 you must add the flag -FcUTF8 or add {$codepage UTF8} at the
> beginning of the unit.
> ...
Uhhh, the same page in "String Litera
On Fri, May 5, 2017 at 2:29 PM, Michael Van Canneyt via Lazarus
wrote:
> Then what is still the problem ?
With BOM you get:
Error: UTF-8 code greater than 65535 found
which is counter-intuitive when the file and the string literal are both UTF-8.
It is related to changing the default codepage at
On Fri, May 5, 2017 at 2:02 PM, Graeme Geldenhuys via Lazarus
wrote:
> If so, when why does LCL also call the above two functions?
Graeme, they are called by LazUtils package, LazUTF8 unit, not by LCL.
It is not limited to GUI programming.
A wrong information easily propagates, thus it is importa
On Fri, May 5, 2017 at 3:56 PM, Sven Barth via Lazarus
wrote:
> That is mainly due to the compiler not supporting surrogate pairs for the
> UTF-8 -> UTF-16 conversion. If it would support them, then there wouldn't be
> a problem anymore...
That is a serious bug. Getting codepoints right is the ab
On Fri, May 5, 2017 at 4:21 PM, Mattias Gaertner via Lazarus
wrote:
> Oops. Which one?
The FAQ says:
"Since FPC 3.0 you must add the flag -FcUTF8 or add {$codepage UTF8}
at the beginning of the unit."
The same page in "String Literals" section says:
"In most cases {$codepage utf8} / -FcUTF8 is
On Sun, May 7, 2017 at 9:35 PM, Fabio Luis Girardi via Lazarus
wrote:
> I (and others co-workers) have experienced the same behavior on Linux mint
> cinnamon 17.3 when Lazarus is built using gtk2 (using Lazarus 1.4, 1.6,
> fixes and trunk).
I have seen similar reports but no common cause was foun
Can you please create a proper backtrace with gdb using the latest
Lazarus trunk.
It shows also function names and parameter values etc.
I was actually able to reproduce the access violation once but not
more however much I tried.
Juha
--
___
Lazarus m
I have simplified and improved the page
http://wiki.freepascal.org/Unicode_Support_in_Lazarus
I tried to move relevant information to the top and remove duplicate
information.
For example there is a short "Usage" section with simple rules and then:
"These rules make most code already compatible
On Sat, May 13, 2017 at 6:55 PM, Werner Pamler via Lazarus
wrote:
> In section "Usage", "For string literals to work the source files must have
> UTF-8 encoding." - Add: "This is the default for source files written by
> Lazarus" - Otherwise people will begin to unnecessarily add these "$codepage
On Sat, May 13, 2017 at 7:56 PM, Sven Barth via Lazarus
wrote:
> Warning: the compiler does *not* consider the file as UTF-8 without a BOM or
> a set codepage!
Yes but that is a very misleading warning.
The whole thing works without a BOM better than with it because of the
"double cheat". See "St
On Sun, Jun 4, 2017 at 3:36 PM, Alexey via Lazarus
wrote:
> you tell that "if LowerCase(s)='default'"
> works faster than "if CompareText(s,'default')", but most of the fonts, dont
> start with letter "d" or "de"=> so CompareText takes one char only,
> LowerCase takes n chars=> LowerCase slower.
On Sun, Jun 11, 2017 at 4:23 PM, Martin Frb via Lazarus
wrote:
> If the row in the OI is NOT selected, then doubleclick works (or maybe it
> does select, then change).
Yes it is interpreted as 2 clicks.
FYI: you can change an unselected checkbox in OI by clicking the
actual box once.
> If the r
On Thursday, June 15, 2017, coppolastudio via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:
> Hi, I want to try Lazarus RC and as usually i was trying to install the
> package FPC 3.0.2 deb but failed because offline an old FPC in the Mint
> lmde repos, is there a way ti solve this?
>
The one
On Sat, Jun 17, 2017 at 11:25 PM, el es via Lazarus
wrote:
> But when, during the course of Queue()d callback,
> I FreeAndNil() the object that had the pointer to the callback procedure, I
> get SIGSEGV pointing at CheckSynchronize in Application. (address F0F0F0F0).
I don't know the details of t
I had to revert r54305 in r55396.
It caused regressions:
http://bugs.freepascal.org/view.php?id=31496
and
https://bugs.freepascal.org/view.php?id=32059
Denis Golovan, can you please test with a recent version of VTV and
then report to bug tracker if the freeze still happens.
Regards,
Juha
--
It surely is reported. See this and the related issues:
https://bugs.freepascal.org/view.php?id=30863
Nobody has found a way to fix it for good on every system. It is annoying,
yes.
Juha
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://
On Wed, Jul 5, 2017 at 12:49 AM, brian via Lazarus
wrote:
> I think "annoying" is a bit of an understatement, myself. If the final
> release of 1.8 still shows the problem *for me*, then I'm certainly
> going to be staying with 1.6.4.
It is not so serious because there are workarounds.
The proble
Moved from the "Release Candidate 3" thread:
On Wed, Jul 5, 2017 at 10:57 AM, Michael Van Canneyt
wrote:
> {
> "OutOfTopic" : ["If by mature you mean 'bloated', then yes.",
> "KDE has become so bloated, it has driven me away.",
> "To linux mint and cinnamon."
On Wed, Jul 19, 2017 at 10:11 AM, Maciej Izak via Lazarus
wrote:
> For now I know from Juha Manninen that
> Sparta for Qt under Linux is broken :\
I tested a little more.
Sparta form designer is broken for both GTK2 and QT.
I used FPC trunk but I guess it makes no difference. Manjaro Linux + KDE.
On Thu, Jul 20, 2017 at 2:39 PM, Ondrej Pokorny via Lazarus
wrote:
> IMO we should give the Lazarus foundation more importance/advertisement.
It should be the other way around. The foundation should advertise the
project it is associated with.
That is what foundations do with other projects.
Some
I simplifiled the code dealing with debugged file names in r55545.
Originally a bug related to symlinks was fixed:
https://bugs.freepascal.org/view.php?id=31577
but the fix was more complex than necessary.
Now it is simpler. Please test everybody. Everything related to
debugging should work as be
On Tue, Jul 25, 2017 at 3:01 PM, Lars via Lazarus
wrote:
> Is it because of QT 5 ?
No. I have understood QT 5 is more modular, optimized and lighter than QT 4 was.
Juha
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-id
A serious issue with QT: When opening an existing form with controls,
the IDE still freezes. Memory overflow, core dump is created.
A minor issue with QT: The designer tab is opened initially when the
IDE is started. The editor tab should be opened.
I remember a similar problem was fixed a long ti
On Wed, Jul 26, 2017 at 9:53 AM, Anthony Walter via Lazarus
wrote:
> Juha, I just tested on Qt4 (I haven't tested Qt5 yet) and the sparta form
> designer is working great with the latest svn trunk, ...
Did you try opening an existing project with a form + some components on it?
I works for me, to
On Thu, Jul 27, 2017 at 1:24 AM, Anthony Walter via Lazarus
wrote:
> Please see issue #32209 for a working fix. Someone familiar with the LCL Qt
> widget implementation needs to look at this in more depth.
The issue appears to be inherent to QT, not caused by LCL-QT code.
I added a comment in the
On Sun, Jul 30, 2017 at 6:06 PM, Werner Pamler via Lazarus
wrote:
> The Lazarus xml procedures are in package LazUtils which is a prerequisite
> for, but not part of, LCL. So, you can use these procedures without adding a
> requirement for LCL, LazUtils is sufficient.
Exactly. The earlier Lazarus
On Wed, Aug 2, 2017 at 5:08 PM, Fabio Luis Girardi via Lazarus
wrote:
> Whats the current state of Lazarus when dealing with packages with dotted
> units (namespaces)?
Dotted unit names are supported more or less.
> Should I avoid this idea?
No. Instead please work with them and report problems
On Wed, Aug 2, 2017 at 5:46 PM, Juha Manninen wrote:
> - The original bug is fixed long time ago, but I understood there are
> 2 others that should be reported separately.
> - F12 in designer.
> - Codetools issues.
... and those may be fixed already, too.
Juha
--
___
On Wed, Aug 2, 2017 at 5:55 PM, Marcos Douglas B. Santos via Lazarus
wrote:
> I believe they were already fixed. I'm using it without these problems.
Thanks. I was lazy to test myself now.
Ondrej resolved the issue. The dotted names support may be quite perfect now.
Juha
--
On Sun, Aug 13, 2017 at 1:21 AM, Bo Berglund via Lazarus
wrote:
> So AnsiString is not safe either
That is a little misleading.
Actually using the Windows system codepage is not safe any more.
The current Unicode system in Lazarus maps AnsiString to use UTF-8.
Text with Windows codepage must
On Sun, Aug 13, 2017 at 1:21 AM, Bo Berglund via Lazarus
wrote:
> I recently had a problem with an application that was converted from
> old string type to AnsiString and seemingly worked in the new Unicode
> environment.
What was the old string type?
> However, we received reports that it had f
On Sun, Aug 13, 2017 at 7:41 PM, Bo Berglund via Lazarus
wrote:
> And our data are NOT text, they are binary streams of bytes.
I see. Then TBytes indeed is the best choice.
You have misused "String" or "AnsiString" from the beginning for binary data.
There have always been warnings against it.
Th
On Mon, Aug 14, 2017 at 5:11 PM, Tony Whyman via Lazarus
wrote:
> Indeed, why isn't there a single container string type for
> all character sets where the encoding whether a legacy code page, UTF8,
> UTF16 or UTF32 is simply a dynamic attribute of the type - a sort of
> extended AnsiString?
As S
On Wed, Aug 16, 2017 at 8:53 AM, Bo Berglund via Lazarus
wrote:
> Based on this experience I wanted to alert the OP of the fact that
> using AnsiString instead of string is not a cure-all for binary data,
> you need to fix the codepage too, which is what the RawByteString does
> for you
Bo, e
On Mon, Aug 14, 2017 at 4:11 PM, Marcos Douglas B. Santos via Lazarus
wrote:
> Unicode everywhere and you using AnsiString and doing everything...
> Now I'm confused.
Yes, please read:
http://wiki.freepascal.org/Unicode_Support_in_Lazarus
I have advertised it so much that some people are already
On Mon, Aug 14, 2017 at 4:21 PM, Tony Whyman via Lazarus
wrote:
> UTF-16/Unicode can only store 65,536 characters while the Unicode standard
> (that covers UTF8 as well) defines 136,755 characters.
> UTF-16/Unicode's main advantage seems to be for rapid indexing of large
> strings.
That shows com
On Wed, Aug 16, 2017 at 12:12 PM, Michael Schnell via Lazarus
wrote:
> UTF-8 and UTF-16 are just encoding variants for 32 bit Unicode "characters",
> storing them in n (or 2*n) Bytes according to a simple scheme.
No, they are encodings for codepoints, not "characters" (whatever that means).
Mich
On Wed, Aug 16, 2017 at 3:37 PM, Alexey via Lazarus
wrote:
> See my prev post: i see that each S[i] good to be like QWord (sizeof(one
> char)= sizeof(Qword)). It can be TextChar. And type can be TextString.
> internally it can be compressed to utf8. TextString is good if i want to
> parse text by
On Wed, Aug 16, 2017 at 2:47 PM, Michael Schnell via Lazarus
wrote:
> -Michael (It's rather frustrating to discuss that obviously never will
> happen :-()
Why don't you implement such a system. This is all FOSS, free and open source.
You are writing about encodings etc. which are part of codepoi
On Wed, Aug 16, 2017 at 5:13 PM, Marcos Douglas B. Santos via Lazarus
wrote:
> Thanks. I know about this page... unfortunately looks like it is not
> enough, since many others still complain.
What is missing? I can try to improve it.
> This thread is not only about WinAPI. I have this problem be
On Wed, Aug 16, 2017 at 4:49 PM, Michael Schnell via Lazarus
wrote:
>> You are writing about encodings etc. which are part of codepoints, but
>> you call them "characters". Why?
>
> Because the type for this stuff used in Delphi and and FPC is called "char".
No, actually the Pascal type "Char" co
On Wed, Aug 16, 2017 at 5:48 PM, Marcos Douglas B. Santos via Lazarus
wrote:
> I cannot say from others, but I had this issue (about WideString) for now.
The section "Calling Windows API" says:
'Only the "W" versions of Windows API functions should be called. It
is like in Delphi except that you
On Wed, Aug 16, 2017 at 6:24 PM, Martin Frb via Lazarus
wrote:
> Actually no.
I know CodeUnit and CodePoint are not called "character" officially by
the Unicode Standard.
They however are called "character" in normal communication.
For example in the "String vs WideString" thread most people used
On Wed, Aug 16, 2017 at 7:53 PM, Martin Frb via Lazarus
wrote:
>> I know CodeUnit and CodePoint are not called "character" officially by
>> the Unicode Standard.
>> They however are called "character" in normal communication.
>
> And that is where the problem starts.
> ...
Exactly. Discussions wh
I answer here Tony's post in "String vs WideString" thread.
On Thu, Aug 17, 2017 at 2:09 PM, Tony Whyman via Lazarus
wrote:
> Are you making my points for me? If such a basic term as "character" means 7
> different things then something is badly amiss. It should be fairly obvious
> that in this
On Wed, Aug 23, 2017 at 1:28 PM, Andrea Mauri via Lazarus
wrote:
> any chance to fix them?
> how can I help?
You can help by providing a patch that fixes them. A valid patch will
be applied for sure.
I found other similar bug reports and marked them as related to the
ones Denis listed.
Juha
--
On Fri, Aug 25, 2017 at 1:29 PM, Andrea Mauri via Lazarus
wrote:
> I would. But I think that is out of my skills. Where should I look? Any
> starting point?
I don't know. I don't have a Mac.
In general contributors / developers just have to learn the code by
debugging and experimenting, little by
In my tests Lazarus compiled with FPC trunk for GTK2 widgetset breaks
AnchorDocking completely.
Please see my comment here:
https://bugs.freepascal.org/view.php?id=32342#c102573
Can others reproduce or is it just my config issue?
Juha
--
___
Lazarus ma
Regarding issue:
https://bugs.freepascal.org/view.php?id=32375
Could somebody please provide a debugger backtrace and preferably a
patch to fix it.
Also finding out which revision caused the regression would be helpful.
http://wiki.freepascal.org/How_do_I_create_a_bug_report#Regression_caused_b
On Sun, Sep 24, 2017 at 9:20 PM, Michael W. Vogel via Lazarus
wrote:
> I added the relavant info on bugtracker.
Thanks.
You found the InterfacePropertyEditor and issue:
https://bugs.freepascal.org/view.php?id=31324
as the culprit.
There was a similar issue:
https://bugs.freepascal.org/view.ph
Marcos Douglas, this wiki page answers all your questions about using
Unicode with Lazarus:
http://wiki.freepascal.org/Unicode_Support_in_Lazarus
On Mon, Sep 25, 2017 at 9:19 PM, Ondrej Pokorny via Lazarus
wrote:
> You will have to write your own methods with IFDEF-ed code for things
> where it
And more ...
Marcos Douglas, the Unicode solution in Lazarus works amazingly well
when your data is Unicode from the start.
It only has trouble with Windows system codepages but they can be
converted, too.
Question: what is the fundamental problem? Why can't you use the
system as it is advertised
On Tue, Sep 26, 2017 at 3:14 AM, Marcos Douglas B. Santos via Lazarus
wrote:
> So, you mean that I cannot declare a constant without specify the
> type. The language allow me but it won't work?
Yes you can declare a string constant without specifying the type.
> 3.1. "When a parameter type is a
On Tue, Sep 26, 2017 at 4:37 AM, Marcos Douglas B. Santos via Lazarus
wrote:
> But according with this table, I shouldn't do that because so many
> problems could happen.
> http://wiki.freepascal.org/Unicode_Support_in_Lazarus#Without_.7B.24codepage_utf8.7D_or_compilerswitch_-FcUTF8
No. It works
On Tue, Sep 26, 2017 at 12:11 AM, Marcos Douglas B. Santos via Lazarus
wrote:
> Yeah, but DOM uses DOMString, which is WideString.
> Lazarus uses UTF8 and have a laz2_DOM that uses "string", which is
> UTF8, but I cannot use this unit with XPath unit, which needs a
> TXMLDocument that works with W
On Tue, Sep 26, 2017 at 10:52 PM, Marcos Douglas B. Santos via Lazarus
wrote:
> So we can say that Lazarus code do not use XPath to work with XML, right?
No I cannot say much about the issue. I didn't try it myself.
I understood Mattias and Michael V.C. have plans to migrate the XML
units to FCL
On Sat, Sep 30, 2017 at 3:59 AM, Vojtěch Čihák via Lazarus
wrote:
> unicodeinfo.pas(1180,53) Error: Wrong number of parameters specified for
> call to "UnicodeToUtf8"
>
> Error: Found declaration: UnicodeToUtf8(PChar;PUnicodeChar;Int64):Int64;
I downloaded UTF8tools from the wiki page and compile
Ok yes, the function name UnicodeToUtf8 is unfortunately used in both
FPC's libs and in Lazarus LazUtils package LazUTF8 unit. It will cause
confusion also in the future.
Juha
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazar
On Tue, Oct 3, 2017 at 6:06 PM, Чернов Дмитрий via Lazarus
wrote:
> Good day everyone.
>
> Recently I've recognized some problems with ProductVersion field in the
> integrated Lazarus support of VersionInfo. Version of Lazarus is 1.6.4.
>
> Attached patch fixes them. It's based on Lazarus codebase
Is it related to issue:
https://bugs.freepascal.org/view.php?id=32333
?
If yes, please upload the patch there.
Bug tracker is the recommended way to deal with patches anyway.
Juha
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.
What can cause it? Certainly it is not disabled in purpose.
Juha
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
On Sat, Oct 7, 2017 at 3:29 PM, Denis Kozlov via Lazarus
wrote:
> Perhaps a Linux or GTK2 only issue.
Probably a widgetset issue.
Torsten, please test with LCL-QT, too.
Juha
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazar
On Mon, Oct 9, 2017 at 9:49 AM, Lubos Pintes via Lazarus
wrote:
> screen reader reports only "button", instead of "StartIDE button", "Help
> button", etc. Yes, the button itself is native, but is broken.
O wonder why that is so. The button really is a native button. Why
does it not know its capti
*I wonder ...
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
On Sun, Oct 8, 2017 at 11:09 PM, Lubos Pintes via Lazarus
wrote:
> Also, how can I rebuilt the package when I modify/add some unit? Do I need
> to always rebuild the IDe, or there is a quicker way?
You can test with any small application. No need to build the whole IDE.
The dependent LCL is compi
On Mon, Oct 9, 2017 at 2:10 PM, Leonardo M. Ramé via Lazarus
wrote:
> My procedure is, first *svn up* fpc, then compile and install with defaults
> (into /usr/local/lib/fpc/3.1.1). The next step is again *svn up* Lazarus
> dir, then *make clean all*.
You don't need FPC trunk to compile Lazarus tr
On Mon, Oct 16, 2017 at 4:43 PM, Martok via Lazarus
wrote:
> when I checked what HTML2TextRenderer uses to translate list items, I found
> that
> since rev 55743 it uses U+26AB MEDIUM BLACK CIRCLE ⚫ and U+26AA MEDIUM WHITE
> CIRCLE ⚪.
No. Since r55743 it uses one of the star emojis.
See in const
On Mon, Oct 16, 2017 at 8:56 PM, R0b0t1 via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:
> Is it not possible to bundle supported resources in the LCL? That seems
> like the typical solution for Windows. On other OSes this is less proper,
> but I have still seen it done.
>
Excuse me?
How could
It is easy to find by typing "outline" into the filter in Options dialog.
Juha
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
On Sun, Oct 22, 2017 at 11:43 AM, FTurtle via Lazarus
wrote:
> Could revisions 56094, 56095 be merged to 1.8 ?
> (Arrange ToolBarConfig categories in a natural way.)
> Report: https://bugs.freepascal.org/view.php?id=32557
Only bug fixes should go to 1.8 now. Arranging categories differently
is no
Sorry FTurtle but I would rather keep this change in trunk only.
People may have different opinions about the order. This is a typical
change that must happen in the development version and not be pushed
to the release at last minute.
Besides, you as a semi-developer of Lazarus will use mostly trun
On Wed, Oct 25, 2017 at 8:30 PM, Vojtěch Čihák via Lazarus
wrote:
> I got this code for design time editing (note the line+comment ***
> aHook.SelectOnlyThis(aECTC.Tabs); { force the OI to refresh } ***).
>
> That line should refresh OI so the deleted item (CollectionItem) is removed
> (node in O
On Sun, Oct 29, 2017 at 12:23 PM, Samuel Herzog via Lazarus
wrote:
> B) Examples that work out of the box. ( when I choose examples in Lazarus,
> half of them do not work).
We would need a list of those.
I remember I went through the examples some time ago and they compiled
and also worked someho
On Sun, Oct 29, 2017 at 5:04 PM, Carlos E. R. via Lazarus
wrote:
> Well, I use Linux :-)
I also use Linux and I have tested them, too.
> Of course not all examples fail, and maybe some were corrected since I
> tried.
When did you try?
> Well, I can try, but I have no idea where/how to report b
On Mon, Oct 30, 2017 at 12:48 AM, Carlos E. R. via Lazarus
wrote:
> About a year ago or more.
> ...
> /usr/share/fpcsrc/packages/fv/examples/testapp.lpi
Ok, this was about FPC examples. I assumed Lazarus examples because
this is Lazarus list.
A year ago there may have been more broken Lazarus exa
On Mon, Oct 30, 2017 at 8:56 AM, Sven Barth via Lazarus
wrote:
> Alternatively you can use the bug tracker that both projects share at
> https://bugs.freepascal.org/
FYI, those bugs should be reported against FPC trunk which already
differs a lot from the release version, due to the slow release
On Tue, Oct 31, 2017 at 11:25 AM, Alexey via Lazarus
wrote:
> It is caused by WinAPI truncating path. i suggested to make workaround for
> WinAPI, but guys declined.
This was the issue:
https://bugs.freepascal.org/view.php?id=31312
I was surprised that Application.MessageBox and ShowMessage beha
Yes, build Lazarus with GTK_REMOVE_CLIPBOARD_NULL.
There are 2 alternative bugs. Choose the one that bothers you less. :(
I will be happy if somebody finds a way to fix it properly. I don't
understand the relevant code enough.
Juha
--
___
Lazarus maili
On Mon, Nov 13, 2017 at 5:26 PM, Dmitry D. Chernov via Lazarus
wrote:
> This is slightly related with recently fixed #32606: my patch fixes only
> wrong inactive state, patch for #32606 fixes determination of the identifier
> under the carriage, as a whole.
>
> This bug is very annoying when you
I finally added a unit IntegerList and class TIntegerList into LazUtils package.
It has a simple implementation using generics.
TIntegerList = class(specialize TFPGList)
I already replaced some TList hacks for integers which required ugly
typecasts like
Integer(PtrUInt(...))
and
Pointer(PtrIn
On Mon, Nov 13, 2017 at 7:58 PM, Alexey via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:
> Thanks for this new list. Diff like
> - Result:=integer(PtrUInt(FCols[aCol]))
> + Result:=FCols[aCol]
>
> shows it's useful. It supports Longint or PtrInt or PtrUInt? Or i need
> another list for PtrInt?
On Mon, Nov 13, 2017 at 8:13 PM, Alexey via Lazarus
wrote:
> Good to include lists for [Int64, PtrInt, PtrUInt] to the same unit.
List of PtrInt or PtrUInt makes no sense. Those types are used only
when casting to/from a Pointer which typically involves some ugly
hack. The original type was wrong
The issue is fixed in r56398 with a patch provided by Dmitry.
Please test everybody.
Juha
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
1 - 100 of 497 matches
Mail list logo
