On 03/27/2013 10:24 AM, Andrea Mauri wrote:
My app is actually compiled both on 32 and 64 bit.
As this is a really typical application that requests for 64 Bit I would
drop the 32 Bit route here.
-Michael
--
___
Lazarus mailing list
On 03/27/2013 12:48 PM, Mark Morgan Lloyd wrote:
Even if half the address room (i.e the upper Bit) is stolen by whatever
organization. 63 Bits is by far enough for any thinkable purpose.
-Michael
--
___
Lazarus mailing list
On Wed, Mar 27, 2013 at 06:54:42PM -0400, Andrew Haines wrote:
Thats because the files were generated with the introspection files from
those two versions. It's pretty easy to generate any version needed for
the bindings using the gir2pas program in the Lazarus CCR
Thanks, that is the bit of
Am 27.03.2013 23:19, schrieb Graeme Geldenhuys:
On 2013-03-27 17:59, Sven Barth wrote:
const
cGitRevision = '{$revision.inc}';
This won't work, because the string takes precedance over the directive.
Probably why my original version build script generates the whole line
with identifier.
Michael Schnell wrote:
On 03/27/2013 12:48 PM, Mark Morgan Lloyd wrote:
Even if half the address room (i.e the upper Bit) is stolen by whatever
organization. 63 Bits is by far enough for any thinkable purpose.
And then somebody steals another bit, and somebody else a couple more...
and
Hi,
Please, where is the package view implemented? I mean the window which
appears when you open the .lpk file as a package.
Thank
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
Graeme Geldenhuys wrote:
On 2013-03-27 17:59, Sven Barth wrote:
const
cGitRevision = '{$revision.inc}';
This won't work, because the string takes precedance over the directive.
Probably why my original version build script generates the whole line
with identifier.
What about the
On Thu, 28 Mar 2013 10:03:59 +0100
Lubos Pintes pin...@gmail.com wrote:
Hi,
Please, where is the package view implemented? I mean the window which
appears when you open the .lpk file as a package.
packager/packageeditor.pas
Mattias
--
___
Lazarus
On 2013-03-28 09:19, Mark Morgan Lloyd wrote:
Another approach- which I use for svn- is to generate the version string
with quotes.
My first reply suggested that, but Xiangrong didn't like the idea of
platform specific scripts.
I'm sure somebody wants to tell us that MSEide handles
On Thu, 28 Mar 2013 09:19:06 +
Mark Morgan Lloyd markmll.laza...@telemetry.co.uk wrote:
[...]
This can be a bit tricky, since it needs something like tr on all
platforms and Lazarus has problems with \ in the ExecuteBefore...Command
Value setting.
What problems?
Mattias
--
On 2013-03-28 05:57, Xiangrong Fang wrote:
I thought {$I revision.inc} is similar as {$I %DATE%}, but apparently they
have different semantic.
From the Free Pascal Programmer's Guide (section 1.1.41), there are 9
hard-coded compiler values that can be used in the format %xxx%. If it
is not
Thank. I searched in ide folder thinking that it is a part of IDE, so
it will be there.
Dňa 28. 3. 2013 10:33 Mattias Gaertner wrote / napísal(a):
On Thu, 28 Mar 2013 10:03:59 +0100
Lubos Pintes pin...@gmail.com wrote:
Hi,
Please, where is the package view implemented? I mean the window which
My first reply suggested that, but Xiangrong didn't like the idea of
platform specific scripts.
I can use InstantFPC to write platform independent script.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
Mattias Gaertner wrote:
On Thu, 28 Mar 2013 09:19:06 +
Mark Morgan Lloyd markmll.laza...@telemetry.co.uk wrote:
[...]
This can be a bit tricky, since it needs something like tr on all
platforms and Lazarus has problems with \ in the ExecuteBefore...Command
Value setting.
What problems?
What about the following...
const
cGitRevision = + {$revision.inc} + ;
That should work :)
That does not work.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On Thu, 28 Mar 2013 11:14:19 +
Mark Morgan Lloyd markmll.laza...@telemetry.co.uk wrote:
Mattias Gaertner wrote:
On Thu, 28 Mar 2013 09:19:06 +
Mark Morgan Lloyd markmll.laza...@telemetry.co.uk wrote:
[...]
This can be a bit tricky, since it needs something like tr on all
Sorry, I looked at the wrong part of your mail. I thought this was about
the #208#154 representation. Probably because I had never debugged
anything that caused the ???.
Maybe I did reproduce it now
Also in your first example
ansi := Utf8ToAnsi('Кукла');
is that cyrillic? Can that be
I don't think that counts as doing all the work for the OP since he's
still got to figure
out why it works :-)
I may leave some of you a wrong impression that I need spoon-feeding. Let
me explain what I mean clearly:
While using {$I %DATE%}, I can write:
WriteLn('COMPILED: ' + {$I %DATE%});
Mattias Gaertner wrote:
On Thu, 28 Mar 2013 11:14:19 +
Mark Morgan Lloyd markmll.laza...@telemetry.co.uk wrote:
Mattias Gaertner wrote:
On Thu, 28 Mar 2013 09:19:06 +
Mark Morgan Lloyd markmll.laza...@telemetry.co.uk wrote:
[...]
This can be a bit tricky, since it needs something
On Thu, 28 Mar 2013 12:11:19 +
Mark Morgan Lloyd markmll.laza...@telemetry.co.uk wrote:
[...]
The IDE converts \,/ in all paths when for example a project saved under
Windows is opened under Linux.
You can define OS dependent paths via the project macros. See project
options /
Mark Morgan Lloyd wrote:
Mattias Gaertner wrote:
On Thu, 28 Mar 2013 09:19:06 +
Mark Morgan Lloyd markmll.laza...@telemetry.co.uk wrote:
[...]
This can be a bit tricky, since it needs something like tr on all
platforms and Lazarus has problems with \ in the
ExecuteBefore...Command Value
Hello,
Am I correctly guessing that TTreeView is not based on platform native
implementation?
Thank
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On Thu, Mar 28, 2013 at 10:30 AM, Lubos Pintes pin...@gmail.com wrote:
Hello,
Am I correctly guessing that TTreeView is not based on platform native
implementation?
Thank
TTreeView is based on platform/widgetset native implementation.
-Flávio
--
There is a list of this here, thought it doesn't fully specify the
case of TTreeView:
http://wiki.lazarus.freepascal.org/Roadmap#Status_of_TCustomControl_based_controls_on_each_widgetset
--
Felipe Monteiro de Carvalho
--
___
Lazarus mailing list
Mattias Gaertner wrote:
On Thu, 28 Mar 2013 12:11:19 +
Mark Morgan Lloyd markmll.laza...@telemetry.co.uk wrote:
[...]
The IDE converts \,/ in all paths when for example a project saved under
Windows is opened under Linux.
You can define OS dependent paths via the project macros. See
Lubos Pintes pin...@gmail.com hat am 28. März 2013 um 14:30 geschrieben:
Hello,
Am I correctly guessing that TTreeView is not based on platform native
implementation?
Its logic is platform independent. It uses the LCL theme drawing functions and
colors.
Some native widgets have some nice
Flávio Etrusco flavio.etru...@gmail.com hat am 28. März 2013 um 14:39
geschrieben:
On Thu, Mar 28, 2013 at 10:30 AM, Lubos Pintes pin...@gmail.com wrote:
Hello,
Am I correctly guessing that TTreeView is not based on platform native
implementation?
Thank
TTreeView is based on
Interesting. On Windows it behaves like something custom drawn. The
screen reader only sees display text, there is no feedback about nodes
like collapsed/expanded etc.
So I will try to figure out why...
Dňa 28. 3. 2013 14:44 Felipe Monteiro de Carvalho wrote / napísal(a):
There is a list of
On 2013-03-28 11:52, Xiangrong Fang wrote:
What about the following...
const
cGitRevision = + {$revision.inc} + ;
That should work :)
That does not work.
Indeed, I just tested it (which I didn't before). Anyway, ignore my
spoon feeding commentemail humour fails
On 2013-03-28 12:00, Xiangrong Fang wrote:
WriteLn('COMPILED: ' + {$I %DATE%});
i.e. the $I above returned a string without trying to parse it.
It just returns a string string + string = string. Hence the
Writeln() statements works. As I said in another reply. The compiler has
some
On 03/28/2013 02:30 PM, Lubos Pintes wrote:
Hello,
Am I correctly guessing that TTreeView is not based on platform native
implementation?
Thank
No, it's not. LCL implementation takes TCustomControl from widgetset and
draws/handles it on it's own.
There was some plans to make it so, but no
On 2013-03-28 13:58, Mark Morgan Lloyd wrote:
I don't think that there's a 100% reliable heuristic, and there probably
Under MSEide and Maximus, I use the different compiler build modes for
this, and it works perfectly. eg: I use Build Mode 1 for Linux, and
Build Mode 2 is used for Windows.
Am 28.03.2013 12:52, schrieb Xiangrong Fang:
What about the following...
const
cGitRevision = + {$revision.inc} + ;
That should work :)
That does not work.
Eh, right. Sorry... I thought a bit too much here (or too less depending
on the
On Thu, Mar 28, 2013 at 11:22 AM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
Flávio Etrusco flavio.etru...@gmail.com hat am 28. März 2013 um 14:39
geschrieben:
On Thu, Mar 28, 2013 at 10:30 AM, Lubos Pintes pin...@gmail.com wrote:
Hello,
Am I correctly guessing that TTreeView is
Hi,
I've just added TProgressBar support for LCL-fpGUI, but I find the
widgetset design extremely confusing.
For example, I implemented TFpGuiWSProgressBar.SetPosition() - the
component is painted on the form, but the position property was never
set. Adding a SendDebug() call inside
On Thu, Mar 28, 2013 at 6:55 PM, Flávio Etrusco
flavio.etru...@gmail.com wrote:
Oops, my apologies then. Last time I saw at least the Win32
implementation was basically a wrapper around ComCtrl32
implementation...
That is in Delphi.
Juha
--
___
On 03/28/2013 05:56 PM, Graeme Geldenhuys wrote:
Hi,
I've just added TProgressBar support for LCL-fpGUI, but I find the
widgetset design extremely confusing.
For example, I implemented TFpGuiWSProgressBar.SetPosition() - the
component is painted on the form, but the position property was never
On 2013-03-28 17:53, zeljko wrote:
Yes, that's something pretty weird in TProgressBar implementation.I've
asked about it on mailing list few months ago afair, but no answer.
Also the ApplyUpdates() idea is extremely inefficient. You change one
property in TProgressBar, and at the widgetset
On Thu, Mar 28, 2013 at 03:21:41PM +0100, Mattias Gaertner wrote:
Its logic is platform independent. It uses the LCL theme drawing functions and
colors.
Some native widgets have some nice features, but have often problems with more
than a few thousands items.
Do they still in windows
On Thu, 28 Mar 2013 22:03:17 +0100
Marco van de Voort mar...@stack.nl wrote:
On Thu, Mar 28, 2013 at 03:21:41PM +0100, Mattias Gaertner wrote:
Its logic is platform independent. It uses the LCL theme drawing functions
and
colors.
Some native widgets have some nice features, but have
On 25/03/2013 11:44, Zaher Dirkey wrote:
On Tue, Feb 19, 2013 at 8:48 PM, Martin laza...@mfriebe.de wrote:
How long has it been virtual in the fpc base class?
Sorry for the delay
TList.Clear is virtual from revision 1, TFPList.Clear is not virtual.
Martin laza...@mfriebe.de написано 28.03.2013 19:58:17:
Also in your first example
ansi := Utf8ToAnsi('Кукла');
is that cyrillic? Can that be translated into ansi on your system? Have
you tried to output the string
for i := 1 to length(ansi) do s := s + inttostr(ord(ansi[i]))+', ';
On 29/03/2013 01:18, Ernest V Miller wrote:
There are 2 issues (in what I reproduced):
1) *** ???
Actually the ? are really present in the string. They are put there by
Utf8ToAnsi for characters that could not be translated to ansi. So in
that the debugger shows the correct content.
At
On Thu, Mar 28, 2013 at 9:04 PM, Graeme Geldenhuys
gra...@geldenhuys.co.uk wrote:
On 2013-03-28 11:52, Xiangrong Fang wrote:
That should work :)
That does not work.
Indeed, I just tested it (which I didn't before).
This problem is relatively frequent.
See
44 matches
Mail list logo
