Am 19.12.2011 04:05 schrieb "Hans-Peter Diettrich" :
>
> Mattias Gaertner schrieb:
>
>
>>> I understand that conflicts can arise, when the same XML file is
modified by different means. But it is not nice when the IDE then crashes.
>>
>>
>> Can you create a stacktrace?
>
>
> How?
>
> The IDE only di
Mattias Gaertner schrieb:
I understand that conflicts can arise, when the same XML file is
modified by different means. But it is not nice when the IDE then crashes.
Can you create a stacktrace?
How?
The IDE only disappears, silently, including the console window :-(
DoDi
On Sat, 17 Dec 2011 17:06:21 +0100
Hans-Peter Diettrich wrote:
> Mattias Gaertner schrieb:
> > On Sat, 17 Dec 2011 15:41:32 +0100
> > Hans-Peter Diettrich wrote:
> >
> >> [...]
> >> The documentation related features could become Lazarus plug-ins, of
> >> course, similar to or as an extension
On Sun, 18 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
I have done so for years, with the existing tools, using the Makefiles.
No changes were necessary.
Can you explain that a bit more? I'm not a professional commandline user,
perhaps I'm doing something stupid?
Michael Van Canneyt schrieb:
I have done so for years, with the existing tools, using the
Makefiles. No changes were necessary.
Can you explain that a bit more? I'm not a professional commandline
user, perhaps I'm doing something stupid?
I just do a "make updatexml" or "make updatefclxml" o
On Sat, 17 Dec 2011, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
On Sat, 17 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Feel free to create this program. If I may give some advice: the tasks
you outline belong in a "Documentation writers IDE"
Mattias Gaertner schrieb:
On Sat, 17 Dec 2011 15:41:32 +0100
Hans-Peter Diettrich wrote:
[...]
The documentation related features could become Lazarus plug-ins, of
course, similar to or as an extension of the FPDoc Editor window. But
this already existing support makes it *harder* to add fur
michael.vancann...@wisa.be schrieb:
On Sat, 17 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Feel free to create this program. If I may give some advice: the
tasks you outline belong in a "Documentation writers IDE".
To some degree, maybe. But checking for updates s
On Sat, 17 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Feel free to create this program. If I may give some advice: the tasks you
outline belong in a "Documentation writers IDE".
To some degree, maybe. But checking for updates should be doable by a script,
without
On Sat, 17 Dec 2011 15:41:32 +0100
Hans-Peter Diettrich wrote:
>[...]
> The documentation related features could become Lazarus plug-ins, of
> course, similar to or as an extension of the FPDoc Editor window. But
> this already existing support makes it *harder* to add further
> functionality
Michael Van Canneyt schrieb:
When we look at new packages, some general tasks come into mind:
[snip]
I'd prefer that all beforementioned tasks can be accomplished by a
single program, by only giving it an project file, task, and
task-specific options.
Feel free to create this program. If
On Sat, 17 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
ACK. There is no *need* to use MakeSkel with a project, but using this option
offers many advantages.
When we look at new packages, some general tasks come into mind:
[snip]
I'd prefer that all beforementione
Michael Van Canneyt schrieb:
Consider an existing FPDoc project, which contains all input files and
all currently existing description files. When you want to create a
new skeleton for an not yet documented unit, how to achieve that?
Should the user copy the stored --input specification for th
On Fri, 16 Dec 2011, Hans-Peter Diettrich wrote:
No. You forget that the coupling with unit names does not exist.
Please explain?
Both FPDoc and MakeSkel accept one or more --input arguments, each
representing one *unit*. When a project is used instead, either none or all
units can be sel
Michael Van Canneyt schrieb:
Then the created skeletons can be added to the DescrFiles list, and
the updated project can be saved on exit.
I don't think this is good. makeskel creates a diff, you should not add
this to the list of files; instead, after it was created, it should be
merged wit
On Fri, 16 Dec 2011, Hans-Peter Diettrich wrote:
When MakeSkel shall use FPDoc projects, this can be achieved by adding
something like:
procedure LoadProject(const Arg: string);
begin
ProjectName := Arg;
Project := TFPDocProject.Create(Nil); //owner component?
With TXMLFPDocOptions.Create
When MakeSkel shall use FPDoc projects, this can be achieved by adding
something like:
procedure LoadProject(const Arg: string);
begin
ProjectName := Arg;
Project := TFPDocProject.Create(Nil); //owner component?
With TXMLFPDocOptions.Create(Project) do
try
LoadOptionsFromFile(Pro
17 matches
Mail list logo
