[fpc-devel] FindFirst under Linux doesn't set faHidden
Hi, As per the documentation: http://lazarus-ccr.sourceforge.net/docs/rtl/sysutils/findfirst.html - faHidden The file is hidden. (On unix, this means that the filename starts with a dot) --- I've tried this today using FPC 2.1.5 and faHidden doesn't seem to be set, ever. Below is a list of files I tested on under Linux. I first printed the filename found by FindFirst/FindNext and then I printed True or False if the faHidden attribute was set. As you can see even for files with the '.' (dot) prefix, the faHidden is never set. .. FALSE .svn FALSE units FALSE . FALSE filegrid.lpr FALSE filegrid.lps FALSE filegrid.compiled FALSE filegrid.lpi FALSE filegrid FALSE .I_should_be_hidden FALSE I know unix OS's don't have a real notion of 'hidden' files, but it is a standard to treat dot prefix files as hidden. The FPC documentation mentions that and Kylix treated it like that as well. Can anybody else confirm this, before I submit a bug report? Oh, and here is the function I use to test the attribute: // Example: HasAttrib(sr.Attr, faHidden) returns True if faHidden was set. function HasAttrib(fileAttrib, testAttrib: Integer): Boolean; begin Result := (fileAttrib and testAttrib) 0; end; Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: FindFirst under Linux doesn't set faHidden
faSymLink also seem to never be set. Same issue as faHidden. Graeme. On 16/08/07, Graeme Geldenhuys [EMAIL PROTECTED] wrote: Hi, As per the documentation: http://lazarus-ccr.sourceforge.net/docs/rtl/sysutils/findfirst.html - faHidden The file is hidden. (On unix, this means that the filename starts with a dot) --- I've tried this today using FPC 2.1.5 and faHidden doesn't seem to be set, ever. Below is a list of files I tested on under Linux. I first printed the filename found by FindFirst/FindNext and then I printed True or False if the faHidden attribute was set. As you can see even for files with the '.' (dot) prefix, the faHidden is never set. .. FALSE .svn FALSE units FALSE . FALSE filegrid.lpr FALSE filegrid.lps FALSE filegrid.compiled FALSE filegrid.lpi FALSE filegrid FALSE .I_should_be_hidden FALSE I know unix OS's don't have a real notion of 'hidden' files, but it is a standard to treat dot prefix files as hidden. The FPC documentation mentions that and Kylix treated it like that as well. Can anybody else confirm this, before I submit a bug report? Oh, and here is the function I use to test the attribute: // Example: HasAttrib(sr.Attr, faHidden) returns True if faHidden was set. function HasAttrib(fileAttrib, testAttrib: Integer): Boolean; begin Result := (fileAttrib and testAttrib) 0; end; Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc HTML with search feature
[...this is maybe not the best list to discuss this...] On 16/08/07, Michael Schnell [EMAIL PROTECTED] wrote: The Lazarus LCL did not work for us. That's too bad ! What was the problem ? (I'm asking, as I might want to use Lazarus or a modification of same for an embedded project which could need a remote GUI access sometimes, but not permanently) Let me make one thing clear. The IDE is great, it's just the LCL we have a issue with. If you develop for a single platform you shouldn't have any issue. Our products need to run under Windows and Linux, and this is where the problems started. 1) We have experienced events firing in different order depending on the platform. This makes event handling very difficult. 2) We experienced events firing multiple times on one platform, but not on another (OnClick or OnSelect events come to mind). 3) One platform supports changing the background color of a Form, the other platform doesn't. ... the list goes on, but I think you get the idea. Now in some case we could create workarounds and sometimes wrap code with IFDEF's (which defeats the point of Lazarus LCL). This all worked fine until one of those issues where fixed, which means our code breaks again! We got tired of going back and forwards. Now as I mentioned, if you target a single platform, these issues should go away. fpGUI has been revived and lives on! :-) Is the revived version publicly available ? What are it's advantages over the older version and over the Lazarus RTL in detail ? Yes it's publicly available. The project is hosted on SourceForge. For more details on the project, advantages and features, have a look at the project website. http://opensoft.homeip.net/fpgui/ In summary. The new fpGUI is much faster and also uses less code because we take advantage of what the underlying windowing system was designed to do - handle windows, events, clipping etc. No need to rewrite all of that again. We also needed consistency across platforms (which the LCL lacked) as our products will run in 250+ centres which have a mixed install base (Windows and Linux in the same centre, slowly converting some to Linux only). Some of our products also target school kids so tend to be more visual (graphical) and need lots of customization. All these and more are addressed in the new fpGUI. Thanks for enlightenment ! Always a pleasure. ;-) Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc HTML with search feature
Graeme Geldenhuys schreef: [...this is maybe not the best list to discuss this...] On 16/08/07, Michael Schnell [EMAIL PROTECTED] wrote: The Lazarus LCL did not work for us. That's too bad ! What was the problem ? (I'm asking, as I might want to use Lazarus or a modification of same for an embedded project which could need a remote GUI access sometimes, but not permanently) Let me make one thing clear. The IDE is great, it's just the LCL we have a issue with. If you develop for a single platform you shouldn't have any issue. Our products need to run under Windows and Linux, and this is where the problems started. I am a bit disappointed to hear this. 1) We have experienced events firing in different order depending on the platform. This makes event handling very difficult. It is hard to get right, but we make are best attempts to fix these kind of inconsistencies, if they are reported. 2) We experienced events firing multiple times on one platform, but not on another (OnClick or OnSelect events come to mind). See 1. 3) One platform supports changing the background color of a Form, the other platform doesn't. I guess you are only limited by the windows backend, while the LCL is also limited by the widget set. ... the list goes on, but I think you get the idea. Now in some case we could create workarounds and sometimes wrap code with IFDEF's (which defeats the point of Lazarus LCL). This all worked fine until one of those issues where fixed, which means our code breaks again! We got tired of going back and forwards. I hope you don't blame us for making bug fixes ;-) Now as I mentioned, if you target a single platform, these issues should go away. Single platform LCL kind of defeats the purpose of the LCL. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc HTML with search feature
Graeme Geldenhuys wrote: Now in some case we could create workarounds and sometimes wrap code with IFDEF's (which defeats the point of Lazarus LCL). This all worked fine until one of those issues where fixed, which means our code breaks again! We got tired of going back and forwards. It surprises me you didn't consider fixing the LCL, while you are now writing a complete widgetset yourself. The LCL seems complex, but with some answered questions you may have, it's not exactly rocket science either. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc HTML with search feature
On 16/08/07, Vincent Snijders [EMAIL PROTECTED] wrote: If you develop for a single platform you shouldn't have any issue. Our products need to run under Windows and Linux, and this is where the problems started. I am a bit disappointed to hear this. And so were we experiencing it. :-) 1) We have experienced events firing in different order depending on the platform. This makes event handling very difficult. It is hard to get right, but we make are best attempts to fix these kind of inconsistencies, if they are reported. Oh I don't argue that and yes I have reported many bugs already! Even fixed a few. I think all the LCL developers have done an amazing job so far. I can only imagine how difficult it must be to even out all the widget set differences and get a common set of functionality in the LCL - _plus_ make it as Delphi compatible as possible. That is no small task! I think the design choice to use native widget sets was a very ambitious one. Not realizing how different widget sets can be and that maybe implementing their own Lazarus widget set would have been a much easier and quicker task. Just see how much I have accomplished in only 6 weeks (though I'm not near the feature list of LCL yet). I hope you don't blame us for making bug fixes ;-) :-) Not at all. Bug fixes are always welcome, as you know. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] error in comment?
While browsing the rtl sources, I stumbled on the following in rtl\win32\system.pp const CtrlZMarksEOF: boolean = true; (* #26 not considered as end of file *) The comment seems inconsistent with the the value 'true'. See also http://lazarus-ccr.sourceforge.net/docs/rtl/system/ctrlzmarkseof.html Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc HTML with search feature
On 16/08/07, Micha Nelissen [EMAIL PROTECTED] wrote: It surprises me you didn't consider fixing the LCL, while you are now writing a complete widgetset yourself. The LCL seems complex, but with some answered questions you may have, it's not exactly rocket science either. I have fixed a few bugs but no matter how much you fix, their will always be some issues. The underlying (native) widget sets are a moving target as they are constantly developed as well. Also you have other issues to consider: * Maybe we had bad luck with timing. We used GTK1 because GTK2 was unusable at that stage. Then development started on GTK2 and broke very frequently the GTK1 widget set. We couldn't change to GTK2 at that stage, because it was heavily under development. We had to revert to older Lazarus version where GTK2 didn't break anything and couldn't take advantage of bug fixes available to GTK1. * What if you find a bug in a Windows component, and that same component under GTK or Qt doesn't have that issue. More workarounds in the Windows layer, because you can't actually fix the bug at hand. * Then lets talk about native widgets limitations. A simple thing like changing the background color of a button. Not possible under Windows (without a custom button component) but is under GTK. Reported back in 2005 and still not resolved. Still being discussed (last postings on mailing list dated 18 July 2007) http://www.freepascal.org/mantis/view.php?id=1188 The same I believe was true (but opposite way around in GTK) with Form background color. Not sure if this was resolved yet. Last time I was told I am not supposed to change the Form's background color, but should let the desktop theme control that. Tell that to WinAmp style apps. We would like to control the look of our applications. These are _not_ supposed to be complex problems! Using a custom written widget set, such issues could have been fixed in minutes and work on all platforms. Sorry for the long post... :) Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc HTML with search feature
Graeme Geldenhuys wrote: * What if you find a bug in a Windows component, and that same component under GTK or Qt doesn't have that issue. More workarounds in the Windows layer, because you can't actually fix the bug at hand. Workarounds? Why can't the bug be fixed? * Then lets talk about native widgets limitations. A simple thing like changing the background color of a button. Not possible under Windows (without a custom button component) but is under GTK. TSpeedButton should be able to do this, since it's custom drawn ? The same I believe was true (but opposite way around in GTK) with Form background color. This is an unfortenate one indeed. I'd hardly call it a show stopper though; even can be worked around on LCL level by perhaps implementing some 'OnPaint' or a panel or graphic control on top that draws the requested color. If you want background pictures, which is not a very big step from just a color, you need something like that always. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc HTML with search feature
On 16/08/07, Micha Nelissen [EMAIL PROTECTED] wrote: * What if you find a bug in a Windows component, and that same component under GTK or Qt doesn't have that issue. More workarounds in the Windows layer, because you can't actually fix the bug at hand. Workarounds? Why can't the bug be fixed? It can't be fixed by Lazarus developers because the Windows component lives in the Common Controls DLL? This is just an example by the way, they same could be said for Qt or Carbon. Graeme. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics
--- Michael Van Canneyt [EMAIL PROTECTED] escribió: On Thu, 16 Aug 2007, Mattias Gaertner wrote: What is the state and future plans of generics? I only found the wiki page http://wiki.lazarus.freepascal.org/Generics which does not even mention the current syntax. The current syntax is descibed in the docs, reference manual. There is a chapter about generics. Feel free to comment on it; any omissions, I'll be glad to fill them in (as far as I can, I don't use generics myself). Michael. Images are so big that is difficult to follow the diagrams.. Jesus Reyes A. ¡Sé un mejor besador! Comparte todo lo que sabes sobre besos. http://mx.yahoo.com/promos/mejorbesador.html ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics
--- Jesus Reyes [EMAIL PROTECTED] escribió: --- Michael Van Canneyt [EMAIL PROTECTED] escribió: On Thu, 16 Aug 2007, Mattias Gaertner wrote: What is the state and future plans of generics? I only found the wiki page http://wiki.lazarus.freepascal.org/Generics which does not even mention the current syntax. The current syntax is descibed in the docs, reference manual. There is a chapter about generics. Feel free to comment on it; any omissions, I'll be glad to fill them in (as far as I can, I don't use generics myself). Michael. Images are so big that is difficult to follow the diagrams.. sorry I forgot to put at least a link: http://www.freepascal.org/docs-html/ref/refse38.html Jesus Reyes A. ¡Sé un mejor besador! Comparte todo lo que sabes sobre besos. http://mx.yahoo.com/promos/mejorbesador.html ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics
On Thu, 16 Aug 2007, Jesus Reyes wrote: --- Michael Van Canneyt [EMAIL PROTECTED] escribió: On Thu, 16 Aug 2007, Mattias Gaertner wrote: What is the state and future plans of generics? I only found the wiki page http://wiki.lazarus.freepascal.org/Generics which does not even mention the current syntax. The current syntax is descibed in the docs, reference manual. There is a chapter about generics. Feel free to comment on it; any omissions, I'll be glad to fill them in (as far as I can, I don't use generics myself). Michael. Images are so big that is difficult to follow the diagrams.. Please use the PDF version, not the HTML version. The HTML is generated from the LaTeX, but the quality is in general rather poor. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpmake listsources
On Thu, 16 Aug 2007, Peter Vreman wrote:
At 19:35 16-8-2007, you wrote:
While looking at the listsources command I found something peculiar (i
think).
The method TPackage.GetSourceFiles lists all sources stored in TSources. This
seems to be strange for two reasons
1) all sources are stored in TTarget
2) the sources variable in TPackage is never filled automatically when you
add units or programs from fpmake.pp, which would indicate the user has to
fill the variable himself, but this defies the listsources command.
This leads me to believe TSources is an artifact from the past. Is that
correct?
I would propose to change the implementation in TPackage.GetSourceFiles so it
retrieves sources from TTarget instead and then remove TSources altogether.
Oh yes, what is the actual planned purpose of listsources ;) ? Is it
something similar to maven verify? In that case I would like to propose to
additionally list the results of all commands plus some checks. I will give a
more detailed example if needed.
This is exactly the point were development of fppkg/fpmake stalled.
Proving my statement that sources was added at a later point, since I
didn't include it initially :-)
There needs to be a xml file generated either in sources.xml or manifest.xml
that can be used by fppkg to create an archive out of it.
Using TTarget for sources is a bit complex because you can have include files
and also implicitly build units that also depend on include files and
depending on the target different source directories. Also how to handle
additional input data files that are convert to typedconstant-includefiles.
Therefor i had the idea to add a TSources that can list complete directories.
That seems a bit overkill. I would add some commands that can be used to fill
up sources.
AddSources('*.pp')
AddSource('somesource.pas');
AddSource('somefile.ini');
There is no final decision made yet. Ideas how to implement it nicely are
welcome.
I'll be on holiday the next week so i won't be able to comment on ideas.
I am not on holiday, so I am available for comments :-)
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics
On Thu, 16 Aug 2007 14:59:47 -0500 (CDT) Jesus Reyes [EMAIL PROTECTED] wrote: --- Jesus Reyes [EMAIL PROTECTED] escribió: --- Michael Van Canneyt [EMAIL PROTECTED] escribió: On Thu, 16 Aug 2007, Mattias Gaertner wrote: What is the state and future plans of generics? I only found the wiki page http://wiki.lazarus.freepascal.org/Generics which does not even mention the current syntax. The current syntax is descibed in the docs, reference manual. There is a chapter about generics. Feel free to comment on it; any omissions, I'll be glad to fill them in (as far as I can, I don't use generics myself). Michael. Images are so big that is difficult to follow the diagrams.. sorry I forgot to put at least a link: http://www.freepascal.org/docs-html/ref/refse38.html Thanks. Maybe the wiki page should be marked as obsolete and a link to the reference should be added? Why is the local variable block needed? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpmake listsources
Michael Van Canneyt wrote:
On Thu, 16 Aug 2007, Peter Vreman wrote:
At 19:35 16-8-2007, you wrote:
While looking at the listsources command I found something peculiar (i
think).
The method TPackage.GetSourceFiles lists all sources stored in TSources. This
seems to be strange for two reasons
1) all sources are stored in TTarget
2) the sources variable in TPackage is never filled automatically when you
add units or programs from fpmake.pp, which would indicate the user has to
fill the variable himself, but this defies the listsources command.
This leads me to believe TSources is an artifact from the past. Is that
correct?
I would propose to change the implementation in TPackage.GetSourceFiles so it
retrieves sources from TTarget instead and then remove TSources altogether.
Oh yes, what is the actual planned purpose of listsources ;) ? Is it
something similar to maven verify? In that case I would like to propose to
additionally list the results of all commands plus some checks. I will give a
more detailed example if needed.
This is exactly the point were development of fppkg/fpmake stalled.
Proving my statement that sources was added at a later point, since I
didn't include it initially :-)
There needs to be a xml file generated either in sources.xml or manifest.xml
that can be used by fppkg to create an archive out of it.
So what is the function of archive then? This command already lists all
source files in the package. Only thing to do is to implement zipfile
creation.
Using TTarget for sources is a bit complex because you can have include files
and also implicitly build units that also depend on include files and
depending on the target different source directories. Also how to handle
additional input data files that are convert to typedconstant-includefiles.
Therefor i had the idea to add a TSources that can list complete directories.
That seems a bit overkill. I would add some commands that can be used to fill
up sources.
AddSources('*.pp')
AddSource('somesource.pas');
AddSource('somefile.ini');
Cannot agree more.
There is no final decision made yet. Ideas how to implement it nicely are
welcome.
I'll be on holiday the next week so i won't be able to comment on ideas.
I am not on holiday, so I am available for comments :-)
Great! I have a lot of questions :)
Darius
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics
On Thu, 16 Aug 2007, Mattias Gaertner wrote: On Thu, 16 Aug 2007 14:59:47 -0500 (CDT) Jesus Reyes [EMAIL PROTECTED] wrote: --- Jesus Reyes [EMAIL PROTECTED] escribió: --- Michael Van Canneyt [EMAIL PROTECTED] escribió: On Thu, 16 Aug 2007, Mattias Gaertner wrote: What is the state and future plans of generics? I only found the wiki page http://wiki.lazarus.freepascal.org/Generics which does not even mention the current syntax. The current syntax is descibed in the docs, reference manual. There is a chapter about generics. Feel free to comment on it; any omissions, I'll be glad to fill them in (as far as I can, I don't use generics myself). Michael. Images are so big that is difficult to follow the diagrams.. sorry I forgot to put at least a link: http://www.freepascal.org/docs-html/ref/refse38.html Thanks. Maybe the wiki page should be marked as obsolete and a link to the reference should be added? Maybe, yes. Why is the local variable block needed? It is not. I asked the same question. It was added for symmetry reasons: if a local type block is allowed, then a var block should also be allowed. But they are not different from local fields. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics
On Thu, 16 Aug 2007 23:31:25 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: [...] Why is the local variable block needed? It is not. I asked the same question. It was added for symmetry reasons: if a local type block is allowed, then a var block should also be allowed. But they are not different from local fields. Strange. ok. What local types are/will be allowed? For example, this is currently not allowed: generic TTreeT = class(TObject) type public TTreeNode = specialize TNodeT; end; And this neither: generic TTreeT = class(TObject) type public TTreeNode = class Data: T; end; end; OTOH records and pointers are allowed. Will this stay, or is this just not yet implemented? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
