Il 11/03/2010 04:02, Paul Ishenin ha scritto:
10.03.2010 22:35, Michael Van Canneyt wrote:
Is this known and tlb was not implemented because of some reason or it
was just ocasionally omited?
I think it is occasionally omitted.
Then please review r15001, r15002.
Looks good.
Just change
Il 01/02/2010 08:58, Paul Ishenin ha scritto:
01.02.2010 14:50, Giulio Bernardi wrote:
The reason is explained in this log message (2008-01-10):
* .res files must be copied to units output folder, otherwise .res files
will not be found when only compiled units path is available and
compiler
Il 01/02/2010 04:09, Paul Ishenin ha scritto:
Hello, FPC developers' list.
Is there a reason that during project compilation compiler duplicates
all the resource files in the compiler output dir? For me it looks as
both a waste of time and hdd free size. This happens for all LFM and RES
files
Il 29/01/2010 08:25, Paul Ishenin ha scritto:
Together with Dmitry we found the solution. Patch is attached.
Thanks, applied in rev 14824
Giulio
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Il 25/01/2010 15.40, zeljko ha scritto:
Hi all,
I've already filled up an issue
http://bugs.freepascal.org/view.php?id=15586 which shows the problem.
It cannot link application with 255 lfms (mac only - win32 linux are ok).
fpc-2.4.1 r14802
Anyone ?
Could you please make a test with the
Il 25/01/2010 18.40, zeljko ha scritto:
lindas-computer:~/genres Linda$ ppc386 test.pas
Free Pascal Compiler version 2.4.1 [2010/01/24] for i386
Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Darwin for i386
Compiling test.pas
Assembling test
Compiling resource test.or
Error: Can't open
Il 26/12/2009 20:43, Paul Ishenin ha scritto:
Giulio Bernardi wrote:
I have no fpc available at the moment. However, you can build yourself
the fcl-res documentation (run makehtml.sh) in xml directory, inside
fcl-res
directory. There are examples for groupiconresource too.
Yes, examples
Il 25/12/2009 17:05, Paul Ishenin ha scritto:
Hello, FPC developers' list
I have a question regards cursor and icon resource types.
When icon resource is used in rc file it is compiled into icon group and
several icon entries (as ico file has). Therefore each ico file is
splitted into entries
Marco van de Voort ha scritto:
On Mon, Nov 30, 2009 at 10:59:45PM +0100, Giulio Bernardi wrote:
perfectly now. Can it save without the BOM even if file had it before?
Yes, that would be possible.
But I think this should be fixed in fpcres. Otherwise windows
users editing the lfm files
Mattias Gaertner ha scritto:
On Mon, 30 Nov 2009 17:19:20 +0700
Paul Ishenin i...@kmiac.ru wrote:
Mattias Gaertner wrote:
Some clarifications:
The option does nothing at the moment.
The IDE auto detects if an unit uses $R or $I .lrs. If it uses $R
then the IDE will not update/create the .lrs
Marco van de Voort ha scritto:
Paul Ishenin ha scritto:
imposible for fpc 2.2.2. But yesterday it has been released and what
about next fpc version? Will you merge that nice staff into current
fixes branch or it will never be merged? I suppose if it ever will be
merged then better to merge it
Michael Van Canneyt ha scritto:
On Tue, 12 Aug 2008, Giulio Bernardi wrote:
Paul Ishenin ha scritto:
Hello, FPC developers' list
Since resource rework appeared in the trunk we are asking to merge that into
fixes branch to let lazarus use it. You told many times that it was
imposible for fpc
Tomas Hajny ha scritto:
Sorry, not root of ZIP file but root of units/i386-win32. Anyway, this
seems to be specific to 2.3.x (at least as of now, i.e. unless this bit
gets merged), because these units apparently belong to the new fpcres. I
guess that they shouldn't be distributed at all as they
From: [EMAIL PROTECTED]
To: fpc-devel@lists.freepascal.org
Subject: RE: [fpc-devel] Important: Call for testing.
Date: Sun, 30 Mar 2008 22:21:52 +
I have noticed another incompatibility with the previous version - the
TParser object in parser.inc can now return toWString as one of the
I have noticed another incompatibility with the previous version - the
TParser object in parser.inc can now return toWString as one of the
possibilities; the previous version returned toString regardless, but
offered a wide and normal version of the string. This change breaks
lazarus on
Date: Fri, 21 Mar 2008 16:24:12 +0100
From: [EMAIL PROTECTED]
To: fpc-devel@lists.freepascal.org
Subject: Re: [fpc-devel] Fix request
Martin Schreiber schreef:
On Friday 21 March 2008 15.09:22 Vincent Snijders wrote:
Martin Schreiber schreef:
On Friday 21 March 2008 14.54:24 Vincent
I could test only today. Now it works, thank you :)
bye,
Giulio
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
Please compile with -al, note the lines at which the assembler
complains (it prints them as pascalsourcefile:linenr, but those line
numbers are actually inside the assembler file) and create a bug
report showing what kind of expressions cause problems.
Done:
Hi,
I tried to cycle the compiler on my ancient PowerMacintosh G3 and both 2.2.1
and 2.3.1 fail.
The reason is that the assembler supplied with Xcode 1.5 (the last supported
version for 10.3.9) doesn't like the output generated by fpc.
I think that 2.2.0 is not affected since, when cycling,
That's probably the end of that computer lazarus installation, I can't
risk to mess up the libs again.
Personally, I use a 32 bit chroot environment to avoid headaches. The only
drawback is that you need root privileges to run chroot.
I wrote some bash scripts (very ugly and without error
Declare the structure again (in lazarus IIRC there are already some windows
types/records redefined) without ifdefs and make it compatible with the latest
version. With some care you can use the same structure on all windows versions.
In fact usually windows structures are the same at the
One of the reason Lazarus does not use resources like Delphi, is that
there is no support for Mac OS X yet (elf is supported by fpcres, as you
mentioned). Does your library support that?
No because I thought that on os x it was better to store resources as files
inside the app bundle since
Hi,
I was curious about resource support in FPC, and after investigating a bit I
wrote a library to handle resources. It provides classes to deal with some
common resource types, and readers and writers for various file formats
(res, coff, elf).
There could be various uses, for example:
-
Never mind, it's in the lines before. Seems like fpc doesn't allow
dereferencing a variable of a generic type in any way. The expression p^
will generate the error.
Sorry I made the wrong example. The problem isn't in the dereferencing of
the pointer,
but in accessing record fields. Here is
Hi,
I have a problem with generics (see code at the end of the mail).
I'm trying to use a record as the type of a generic class, but
the code doesn't compile because fpc complains with:
Error: Illegal qualifier
on lines where I use the record fields.
I think that the compiler should raise this
Is there any known to work binding for QT3 (or 4) that works without
using Lazarus ?
Yes: http://users.pandora.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html
bye,
Giulio
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 29 May 2006, at 19:39, Mattias Gaertner wrote:
Are there any known problems running FPC apps with Rosetta?
No, they work perfectly. Only the ppc compiler itself needed some changes
(to tell the assembler and linker to assemble/link ppc instead of x86
code).
What's the state of the
Here it is.
SPI* constants are ordered by number and by os version required.
definespatch.diff
Description: Binary data
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Hi,
I was playing around with lazarus and I found that solution to a bug (6950)
is trivial.
But it needs a constant (SPI_GETFLATMENU) that is not in
rtl/win/wininc/defines.inc
(or rtl/win32/wininc/defines.inc for fpc 2.0.x).
Is it ok if I send a patch to add all SPI* constants (taken from
Hi,
a strange thing has happened :P
When Peter fixed the gprof bug on win32, I simply downloaded gprt0.as from
svn, recompiled it
and replaced the old gprt0.o in my 2.0.2 install with the new one:
everything worked.
Now, I made a small package (gprof_win32) with libraries from cygwin and
Did someone manage to enable profiling on win32?
I linked with libc.a, libgmon.a, libgcc.a and libkernel32.a from cygwin
but
it fails on startup.
If I start the -pg compiled program I see:
monstartup: out of memory
Then program runs without problems, and at the end I see a couple of
access
Hi.
I'm writing a sort of compiler for a language similar to php (so it is not
a compiler since
it doesn't produce any object code, it only checks syntax and so on). I use
delphi 6 on
win32, and freepascal 1.9.x on Linux/i386 and Mac OS X. Sometimes I compile
it with
fpc under win32 too.
It works
32 matches
Mail list logo
