Michael Van Canneyt schrieb:
That would conflict with the GUI TApplication instance, so I really
don't see the point of this exercise.
Then another error in the logic exists: CreateDocumentation should be
a method of TFPDocProject, not of TFPDocAplication.
Why ? TFPDocProject is just storag
In my review of the fpdoc project option some questions popped up. The
most important question: should fpdoc be usable for creating online help
only, or should it also allow users to create offline documentation on
their local machine? When a user can create documentation files for
local use, t
On Tue, 29 Nov 2011, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
When this were the *only* code in the fpdoc program file, another project
could create a derived class, with a possibly specialized Run method,
without touching the declaration or implementation of TFPDocAp
On 29 Nov 2011, at 19:19, Thaddy wrote:
> There's a documented delphi version: almost complete D7 support *by the
> compiler* and by now d2006 now almost feature complete.
That only works in one way: the compiler can support most of D7 and D2006, but
if you check for everything the compiler s
In our previous episode, Thaddy said:
> There's a documented delphi version: almost complete D7 support *by the
> compiler* and by now d2006 now almost feature complete.
That goes for the release branch that is already in freeze. New features
will go into trunk, which will have, among others, the
On 29/11/2011, Sven Barth wrote:
>
> You could try the Jedi Code Formatter included with Lazarus. I've never
> tested it myself, because it is the first thing I disable when
That copy of JCF is bugy. Rather use the original version available
for download on SourceForge, from the JCF project. Also
On 29.11.2011 13:11, Hans-Peter Diettrich wrote:
I'm even trying to concentrate as good as possible to adhere to the
style used there,
Where's the code formatter, that would eliminate all such discussions?
You could try the Jedi Code Formatter included with Lazarus. I've never
tested it myse
On 29-11-2011 18:49, Tomas Hajny wrote:
Which Delphi version would be the supposedly supported one? If this is
not explicitly defined, compilation might still fail when people using
lower Delphi versions try to compile the code. Do you really want to
track the feature set (especially for smalle
On Tue, November 29, 2011 17:51, Thaddy wrote:
> On 29-11-2011 16:54, Felipe Monteiro de Carvalho wrote:
>> mode delphi is used in a huge amount of code, so any break in
>> backwards compatibility here would be extremely unwelcome. It surely
>> would break a lot of code that I wrote. But yes, $mode
On 29-11-2011 16:54, Felipe Monteiro de Carvalho wrote:
mode delphi is used in a huge amount of code, so any break in
backwards compatibility here would be extremely unwelcome. It surely
would break a lot of code that I wrote. But yes, $mode strictdelphi
looks like a good idea if you want to im
michael.vancann...@wisa.be schrieb:
When this were the *only* code in the fpdoc program file, another
project could create a derived class, with a possibly specialized Run
method, without touching the declaration or implementation of
TFPDocApplication.
That would conflict with the GUI TAppli
On Tue, Nov 29, 2011 at 4:14 PM, Thaddy wrote:
> So, much like $mode objfpc extends the syntax let $mode delphi restrict the
> syntax.
> There is a case to make that f.e. the C style operators and the macro
> facilities belong to $mode objfpc anyway.
> Or am I wrong here?
> Or is there value in it
On 29 Nov 2011, at 16:14, Thaddy wrote:
On 29-11-2011 15:46, Jonas Maebe wrote:
Possibly, but it would also require RTL changes (the FPC system
unit contains many types, constants, variables and functions that
do not exist in Delphi -- and for programmers the difference
between the langua
BTW I am aware I can solve this at the sourcecode level with defines - I
just did that -, but would prefer one of my suggestions.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 29-11-2011 15:46, Jonas Maebe wrote:
Possibly, but it would also require RTL changes (the FPC system unit
contains many types, constants, variables and functions that do not
exist in Delphi -- and for programmers the difference between the
language and the system unit is often not very clear
On 29 Nov 2011, at 15:39, Thaddy wrote:
I ran into my own problem when writing a program in freepascal that
also should compile in Delphi (don't ask)
Logically you would expect $mode delphi to enforce delphi
compatibility at the sourcecode level.
But this is not the case if f.e. C style oper
On 29 Nov 2011, at 15:30, Michael Müller wrote:
Am 28.11.2011 um 13:12 schrieb Jonas Maebe:
You do get a warning if you use an "out" parameter inside a routine
without first writing to it.
But only if you try to access an array element. I would have
expected to get such a warning also w
I ran into my own problem when writing a program in freepascal that also
should compile in Delphi (don't ask)
Logically you would expect $mode delphi to enforce delphi compatibility
at the sourcecode level.
But this is not the case if f.e. C style operators are used or
specified, or macro's.
I
On Tue, 29 Nov 2011, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
begin
With TFPDocAplication.Create(Nil) do
try
Run;
finally
Free;
end;
end.
When this were the *only* code in the fpdoc program file, another project
could create a derived class, with
On Tue, 29 Nov 2011, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
A "make -n rtl.chk > test.txt" succeeded, at least. Now I suspect some
Windows or RTL commandline limitations, which seem to truncate the long
command lines created by the scripts (4890 chars for rtl.chk).
Am 28.11.2011 um 13:12 schrieb Jonas Maebe:
>
> On 28 Nov 2011, at 12:02, Michael Müller wrote:
>
>> Am 28.11.2011 um 01:05 schrieb Jonas Maebe:
>>
>>> If you enable hints, the compiler will print a hint if it detects you
>>> passing a potentially uninitialized variable to a "var" parameter,
Tomas Hajny schrieb:
The current limit of the default MS Windows shell is 8 kB according to
information found on Microsoft pages (among others). Are those 4890
characters mentioned above Unicode (UTF-16) characters (thus breaking the
limit)? Anyway, it might be possible to use a different comman
Sven Barth schrieb:
I'm not a huge fan of the style used in the compiler, but am I
complaining?
Did I?
I'm even trying to concentrate as good as possible to
adhere to the style used there,
Where's the code formatter, that would eliminate all such discussions?
so that the changes I want to
michael.vancann...@wisa.be schrieb:
2. Try to separate things. You coded a change in package selection
handling, please don't mix this with the change for writing a package
file. It makes it more difficult to debug when bugs arise.
How can I create patches for different topics, when the whole
michael.vancann...@wisa.be schrieb:
A "make -n rtl.chk > test.txt" succeeded, at least. Now I suspect some
Windows or RTL commandline limitations, which seem to truncate the
long command lines created by the scripts (4890 chars for rtl.chk).
This is a problem of windows, yes.
Argh :-(
Try
On Tue, 29 Nov 2011, Marco van de Voort wrote:
In our previous episode, michael.vancann...@wisa.be said:
INF or HTML), and replaced them with simple command line programs that
can be compiled from: fpc somecoolutitility.pas
You then have TProcess, the whole RTL and FCL at your disposal. MUC
In our previous episode, michael.vancann...@wisa.be said:
> > INF or HTML), and replaced them with simple command line programs that
> > can be compiled from: fpc somecoolutitility.pas
> >
> > You then have TProcess, the whole RTL and FCL at your disposal. MUCH
> > more powerful than scripts or ma
Am 29.11.2011 12:18, schrieb michael.vancann...@wisa.be:
On Tue, 29 Nov 2011, Graeme Geldenhuys wrote:
On 29/11/2011, Hans-Peter Diettrich wrote:
A "make -n rtl.chk > test.txt" succeeded, at least. Now I suspect some
Windows or RTL commandline limitations, which seem to truncate the long
c
On Tue, 29 Nov 2011, Graeme Geldenhuys wrote:
On 29/11/2011, Hans-Peter Diettrich wrote:
A "make -n rtl.chk > test.txt" succeeded, at least. Now I suspect some
Windows or RTL commandline limitations, which seem to truncate the long
command lines created by the scripts (4890 chars for rtl.ch
On 29/11/2011, Hans-Peter Diettrich wrote:
>
> A "make -n rtl.chk > test.txt" succeeded, at least. Now I suspect some
> Windows or RTL commandline limitations, which seem to truncate the long
> command lines created by the scripts (4890 chars for rtl.chk).
Does this limitation apply when using T
On Tue, November 29, 2011 10:42, michael.vancann...@wisa.be wrote:
> On Tue, 29 Nov 2011, Hans-Peter Diettrich wrote:
>> Hans-Peter Diettrich schrieb:
>>
>>> Unfortunately there remain some problems, e.g. the FPC documentation
>>> cannot
>>> be created on Windows, what is one reason for the extende
On Tue, 29 Nov 2011, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
On Mon, 28 Nov 2011, Hans-Peter Diettrich wrote:
I just implemented and option to create an XML project from the
commandline arguments. This should allow to create projects from the
scripts and Makefiles
Am 29.11.2011 11:09, schrieb Hans-Peter Diettrich:
michael.vancann...@wisa.be schrieb:
On Mon, 28 Nov 2011, Hans-Peter Diettrich wrote:
I just implemented and option to create an XML project from the
commandline arguments. This should allow to create projects from the
scripts and Makefiles,
michael.vancann...@wisa.be schrieb:
On Mon, 28 Nov 2011, Hans-Peter Diettrich wrote:
I just implemented and option to create an XML project from the
commandline arguments. This should allow to create projects from the
scripts and Makefiles, used to build the documentation for the
standard l
On Tue, 29 Nov 2011, Hans-Peter Diettrich wrote:
Hans-Peter Diettrich schrieb:
Unfortunately there remain some problems, e.g. the FPC documentation cannot
be created on Windows, what is one reason for the extended project option,
but doesn't allow me to debug this feature with real life pro
Hans-Peter Diettrich schrieb:
Unfortunately there remain some problems, e.g. the FPC documentation
cannot be created on Windows, what is one reason for the extended
project option, but doesn't allow me to debug this feature with real
life projects (RTL...).
A "make -n rtl.chk > test.txt" suc
On Mon, 28 Nov 2011, Hans-Peter Diettrich wrote:
I just implemented and option to create an XML project from the commandline
arguments. This should allow to create projects from the scripts and
Makefiles, used to build the documentation for the standard libraries. See
Mantis #20769.
I had
37 matches
Mail list logo
