Re: [fpc-devel] FPDoc parser doesn't handle forward declarations properly?
On Thu, 8 Dec 2011, Graeme Geldenhuys wrote: On 7 December 2011 23:09, Hans-Peter Diettrich wrote: Does there exist a chance (trick) to use the input files of a different installation, without copying the description files? If you use the make command to generate the docs, simply pass the FPCSRCDIR command line parameter. eg: make rtl.chk fcl.chk FPCSRCDIR=/opt/fpc_2.4.5/src/ That's correct, but AFAIK, he uses a private description file. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFPCustomCanvas Expanded Clipping
Some more changes I'd like to propose. It seams that Rectangle is not TCanvas compatible: procedure TFPPixelCanvas.DoRectangle (const Bounds:TRect); A rectangle over (0, 0, 10, 10) should not include the pixels line with x=10 and y=10 but instead go only to x=9 and y=9, it is considered that the position is in the top-left of the pixel DoLine should not include the last point of the line (maybe unless you have a pen cap), although this one is a bit confusing. But it is how TCanvas works. On Wed, Dec 7, 2011 at 2:43 PM, Hans-Peter Diettrich wrote: >> Things in practice are much more complex then one might initially >> imagine. My regions implementation is reused for several things: >> 1> Drawing clipping >> 2> Drawing complex objects like poligons, polybeziers, arbitrary regions >> 3> To clip mouse/touch events There are more uses too: 4> Implement TRegion in LCL-CustomDrawn 5> Describe the shape of controls and forms -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFPCustomCanvas Expanded Clipping
On Thu, 8 Dec 2011, Felipe Monteiro de Carvalho wrote: Some more changes I'd like to propose. It seams that Rectangle is not TCanvas compatible: procedure TFPPixelCanvas.DoRectangle (const Bounds:TRect); A rectangle over (0, 0, 10, 10) should not include the pixels line with x=10 and y=10 but instead go only to x=9 and y=9, it is considered that the position is in the top-left of the pixel DoLine should not include the last point of the line (maybe unless you have a pen cap), although this one is a bit confusing. But it is how TCanvas works. Yes, but changing this will break existing code ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFPCustomCanvas Expanded Clipping
On Thu, Dec 8, 2011 at 9:33 AM, wrote: > Yes, but changing this will break existing code ? Yes, it cannot do both at the same time, unless we add a property PaintLikeTCanvas or something like that. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc parser doesn't handle forward declarations properly?
Am 08.12.2011 02:59, schrieb Hans-Peter Diettrich: Michael Van Canneyt schrieb: Wait, did you try this on FPC trunk sources ? That won't work. 2.6.0 sources should be OK. I could build RTL and FCL docs from 2.4.2 without major problems (the trunk Makefile was not fully compatible with the old directory structure). But when I tried to build the LCL, fpdoc crashes badly in THTMLWriter.AppendProcType (SIGSEGV). I tried to catch this error by try-except, but then Windows kills fpdoc. Running from the commandline at least reveals the Element as "FontEnumProc". I'll have to research a bit more... The -v option should become more verbose, just for hunting such bugs. And the messages should go to stdout instead of stderr, at least on Windows (with poor redirection capabilities). StdErr redirection works in Windows the same as on Unix systems. c:\>someapp.exe > stdout.txt 2> stderr.txt Will result in the output being split into the two textfiles. You can also redirect only the StdErr. See also: http://technet.microsoft.com/en-us/library/bb490982.aspx Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFPCustomCanvas Expanded Clipping
On Thu, 8 Dec 2011, Felipe Monteiro de Carvalho wrote: On Thu, Dec 8, 2011 at 9:33 AM, wrote: Yes, but changing this will break existing code ? Yes, it cannot do both at the same time, unless we add a property PaintLikeTCanvas or something like that. Hm. I would reverse the property. "UseFPCPaint", which must be switched 'on'. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc parser doesn't handle forward declarations properly?
In our previous episode, Sven Barth said: > > The -v option should become more verbose, just for hunting such bugs. > > And the messages should go to stdout instead of stderr, at least on > > Windows (with poor redirection capabilities). > > StdErr redirection works in Windows the same as on Unix systems. > > c:\>someapp.exe > stdout.txt 2> stderr.txt Or someapp.exe 2>&1 > stdoutandstderr.txt to combine it, but then someapp must flush every line. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc parser doesn't handle forward declarations properly?
michael.vancann...@wisa.be schrieb: Does there exist a chance (trick) to use the input files of a different installation, without copying the description files? If you use the make command to generate the docs, simply pass the FPCSRCDIR command line parameter. eg: make rtl.chk fcl.chk FPCSRCDIR=/opt/fpc_2.4.5/src/ That's correct, but AFAIK, he uses a private description file. Right. I didn't test what fpdoc stores in the new project file when invoked with such a commandline, and whether it could be substituted by --input-dir (most probably not). Since the document sources reside in their own repository, I simply move around that directory on my system, for now. Currently the following steps are required to build the project file and the docs: 1. make -n > mydocs.bat 2. edit mydocs.bat to make fpdoc create an project file 3. mydocs.bat 4. edit the mydocs.xml project as required 5. fpdoc mydocs.xml 2+3 could be omitted, when fpdoc would automatically create a project. 4+5 can be repeated as often as required. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc parser doesn't handle forward declarations properly?
Marco van de Voort schrieb: In our previous episode, Sven Barth said: The -v option should become more verbose, just for hunting such bugs. And the messages should go to stdout instead of stderr, at least on Windows (with poor redirection capabilities). StdErr redirection works in Windows the same as on Unix systems. c:\>someapp.exe > stdout.txt 2> stderr.txt Or someapp.exe 2>&1 > stdoutandstderr.txt to combine it, but then someapp must flush every line. Thanks, I need just that latter case. But it was much easier to patch fpdoc to use stdout for all messages :-) Now I have to check where and how to show more helpful information. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFPCustomCanvas Expanded Clipping
michael.vancann...@wisa.be schrieb: Yes, but changing this will break existing code ? Such code can be considered broken, deserves an fix anyhow. Yes, it cannot do both at the same time, unless we add a property PaintLikeTCanvas or something like that. Hm. I would reverse the property. "UseFPCPaint", which must be switched 'on'. I'd suggest that you use the TCanvas conventions, before you run into well known pitfalls. E.g. an empty rectangle should be (x,y, x,y), while a single pixel should be (x,y, x+1,y+1). The Width is Right-Left, not Right-Left+1. Otherwise combining regions, tiling (tables...), rotating etc. will be overly complicated and consequently almost buggy. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc parser doesn't handle forward declarations properly?
On Thu, 8 Dec 2011, Hans-Peter Diettrich wrote: michael.vancann...@wisa.be schrieb: Does there exist a chance (trick) to use the input files of a different installation, without copying the description files? If you use the make command to generate the docs, simply pass the FPCSRCDIR command line parameter. eg: make rtl.chk fcl.chk FPCSRCDIR=/opt/fpc_2.4.5/src/ That's correct, but AFAIK, he uses a private description file. Right. I didn't test what fpdoc stores in the new project file when invoked with such a commandline, and whether it could be substituted by --input-dir (most probably not). Since the document sources reside in their own repository, I simply move around that directory on my system, for now. Currently the following steps are required to build the project file and the docs: 1. make -n > mydocs.bat 2. edit mydocs.bat to make fpdoc create an project file 3. mydocs.bat 4. edit the mydocs.xml project as required 5. fpdoc mydocs.xml 2+3 could be omitted, when fpdoc would automatically create a project. Or if the documentation is created from projectfile directly, which is the plan. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc parser doesn't handle forward declarations properly?
Marco van de Voort schrieb: But when I tried to build the LCL, fpdoc crashes badly in THTMLWriter.AppendProcType (SIGSEGV). I tried to catch this error by try-except, but then Windows kills fpdoc. Running from the commandline at least reveals the Element as "FontEnumProc". I'll have to research a bit more... That's a known issue. IIRC a workaround was to compile fpdoc without optimization. Sorry, that didn't help :-( Perhaps something else is broken, I get an AV just at program start, since I use the trunk compiler. I tried to use an older compiler, too, but that fails due to recent changes to the parser. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc parser doesn't handle forward declarations properly?
In our previous episode, Hans-Peter Diettrich said: > >> But when I tried to build the LCL, fpdoc crashes badly in > >> THTMLWriter.AppendProcType (SIGSEGV). I tried to catch this error by > >> try-except, but then Windows kills fpdoc. Running from the commandline > >> at least reveals the Element as "FontEnumProc". > >> I'll have to research a bit more... > > > > That's a known issue. IIRC a workaround was to compile fpdoc without > > optimization. > > Sorry, that didn't help :-( So what was your commandline to build the checkout ? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc parser doesn't handle forward declarations properly?
michael.vancann...@wisa.be schrieb: Currently the following steps are required to build the project file and the docs: 1. make -n > mydocs.bat 2. edit mydocs.bat to make fpdoc create an project file 3. mydocs.bat 4. edit the mydocs.xml project as required 5. fpdoc mydocs.xml 2+3 could be omitted, when fpdoc would automatically create a project. Or if the documentation is created from projectfile directly, which is the plan. I wonder how such a project file will look like. Currently the Makefile does some configuration, what will not be possible with a common project file. Can somebody provide an project file, as used to build the official documentation - on a Linux system, I suppose? Then we can find out what may (or may not) be required to run that project on other platforms. Let me also repeat my thoughts about a general (HTML) documentation layout: - Keep all documentation in a user specified directory (where the user has all rights), with subdirectories for each package. - Have one css file in that directory, for use by all HTML pages. - Put all content files in that directory, too. - Add a global documentation page, covering all documented packages. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFPCustomCanvas Expanded Clipping
On Thu, Dec 8, 2011 at 11:49 AM, Hans-Peter Diettrich wrote: > I'd suggest that you use the TCanvas conventions, before you run into well > known pitfalls. > > E.g. an empty rectangle should be (x,y, x,y), while a single pixel should be > (x,y, x+1,y+1). The Width is Right-Left, not Right-Left+1. Otherwise > combining regions, tiling (tables...), rotating etc. will be overly > complicated and consequently almost buggy. Yes, in the case of the rectangle drawing I think it was a typo by who implemented the current rectangle in fcl-image, I have done various similar typos in my coding and they don't mean I really wanted to redefine rectangle. But the TCanvas line is trully confusing by not adding the last pixel. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc parser doesn't handle forward declarations properly?
Marco van de Voort schrieb: That's a known issue. IIRC a workaround was to compile fpdoc without optimization. Sorry, that didn't help :-( So what was your commandline to build the checkout ? Argh, I did updates regularly, but forgot to rebuild the compiler etc. :-( But rebuilding only removed the AV at program start, fpdoc still crashes at the same location :-( Fpdoc seems not to collect properly the declarations, e.g. Warning: Target ID of is unknown: "#lcl.Controls.TCursor" should not occur. Now I'll start to check and fix the warnings in the RTL and FCL, perhaps this will give some more insight... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFPCustomCanvas Expanded Clipping
Felipe Monteiro de Carvalho schrieb: Yes, in the case of the rectangle drawing I think it was a typo by who implemented the current rectangle in fcl-image, I have done various similar typos in my coding and they don't mean I really wanted to redefine rectangle. But the TCanvas line is trully confusing by not adding the last pixel. It works properly in drawing polygons, in detail with lines of different colors or styles. When the last (end) pixel would be painted for every line, the connection points would be drawn twice. This doesn't look dramatic for polygons, but may cause trouble in drawing other elements. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Makeskel errors on Windows
Makeskel expects another(?) semicolon after win\wininc\func.inc:
function GetRandomRgn(aHDC: HDC; aHRGN: HRGN; iNum: WINT): WINT;
stdcall; external 'gdi32';
function ...
Perhaps it cannot parse the "external" directive?
FPDoc seems to suffer from the same problem, it creates an all-empty
description for windows.pp.
Workaround: exclude "func.inc" from the include file list in windows.pp:
{$IFNDEF fpdocsystem}
{$i func.inc}
{$ENDIF}
Then windows.pp can be added to the rtl project, and is documented by
fpdoc. No content so far, of course.
I also could not find an option to make the Makefile use a different
OSTARGET - it always seems to use the current system settings. Even if
some cross-platform information may be desireable in the documentation,
some essentially platform-dependent units should be documented in the
current platform variation, e.g. rtl/win32/system.pp instead of
rtl/linux/system.pp, winsocks instead of or in addition to the linux
sockets. For units for other targets (dos...) the compiler options
should reflect the proper compiler options (-d, -Fi), else the
generated documentation may be quite useless.
For platform-specific units with a common interface (system, classes...)
the XML files can either reflect all platform variations, or the
descriptions can be separated into common documentation (*.xml) and
platform specific extensions (*.xml), so that entries are not
inadvertently removed, when they do not apply to the platform of an
documentation writer.
Regardless of whether we want to provide all-in-one documentation, or
platform specific documentation, the generation of the documents
deserves some more thoughts. The current Linux (+dos+...-windows)
documentation is not really helpful to Windows users.
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
