Re: [Lazarus] Docked Form
Am 12.06.2015 um 18:15 schrieb Juha Manninen: On Fri, Jun 12, 2015 at 4:03 PM, Maciej Izak hnb.c...@gmail.com wrote: IMO the best option for Lazarus is synergy of solution from CodeTyphon (the way of handling docked form in many platforms) and FreeSparta (elastic interfaces, it handles many usefull events like: Sounds good but how much are you willing to help with it? I have now time for Lazarus development but I don't know where to look for your docking code or elastic interfaces. We need a patch against Lazarus trunk. Two problems with docking: 1) Delphi-docking is not well supported, else the IDE DockManager could be used. 2) The IDE has much code for window placement, all over, instead of a common window layout manager. [1] Could be fixed, but the required patches (of Controls.pas) are rejected by the Lazarus team. for too many changes at a time :-( [2] I tried to replace the many window placement calls in the IDE by a better window management, but finally gave up. The IDE window managers are quite useless, except for the existing inflexible solution. Most probably patches will be rejected with the same rationale. IMO a general layout manager interface would be nice, where Delphi-docking, AnchorDocking or any other layout manager could be hooked in. But it looks like impossible to remove AnchorDocking from Controls, it's too much interwoven with AutoSize and other basic control methods, and will cause conflicts with any other layout manager. That's why I stopped working on Lazarus a long time ago :-( DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docked Form
Am 13.06.2015 um 11:41 schrieb Juha Manninen: On Sat, Jun 13, 2015 at 12:17 PM, Hans-Peter Diettrich drdiettri...@gmx.de wrote: Two problems with docking: 1) Delphi-docking is not well supported, else the IDE DockManager could be used. 2) The IDE has much code for window placement, all over, instead of a common window layout manager. A docking API is a good idea. I think Maciej had similar idea with his ToolsAPI thing. Docking is only one special method for adding, removing or rearranging components. The basic API will arrange, measure and resize child components, according to its own rules, when told to do so. See the Java layout managers, which can be selected independently into any container control. It should not be hard to work out an according API, the problem is to make e.g. AnchorDocking work as such a selectable layout manager. Dodi, I remember you patches were rejected because they did not work. Perhaps the patches were already outdated when supplied, but they worked on my system. Who can tell which concurrent changes will affect some code, unless the functional responsibilities and interaction of parts of the affected code is well defined? They were more like shooting around blindly. They may *look* so, in detail the IDE patches, but how would you start adding an manager to previously unorganized code? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Log4D weirdness
Am 31.12.2014 um 21:51 schrieb Marco van de Voort: Afaik the problem is that const as used in classic delphi is not very portable. In theory it is specified as immutable (can't be modified), but widely abused to mean by reference. Const parameters exist for optimization, the compiler is allowed to pass them by reference instead of a copy. This happens to be the case for x86 ABIs, but this is not portable (which why FPC introduced constref) I don't see how this is not portable - as long as the procedure is OPL. External procedures of other languages don't leave room for such an optimization, even in x86 ABIs, that's why constref was introduced for them. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Log4D weirdness
Am 27.12.2014 um 22:49 schrieb Marco van de Voort: On Fri, Dec 19, 2014 at 06:49:07PM -0300, Mario R. Carro wrote: There's a LogLog variable that is destroyed in the finalization section (and fails). The problem is that the TLogODSAppender created in the ctor ends up destroyed inside the AddAppender call. This is the AddAppender code: procedure TLogLogger.AddAppender(const Appender: ILogAppender); [...] Yes, this is a known kind of buggy code. (buildin assumptions of Delphi code that only happens to work on Delphi). Delphi /usually/ destroys automatically created temps at the end of a function, while FPC can also do it after a block. Best is to explicitely keep a local variable reference, local variable references are kept to the end at the moment, as you already found out. Who is at fault here? Log4D? The compiler? Me? Hard to say, there is some opinion involved there. Like many cases, Delphi does not specify this behaviour, and in general for Delphi not much is known what of the implementation is intended, or what is coincidence. This is aggrevated by the fact that too much Delphi code messing with interface refcounting seems to be created with trial and error. Also strings had (have?) problems with refcounting of *const* parameters in Delphi. As a first try I remove the const, in case of unexpected trouble. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Only VCL-compatible components in LCL
Am 11.12.2014 um 14:29 schrieb Dmitry Boyarintsev: On Thu, Dec 11, 2014 at 1:11 AM, Hans-Peter Diettrich drdiettri...@gmx.de mailto:drdiettri...@gmx.de wrote: As I understand that: The components in the LCL should be available with all supported widgetsets. An implementation for only one widgetset is not worth of adding it to the LCL, because it would burden the LCL maintainers with the implementation for all other widgetsets. On the other hand, it pretty much blocks anyone else to add components to LCL. Because an author has to introduce a solution for all (or most?) widgetsets by LCL. With more widgetsets introduced to LCL, it might be next to impossible for some developers. Why not leave it to the LCL maintainers, which controls should be added to the LCL, and which not? Provide them good reasons for doing so... DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Only VCL-compatible components in LCL
Am 11.12.2014 um 00:20 schrieb Graeme Geldenhuys: On 2014-12-09 22:29, Michael Fuchs wrote: It is not a problem for me, to publish this component outside the LCL. I was just surprised, that the development of the LCL has such a strong dependency to the VCL. Maybe I'm not understanding Juha, but I think this is rubbish. It's not that black and white. LCL contains a lot of components not compatible or not existing in the VCL. But I also understand that they don't want every single component included in the LCL, because it means they will probably end up having to support it. As I understand that: The components in the LCL should be available with all supported widgetsets. An implementation for only one widgetset is not worth of adding it to the LCL, because it would burden the LCL maintainers with the implementation for all other widgetsets. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPC 2.7.1 and console output
Mattias Gaertner schrieb:
On Thu, 04 Dec 2014 07:00:59 +0100
Hans-Peter Diettrich drdiettri...@aol.com wrote:
UTF8Console is needed, when your source is UTF-8, but the compiler
thinks it is Windows CP. UTF8Console is defined in LazUTF8.
An alternative is UTF8Decode.
Thanks :-)
Just tested on WinXP:
program test;
var a: AnsiString;
begin
a := 'äöü';
WriteLn(a,'äöü');
end;
works differently with file encoding Ansi, UTF-8 and UTF-8bom. The
latter correctly shows 'äöüäöü', else a mix of several encodings shows
up in the console.
I see.
Only after testing the string encodings I found out that $codepage does
not affect CP_ACP, this was unclear to me before. A new Lazarus version
instead may try to set DefaultSystemCodePage to UTF-8, in order to
preserve compatibility with the current assumption about UTF-8 encoding
with AnsiStrings.
Indeed I never tried passing a constant in writeln.
You never wrote text or separtors?
Does Delphi also pass constants unconverted to writeln?
Delphi does not convert anything in console output, the user must
convert everything to CP_OEM :-(
{$codepage UTF8} requires UTF-8 file encoding as well, doesn't
compile when stored as Ansi.
What do you mean with doesn't compile? What compiler error?
Hmm, until yesterday the error message was illegal character... - or
was it file I/O error? - with non-ASCII characters in string literals.
Just tested, the error has disappeared, instead garbage is displayed at
runtime. Now string literals seem to be stored as UTF-8 (file encoding),
with 0 (CP_ACP) for the encoding. That means that the UTF-8 bytes are
treated at runtime as being DefaultSystemCodePage characters. You
certainly can imagine what happens in a conversion of these bytes into a
different encoding :-(
DoDi
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPC 2.7.1 and console output
Mattias Gaertner schrieb:
On Tue, 02 Dec 2014 22:41:04 +0100
Hans-Peter Diettrich drdiettri...@aol.com wrote:
Next I tried FP, but couldn't figure out how to configure it at all, for
using the trunk compiler :-(
Do you mean in Lazarus?
No, the FP IDE. It has become almost useless, most options are read-only :-(
What do you mean with string output?
WriteLn to the console.
Beware that if you want to test string encoding, console is deceiving.
Input and output.
Until now wrong console output indicated a problem with the encoding of
the strings to output - that's what I want to know, for further test.
Otherwise the conversion to the actual console CP is working, because
the fpc_Write_Text_xyz routines use RawByteString arguments, so that
they have to check the dynamic string encoding. Ordinary subroutines,
that use other string argument types, will almost produce random
results, because AnsiStrings tend to have a dynamic encoding different
from the expected (static) encoding. I wonder when this flaw will be
fixed :-(
You can use your current codepage as source encoding, or use UTF-8
sources and function UTF8ToConsole for x-platform. The latter is
does not magically extend the limitations of the console, but at
least other people can read your sources and you can use your code
with the LCL.
Using UTF-8 sources *and* {$codepage UTF8} cures the unusable CP_ACP
encoding of string literals, they are converted as expected in immediate
output or when assigned to any AnsiString. Other settings cannot work
with the current handling of AnsiString :-(
DoDi
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPC 2.7.1 and console output
Mattias Gaertner schrieb:
On Tue, 02 Dec 2014 22:41:04 +0100
Hans-Peter Diettrich drdiettri...@aol.com wrote:
[...]
I can see two major problems with the current FPC AnsiString model. The
first problem is the strange FPC convention, that a string variable can
have a different static/dynamic encoding, not only with RawByteString.
That convention (flaw) can require an explicit SetCodePage for every
string parameter, because a string argument of e.g. static type CP_OEM
(for console output) can have any other actual (dynamic) encoding, not
useful when passing the string to the external function.
The FPC sources need SetCodePage only in the RTL and only either for
codepage conversion functions or for Default(RTL)FileSystemCodePage.
It seems it is not a major problem for Lazarus users.
Let's see, currently I try to debug AnsiUpperCase, that doesn't seem to
work.
Q: how do I debug the RTL (step into)?
The next problem results from the Delphi incompatible dynamic encoding
of CP_ACP(=0), that seems to be used when a literal is stored in an
AnsiString. These strings have the encoding assumed at *compile time*,
perhaps from a {$codepage ...} switch, which can differ from the
DefaultSystemCodepage at *runtime*. Then the conversion routines assume
the the string is encoded according to DefaultSystemCodepage, what's not
necessarily true:
var
A: AnsiString;
begin
a := ' äöü';
WriteLn('CP_ACP=',DefaultSystemCodePage);
WriteLn('Ansi CP=',StringCodePage(a),' Len=',Length(a),' =',a,'');
end.
Reports (on Windows) CP_ACP=1252, string CP=0, and due to the Lazarus
File Encoding of UTF-8 the string literal and variable contains UTF-8
(Len=7), as assumed by the compiler. The attempt in WriteLn, to convert
the string to CP_OEM from encoding 0, mapped by TranslatePlaceholderCP
into DefaultSystemCodePage (=1252 at runtime), results in a conversion
of the UTF-8 bytes from CP 1252 into CP_OEM :-(
I described two ways in my other mail how to handle that.
I don't want want workarounds for a flawed FPC implementation, I want an
FPC working on Windows without hacks.
About the example:
Writeln on the Windows Console requires the console codepage and is
therefore limited to characters of this codepage.
That's perfectly sufficient for my tests.
If your code contains
literals for a specific Windows codepage then you are limiting
yourself to that codepage (not x-platform). That is your choice.
OTOH Lazarus main target is x-platform programs. For example the
UTF8ToConsole solution works on Unix too, while your CP1252
example does not.
What's CP1252 specific in my example?
With FPC 2.7.1 there is a new possibility.
Please note that I *am* using and writing about FPC 2.7.1.
With the new UTF-8 mode
your example gives:
CP_ACP=65001
Ansi CP=0 Len=7 = äöü
This works on Unix too, while the CP1252 example does not.
Under Windows it works if the console codepage contains äöü (which
can be more than one codepage). Basically the compiler adds the
UTF8ToConsole for you.
This works only for a DefaultSystemCodePage of UTF-8, see your CP_ACP
encoding shown above :-(
If this doesn't change, the string encodings are quite useless, and a
single AnsiString type of fixed encoding CP_UTF8 were sufficient (and
faster, due to omitted string conversions). Windows users may not like
that, some prefer to use the default Windows codepage or UTF_16 instead
(Delphi compatible).
[...]
Delphi string literals instead come with their true dynamic encoding, which
never can be 0, and thus can be assigned and shown properly. Above code
then will show CP=1252 and Len=4 for the AnsiString variable.
No, it should show garbage and Len=7, because the source is UTF-8,
while the compiler treats it as your system codepage.
Well, I tested my program with XE, with the default Windows textfile
encoding. When FPC or Lazarus has problems with such a program file,
then something is flawed :-(
DoDi
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Code Browser
Lazarus 1.3 shows the codebrowser when I hit F1 on an unknown (incomplete...) identifier. That's a nice feature, but searching in the browser can become tedious. When a unit is missing from a uses list, searching in the project files seems not to be the right choice, instead it seems to be required to search the FCL as well(?) - what takes a considerable time. Unfortunately the browser restarts the search as soon as I try to change the search string, before I finish typing :-( Suggestions: 1. Wait until the user presses Rescan, optionally add an according (Auto Rescan) checkbox. 2. Add an Stop/Cancel button, that allows to stop the search (not closing the browser window!). 3. Add F1 and/or Help button for help on using the Code Browser. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPC 2.7.1 and console output
Mattias Gaertner schrieb:
On Wed, 03 Dec 2014 16:46:43 +0100
Hans-Peter Diettrich drdiettri...@aol.com wrote:
[...]
Q: how do I debug the RTL (step into)?
Compile it with debugging info (-gl) and install it.
Thanks, I added OPT=-gl to the make commandline, and it worked :-)
[...]
If your code contains
literals for a specific Windows codepage then you are limiting
yourself to that codepage (not x-platform). That is your choice.
OTOH Lazarus main target is x-platform programs. For example the
UTF8ToConsole solution works on Unix too, while your CP1252
example does not.
What's CP1252 specific in my example?
Your example works if you use CP1252 as source encoding, as I have
told you. I'm not sure why you call that a 'hack'.
I included the code (readable by everybody), didn't transmit an file.
Also UTF8ToConsole seems not to exist any more in FPC 2.7.1, and should
not be required any more.
So I'm not sure what you mean :-(
Just tested on WinXP:
program test;
var a: AnsiString;
begin
a := 'äöü';
WriteLn(a,'äöü');
end;
works differently with file encoding Ansi, UTF-8 and UTF-8bom. The
latter correctly shows 'äöüäöü', else a mix of several encodings shows
up in the console.
Using the default Lazarus file encoding (UTF-8 without BOM) requires to
add {$codepage UTF8}, to make the program (hopefully) work on either
platform. {$codepage UTF8} requires UTF-8 file encoding as well, doesn't
compile when stored as Ansi.
Adding SysUtils, and AnsiUpperCase for the WriteLn arguments, correctly
shows 'ÄÖÜÄÖÜ' in Ansi file encoding, but 'äöüäöü' in UTF8bom encoding,
garbage with UTF-8 file encoding, and again 'äöüäöü' with added
{$codepage UTF8}.
Thus portable source files seem to be bound to both file and $codepage
UTF-8, disallowing different CP_ACP settings (for now).
Since I'm just exploring the Unicode support, I hope to mention in the
future all related options, possibly influencing the behaviour of sample
code. Apart from that I'd expect (hope) that a given (Delphi...) project
will work in FPC/Lazarus as well, at least on Windows, regardless of
inobvious requirements like CP_ACP settings (see bottom lines).
[...]
Delphi string literals instead come with their true dynamic encoding, which
never can be 0, and thus can be assigned and shown properly. Above code
then will show CP=1252 and Len=4 for the AnsiString variable.
No, it should show garbage and Len=7, because the source is UTF-8,
while the compiler treats it as your system codepage.
Well, I tested my program with XE, with the default Windows textfile
encoding.
Ah, so you tested CP1252 encoding under XE.
How else should I compare the results of running the same code in Delphi
and FPC/Lazarus? Actually I'm testing the Delphi compatibility of FPC
(trunk).
The same works under FPC.
When FPC or Lazarus has problems with such a program file,
then something is flawed :-(
PEBCAK
Please point me to the according Lazarus documentation.
When some Delphi user wants to find out whether Lazarus is a usable
alternative, what should he know before trying to run some Delphi code
in Lazarus? If this is not documented appropriately, many people may
drop Lazarus immediately as unusable (incompatible...) :-(
DoDi
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPC 2.7.1 and console output
Mattias Gaertner schrieb:
On Wed, 03 Dec 2014 16:06:28 +0100
Hans-Peter Diettrich drdiettri...@aol.com wrote:
[...]
Otherwise the conversion to the actual console CP is working, because
the fpc_Write_Text_xyz routines use RawByteString arguments, so that
they have to check the dynamic string encoding. Ordinary subroutines,
that use other string argument types, will almost produce random
results, because AnsiStrings tend to have a dynamic encoding different
from the expected (static) encoding.
What example are you referring to?
See AnsiUpperCase.
[...]
Using UTF-8 sources *and* {$codepage UTF8} cures the unusable CP_ACP
encoding of string literals, they are converted as expected in immediate
output or when assigned to any AnsiString. Other settings cannot work
with the current handling of AnsiString :-(
CP_ACP is usable with the DefaultSystemCodepage.
Currently AnsiUpperCase etc. will work on Windows *only* if
DefaultSystemCodePage matches the WinAPI CP_ACP.
DoDi
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPC 2.7.1 and console output
Sven Barth schrieb: You need to build the FP included with trunk, because the compiler is statically linked into FP. This is usually done when you do a make all or at least when you do a make install. Thanks, looks as if I used the FP of the old (bootstrap compiler) installation. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] FPC 2.7.1 and console output
First I thank the Lazarus team for the fine 1.3 version, usable for
development with FPC trunk (Unicode version). In detail the greyed-out
branches in conditional compilation sections are very helpful when
inspecting the RTL units :-)
On my first steps with the Unicode RTL I found a different behaviour,
when a console program is compiled from an PAS file, and from an LPI/LPR
project. [on WinXP, Ansi source files]
When compiled from an PAS file, the behaviour is identical to the direct
compilation on the commandline, string output is readable.
When compiled from an LPR file (LPI project), the string output has
unreadable UTF-8 encoding, even for UnicodeString. Did I miss some
project setting, required for proper console output?
When I try {$codepage 1252}, I get an error during compilation (file
not open)? The charset unit, mentioned in help on $codepage, doesn't
give any clues about allowed values. What's the correct value for
Windows default (western)? Or how else can I establish a global default
sourcecode codepage?
DoDi
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPC 2.7.1 and console output
Mattias Gaertner schrieb:
On Tue, 02 Dec 2014 11:21:43 +0100
Hans-Peter Diettrich drdiettri...@aol.com wrote:
On my first steps with the Unicode RTL I found a different behaviour,
when a console program is compiled from an PAS file, and from an LPI/LPR
project. [on WinXP, Ansi source files]
What do you mean with compiled from an PAS file?
I wrote my first test programs with NotePad, and called FPC from the
commandline. These files also compile okay with Lazarus, when loaded as
projects.
Next I tried FP, but couldn't figure out how to configure it at all, for
using the trunk compiler :-(
Finally I managed to build Lazarus trunk, and that's where I'm now.
When creating a project in Lazarus, the default file encoding (now?)
seems to be UTF-8 without BOM, at least I had no problems with older
versions - maybe because I only used ASCII in my programs, and rarely
wrote console programs.
So how can I convince Lazarus to use (and assume) source files of my
(non-VCL) projects being Windows codepage (1252)?
You can see what parameters the IDE passed to the compiler. Right click
on the messages (e.g. the Compile Project...), then About Compiler
Project
Then I need an wizard that explains me the consequences of (not) using
any possible switch :-(
Have you set any flags in the Configure Build Lazarus dialog?
Not yet, I had a hard time until I could build and configure the current
Lazarus trunk version. It looks to me as if the last FPC *release*
version is required to build Lazarus, while I want to use the *trunk*
version for compiling my own projects. If so, how do I tell all that to
Lazarus?
What do you mean with string output?
WriteLn to the console.
LCL and debugln expect UTF-8, writeln needs DefaultSystemCodePage in
FPC 2.7.1 and file is a broad category.
All that should become unimportant with the Unicode RTL, when every API
stub expects/returns strings of the according encoding, or converts its
arguments to the right encoding. Every file object (TFileStream...) has
a settable encoding, under full control of the coder.
I can see two major problems with the current FPC AnsiString model. The
first problem is the strange FPC convention, that a string variable can
have a different static/dynamic encoding, not only with RawByteString.
That convention (flaw) can require an explicit SetCodePage for every
string parameter, because a string argument of e.g. static type CP_OEM
(for console output) can have any other actual (dynamic) encoding, not
useful when passing the string to the external function.
The next problem results from the Delphi incompatible dynamic encoding
of CP_ACP(=0), that seems to be used when a literal is stored in an
AnsiString. These strings have the encoding assumed at *compile time*,
perhaps from a {$codepage ...} switch, which can differ from the
DefaultSystemCodepage at *runtime*. Then the conversion routines assume
the the string is encoded according to DefaultSystemCodepage, what's not
necessarily true:
var
A: AnsiString;
begin
a := ' äöü';
WriteLn('CP_ACP=',DefaultSystemCodePage);
WriteLn('Ansi CP=',StringCodePage(a),' Len=',Length(a),' =',a,'');
end.
Reports (on Windows) CP_ACP=1252, string CP=0, and due to the Lazarus
File Encoding of UTF-8 the string literal and variable contains UTF-8
(Len=7), as assumed by the compiler. The attempt in WriteLn, to convert
the string to CP_OEM from encoding 0, mapped by TranslatePlaceholderCP
into DefaultSystemCodePage (=1252 at runtime), results in a conversion
of the UTF-8 bytes from CP 1252 into CP_OEM :-(
Even if the string A is assigned to an AnsiString(CP_OEMCP), that string
has a dynamic encoding of 437, but contains the 7 UTF-8 bytes :-(
This mess could be eliminated easily, when FPC would store the *true*
compile-time encoding with all string literals, not CP_ACP(=0). Delphi
string literals instead come with their true dynamic encoding, which
never can be 0, and thus can be assigned and shown properly. Above code
then will show CP=1252 and Len=4 for the AnsiString variable. What's
missing from XE is the automatic conversion on console output into
CP_OEM, as done by FPC.
The use of TranslatePlaceholderCP() then also could be reduced to the
rare cases, where *user* code is allowed to supply an encoding value
(TSystemCodePage) separate from an string, e.g. in the AnsiString type
declarations or SetCodePage.
As an ugly hack the coder can use {$codepage UTF8}, *and* force Lazarus
to store the source files accordingly, and hope that then the literals
have a useful dynamic encoding. This *is* an hack, because it makes the
source files almost unusable with other programs (editors...) on Windows
and other platforms, which don't have UTF-8 for their default encoding
(CP_ACP). I also wonder what will happen on platforms with a default
encoding of CP_UTF8, when the user is allowed to and then changes that
default codepage into something else
Re: [Lazarus] UTF8 RTL for Windows
Mattias Gaertner schrieb: On Mon, 24 Nov 2014 22:53:44 +0100 Hans-Peter Diettrich drdiettri...@aol.com wrote: Graeme Geldenhuys schrieb: How is ThousandSeparator and DecimalSeparator supposed to work it TFormatSettings? If you switched the RTL to UTF-8 or UTF-16 a Russian thousand separator (4-byte non-breaking white space character) for example will not fit into a Char type. The Char type is quite useless with Unicode, Correction: *This* Char type needs to be extended. Please specify. Char in general is very useful. at least if it has less than 3 bytes (4 for UTF-8). There exist many more flaws in the RTL/LCL, assuming that a character always fits into a Char (like the Pos overload...). There is a Pos overload for strings. Where is the flaw in Pos? The flaw is the added overload with a Char parameter. Furthermore the Pos arguments should never be subject to automatic conversion, otherwise the returned index will be useless. In the best case Char could be retyped into an string (substring), That would be wrong in 99.9% of the cases. Please give at least one example. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8 RTL for Windows
Mattias Gaertner schrieb: On Mon, 24 Nov 2014 22:15:29 +0100 Hans-Peter Diettrich drdiettri...@aol.com wrote: [...] The Delphi (and FPC) encoding model allows for strings of different static (declared) and dynamic (true content) encoding, see the special handling of RawByteString (Wiki). So far it's not a good idea to simply *assume* that a string variable contains bytes of the declared encoding. In detail one should check or force the right dynamic encoding of every string variable, before searching for specific bytes (chars) in it. I'm missing documentation for working safely (and efficiently) with such irregular strings, most probably none of the FPC (and Delphi) developers ever noticed how users are left alone with this problem :-( Maybe I don't understand the question, but it seems to me this is documented where static-, dynamic cp and rawbytestring are explained. More concrete questions: How can a user be sure that a string parameter in a subroutine has the specified encoding? How to check, how to fix if needed? http://wiki.freepascal.org/FPC_Unicode_support#Ansistring When a procedure requires a specific encoding it uses a specific String type. If it works with CP_ACP it uses String. If it needs UTF8 it uses UTF8String. Such specifications are meaningless when the string parameters can have a different dynamic encoding :-( Unicode Delphi works well as long as only one codepage (CP_ACP) is used, in addition to Unicode (UTF-16) strings. As soon as multiple codepages can be involved at the same time, the dynamic string encodings become almost random (observed in Delphi XE). FPC now already has multiple built-in codepage variables (DefaultSystemCodePage...), with possibly different values, so that the observed Delphi mess is inevitable, as long as RawByteString results (of e.g. standard stringhandling functions) are *not* converted when assigned to a string variable of some specific static encoding. Unfortunately I cannot test Lazarus trunk since a long time, no answer on my request for assistance. So I have to wait for the next installable download, before I can give concrete examples. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8 RTL for Windows
Mattias Gaertner schrieb: On Tue, 25 Nov 2014 13:10:26 +0100 Hans-Peter Diettrich drdiettri...@aol.com wrote: [...] Maybe I don't understand the question, but it seems to me this is documented where static-, dynamic cp and rawbytestring are explained. More concrete questions: How can a user be sure that a string parameter in a subroutine has the specified encoding? How to check, how to fix if needed? As you know in general you cannot find out the encoding of a text. You have to trust that the caller gave the right encoding. This was true before 2.7.1 and it still is. The new thing with 2.7.1 is that String now has an encoding field and that you can use this to let the compiler convert encodings automatically. For example the RTL uses this to convert between OS strings and program strings. This means some RTL functions don't need manual encoding conversions (e.g. UTF8ToAnsi) anymore. You can simply pass the string. Hopefully more and more RTL functions/variables will be converted. In short: Most of the time you code exactly like before. FACK, so far :-] If your code works with various encodings, then formerly you had to be very careful what you do with the strings. For example when you pass the strings to the RTL you had to convert them to the system codepage. Now you can use for instance UTF8String instead and omit the UTF8ToAnsi. It is like gaining some type safety. The Delphi model already broke that claimed type safety, by omitting conversions of RawByteString results, for speed optimization. That's dangerous, because the compiler can *only* check the static type of string variables, but not the dynamic encoding of their contents. And you can now use SetCodePage. But then you have to be very careful again. SetCodePage is safe, as long as it enforces an according conversion of the dynamic string encoding. The option, of only changing the encoding field, is reserved for adjustments after reading strings from external sources, or from Char, Char arrays/pointers or ShortString, where the correct codepage is unknown to the compiler and library routines. http://wiki.freepascal.org/FPC_Unicode_support#Ansistring When a procedure requires a specific encoding it uses a specific String type. If it works with CP_ACP it uses String. If it needs UTF8 it uses UTF8String. Such specifications are meaningless when the string parameters can have a different dynamic encoding :-( Please read the paragraph Dynamic code page again. Please read my statement again, you still miss my point. With FPC 2.7.1 we have a new possibility. This is the new mode I was talking about. Now we get UTF-8 strings in many places in the RTL. Not all places yet. But we are working on it. And you can help. I'm trying to help all the time, but if you don't understand my arguments, I cannot help you :-( I've explored the encoded AnsiStrings in Delphi XE, years ago, and identified a couple of problems with the Delphi implementation. I can help by explaining these problems, and how to avoid or reduce these problems in FPC/Lazarus. But according fixes to legacy code must be applied by the maintainers of that code, who know about the *right* way (intended behaviour) to fix every single problem. Well, two weeks ago I was rolling my eyes when I read about this complex system and DefaultSystemCodePage. But then I tried to set it and now we can use one String encoding cross platform and it works with file functions, TStringList and friends. Almost all of the UTF8ToSys calls are no longer needed and file functions now support full Unicode. This was clear to me just after exploring and understanding encoded strings in Delphi. In FPC/Lazarus we now have a *chance* for simplifications and improvements, when the new features are used in the *right* way. But many arguments and opinions, presented in this thread, indicate to me an yet incomplete understanding and many misunderstandings, which I actually try to spot. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8 RTL for Windows
Mattias Gaertner schrieb: On Tue, 25 Nov 2014 14:49:52 +0100 Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com wrote: On Tue, Nov 25, 2014 at 2:45 PM, Mattias Gaertner nc-gaert...@netcologne.de wrote: Retype Char to String and the compiler will bark. For example in Graphics. What about changing to WideChar then? If you mean unit Graphics: It checks for ASCII characters. So a change to WideChar would add implicit conversions without any gain. You see that Unicode handling requires more than only changing declarations? [Where changing Char to Byte in Graphics might be sufficient, as long as such bytes are not kept in Strings] In case of ThousandSeparator: That would probably be sufficient. Although some code needs to be adapted. Then you should also see that certain means should at least *allow* to *identify* code that is not sufficiently Unicode-aware. This would not only allow the FPC/Lazarus developers to identify flaws in the standard libraries, but also users will appreciate spotted flaws in their legacy code :-) DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Testing UTF8 RTL for Windows
Mattias Gaertner schrieb: On Tue, 25 Nov 2014 13:10:26 +0100 Hans-Peter Diettrich drdiettri...@aol.com wrote: Unfortunately I cannot test Lazarus trunk since a long time, no answer on my request for assistance. ? Since the introduction of the FPC Unicode branch I cannot build FPC and Lazarus any more on my system (Win8), even after removing all previous installations. I don't remember details, but would appreciate any assistance by mail, chat or however else. For an first step, which are the current FPC and Lazarus sources (branches?) I should checkout now, for an exploration of the UTF8 RTL? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8 RTL for Windows
Michael Schnell schrieb: On 11/23/2014 07:52 PM, Felipe Monteiro de Carvalho wrote: Well, the first reports of how the unicode rtl would look like were pretty scary: Total break of the string part of millions of lines of code that people wrote with Lazarus since years. That is why I stopped recommending Lazarus to my colleagues who are doing Delphi. They took a huge amount of pain to convert their software from Delphi one byte strings to Delphi two bytes strings. I had similar problems, but only in porting a huge codebase from ShortString to AnsiString. The move from D5 to XE was painless then, only the uses lists deserved some updates. In so far it might be a good idea to educate some old-school Delphi coders, how to deal with managed strings and other past-BP items in general. As for Lazaurs, I think that UTF-8 is the best choice for multi-platform projects, with almost no extra conversions required on any platform. Please note that until now Windows did the Ansi to UTF conversions itself, in every API call with strings involved. If this was not noticed before, the conversions won't be noticeable afterwards as well. A move to UTF-16 instead will only favor Windows, while additional string conversions will be required on almost every other platform. I think that FPC/Lazarus should fork and support separate libraries (RTL...) for UTF-8 and UTF-16 strings, if compatibility with newer Delphi VCL projects is desired. Full Delphi compatibility would also require a FireMonkey replacement for the LCL, and that were another very new project, extending the UTF-16 branch (only). Just my 0.02€ DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8 RTL for Windows
luiz americo pereira camara schrieb: When DefaultSystemCodePage is CP_ACP the variable S will have the content of UTF8 but the encoding will be ACP (in my case 1252), just like is today. With DefaultSystemCodePage as CP_UTF8 both content and code page will match The Delphi (and FPC) encoding model allows for strings of different static (declared) and dynamic (true content) encoding, see the special handling of RawByteString (Wiki). So far it's not a good idea to simply *assume* that a string variable contains bytes of the declared encoding. In detail one should check or force the right dynamic encoding of every string variable, before searching for specific bytes (chars) in it. I'm missing documentation for working safely (and efficiently) with such irregular strings, most probably none of the FPC (and Delphi) developers ever noticed how users are left alone with this problem :-( DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8 RTL for Windows
Graeme Geldenhuys schrieb: How is ThousandSeparator and DecimalSeparator supposed to work it TFormatSettings? If you switched the RTL to UTF-8 or UTF-16 a Russian thousand separator (4-byte non-breaking white space character) for example will not fit into a Char type. The Char type is quite useless with Unicode, at least if it has less than 3 bytes (4 for UTF-8). There exist many more flaws in the RTL/LCL, assuming that a character always fits into a Char (like the Pos overload...). In the best case Char could be retyped into an string (substring), so that it can hold any Unicode character *and* its encoding. Unicode stringhandling in general should always use substrings, for the same reasons. Until then 99.9% of occurences of Char in UTF-8 aware library or application code can be considered bugs :-( The FPC team can sort out the real low-level code (most probably only the string conversion routines), the rest will become Delphi incompatible when fixed. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8 RTL for Windows
Mattias Gaertner schrieb: // GetCommandLineW returns a UTF-16 PWideChar // the compiler adds code to convert this to the // default system codepage (CP_ACP = CP_UTF8) // the resulting string has StringCodePage CP_ACP // and is encoded in UTF-8. Does this mean that Lazarus (new mode) ignores the OS system codepage setting? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Error messages: cannot versus can't
Mark Morgan Lloyd schrieb: Considering your particular example, I'd suggest that the manual should be written as If the compiler cannot find, but that compiler messages which are basically declamatory may lean towards the spoken contraction Can't find suchandsuch. This also has the advantage that it keeps the fixed part of error messages comparatively short, allowing more space (per acre) for information on paths etc. This just remembers me of several topics. As a non-native English reader I prefer the short forms, which are easier to parse. In German one can form huge words by appending obviously unrelated terms, with the common example of Donaudampfschifffahrtsgesellschaftskapitän. I bet that non-native readers would appreciate a rewrite as e.g. Donau'dampf'schiff'fahrt'gesellschaft'kapitän or DonauDampfSchiffFahrtsGesellschaftsKapitän, with the former form for informal purposes, the latter in source code. However, the overriding consideration is that many users of development tools will select English as the working language, even if it is not the language that they are most comfortable with. Indeed! In former times, at least, it was a good idea to install every program in its *original* language, because the translated terms were often ugly, misleading or plain of translation errors, what made menus, error messages and documentation unreadable. I'd suggest that the bottom line is that if somebody such as yourself finds the more formal cannot more intelligible than the can't contraction, then that's the one to use. Or, of course, vice versa. I'd not depend on personal taste here. Msegui is my favorite example for unreadable source code, which makes (not only) my eyes bleed due to lack of parsing aids in all-lowercase composed identifiers, while its author has the opposite opinion :-( DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Error messages: cannot versus can't
Mark Morgan Lloyd schrieb: It's usually easier to read a language than to write it, although I'm told that beginners usually send Morse code faster than they can receive it. Right, even if I can send Morse code, I'm incapable of receiving it at all :-( The frequently-cited error in comprehending standard English is the worker who thought that drums labelled Inflammable were safe to store next to a stove. Well, U.S. citizens are approved for not understanding even the obvious - like that hot coffee may burn them :-] Does Lazarus etc. have internationalisation for Esperanto? Err, isn't that *nationalization*? ;-) Here my first question were, whether there exists dictionaries for IT terms, for Esperanto and Volapük? Next question, whether it's really wise to translate such terms in IT context. Remember the differences between Brasilian and Portuguese Portuguese? Even todays German users don't know about the meaning and pronunciation of the Strg key, which is usually associated with string instead of the intended Steuerung (control). Looking at my German keyboard, I'm just finding keys labeld Enter, Shift and Backspace! Dunno about the suggested official translation, but Rücklauf, Umschaltung (switch?) and Rückschritt (retrogression?) really were meaningless until misleading. AFAIR Russian suffers from even longer words for common English terms. French is another special case, where the government strictly disallows to borrow even technical terms from other languages, what made their brave citicens create many new words that *look* like written French, but *sound* like English :-) [Note to myself: should get rid of dunno] DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Error messages: cannot versus can't
Michael Schnell schrieb: On 10/17/2014 12:16 PM, Mattias Gaertner wrote: Googling gives lot of pages saying that cannot is more formal than can't. IMHO, Open Source projects are not supposed to be formal in that way. I always find it repellent when some software in German uses the formal Sie instead of the familiar/colloquial Du I don't like both :-( In German documentation I'd avoid to address the reader, as far as possible. This also eliminates the problem of sex, in any language, where anti-discrimination and political correctness shudder requires the mention both males and females. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Error messages: cannot versus can't
Reinier Olislagers schrieb: Apparently the Microsoft Manual of Style (sorry Giuliano, seem to hit only MS references) suggests contractions could hinder comprehesion for non-native speakers, which can IMO indeed be an important factor in deciding what to use. My experience tells that in detail English-only speakers don't understand the problems of non-native speakers, and of foreign languages and translations at all. Fortunately the Lazarus community is not such a closed club :-) DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Redundant text on project buttons
Jürgen Hestermann schrieb: Icons are realy useless. You cannot search for nor filter nor sort them. They eat up space and performance without benefit. I think that they were introduced for the illiterates who can't read. Icons have been introduced for visual people, who organize their desktop by landmarks and locations, not by searching. When I met the first GUI on my Atari ST, I was familiar with it within a few minutes, and knew that this is the way I want to work with computers and programs. While I can remember patterns (arrangements, pictures, faces...) very well, I cannot remember names (of commands, people...), unless I use these names every day. I admit that too many icons, with too few differences, are not really helpful, i.e. textual menus and lists have their place in my world, too. But the same applies to text (captions), which have to be different enough without wasting too much space. That's why I'd prefer icons without captions, but with hints, and kind of a (context) menu for an *entire* toolbar that can be popped up whenever needed. In the best case that popup should be searchable by keystrokes (incremental search), to please me and also people why prefer to work with text. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] GetWindowSize misleading documentation or bug?
Luca Olivetti schrieb: Strange, on mageia 4, kde, lazarus 1.2.4 it doesn't work. What I'm trying to do is to tile windows one next to the other. Using GetWindowRect under windows I can do it properly, while on linux gtk the windows overlap (i.e. with this layout A B C D E A overlaps D and B overlaps E, the amount of overlap seems to be equal to the height of the title bar). IIRC the Linux (X11) window managers communicate only the size of the client area to the widgetsets, so that attempts to derive the total window extent from this information are subject to assumptions about the extent of the window decoration (caption, theme...). They also don't allow (offer no means for) ownerdraw of the NC area of a window. On Windows instead the owner of a form can paint the entire area of a window (in WM_NCPAINT), so that the Windows window manager allows access to the full extent of a window. Also note that Windows uses distinct windows for every TWinControl, while these are ordinary controls in X11, under exclusive management of the widgetset. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] DragManager issues
I received messages from Mantis, that something changed in the bug reports related to drag/drop. Please let me know when somebody wants to put his hands on related code. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] font.name=default
Philippe schrieb: nice. I´ll try it. (my recursive procedure worked well, not a big deal!). That's what I use, too, sometimes :-) I had some difficulty to find informations about controls, components ... if you about them you can find the reference ... but it does not help much! ... any hint? I only know from Delphi that obj.Components contains all components owned by obj, while obj.Controls contains the child controls of obj, whose Parent is obj. A TForm typically owns all its contained components (flat view), while nested (visual) controls reside in their Parent TWinControl (tree view). DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] font.name=default
Philippe schrieb: just for information ... I tried to use your suggestion ... it works ... but ... I am using TGroupBox in TGroupBox in TGroupBox ... your example just loops on the top level controls of the form ... needing to use recursive function to go through contained group boxes ... what I´ll do later. Then use Components[] instead of Controls[]. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Accessibility of Lazarus
Grzegorz Zlotowicz schrieb: the fragment of the NVDA's log says about this control: name: u'' role: ROLE_BUTTON states: STATE_FOCUSABLE, STATE_FOCUSED isFocusable: True hasFocus: True description: None value: None windowHandle: 32703706 windowClassName: u'Button' windowText: u'' displayText: u'' IAccessible event parameters: windowHandle=32703706, objectID=-4, childID=0 IAccessible accName: None IAccessible accRole: ROLE_SYSTEM_PUSHBUTTON IAccessible accState: STATE_SYSTEM_DEFAULT, STATE_SYSTEM_FOCUSED, STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (1048836) IAccessible accDescription: None IAccessible accValue: None It looks to me like the WNDCLASS and/or WNDPROC of the control lacks support for the Name, WindowText and DisplayText fields or methods. E.g. for the WindowText the WNDPROC should react on WM_GETTEXT messages. The NVDA developers should know more about how they try to obtain above properties from a window handle. The fix depends on the handling of the WNDCLASS.WNDPROC in the Lazarus widgetsets, at both designtime and runtime. In either case this WNDPROC should react properly on WM_GETTEXT, i.e. return the Text or Caption string (PCHAR) associated with the control. The LCL gurus should be able to find out why this doesn't work as expected. A test program can enumerate the window handles, associated with a running Lazarus IDE or some Lazarus application, and output the result of WM_GETTEXT for each handle. More tests can be added for the other properties retrieved by NVDA (selected state...). It would be helpful if you supply the Lazarus version and widgetset which you are using, and whether you use a 32 or 64 bit Lazarus and Windows. A screen reader finally should be able to retrieve all required values in all these combinations. Did you also try other than the Win32 widgetset in building the IDE or applications, with possibly different results in your screen reader? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
Giuliano Colla schrieb: Whenever you need a form to stay on top you never know if it'll work or not. For Gtk2, it did work on Lazarus 1.0.8, but it stopped working since Lazarus 1.1. This means that a user may lose an alarm which pops up, because he inadvertently touched the larger form. I just got some information about this issue, when I encounterd z-order problems with a Delphi XE application. Here's what Peter Below wrote, most LCL developers will be able to read this: In D7 war das Application-Window (nicht sichtbar) der API-Parent für alle Forms, d. h. sie waren alle Geschwister in der Fenster-Hierarchie. Das Taskbar-Button der Anwendung gehörte dem Application-Window. Der API-Parent bestimmt die Z-Ordnung der Fenster und Windows sorgt dafür, dass ein Fenster immer über seinem API-Parent in der Z-Ordnung liegt. Seit D2009 ist das Mainform standardmäßig der API-Parent für alle anderen Forms und der Taskbar-Button gehört zum Mainform. Das war notwendig, um Anzeigeprobleme auf dem Vista Aero-Desktop zu vermeiden. Damit liegen aber auch alle anderen Fenster in der Z-Ordnung über dem Mainform. Application.MainformOntaskbar := false geht zum Verhalten von D7 zurück, mit den damit verbundenen Problemen auf dem Aero-Desktop (betrifft wohl diese Mini-Fensteransicht, die man kriegt, wenn die Maus über einem Taskbar-Button schwebt). Es gibt eine Alternative: wenn man ein spezielles Form aus dieser Z-Ordung lösen will kann man seine CreateParams-Methode überschreiben. inherited; params.WndParent := 0; Damit bekommt man ein Fenster ohne API-Parent, das also in der Z-Ordnung von den anderen Fenstern der Anwendung losgelöst ist. Wenn man statt 0 Application.Handle verwendet sollte das Fenster auf der gleichen Ebene der Fensterhierarchie landen wie das Mainform. In beiden Fällen kann es sinnvoll sein, dem Fenster einen eigenen Taskbar-Button zu verschaffen. Dazu kommt folgende Zeile in die überschriebene CreateParams-Methode: params.ExStyle := params.ExStyle or WS_EX_APPWINDOW; -- Peter Below -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Accessibility of Lazarus
Grzegorz Zlotowicz schrieb: Returning to the accessibility: the wm_gettext message result is defined in the windowText field of quoted log, but instead relying only on winapi, NVDA tries to use MSAA or IAccessible interfaces, which give much more (for example possibility of reacting to events of control changing state, without querying it continously and comparing with previous state). I didn't know of existing accessibility support yet, very interesting :-) DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
Michael Schnell schrieb: On 06/27/2014 03:19 AM, Hans-Peter Diettrich wrote: Every clock tick increments the internal clock, and triggers all events... This is exactly what I want to avoid. Any time source is applicable with this model. The ticks (or even longer intervals) can be deliverd by callbacks, messages... DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] App crash at TScreen.GetCustomFormsZOrdered
Petr Hlozek schrieb: I'd like to do that and hopefuly already did but the app is quite big and I'm not sure fo 100%. Is there any way how to find out with any utility? FastMM4 can do that with Delphi, dunno about an FPC version. It can detect references to already destroyed objects, as well as objects not released when the program terminates. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Source Editor enhancement mini-patch
Giuliano Colla schrieb: However there's a Delphi IDE small feature which I miss when using Lazarus: a quick mouse access to the Jump Back/Jump Forward function, to navigate history. I find keyboard shortcuts (CTRL-H and Shift-CTRL-H) more cumbersome. Just a note: Delphi shorcuts for these are Alt-Left and Alt-Right. I also would like to have clickable forward/back items. They also might become part of the editor gutter? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
Michael Schnell schrieb: TThread.Queue in the end calls WakeMainThread() to wake the main thread (i.e. terminate the CheckSynchronize call waiting for a timeout). In Simula a single time base is used to trigger events at a known time. Each event, to occur after a given delay, is enterd into a queue, sorted by the absolute time of the event. Every clock tick increments the internal clock, and triggers all events waiting for the time just reached. For periodic events the event handler enters itself into the queue again, for the next event time. When the next time is calculated from the time of the previous event, incremented by the time period, jitter or delays in event processing are eliminated. Event handlers in the main loop can be invoked immediately, for handlers in other threads the thread is suspended when it waits for an event, and is resumed when the time has been reached. This way a thread also can wait for multiple events, it only has to fork to the handler associated with the just signaled event. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Paint over TEdit control
Krzysztof schrieb: I'm overriding protected PaintWindow method but seems that it is never called I had similar observations, when I wanted to paint borders around the control. It looks to me like the Windows EDIT control eats some messages :-( DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Adding functionality to a control
Timothy Groves schrieb: TMemo offers soft word wrapping. As far as I can tell through Google searches, this is not possible in TSynEdit. So is there a control somewhere that has both, and doesn't require that I use Rich Text or HTML? If not, can you point me towards a decent tutorial on extending the functionality of an existing control? Extending a simple control may be easy, you can split the internal list of lines as required. But when syntax highlighting or other text attributes or links are supported by a control, all these functions have to be upgraded to support a dynamically changing lines list. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] what is function header problem ?
FreeMan schrieb: I'm trying port some code, I get this error. IDE code complied is work, rename tool working. what is wrong? Thank you Kubuntu 14.04 x64, fpc svn r27818 lazarus svn r45213 /comp/asg.pas(100,10) Error: function header doesn't match the previous declaration DrawEx(TCanvas;AnsiString;TRect;TCustomImageList;LongInt;LongInt;LongInt;LongInt;LongInt;Boolean;Boolean;Boolean;Boolean;Boolean;Boolean;Boolean;Boolean;Double;TGraphicsColor;TGraphicsColor;TGraphicsColor;TGraphicsColor;var AnsiString;var AnsiString;var A When you override a method in a derived class, the method declaration must match the declaration in the *base class* (previous declaration). DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] EpikTimer v1.0.1 released
Michael Schnell schrieb: Here I found, that it is a rather appropriate use for EpikTimer to handle it in a static way, not creating an instance of TEpikTimer with every use of same, but simply to use class properties, class procedures and class functions of TEpikTimer. You know that the Pascal implementation of such singletons is called a unit? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Wanted: OpenGL gui framework supporting Windows, Linux, Mac, Android, etc.
J S schrieb: It would be great to have an OpenGL gui framework for Lazarus. I see the TOpenGLControl, but would like something more ambitious. [...] To be sure, this OpenGL framework would probably require its own OpenGL specific custom controls and wouldn't support TForm and most of the current windowed controls. I don't see how and why somebody would use such a framework, as long as no component library (like LCL) is implemented for it. Using the LCL requires that the components are of the basic types (TComponent, TControl, TCustomForm...). I am unsure how to make Lazarus support a non TCustomForm-derived object (TOpenGLForm), and be able to drop controls onto it in the designer. Any opinions on the best way to do this? Perhaps msegui/mseide are a better framework for your project. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Michael Schnell schrieb: On 03/17/2014 11:22 AM, Hans-Peter Diettrich wrote: Michael Schnell schrieb: This is a Windowish left-over and really alien regarding the OS-independent making of the LCL (even though In fact the LCL even simulates PostMessage in Linux. How would you handle keyboard and mouse input and painting in an application? AFAIK, this is not supported by the PostMessage implementation in the LCL in Linux. The LCL is based on the message queue, regardless of any OS or widgetset. PostMessage is part of the message queue. So it in fact is a Windowish left-over. You didn't answer my question: which other event handling model would you prefer, for use on any target and widgetset? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Michael Schnell schrieb: On 03/18/2014 09:57 AM, Hans-Peter Diettrich wrote: The LCL is based on the message queue, regardless of any OS or widgetset. PostMessage is part of the message queue. Yep. (Even though I prefer the term Event Queue as the queued information this is not necessarily similar to Windowish Messages.) The message queue is not restricted to events. In fact there is an Event Queue in the RTL (that is used e.g. for TThread.xxx based events) and an additional Event Queue that handles events based on the GUI the LCL binds to (here the Events are Messages if the GUI is Windows). With Windows, the Queue itself is implemented in the OS and only _used_ in the LCL, while with any Linux GUIs, the queue is implemented in the LCL and is fed by Events _generated_ by the GUI (no idea about Mac). Yes, events fit nicely into a message queue. The events, created by the window manager and other OS services, must find their way to the component and user handlers, what in most widgetsets is done by calling dedicated callback functions. The parameter lists and events must be unified, so that the LCL can provide a common interface for all user supplied handlers. What's so bad in using the Windows messages for that purpose, and what would be your other way of doing that? Now, the GUI-attaching Widget Type implementations in the LCL merge the events of both queues, while the not GUI-attaching Widget types currently even ignore the RTL based queue. What's GUI-attaching? You didn't answer my question: which other event handling model would you prefer, for use on any target and widgetset? Because I don't understand the your meaning here. Do you understand events at all, their implementation and handling? [...] - I don't understand what you intend by mentioning the mouse input and painting issue. Then try to explain how e.g. a key or button press event is processed in your model. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Michael Schnell schrieb: On 03/18/2014 02:13 PM, Hans-Peter Diettrich wrote: Then try to explain how e.g. a key or button press event is processed in your model. I don't have a model. I just tried to describe what the LCL does. You can see the multiple Queues in the source code: - Queue in the fpc RTL that is fed by things like TThread.Queue This queue may be unusable for LCL messages (dunno). - Queue in the Linux GUI based LCL that is fed by events (such as Key or Mouse) generated by the WidgetSet it _attaches_ to (this defines is the attach word that I mentioned) - Queue in the Windows OS the LCL in a Windows based Widget type attaches to (instead of implementing it's own event queue) IMO these queues are equivalent, only the implementor (Windows/LCL) is different. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Marcos Douglas schrieb: The requisites isn't a secret: a form needs to notify many windows using asynchronous messages. PostMessage do that but some programmers say this is an old Windowish approach so, I'm searching another method to do the same PostMessage does and making the code more cross. A solution depends on the handling of your asynchronous messages. As long as the windows (forms?) exist in the same thread, all processing within this thread must be sequential (serialized). This can be achieved with a single queue. When you want true asynchronous processing, implement an thread with its own queue that receives the asynchronous messages. Then you are free to implement your own message dispatcher in that thread. You also can implement your own message dispatcher in the main thread, by implementing your own message loop. But then you risk to make the application temporarily unresponsive, when your asynchronous events are processed before UI messages. Another solution may be an Idle message queue, and IMO something like that is implemented for QueueAsyncCall and OnIdle events. Then it depends on the message priority whether it is processed before (high priority) or after (idle state) UI messages, in the (existing/your) main thread dispatcher. Or you add an OnIdle handler to all target windows, or to the main window only, that looks for and processes the asynchronous events in a dedicated message queue, without blocking the UI. For Windows applications you should eventually know some bits about the main thread message queue. Windows e.g. creates mouse move events when needed, but not for every single move; instead the message receives the *current* mouse position, when fetched from the queue. Similarly a WM_PAINT request is queued only when the message queue is empty, and while the update region is not empty. This assures that painting has the lowest priority amongst all messages in the main message queue. Some other messages are sent immediately to a window, bypassing the message queue. And last not least some Windows controls bypass (or peek?) the message queue as well, so that some standard events are never received by user supplied message handlers. At least I found such behaviour with messages related to painting an edit control. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Michael Schnell schrieb: On 03/16/2014 09:23 AM, zeljko wrote: Why you must substitute PostMessage ? This is a Windowish left-over and really alien regarding the OS-independent making of the LCL (even though In fact the LCL even simulates PostMessage in Linux. How would you handle keyboard and mouse input and painting in an application? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Modifying Form Event
Steve Gatenby schrieb:
Hoping somebody may be able to explain why the following doesn't stop
the Form closing.
Button1 sets the method pointer correctly (I believe), as when closing
the form the showmessage occurs as expected (and shows the correct form
name).
But the form closes anyway.
procedure MyFormCloseQuery(Sender: TObject; var CanClose: boolean);
begin
ShowMessage('MyCloseQuery:'+TControl(Sender).Name);
CanClose := FALSE;
end;
procedure TformMain.Button1Click(Sender: TObject);
var
OnCloseQueryMethod:TCloseQueryEvent;
begin
TMethod(OnCloseQueryMethod).Code := @MyFormCloseQuery;
TMethod(OnCloseQueryMethod).Data := formMain;
TForm(formMain).OnCloseQuery := OnCloseQueryMethod;
end;
Here formMain.OnCloseQuery := @MyFormCloseQuery should be sufficient,
unless the OnCloseQuery handler deals with data in the form. But in this
case the handler should be made part of the formMain code, so that it
can access the form's fields and methods.
When your formMain closes anyway, I'd suggest to write an OnClose
handler and set CloseAction to caNone there.
AFAIR OnCloseQuery is intended for ending an application, where the
application denies ending when any form reports CanClose=False. Closing
individual forms instead should be handled in OnClose.
DoDi
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Modifying Form Event
Mattias Gaertner schrieb: On Thu, 13 Mar 2014 22:45:44 +1030 Steve Gatenby ste...@nevets.com.au wrote: Hoping somebody may be able to explain why the following doesn't stop the Form closing. Button1 sets the method pointer correctly (I believe), as when closing the form the showmessage occurs as expected (and shows the correct form name). But the form closes anyway. procedure MyFormCloseQuery(Sender: TObject; var CanClose: boolean); Methods have a hidden Self parameter: procedure MyFormCloseQuery(Self: TObject; Sender: TObject; var CanClose: boolean); Ah, I missed *that* essential detail in my answer :-( Thanks DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Modifying Form Event
ste...@nevets.com.au schrieb: On Thu, 13 Mar 2014 22:45:44 +1030 Steve Gatenby ste...@nevets.com.au wrote: Hoping somebody may be able to explain why the following doesn't stop the Form closing. Button1 sets the method pointer correctly (I believe), as when closing the form the showmessage occurs as expected (and shows the correct form name). would there be any way to accomplish what I'm after then ? I am trying to indirectly prevent the form closing (by passing the Form to a Method / Proc) So with no additions to the original forms class or instance. You can add your handler to the form containing Button1. Then the handler is a method, ready for assignment to the OnFormClose of any form in your project. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] constructor Create How is it work?
FreeMan schrieb: DoDi Thank you very much, You explain much better then me :) Main problem constructor not finished construction, I mean how to handle Self(TExLookUp) construction is finished? I have to wait, when self(TExLookUp) has created, and load self's properties loaded from, form resources (from .lfm) , then I can to use TExLookUp's properties, for child control, or some one else I need similar a TExLookUp.creatED event, so I can now, class created and ready for use. Right. Perhaps Loaded() is what we are looking for. Override it in your component and add the creation of the other control to it. @DoDi: TExLookUp.OnCreate handler how to add this? if add it my self, where to triggered or its just example Add you handler to the component, and in the constructor install it: OnCreate := @MyOnCreateHandler; AFAIK what mean this word? english is not mine language, I'm using dictionary while writeing message. As Far As I Know DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE default font
Antonio Fortuny schrieb: Hi Folks. If I remember well, a discussion took place some weeks ago about the IDE fonts in Lazarus but I can't find it any more So there is my question: Is it possible to change the default font used by visual controls when they are dropped onto the form ? When you set the form's Font as desired, set ParentFont=True in all dropped components. Isn't this setting the default? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] constructor Create How is it work?
FreeMan schrieb: ExLookUp1:=TExLookUp.Create(Form1); This is for manual creating, I'm talk about, I'm designing in IDE, 1-2 TExLookUp on form, and run my application, TExLookUp is class(TCustomEditButton) so Edit and button is shown on where I put on form, in designtime IDE. constructor TExLookUp.Create(AOwner: TComponent); begin inherited Create(AOwner); Self.OnChange := @EditChange; set more Self properties here! FGrid := TRxDBGrid.Create(Self); FGrid.Parent := Self.Parent; FGrid.Left := Self.Left; FGrid.Top := Self.Heigh + 10; FGrid.Width := 150; FGrid.visible := False; ... Please remember that you are in the TExLooUp constructor. Finish initialization of this component, before assigning Self.whatever to the FGrid. When the TExtLookUp is initialized from the form resource, you have to wait until this has been done. In this case I'd move the FGrid related part into the TExLookUp.OnCreate handler, which AFAIK is called *after* the TExtLookUp has been created and fully initialized. Or put the code into ExtLookUp.SetParent, as Mattias suggests. But this solution depends on the order, how the TExtLookUp properties are initialized from the form resource. When Parent is set before Left, Height etc., this solution doesn't work either. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What GetChildParent does in designer and reader?
Mattias Gaertner schrieb: On Thu, 27 Feb 2014 10:26:04 -0300 Fabio Luis Girardi fluisgira...@gmail.com wrote: 2014-02-27 10:07 GMT-03:00 Mattias Gaertner nc-gaert...@netcologne.de: On Thu, 27 Feb 2014 09:32:31 -0300 Fabio Luis Girardi fluisgira...@gmail.com wrote: [...] No. Lazarus allow me to add a child to my control, but I want redirect these childs to use a Panel inside of my TCustomControl as their parent. I see. There is no function yet, to redirect designer drops. Components can only accept or refuse. Maybe a method can be added to TWinControl: function GetDesignerDropTarget(aControl: TControlClass): TWinControl; virtual; Component DragDrop operations can be configured and controlled by the originator (here: Palette, Designer, Component...), which can e.g. provide a TDragObject governing the whole operation. In Lazarus these capabilites are restricted by the incompatible LCL DragManager, which does not use the methods of the TDragObjects declared in the VCL. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Using different FPC versions
Mattias Gaertner schrieb: http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Change_the_output_directory_of_project_and_all_packages Nice :-) I don't understand the IDE directories in Paths: The IDE has one set of search paths for every directory. That means a package can have different search paths than the active project. Here directory is not clear, sounds like a recursive definition? Eventually the more detailed description (second last item in the list) should be moved in front of above item, or replace it? I suspect a problem with the ambiguous definition/usage of path. It is used both for a single directory (relative path), or for a list of directories (search path). The same for paths, which can denote either the elements in an search path, or multiple search paths. I know that this confusion is common practice, but it makes just the Paths topic very hard to understand. Perhaps directory is used here to denote an *element* of an search path, as an disambiguation attempt, but this should be mentioned before its first use. Else directory will be associated with an folder on a disk, what here obviously is not the intended interpretation. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads and Libraries (dll and so)
Michael Schnell schrieb: On 02/07/2014 05:31 PM, Hans-Peter Diettrich wrote: Window managers do not care about widgets,,, So maybe I am confused about the term Window Manager (I think I did not introduce it here) MS Windows does not distinguish between the window manager and widgetset, it provides both. The Windows-provided widgets again are windows (have a HWND...), so that the window manager must handle *nested* windows. Also both send messages to a window's message queue (WM_...), so that an ordinary Windows user doesn't notice a difference between both. X11 instead does not provide widgets itself, these must be added by dedicated libraries (widgetsets). The communication between an application and the window manager and an widgetset works differently, events from both sources must be merged into the LCL message queue, for VCL/Windows compatibility. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Using different FPC versions
Mark Morgan Lloyd schrieb: Michael Van Canneyt wrote: Ah, in this completely un-understandable dialog. I am avoiding it like the plague :( A GUI is meant to make things simpler, not complicate them, this dialog is IMHO a prime example of a violation of that principle. (somewhat like the MS Access visual query builder) A useful feature of makefiles (and, for that matter, SQL queries) is that you can annotate them and tell the viewers why you're doing something and warn them of subtleties in your technique. A drawback of makefiles and all commandline tools is the lack of interaction, between the client and server. A decent API for every tool instead allows to configure it with e.g. immediate error handling and callback functions, before starting an operation. The documentation then resides in the source code, that can do much more than only provide it all options and cross your fingers. In so far I dislike the need for setting up everything in a way so that finally commandlines can be created for some tool (fpc,linker...), and the tools possibly must be restarted multiple times, with variations of the commandline options. And I agree with Michael that I never understood that dialog, too. It reflects the tools, models and strategies used by its designer, which have to be explained to, and understood by, every user of that dialog. Perhaps the wiki page now makes parts of that puzzle clearer to me, once I find the time to study it (and related material) in detail. Lately I tried to make Lazarus (release and trunk) work in a dedicated VM, but ended up in strange error messages in every attempt to run something like a hello-world program. Nobody could or wanted to explain me what these error messages mean, what might be wrong with my installation, and how to cure the problems. So all the nice looking configuration dialogs are worth nothing without assistance by further wizards, be tools or persons :-( DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Using different FPC versions
Michael Van Canneyt schrieb: I find makefiles with all the variables, rules and whatnot far easier to understand than this dialog. I only can interpret the final commandlines, generated from makefiles after macro substitution. From there it's a puzzle to find out what deserves an adjustment, in order to yield the intended result. Some packages do not support overriding the output directory. Huh ? These packages are not very well designed then. A package should always be oblivious to the output dir. This again indicates to me that it is overly complicated to understand the rules, and to provide proper/conforming configurations. If it is not, it should IMHO be discarded from the lazarus installation. Why not simply fix the packages? Another possibility is to add a wizard to quickly setup some common options. Similar to the initial setup dialog. In view of the Some packages do not support overriding the output directory. you mentioned earlier, I somehow doubt this is a workable idea ? Just that problem (and all others) should be fixable by such a tool. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Using different FPC versions
Mattias Gaertner schrieb: Martin Frb laza...@mfriebe.de hat am 10. Februar 2014 um 14:08 geschrieben: [...] I don't understand the IDE directories in Paths: The IDE has one set of search paths for every directory. That means a package can have different search paths than the active project. Here directory is not clear, sounds like a recursive definition? I guess it means package directory. Then the sentence reads ok. Actually, it means directory - any directory. A package can have source files in many directories. The search paths of a package are used for all files in all directories of a package. Same for projects. Sounds reasonable, if the search path is applied to every file (unit) in whatsoever directory. The IDE has one set of search paths (unit search path, include search path, sources search path) for each directory. This instead would indicate that the search path can vary, for units of the *same* package/project in *different* directories? It creates these sets on demand. Whenever a file is parsed the IDE looks up its cache. If this is the first time that a file in that directory is parsed, the IDE collects all settings and calculates the search paths and compiler options. This data is not stored on disk. Does this mean that the IDE determines to which project/package the directory belongs, and then applies the settings for that package (owner?) to that directory? Then we could eliminate the confusing directory references at all, and instead state that the project/package rules apply to every unit of that project/package. When the IDE uses directories internally, to find out to which project/package a file belongs, that's nothing that the user must know or care of. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Using different FPC versions
Martin Frb schrieb: On 10/02/2014 12:17, Hans-Peter Diettrich wrote: Mattias Gaertner schrieb: http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Change_the_output_directory_of_project_and_all_packages Nice :-) I don't understand the IDE directories in Paths: The IDE has one set of search paths for every directory. That means a package can have different search paths than the active project. Here directory is not clear, sounds like a recursive definition? I guess it means package directory. Then the sentence reads ok. IMHO it should be The IDE has one set of search paths for every package and project. That means a package can have different search paths than the active project. That was my first impression, too, but it conflicts with following sentences. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads and Libraries (dll and so)
Mark Morgan Lloyd schrieb: Hans-Peter Diettrich wrote: Mark Morgan Lloyd schrieb: OK, so assuming an OS similar to X, can a single app support two forms on different displays, and/or move forms between displays? That's the job of the desktop/window manager, on every OS. When a form shall be updated on screen, the manager determines the monitor from the form's screen coordinates, then asks the form to paint itself. Moving forms means nothing but changing their screen coordinates, then request an screen update. My understanding is that moving forms *between* *displays* requires rather more than that, in fact I'm not sure it's doable on X (if it were then we wouldn't need Xinerama, Xdmx etc.). Try to move a form with the mouse to an different monitor. This works on Linux without additional libraries. Linux also can show the same form on all desktops, without additional code or libraries. If you mean desktops for displays, or different X sessions, that's a bit different. But even then it's only a process property, on which desktop or X session a form is shown. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads and Libraries (dll and so)
Mark Morgan Lloyd schrieb: Try to move a form with the mouse to an different monitor. This works on Linux without additional libraries. Linux also can show the same form on all desktops, without additional code or libraries. Oh no it doesn't. You need something like Xinerama (RandR, Xdmx) installed, or hardware/drivers that support multiheaded operation. Okay with multiheaded graphics cards, dunno how to work with multiple cards. Otherwise the two monitors are separate *screens* (specific, technocal term- go look at your xorg.conf) identified as :0, :1 and so on. I cannot test that right now, having Linux only in virtual machines. But from my DragDrop and IDE experiments I know that nothing special is required to spread the IDE windows across multiple monitors, once the monitors are arranged to form an desktop. If you mean desktops for displays, or different X sessions, that's a bit different. But even then it's only a process property, on which desktop or X session a form is shown. You're jumbling terms up badly there. Desktop has no meaning in classic X organisation, these days it's roughly synonymous with window manager where a window manager operates on a single screen (i.e. identified as display :0, display :1 and so on). Where a desktop has some sort of pager then forms can be moved around trivially: my understanding is that on unix this is handled by minimisation/hiding (on Windows there is the windowstation layer, which is somewhat different). AFAIR the term desktop became popular with the multiple-desktop feature of X11, never implemented by Windows. Multi-monitor desktops are different, in Delphi/Lazarus they are described by the Screen object. So I stick to my position that it's at best unclear whether forms can be moved around between displays (I think you'd like to call those sessions, in any event corresponding to a screen) and whether an app can distribute forms over multiple displays (e.g. one form on display :0, another on :1 and so on). You can test that yourself, when you have a system with multiple monitors. Write a test form that displays its screen coordinates, then move it around. AFAIR moving a form to an different desktop can be achieved by the window context menu. For completeness, displays are usually identified as :0 etc. but there's actually another layer hence :0.0 :0.1 etc. I've not come across this being used even on e.g. Xinerama, and I don't know what it's supposed to represent. The :0.0 notation may denote a desktop and monitor number. Deciphering such an ID requires access to the native window implementation, which is hidden from LCL users. Of course the system and window manager has to know about all that, see the Monitors object in Delphi/Lazarus and related methods/functions. I assume that low-level access to distinct monitors requires such addressing, but ordinary applications don't have to bother with the availability, arrangement and resolution of multiple monitors on their desktop. The widgetset experts may contribute more precise information. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] kzdesktop...
Flávio Etrusco schrieb: -Flávio PS. I'm Brazilian. Oh, I always thought you were an old Italian guy ;-) DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads and Libraries (dll and so)
Michael Schnell schrieb: On 02/07/2014 03:57 AM, Hans-Peter Diettrich wrote: fill their video buffer, This only sounds appropriate for pixel graphics, not for the complex stuff widgets create and that result in object descriptions that are rendered by the processor in the video adapter. What kind of objects should that be? Window managers do not care about widgets, these reside in a widgetset layer between the application and window manager. A window manager only splits up the available desktop extent, into application specific windows, and identifies the application that has to receive events (mouse, touchpad...) and paint the window interior (client area). DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads and Libraries (dll and so)
Michael Schnell schrieb: On 02/06/2014 11:54 AM, Reimar Grabowski wrote: You see that as shortcomings. Most others (even widgetset developers) see thread-safe GUIs as nonsense without real benefit, else they would be available. I think we can agreee to disagree. This is a funny opinion indeed. It's based on the fact that there is only one window/desktop manager, which handles screen updates in strictly sequential fashion. When an application relies on high speed updates, it should serialize these requests itself, as required, instead of leaving this to the desktop manager and its arbitrary request scheduling. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads and Libraries (dll and so)
Mark Morgan Lloyd schrieb: I think that the only thing remotely worth pursuing, bearing in mind the current state of widget sets etc., would be whether an LCL in a dll/so animated by its own thread (which MichaelS has already said was doable) could output to a buffer, which could then be copied in a thread-safe fashion to the main form. I speculate that even if that was doable, getting UI events into the background LCL would be difficult, which in practice would severely curtail the components which could be used. That's exactly how it should be done. Threads fill their video buffer, then send a message to the GUI thread, to copy the frame into the output buffer and request an screen refresh. That's a total of 3 messages per stream and frame. Eventually the video threads can write directly into the output buffer, eliminating one copy action. Then the GUI thread can switch between multiple buffers, one to be filled and the other one ready for display. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads and Libraries (dll and so)
Michael Schnell schrieb: On 02/06/2014 02:13 PM, Hans-Peter Diettrich wrote: When an application relies on high speed updates, it should serialize these requests itself, as required, instead of leaving this to the desktop manager and its arbitrary request scheduling. Once again, this is not about serializing requests but about allowing as much code as possible to be distributed on multiple CPUs as possible. The desktop manager does not care about threads, it only manages windows as areas on a monitor. The Widget Provider (including X or whatever) does a fine job serializing the requests to the graphics driver, as you can see when doing the same stuff in multiple applications instead of multiple threads. Right, but the *timing* of the screen updates is undefined. On Windows a screen update (WM_PAINT) is performed at lowest priority, when the application (GUI thread) has no other outstanding messages. Then it depends on when the application has time to fetch and serve the message. This should not be very different in other managers (X11...). The worst thing an application can do, WRT screen update timing, is having the GUI thread busy with other things, like copying large data structures (frame bitmaps...). DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads and Libraries (dll and so)
Mark Morgan Lloyd schrieb: OK, so assuming an OS similar to X, can a single app support two forms on different displays, and/or move forms between displays? That's the job of the desktop/window manager, on every OS. When a form shall be updated on screen, the manager determines the monitor from the form's screen coordinates, then asks the form to paint itself. Moving forms means nothing but changing their screen coordinates, then request an screen update. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads and Libraries (dll and so)
Michael Schnell schrieb: On 02/05/2014 10:51 AM, Michael Van Canneyt wrote: Judging by your explanation to Dido, it seems you must explain your users the limits of their own brains. Adding monitors and indicators does not guarantee that they will process more info :) Please see the discussion on surveillance camera systems. You can't sell a (huge) system that does not fulfill the customer's expectations regarding their workflow. :-( . Then you have to include appropriate hardware, where multiple GPUs are preferable to multiple CPUs when it comes to processing multiple video streams concurrently. E.g. my over 10 year old TV card talks directly to the graphics card, so that TV display frequently continues even if the system is unresponsive due to some crash. When nowadays hardware doesn't allow for more video sources, fed into one video card, then still multiple (small) monitors with dedicated graphics cards could be used to display one video stream each. Such a configuration should outperform every threaded software solution, where the video data must go through a single CPU bottleneck. Please note that even a CPU with multiple cores doesn't have multiple data busses for the cores. That's the narrowest bottleneck, which limits the throughput on every standard machine. Next comes the DMA over one common data bus, which again limits the overall throughput. When instead you spend each camera its own small machine and monitor, the overall throughput can be increased (scaled) without limitations. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] BSD Magazine Pascal quote
Allan E. Registos schrieb: Hello to all, (Part of this mail also I posted earlier at the Lazarus forum). I was skimming the BSD Magazine: FreeBSD Programming Primer. In page 7 the magazine mentioned about Pascal this way: Quote: BASIC and Pascal are great for learning how to code, but they have some limitations I've just visited the German Wikipedia page for Pascal, and found it in questionable state, too. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads and Libraries (dll and so)
Michael Schnell schrieb: I stumbled over this: http://tronche.com/gui/x/xlib/display/XInitThreads.html So Xlib is thread aware and they seem to suggest that it dopes make sense to create multiple X sessions (i.e. one per thread) in a single program. This may make sense with remote displays. So in fact X does support multiple !GUIs (e.g. one per thread) in a multithreadded project. This is not a matter of X (Windows: GDI), but of the application GUI code and libraries. Of course it might be that QT (or KDE) impose additional restrictions (though I still suppose that this can be handles somehow). Right, and the restriction to one widgetset resides in the Lazarus widgetset handling. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Threads and Libraries (dll and so)
Michael Schnell schrieb: On 02/04/2014 12:09 PM, Hans-Peter Diettrich wrote: Right, and the restriction to one widgetset resides in the Lazarus widgetset handling. I do know. But it does not make much sense to be nagging towards the powers here about LCL not being reentrant, if the library (Widget Set, ...) it binds to does not decently support multiple GUIs in multiple threads of an application. Right, nobody tries to support threads in GUI related libraries, because this doesn't make sense. Every programming language that supports threads also supports inter-thread communication, which can be used to send update requests to an dedicated GUI thread. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] key press in graphics
JIMB schrieb: Years ago, I wrote a program in Borland TP7 that created a graphic screen and the user controlled activity with mouse and or key board. Nowadays you can use a Form with a PaintBox for drawings, in Delphi or Lazarus. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need Windows CE OS Image
Graeme Geldenhuys schrieb: On 18/01/14 12:00, Bart wrote: B.t.w. distributing WinCE images is illegal and this kind of illegal stuff should not be discussed on Lazarus mailinglist. Uh? The WinCE emulator and related images used to be freely available to download from Microsoft. Freely available does not imply freely redistributable. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Delphi incompatibility - hard cast
Alejandro Gonzalo schrieb: In Delphi this will work even if the Sender is not a TdbGrid, as long as it has a DataSource property: It only *happens* to work for you in Delphi. TdbGrid(Sender).datasource:=myDataSource; This hack requires that Sender has a DataSource property in *exactly* the same place where it sits in TdbGrid. That's very unlikely for any other class. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus Second Release Candidate, 1.2RC2
Mattias Gaertner schrieb: The Lazarus team would like to announce the second Release Candidate for the upcoming Version 1.2. We invite all users to test this Release Candidate. Please read here why everybody really should join the testing now. I've tried to test it, but couldn't make it work at all :-( It would be nice to have a complete distribution package, that also performs the installation as seen by the users later. Size is not a problem (to me), but I cannot continue to use or recommend the use of Lazarus, when it takes significantly more than one hour before it's ready for testing. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] [ANN] Lazarus Manager v0.8
Kjow schrieb: I'm glad to announce the release of Lazarus Manager 0.8 Thanks for updating the wiki :-) Now I upgraded to the latest TortoiseSVN (including svn.exe). 1) Is it really required to export the fpc sources? (from Tools\Downloads... to fpc\fpc\svn_sources...) 2) I still get no Lazarus.exe etc. in lazarus (fixes_1_2)? (laztrunk is okay, so far) What's the difference between building lazarus and laztrunk? Can an existing ...\Local Settings\lazarus directory (from normal distribution) get into the way? 3) Which is the minimal path required for a manual make? When the path used by Lazarus Manager is: C:\LazMgr\fpc\Bootstrap;C:\LazMgr\fpc\Binutils;C:\LazMgr\fpc\Utils\bin\i386-win32;C:\Program Files\TortoiseSVN\bin\ Can the Bootstrap or Binutils get into the way when I want to build lazarus.exe? [2+3] Using path=C:\LazMgr\fpc\Utils\bin\i386-win32;C:\LazMgr\fpc\fpc_2.6.x\bin\i386-win32 make clean bigide a lazarus.exe and lazbuild.exe are created. Doesn't work, though, even after make clean all something is wrong with the packages - just the basic Standard, Additional etc. tabs are missing from the palette. Lazarus trunk (1.3) fails to build a project with errors: PPU Loading C:\LazMgr\laztrunk\lcl\units\i386-win32\win32\interfaces.ppu PPU Invalid Version 164 Hello.lpr(9,3) Fatal: Can not find Interfaces used by Hello, ppu=C:\LazMgr\laztrunk\lcl\units\i386-win32\win32\interfaces.ppu, package LCL Which is the compiler related to Version 164? Also fails to rebuild the IDE. What's wrong? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] [ANN] Lazarus Manager v0.8
Kjow schrieb: 2014/1/10 Hans-Peter Diettrich drdiettri...@aol.com mailto:drdiettri...@aol.com Well, if Lazarus Manager can't use svn nothing will work. [...] *Manually* here means using some tool - which one? 7-zip - Open These two tools should be mentioned in the docs, how to check for already installed, or how to install. No need to explain further details to me, I found the existing documentation sufficient so far. Without binutils nothing will work. Of course, the manager already checks that and reports problems. When I found the target directories missing, I tried to repeat FirstInstall (no improvment). How do I a clean restart? Lazarus Manager is not working for you, because it doesn't recognize svn and you don't have extracted binutils. Sorry, I *did* install svn, 7zip, filled the Binutils dir, and got the sources checked out. My problems start with the compilation of the sources. Anyway, to restart, just delete the root installation directory you choose for Lazarus Manager (e.g. C:\Develop ). I've moved the Binutils directory to an safe place now, so that I can copy it into the root directory afterwards. Then restarted with a fresh copy of Lazarus Manager. Tried to modify the Binutils path, to use my saved Binutils, but the box seems to be read-only. Well... Started Lazarus Manager, proceed until FirstInstall, copy the binutils when propted, checkout starts, make seems to do something, all consoles close. BTW a DebugScripts checkbox would be nice, redirecting (at least make) console output into log files (easier than halting before the consoles close). Remaining questions: Where is the make output (installed files)? The fpctrunk and fpc_2.6.x directories look fine to me. laztrunk too, but lazarus contains no Lazarus.exe??? How do I start/configure the various Lazarus versions (trunk/stable)? Do both Lazarus versions use the same FPC (stable branch) version? IMO they should, at least when Lazarus has to be rebuilt. So how do I use fpctrunk with Lazarus? Lazarus setup doubts about the correct make.exe: Warnung:Es gibt keine fpc.exe im Verzeichnis von make.exe. Üblicherweise wird make zusammen mit dem FPC-Compiler installiert. Is it okay to use make.exe from fpc\Utils\bin...? Could this cause the following problem: The IDE (1.3) then starts fine, but seems to use *fpctrunk* and consequently fails to build my HelloWorld project :-( Since this issue seems to be Lazarus related, I'll ask in another thread. Please clarify: is the temporary path (shown in the log) the full path used during the build process? Which other standard directories are involved? The path reported in the log is the path that Lazarus Manager use during its processes. That's fine, and I'd leave it like that. Using and modifying the OS path IMO is not a good idea, because then multiple versions and third party adds can get into the way. I already considered to remove the directories added by previous Lazarus installations... How is the \pp directory involved? It was created by another Lazarus (older, stable) installation, obviously incompatible with the current/trunk projects. This is the strange part... teorically there are not interactions with Lazarus Manager processes... but what you reported has put me on alert. Looks like this problem doesn't exist any more. At least the files found in pp\bin\... date from 2010. A general note on FPC/Lazarus installation: I had several installations on my old (Win7) system, but don't remember how I made make work there, and which one was the most recent one. Is there something simpler than the BuildFAQ, telling how to make things work without killing other existing installations? Tecnically, with Lazarus Manager you can install as many times you want different and indipendent installations. At the moment, I have FIVE roots within any of them two Lazarus and two FPC installations (branch/trunk) and I have no problems: Great :-) DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Some problems with trunk
I just used Lazarus Manager to create FPC and Lazarus trunk and stable/patches versions on a WinXP system. But then I ran into the following problems, which seem not to be related to this tool: No Lazarus.exe is created for the stable (fixes_1_2) branch? The trunk IDE (1.3) setup expects fpc.exe in the make.exe directory. I have no fpc.exe in the shared make directory (fpc\Binutils...), nor make.exe in the fpc\bin... directory. Is something wrong with the installation? Looking at the environment options, The German (default) IDE displays help on *Project Options*, looks like a translation problem? After changing the language to English the correct page is displayed. Compiling a HelloWorld project fails, first with messages mentioning fpctrunk instead of the configured fpc_2.6.x, then with: PPU Loading C:\LazMgr\laztrunk\lcl\units\i386-win32\win32\interfaces.ppu PPU Invalid Version 164 Hello.lpr(9,3) Fatal: Can not find Interfaces used by Hello, ppu=C:\LazMgr\laztrunk\lcl\units\i386-win32\win32\interfaces.ppu, package LCL From About FPC: FPC executable: Compiler=C:\LazMgr\fpc\fpc_2.6.x\bin\i386-win32\fpc.exe Options= CompilerDate=11.01.2014 14:21:00 RealCompiler=C:\LazMgr\fpc\fpc_2.6.x\bin\i386-win32\ppc386.exe RealCompilerDate=11.01.2014 14:21:46 RealTargetOS=win32 RealTargetCPU=i386 RealCompilerInPath=C:\LazMgr\fpc\fpc_2.6.x\bin\i386-win32\ppc386.exe Version=2.6.3 CfgFilename=C:\LazMgr\fpc\fpc_2.6.x\bin\i386-win32\fpc.cfg What's wrong? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] [ANN] Lazarus Manager v0.8
Reinier Olislagers schrieb: On 11/01/2014 01:09, waldo kitty wrote: On 1/10/2014 5:04 PM, Kjow wrote: AFAIK, TortiseSVN has never had a svn.exe... i've always had to use their executable's filename in my scripts... http://stackoverflow.com/questions/2967176/where-is-svn-exe-in-my-machine UPDATE: Recent versions of the TortoiseSVN package can install a discrete svn.exe in addition to the one linked into the GUI binary. It is located in the same bin directory where the main program is installed. Thanks for the info :-) DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] [ANN] Lazarus Manager v0.8
waldo kitty schrieb: AFAIK, TortiseSVN has never had a svn.exe... i've always had to use their executable's filename in my scripts... eg: for FPC - TortoiseProc /command:update /path:%myFPCdir% for LAZ - TortoiseProc /command:update /path:%myLAZdir% Thanks, installing another (non-Tortoise) SVN version fixed the problem. i don't know anything about 'their' (TortiseSVN) having any sort of 'bash shell'... AFAIK, there isn't such a beast on winwhatever... Right, I confused SVN and GIT :-( DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New NumbersOnly property for TCustomEdit (r43678)
Bart schrieb: An edit control that controls input based on a regex, and looking like a simple TEdit, might be a nice feature to have. I found general masking problems while entering (incomplete) input, and while editing the previous input. Where should the cursor be moved, i.e. which (first) character doesn't match the specification? IMO the problem boils down to an fault-tolerant parser, that allows to hilite wrong parts of some input, but does not prevent changes in other places, which finally *may* lead to a correct input. Not so obvious with only numerical input, but a big problem with e.g. phone numbers with embedded fixed characters. The control should allow to hilite individual wrong characters, what's beyond the capabilities of simple edit controls (requires RTF or similar formatting features). DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New NumbersOnly property for TCustomEdit (r43678)
Bart schrieb: On 1/11/14, Hans-Peter Diettrich drdiettri...@aol.com wrote: I found general masking problems while entering (incomplete) input, and while editing the previous input. Where should the cursor be moved, i.e. which (first) character doesn't match the specification? You lost me here. Which component are you describing here? A new one, that overcomes the problems of the existing ones. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] [ANN] Lazarus Manager v0.8
Kjow schrieb: More detail and download link here: http://wiki.lazarus.freepascal.org/Lazarus_Manager PS Please, take it as an hobby... I know that it can be improved a lot and there are surely mistakes/faults, so please tell me which issues you will find and I'll try to fix in my free time :) On Win8-64 -- First problem: the edit box for the root directory shows strange behaviour. Inserting characters *into* text can make the cursor jump to the end of the text. I'm missing an button for executing the Pre-Installation. Start Necessaries Download doesn't react, the FirstInstall button is far away. SVN is not found, even if TortoiseSVN\bin is in the path, and I don't remember SVM problems with fpcup. - what exactly should be in the path? - does it harm when another SVN is installed by the manager? - Clicking Cancel makes the program unresponsive, Windows kills it. - The same when clicking OK. The last log entry is [10:47:25]: Start gdb.exe download. fpcup had other problems, couldn't make it work either. Second try in WinXP-32 VM - SVN can be started in a console, seems to be installed already. Downloads seem to succeed. Error: Binutils directory is empty. Maybe .lzma and .tar are not supported? -- installed 7zip and zlib. Now a couple of consoles seem to checkout the repositories. All done - what now? Try close a console: Windows cannot cannot close this program Try Update, more consoles open *and* close (rapidly, empty?)! These seem to be the make consoles? Error: Failed to execute: 2. Huh? config: Drive=2 ? At least the log continues, starting make's *and* finally states Update completed :-) Ending the program - the consoles still are open. Kill them now brutally :-] But where are the binaries? Looking at the log, the INSTALL_PREFIX directories do not exist :-( Log doesn't mention any missing paths, only: Temporary EnvironmentVariable (PATH): C:\LazMgr\fpc\Bootstrap;C:\LazMgr\fpc\Binutils;C:\LazMgr\fpc\Utils\bin\i386-win32;C:\Program Files\CollabNet\Subversion Client\ Fix the shortcut file (root changed!). Error: problems with android NDK... Of course no such directories exist, I didn't select Android support!? Ignore -- program starts, with all targets checked! :-( Uncheck except win32. QuickBuild -- not yet implemented Close, remove Android directories from config.ini - oops, bad idea? Remove all from the shortcut. Start again, consoles open and close quickly - still no target directories created. fpctrunk source missing compiler directory! Creating batch file for start with above directories appended. No difference :-( Add CD... and make... for testing C:/LazMgr/fpc/Bootstrap/ppc386.exe -Fui386 -Fusystems -Fuc:/pp/units/i386-win32/ rtl -Fii386 -FE. -FUi386/units/i386-win32 -di386 -dGDB -dBROWSERLOG -Fux86 pp.pas PPU Loading C:\pp\units\i386-win32\rtl\system.ppu PPU Invalid Version 100 Fatal: Can't find unit system used by pp Fatal: Compilation aborted make: *** [ppc386.exe] Error 1 Cleaning \pp\units... Invalid Version disappears, rest same error :-( What's wrong? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] [ANN] Lazarus Manager v0.8
Reinier Olislagers schrieb: On 10/01/2014 13:40, Hans-Peter Diettrich wrote: fpcup had other problems, couldn't make it work either. Please feel free to post bug reports on the forum I'll have a look. I don't remember the exact details. According to the docs, I deleted ppcx64.exe, and now it is *not* recreated automatically. What should I do to restart in a usable state? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] [ANN] Lazarus Manager v0.8
Kjow schrieb: wow, a lot of stuff! 2014/1/10 Hans-Peter Diettrich drdiettri...@aol.com mailto:drdiettri...@aol.com On Win8-64 -- First problem: the edit box for the root directory shows strange behaviour. Inserting characters *into* text can make the cursor jump to the end of the text. This is a bug... in path can't be used spaces or special char and it doesn't reposition the cursor at the right place :) No special characters, I only tried to insert 'LazMgr\' in front of the suggested directory. It may be a timing problem, the 'a' or 'z' caused the jump to the end of the text. I'm missing an button for executing the Pre-Installation. Start Necessaries Download doesn't react, the FirstInstall button is far away. mmhh... it use generic svn command line program, so if you type svn in a new command prompt window it should work also on Lazarus Manager... So it seems to me that TortoiseSVN doesn't install the standard svn.exe. Dunno how they make svn known to their bash shell. fpcup had other problems, couldn't make it work either. I don't know how fpcup works, but if both aren't working it should be a system problem... I don't know... I'll try with an other PC (win8.1 x64). I use Win8 (NOT 8.1!) only if necessary or simple, otherwise XP (VM) is more tansparent and usable for me. Had to disable automatic updates on Win8 a long time ago, because it broke several apps; this may be the reason why I couldn't (and don't want any more) to upgrade to 8.1. Never change a working Windows ;-) Second try in WinXP-32 VM - SVN can be started in a console, seems to be installed already. Downloads seem to succeed. Error: Binutils directory is empty. Maybe .lzma and .tar are not supported? -- installed 7zip and zlib. Lazarus Manager can't manage lzma (or tar), I show a pop-up when required (and I add an advice on log) that this step should be done manually. *Manually* here means using some tool - which one? Now a couple of consoles seem to checkout the repositories. All done - what now? Try close a console: Windows cannot cannot close this program Well, the procedure should follow a defined path. If there isn't binutils into the directory everything after the check doesn't work. Of course, there are controls about not proceeding if binutils aren't found, I don't know why in your system this doesn't work... strange. Would it be simpler to disable single click installation in case of trouble, and proceed step by step? (should be documented as well) Try Update, more consoles open *and* close (rapidly, empty?)! These seem to be the make consoles? Error: Failed to execute: 2. Huh? config: Drive=2 ? Update works only if first installation was ok, so something not defined is happened (and binutils are absolutely required). When I found the target directories missing, I tried to repeat FirstInstall (no improvment). How do I a clean restart? This log is not so smart :-p It just writes what is processing and when it ends, but it doesn't tell (yet?) if all is gone right. Anyway, if in Lazarus (branch/trunk) there are exe files all is gone right :) Can the make consoles be kept open in case of errors (ErrorLevel?), for inspection of eventual error messages? Then close after prompting the user... I don't really know... it seems like there is some interference with other installation/something else, but Lazarus Manager should not care... Please clarify: is the temporary path (shown in the log) the full path used during the build process? Which other standard directories are involved? How is the \pp directory involved? It was created by another Lazarus (older, stable) installation, obviously incompatible with the current/trunk projects. A general note on FPC/Lazarus installation: I had several installations on my old (Win7) system, but don't remember how I made make work there, and which one was the most recent one. Is there something simpler than the BuildFAQ, telling how to make things work without killing other existing installations? As a normal user I'm happy with a single installation, but when I now want to explore the new AnsiStrings, I need multiple independent installations of FPC (and Lazarus?). E.g. on Win7 I had an \fpc directory, containing various FPC installations, so that I know where to install and find some specific compiler. A single (unversioned) \pp directory is not so useful. In detail I don't remember which config files/directories belong to which version... I also considered to have different users for each branch, but AFAIR this also didn't allow to isolate the installations sufficiently. Would this be easier on Linux? [I doubt that, when \lib and other shared directories or links are used] Also my Ubuntu VM recently stopped working, after an update, with an irrecoverably broken package
Re: [Lazarus] Optimize DBGrid speed
Petr Kristan schrieb: In the beginning of Grid paint is Canvas.GetClipRect called to obtain area which wee must redraw. This function directly calls WidgetSet.GetClipBox. I find out difference betwen Win32 and gtk2 bahaviour of this func. In gtk2 TGtk2WidgetSet.GetClipBox returns previously Invalidated area (through DC.PaintRectangle = PS.rcPaint retrieved in BeginPaint) But in win32 directly calls Windows.GetClipBox, but this func returns whole grid area. Do not takes account on invalidated area retrieved in BeginPaint. It may be a bug in the Win32 widgetset, invalidating the entire control area instead of only the affected cell, *or* some special handling of invalidated areas by Windows. I remember that Windows used to extend the UpdateRect to include *all* invalidated parts of the DC. This can lead to a big update area, when a single bit at the top left and at the bottom right of the DC was invalidated. This may have changed in the meantime, though. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] [fpc-devel] Encoded AnsiString
Paul Ishenin schrieb: 30.12.2013 9:07, Hans-Peter Diettrich пишет: Do you think that FPC should really reproduce all this inconsistent behaviour? Who would test or even specify the compatible behaviour, when every new variation will result in more unexpected results? IMO it's much easier to do it right, and fix the Delphi flaws in FPC. The work is already done by FPC team. AnsiString(codepage) works and works compatible with Delphi (whether someone like this or not) and the behavior is covered by tests. Trunk version is very close to 2.8 release. This means that UTF-8 won't work properly when it's not CP_ACP :-( DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] *** GMX Spamverdacht *** Re: *** GMX Spamverdacht *** Re: Lazarus (UTF8) and Windows: SysToUTF8, UTF8ToSys... Is there a better solution?
Michael Van Canneyt schrieb: Perhaps the Delphi developers have a look at FPC discussions and innovations, and add useful features to Delphi? That would be a first. There have been several occasions when we had a feature first. They have always added it differently. Well, would they have added it without such an inspiration? And yes, they'll have to add it in a different way, to prevent patents etc. infringements. Like MS insisted in a remake of all yet known errors, during Windows evolution, just to proof that they are the inventors of something new ;-) DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Beyond Compare 4 built with Lazarus 1.2
Michael Van Canneyt schrieb: http://docwiki.embarcadero.com/Libraries/XE5/en/System.SysUtils.FindFirst No mention of encoding either. Wake up! In XE5 String is UnicodeString, so what's unclear? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] OT: Re: Lazarus (UTF8) and Windows: SysToUTF8, UTF8ToSys... Is there a better solution?
Sven Barth schrieb: The compiler can already parse UTF-8 files with strings and comments being real UTF-8 texts which can be seen as such inside an editor. AFAIK it can even handle UTF-16 files (though I'm not entirely sure about this). What it however does definitely not allow (and none of the current devs wants to work on this) is support for non-Unicode identifiers as newer Delphi versions support. You certainly mean *non-ASCII* identifiers? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus (UTF8) and Windows: SysToUTF8, UTF8ToSys... Is there a better solution?
Sven Barth schrieb:
On 26.12.2013 17:02, Sven Barth wrote:
Am 26.12.2013 12:30 schrieb Hans-Peter Diettrich drdiettri...@aol.com
mailto:drdiettri...@aol.com:
Sven Barth schrieb:
Am 26.12.2013 02:19 schrieb Hans-Peter Diettrich
drdiettri...@aol.com mailto:drdiettri...@aol.com
mailto:drdiettri...@aol.com mailto:drdiettri...@aol.com:
Please specify AnsiString, of which encoding?
When I concat an AnsiString and an UTF8String and assign it to an
OEMString
o := a + u;
then I get these warnings in XE:
[DCC Warning] ConcTest.dpr(20): W1057 Implicit string cast from
'AnsiString' to 'string'
[DCC Warning] ConcTest.dpr(20): W1057 Implicit string cast from
'UTF8String' to 'string'
[DCC Warning] ConcTest.dpr(20): W1058 Implicit string cast with
potential data loss from 'string' to 'OEMString'
I cannot see the system codepage used here.
Try to make o of type RawByteString. And maybe also use more than two
strings.
As I already statet: RawByteString is not for application use!
Ok, I didn't remember the situation correctly. When searching for Jonas'
mail I mentioned below I also found this which I was referring to:
=== quote of Jonas begin ===
var
mypath: utf8string;
sr: tsearchrec;
begin
{ assign some utf-8 string to mypath }
if findfirst(mypath+allfilesmask,faAnyFile,sr)=0 then
begin
...
end;
end
Delphi has no problem with this code, because all strings are upgraded
to UnicodeString.
If the DefaultSystemCodePage is something different from UTF-8, the
result of mypath+allfilesmask will be downgraded to
DefaultSystemCodePage because the string constant allfilesmask is
encoded using that code page.
Delphi has no rule of downgrading.
When mypath+allfilesmask is assigned to a variable, the result has the
correct encoding, not necessarily CP_ACP.
This is due to rule that concatenating
ansistrings with different encodings results in an ansistring with the
encoding of the destination ansistring is followed, and the destination
ansistring is a rawbytestring here (the first argument of findfirst), in
which case the ansi encoding is used.
Again: RawByteString is a mess, should be used with care.
The first argument of FindFirst (file mask) certainly *can not* be a
RawByteString.
=== quote of Jonas end ===
What I want to point out are the string function overloads, where
Delphi supplies only string (UTF-16) and RawByteString arguments, and
AnsiString(CP_ACP) in unit AnsiStrings. FPC could add UTF8String
overloads and use these when dealing with AnsiStrings of an encoding
different from CP_ACP.
That was already discussed some time ago between devs and was deemed not
useable by Jonas. I'll try to find his mail with his explanation.
=== quote of Jonas begin ===
Adding explicitly named UTF-8 versions of routines with constant or value
rawbytestring arguments (FindFirstUTF8 etc) with UTF8String arguments and
that internally simply call through to the rawbytestring versions could
perhaps be useful. Interestingly, Lazarus users probably won't suffer
from this particular problem as they already use such routines from the
LCL, and those routines can simply be adapted by simply removing all the
UTF8ToSys calls (they will keep working in their current state though,
they simply keep suffering from the same data loss issues they had
before).
=== quote of Jonas end ===
I see no argument for or against UTF-8 overloads here.
Please note that Jonas states that different named overloads would be
needed. Equally named UTF8String overloads won't necessarily work
correctly.
You see the need for making RawByteString a compiler magic? :-]
It should be used only as the last resort, when no other string type
matches a given string encoding.
As for FindFirst, a choice of the mask string exists only on Windows,
depending on the use of the A or W API. Other targets have an dedicated
encoding for filenames, that should be used in all file and directory
functions. Even on Windows only the W API should be used nowadays; the A
API (as used in older Delphi versions) was only for support of legacy
Win9x systems, where not all W subroutine versions were available.
DoDi
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus (UTF8) and Windows: SysToUTF8, UTF8ToSys... Is there a better solution?
Juha Manninen schrieb: It happened again. The word Unicode was mentioned and the result is an endless debate of how it should be done. Now 100 messages and counting ... Now that we are in pre-release of strings with Encoding, the debate enters a very new round. I personally don't care much what the default encoding will be, but I wonder how easy it will be to use UTF-8 for my employer's code. The situation with FPC will be better than with Delphi because FPC does not convert automatically to default encoding ALWAYS. It only converts when the conversion is needed. For example TStringList can be used for UTF8Strings and it does not trigger automatic conversion. Isn't it so? Please correct me if I still got it wrong. That's the old state, where strings have no stored Encoding. As soon as AnsiStrings have an encoding, the default encoding becomes important for the reduction of automatic conversions. When the RTL is converted to UTF-16, you'll have to accept either this new default encoding, or any number of automatic conversions between Ansi and UnicodeStrings. It means UTF-8 with FPC will be easier than UTF-8 with Delphi, even if UTF-16 was the default. Delphi suffers from the use of CP_ACP, which was the only supported encoding before, and still is the only explicitly supported encoding when the AnsiString unit is used. In Lazarus we had the same only one encoding philosophy, except that here the default string type is UTF-8. With the encoded AnsiStrings the problem of other encodings and automatic conversion arises. Delphi solved most problems by changing string to UTF-16, so that only the forced used of AnsiString will ever result in automatic conversions due to different string encodings. In FPC/Lazarus the situation is somewhat different, because now the default string type could be UTF-8, UTF-16 or even CP_ACP, with a number of users voting for each of them. Technically the simplest solution would be to keep the de-facto standard UTF-8, as assumed by Lazarus. But when string becomes UTF-16, as in recent Delphi versions, Lazarus and the LCL deserves heavy refactoring. That's the top discussion topic right now. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus (UTF8) and Windows: SysToUTF8, UTF8ToSys... Is there a better solution?
Marco van de Voort schrieb: On Thu, Dec 26, 2013 at 12:28:54AM +0100, Hans-Peter Diettrich wrote: is dangerous if they are not all the same encoding. If there is any mismatch, it will be converted down to default encoding. Then the implementation is wrong. Wrong according to you. Wrong, or better *broken*, with regards to expected results. Not wrong according to defined Microsoft applications. Where do you see Microsoft applications using Ansi strings, nowadays? This way of top-down thinking will turn FPC into a Java, where you are lugging along an own platform-within-an-platform everywhere. That's what FPC and Lazarus do already: they assume an UTF-8 environment, till now. That's okay for all targets execpt Windows, where a UTF-8/16 conversion is required on the app-WinAPI boundary. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus (UTF8) and Windows: SysToUTF8, UTF8ToSys... Is there a better solution?
Marco van de Voort schrieb: On Fri, Dec 27, 2013 at 06:39:38PM -0200, Marcos Douglas wrote: If we continue to follow Delphi, means that we are always one step behind. If we stop following delphi, we are multiple steps behind. FPC/Lazarus always was in front of Delphi. It had Unicode support (UTF-8) since long, supports multiple widgetsets, platforms and machines. Even the help system and is better and more user friendly, as well as are the editing helpers. The compatibility problems are selfmade, IMO. Compatibility with all versions of a continuously moving target is near impossible, at least not feasable with the available manpower. Now that Delphi introduced something really useful (encoded strings and automatic conversion), the new Unicode support should be integrated into FPC and Lazarus. When this works for the AnsiString version (UTF-8), somewhat compatible with D7, a UnicodeString (UTF-16) version can be considered, compatible with some newer Delphi version. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus (UTF8) and Windows: SysToUTF8, UTF8ToSys... Is there a better solution?
Sven Barth schrieb: Am 26.12.2013 02:19 schrieb Hans-Peter Diettrich drdiettri...@aol.com mailto:drdiettri...@aol.com: Sven Barth schrieb: If in 2.6.2 your three strings contain text of different encodings then the resulting string might be garbage from the user's POV. In trunk the encoding is part of each string and if they differ then each strings will be converted to the default string encoding (defined by a global variable inside unit System) and thus the string might still be valid. If so, this flaw should be fixed immediately. Delphi uses lossless conversions, i.e. an up-cast to Unicode. No it does not. If the variables you concatenate are AnsiString and the variable or parameter you pass them to is AnsiString as well (AFAIK it even needs to be RawByteString) then the strings are converted to the system encoding before they are concatenated and passed. This is implemented Delphi compatible in FPC. Please specify AnsiString, of which encoding? When I concat an AnsiString and an UTF8String and assign it to an OEMString o := a + u; then I get these warnings in XE: [DCC Warning] ConcTest.dpr(20): W1057 Implicit string cast from 'AnsiString' to 'string' [DCC Warning] ConcTest.dpr(20): W1057 Implicit string cast from 'UTF8String' to 'string' [DCC Warning] ConcTest.dpr(20): W1058 Implicit string cast with potential data loss from 'string' to 'OEMString' I cannot see the system codepage used here. What I want to point out are the string function overloads, where Delphi supplies only string (UTF-16) and RawByteString arguments, and AnsiString(CP_ACP) in unit AnsiStrings. FPC could add UTF8String overloads and use these when dealing with AnsiStrings of an encoding different from CP_ACP. Such problems can be avoided by making RawByteString a compiler magic, that enforces a Unciode conversion whenever AnsiStrings of a different dynamic encoding have to be combined. RawByteString is already as magical as it gets and exactly is what's on the tin: a raw byte string. No automatic conversions ever. This is a type that is needed for implementing String handling in RTL so overloading it with another meaning will only result on problems. If you want UTF-8 encoded strings then use UTF8String. Period. Please understand that the use of RawByteString in Delphi can lead to strings with wrong encoding. This type should not be available for declaring variables, only for parameters and function results. This restriction requires compiler magic. UnicodeString is *defined* as 2-Byte character reference counted string. There will be no change there. Sorry, I meant the generic string type. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Beyond Compare 4 built with Lazarus 1.2
Craig Peterson schrieb: On Dec 25, 2013, at 5:11 PM, Hans-Peter Diettrich drdiettri...@aol.com wrote: I wonder what exact support he means. Wonder no more: 1) string uses a Unicode encoding 2) AnsiString/UTF8String casts perform appropriate conversions 3) File APIs support Unicode filenames 4) Windows headers use W version by default. 5) LCL and RTL agree on string encoding 6) In a stable Lazarus and FPC release Thanks for this list :-) Everything except (2) should have been available already, that's why I was wondering. Automatic conversions (2) were hard to implement without stored string Encoding, should come soon. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
