I wonder how to obtain the size of an file on disk. The only function I could find so far is FileSize, which requires an open File, but nothing for an file name :-(

ATM FileSize(TEXT) would help, too, but FileSize only accepts an FILE, not TEXT :-(

FpFStat() seems unavailable on Windows :-(

FindFirst may be usable, but is very clumsy for this simple request.

DoDi

-- 8< --

function File_Size (const File_Name : String) : Int64;
var
    F : File;
begin
    {$HINTS OFF} // This *is* the initialization of "F".
    Assign (F, File_Name);
    {$HINTS ON}
    try
       Reset (F, 1);
       try
          exit (FileSize (F));
       finally
          Close (F);
       end {try};
    except
       on e : SysUtils.Exception do
          ; // Whatever...
    end {try};
    // default to error (reached only on exception)
    exit (-1);
end {File_Size};
-- 8< --

WFM.

Vinzent.

Nevertheless, it is the only option.

For example FileAge also calls FindFirst.

Michael.

I don't think that it's really the only option in general - at least DOS-like platforms (DOS, OS/2, MS Windows) usually retrieve the size by a Seek API call specifying to seek end of the file and retrieving the current file position out of that. Actually, it's somewhat surprising for me to see that System.FileSize is implemented using fpStat under Unix platforms rather than using fpLSeek (which should be the equivalent to the API calls used under other platforms if I understand it correctly). FileAge is a different story from this point of view.

Tomas

That would fail if you don't have rights to open the file.

Jonas

What exactly do you want to achieve? Is it because the file may be open as a text and denied sharing wouldn't allow parallel opening for reading as an untyped file (as suggested by Vinzent)? If this is the case, there is a nasty but completely platform independent hack which you could use (based on the fact that the underlying operating systems and their APIs make no difference between file and text).

Or is it because you don't want to open the file at all (e.g. to avoid modifying the timestamp of the last file access)? If this is the case, you probably need to stick to FindFirst, etc.

Tomas

That's true (and equally true for other platforms, btw), but System.FileSize is defined as requiring an open file, i.e. this should not make any difference, IMHO.

Tomas

Tomas Hajny wrote

That's true (and equally true for other platforms, btw), but System.FileSize is defined as requiring an open file, i.e. this should not make any difference, IMHO.

Oops, you're right!

Jonas

Then it shouldn't be a problem to add an according FileSize function to the RTL?

DoDi

Effectively I'm missing a function FileSize(filename), similar to FileExists or FileAge, for general use.

Normally I use TFileStream's, which have a Size property. But I find it nasty to open an file, when I only want to know its size. FPC (like Delphi) lacks some basic file/directory handling functions (Size, Remove, Rename...), at least none are listed in the "File handling overview". While a Delphi user can use the WinAPI for such tasks, a cross-platform development system should provide according platform-independent functions.

Or is it because you don't want to open the file at all (e.g. to avoid modifying the timestamp of the last file access)? If this is the case, you probably need to stick to FindFirst, etc.

These subtle problems should be considered by the implementors of such basic general-purpose functions.

DoDi

In lazarus/components/lazutils/fileutil.pas there is:

function FileSize(const Filename: string): int64;

And as a bonus it works only with UTF-8

MSEgui has lib/common/kernel/msefileutils.pas:
"
type
 ext1fileinfoty = record
  filetype: filetypety;
  attributes: fileattributesty;
  size: int64;
  modtime: tdatetime;
  accesstime: tdatetime;
  ctime: tdatetime;
 end;
 ext2fileinfoty = record
  id: int64;
  owner: longword;
  group: longword;
 end;
 fileinfoty = record
  name: filenamety;
  state: fileinfostatesty;
  extinfo1: ext1fileinfoty;
  extinfo2: ext2fileinfoty;
 end;
function getfileinfo(const path: filenamety; var info: fileinfoty): boolean;
                  //false if not found
"
As a bonus it works with UnciodeString. ;-)

Martin

I think you didn't look very well in the docs.

DeleteFile
RenameFile

I agree the filesize is missing.

I will look into adding them to the documentation topics.

Michael.

Alright. Then something based on FindFirst is your solution.

Basic functionality for working with files is available in units System, SysUtils and Dos - see e.g.
http://wiki.freepascal.org/Unit_categorization. Which 'File handling overview' do you refer to (document and chapter)?

The point is that depending on your use case, these 'subtle problems' may not be relevant at all and efficiency of possible alternative solutions differs too (that 'subtle problem' doesn't exist if you already have a file open anyway, even though it's open for text processing or TFileStream or whatever, and the solution used in System.FileSize might be extended to text files too with a fairly limited effort).

Tomas

After I couldn't find it in the FPC docs, I looked into the D7 docs, where many more functions are listed in "File management routines".

I understand that FPC has to implement some functions with the Delphi names, but when most other file related functions start with "File", how should a user know (and search for) names *ending* with "File" :-(

I agree the filesize is missing. I will look into adding them to the documentation topics.

Thanks :-)

IMO a separation into topics "File handling" (FILE based) and "File management" (by filename) would be a good idea. Now I also found an topic "General File handling routines", but it seems to list only Posix functions, not avaialble on other platforms - should read "Posix File ..." instead?

As already mentioned, I still miss platform independent versions of the file management routines. Lazarus implements some routines, but IMO these should become part of the RTL, not of FCL or LCL.

DoDi

Basic functionality for working with files is available in units System, SysUtils and Dos - see e.g. http://wiki.freepascal.org/Unit_categorization.

Searching for "file" in that page doesn't reveal any helpful information. Perhaps it's me, but I rarely can find something useful in the wiki, even if it might be there, somewhere :-(

Which 'File handling overview' do you refer to (document and chapter)?

I've been searching in the RTL.CHM help, don't know about document and chapter :-(

IMO the overview topics should be listed as such, not in the context of a specific unit. Delphi help offers both "routines by category" and "by unit". The FPC "Reference for package 'rtl'" doesn't list any topics. I'll try to add a list of overview topics, as soon as I have some time left...

DoDi

This is why I concentrated on DocView when trying to deal with the help stuff.

-Michael

I repeat: you didn't search very well.

http://www.freepascal.org/docs-html/rtl/sysutils/renamefile.html http://www.freepascal.org/docs-html/rtl/sysutils/deletefile.html

They have the same names as their Delphi counterparts.

Where did you find this topic ?

I will investigate what can be done to make the topics more clear and helpful.

As already mentioned, I still miss platform independent versions of the file management routines. Lazarus implements some routines, but IMO these should become part of the RTL, not of FCL or LCL.

Which ones do you think are missing apart from FileSize ?

Michael.

In our previous episode, said:

Search for rename and file in the chm help:

http://www.stack.nl/~marcov/helpscrdump.png

How hard can it be indeed.

Let me Google that for you also got an answer for that one:

http://lmgtfy.com/?q=freepascal+file+rename

And it is the 1st hit in Google, not the 10th or something like that like in the CHM

In our previous episode, Michael Schnell said:

It's clear that you want to push Docview, but please at least check if what you want to advise performs better in this regard:

http://www.stack.nl/~marcov/helpscrdump.png

In our previous episode, Felipe Monteiro de Carvalho said:

Trick is, Hans didn't use Google, but mentioned the CHM, so whatever Google, Bing, or your Android phone's friendly advisor does is irrelevant.

But if you want to play games, just install the CHMs in the Lazarus IDE, type "filerename" and press F1 on it.

At least functions for deletion and renaming exist in SysUtils:

http://www.freepascal.org/docs-html/rtl/sysutils/deletefile.html http://www.freepascal.org/docs-html/rtl/sysutils/renamefile.html

Regards,
Sven

Marco van de Voort wrote

It's clear that you want to push Docview,

After just a little bit trying it out on the recommendation of Graeme :) .

but please at least check if what you want to advise performs better in this regard:

AFAIK, the CHM viewer works on a single CHM file (I understand that this is what DoDi meant with "Chapter"), while DocView works on multiple INF files (That are 1:1 corresponding to the CHM files after doing the appropriate help creating process) at the same time.

(Thus it's more comparable to the Delphi offline help viewer, that in fact provides the most versatile help I know.)

-Michael

The point about a "chapter" was just an answer to my question raised before DoDi mentioned his source (at that point in time it wasn't clear if he used the PDF documentation or what other source he meant when referring to "file handling functions" not providing helpful information for him). The whole RTL documentation is available as one file for all of PDF, CHM and INF so this shouldn't make any difference, but I wasn't sure originally whether he was referring to the RTL reference (which obviously includes documentation for all the mentioned tasks), or possibly some other document (since there are references to file handling in other documents too, but obviously not providing anything like a complete overview).

Tomas

Tomas Hajny wrote

The whole RTL documentation is available as one file for all of PDF, CHM and INF

Is there a script that creates these "single- combined" files for the multiple "aspects" of Lazarus and FPC from the different svn sources ?

Thanks,
-Michael

In our previous episode, Michael Schnell said:

> AFAIK, the CHM viewer works on a single CHM file (I understand that this is what DoDi meant with "Chapter"),

Don't know what Lazarus does exactly, but it is not a limitation of CHM, while not binary copy like docview, indexes are designed to be very cheaply integratable.

Afaik neither Lazarus nor the textmode IDE currently provide fulltext access to the help. Any help. But that is a limitation of those IDEs, not the helptext system they integrate with.

while DocView works on multiple INF files (That are 1:1 corresponding to the CHM files after doing the appropriate help creating process) at the same time.

Afaik docview does not work within the IDE at all, only via the external tools option?

(Thus it's more comparable to the Delphi offline help viewer, that in fact provides the most versatile help I know.)

That used to be CHM based, but is now using CHM's successor. But that is totally not crossplatform and the helpsystem is external to windows and requires a license to install.

I repeat: you didn't search very well.

Yes, I was not lucky enough :-(

Hmm, you didn't search very well, too? ;-)

#rtl/oldlinux/filehandlingroutines.html

A search on "file handling" in rtl.chm returns a list of near 100 hits, some of which are really procedures. RenameFile is missing from that list, instead it contains many "Reference for unit ..." entries.

I will investigate what can be done to make the topics more clear and helpful.

And make them more easy to find.

I understand that entries without tags are hard to find, but adding tags only would open another can of worms <sigh>. So the only solution, that I can see, is adding overview topics for categories of routines, with a list of the overviews at least in every package. The lists of overviews for a unit are of little use in a general search, when the units of interest are not yet known.

Give me a link to the directory handling topic, then I can tell you more. Ah, found it: "FileName handling routines" (sysutils). At a first glance there is nothing missing, except FileSize. Perhaps ForceDirectories...

DoDi

Search for rename and file in the chm help:

Thanks, slowly I understand how a chm can be searched :-) This should be explained somewhere, too (using Help)

DoDi

Marco van de Voort wrote

Afaik neither Lazarus nor the textmode IDE currently provide fulltext access to the help. Any help.

I installed DocView in Lazarus. This creates a menu entry "Tools" -> "fpGUI DocView (ctrl-shift-F1)". This used to work nicely (providing cross-inf-file search) as well when called by this menu as when used as context sensitive help in a Lazarus editor window and using this key combination for context sensitive help display.

In fact it right now does not work any more as I unsuccessfully played around with the inf files.

I am sure Greame can give more competent comments on this topic.

Afaik docview does not work within the IDE at all, only via the external tools option?

If you mean the text mode IDE, I don't know. But AFAIK, DocView does not have a text mode display option, so it does not seem to make sense to use Doc View with the text mode IDE. As said, DocView does work nicely with the Lazarus IDE, installed as a "tool" but integrating itself by providing a hot-key usable in the editor.

That used to be CHM based, but is now using CHM's successor. But that is totally not crossplatform and the helpsystem is external to windows and requires a license to install.

Yep. (Supposedly this is why DocView has been created.) Of course it is nice that in the Delphi Help you can installed third party CHM files. I don't know whether CHM files we don't have a "source code" of can be converted to inf files.

-Michael

Duh... This unit is really outdated :-)

A search on "file handling" in rtl.chm returns a list of near 100 hits, some of which are really procedures. RenameFile is missing from that list, instead it contains many "Reference for unit ..." entries.

I can't comment on the quality of the search engine in CHM.

Yes.

I don't understand. ForceDirectories exists in sysutils?

Michael.

In our previous episode, Michael Schnell said:
[ Charset ISO-8859-1 unsupported, converting... ]

I meant more that docview doesn't use the lazarus internal help registration.

The textmode IDE has .INF support that doesn't relate to Graeme's efforts afaik. (in TP dialect)

> That used to be CHM based, but is now using CHM's successor. But that > is totally not crossplatform and the helpsystem is external to windows > and requires a license to install.

(CHMs are still available on the Embarcadero ftpserver iirc, though I haven't checked for the last two versions)

Yep. (Supposedly this is why DocView has been created.)

No, it doesn't. Graeme started working on it when CHM was already mostly operational. Most of his original arguments were based on disk sizes and little implementation gotchas, not on functionality. I still don't see the point of inf.

Of course it is nice that in the Delphi Help you can installed third party CHM files. I don't know whether CHM files we don't have a "source code" of can be converted to inf files.

Yes of course. The question is (1) why would you do that? (2) while possible with some work, the quality of the .inf would be doubtful. You are converting one markup to the next.

I actually looked into the other way around to provide tph and inf to chm support so I could kill off those systems in the textmode ide.

In our previous episode, Michael Van Canneyt said:

It's fine, but like most built-in engines it is not google. It doesn't have a rating system, or anything else that builds up experience to rank hits.

Thus you probably won't find general phrases like "file handling" if there are no exact matches.

The said problems are not problems with CHM, but simply very shallow and arbitrary tests.

That doesn't mean that the CHM can't be improved (e.g. by putting more metadata in the fpdoc format so that fpdoc can use it in the various formats generation), but if you want to find problems or make comparisons with Google, you will always find problems.

A possible solution would be to make the entry (home) page an overview page that provides links to "unit list" (the current homepage), and e.g. a page with overviews like for stringhandling and filehandling.

In our previous episode, Hans-Peter Diettrich said:

> Search for rename and file in the chm help: Thanks, slowly I understand how a chm can be searched :-) This should be explained somewhere, too (using Help)

I'm not sure I want to pull every IT education topic into the FPC help :-)

Marco van de Voort wrote

It's fine, but like most built-in engines it is not google.

Can it do "and" and "or" and search for multi word strings ?

(In fact I don't know wheter DocView can do these...)

-Michael

In our previous episode, Michael Schnell said:
[ Charset ISO-8859-1 unsupported, converting... ]

On 12/16/2011 12:42 PM, Marco van de Voort wrote: > It's fine, but like most built-in engines it is not google. Can it do "and" and "or" and search for multi word strings ?

Afaik default is AND. I don't know if it can do OR. (and I'm not sure if that is that relevant for a helpsystem)

(In fact I don't know wheter DocView can do these...)

They are roughly from the same period, and nearly equivalent in any way. So I assume the fulltext possibilities too.

I chose for CHM because we got first class CHM fileformat generation possibilities donated, and many parts of the generator could be shared between html and CHM.

And because the format isn't dead.

Marco van de Voort wrote

Afaik default is AND. I don't know if it can do OR. (and I'm not sure if that is that relevant for a helpsystem)

Maybe or is not very important (but there are cases it can help), but I feel that "and" vs multi-word-string is necessary.

I chose for CHM because we got first class CHM fileformat generation possibilities donated, and many parts of the generator could be shared between html and CHM.

I might be inclined to follow in case that there is a script that creates an combined CHM file for fpc language, rtl, lazarus IDE, LCL, (and ...) from the svn sources.

-Michael

It is not listed in the overview.

DoDi

Michael Schnell wrote

I might be inclined to follow in case that there is a script that creates an combined CHM file for fpc language, rtl, lazarus IDE, LCL, (and ...) from the svn sources.

Regarding the "(and...)".

Michael Schnell wrote

I might be inclined to follow in case that there is a script that creates an combined CHM file for fpc language, rtl, lazarus IDE, LCL, (and ...) from the svn sources.

Regarding the "(and...)",

The user should ba able to include things things like the synapse docu (e.g.: http://synapse.ararat.cz/doc/help/httpsend.html )

This of course suggests not to force creating some huge merged file (be it the complete CHM or just an index), but use a viewer with real-time merging capacities (such as the Delphi help viewer or fpDOC).

-Michael

Yes, DocView supports many search term formats...

"my phrase" - Will seach for that exact phrase my phrase - will search for any of those two words. my +phare - will search for a topic that contains both works (not necessarly next to each other)
my -phrase - will searchfor a topic that contains 'my', but not 'phrase'

DocView also has a rating system - to indicate how exact / close the patch was. DocView also searches for variations of words if an exact phrase was not specified.

Example:
Here is the DocView search result for 'file +handling' using the RTL.INF file.

http://opensoft.homeip.net:8080/~graemeg/docview_search_result.png

Typing the two works 'file handling' (without any quotes) in the Index tab search field, would also have found the "file handling routines" help topic.

Marco van de Voort wrote

They are roughly from the same period, and nearly equivalent in any way.

Not even close, but that is a debate best left for another time.

And because the format isn't dead.

Didn't Microsoft drop CHM format too? ;-) Anyway, INF is far from dead - in fact it is making a comeback with fpGUI. :) Also eComStation still exists, OS/2 installs still exist, and fpGUI based projects all use INF too. Dead is only if _nobody_ uses it any more - INF is far from that. I'm already working on a Object Pascal implemented INF compiler (though a open-source C++ version already exists), and extensions to the INF format.

[No need for a response from you, I just wanted to correct your false statement.]

Michael Schnell wrote

I might be inclined to follow in case that there is a script that creates an combined CHM file for fpc language, rtl, lazarus IDE, LCL, (and ...) from the svn sources.

Which DocView can already do today with the INF files. ;-)

  $ docview rtl+fcl+lcl+ref

[...but enough of the p**sing contest.]

Graeme Geldenhuys wrote

http://opensoft.homeip.net:8080/~graemeg/docview_search_result.png

Sorry I cant see that due the the companies firewall blocking homeip. :-(

You'd rather attach the picture to the message. :-)

-Michael

Graeme Geldenhuys wrote

Which DocView can already do today with the INF files. ;-)

Which in fact is the point of this (off-topic) discussion right now. :-)

-Michael

Great !
Thanks for you "help on help".

(I hope that this explanation is right on the fingertips of anybody who installed DocView in Lazarus.
Trying to check this I tied to compile the DocView project but I git: /usr/bin/ld: warning:
/home/mschnell/Downloads/svn/fpGUI/docview/src/units/i386-linux/link.res contains output sections; did you forget -T?
/usr/bin/ld:
/home/mschnell/Downloads/svn/fpGUI/lib/i386-linux/fpg_x11.o: undefined reference to symbol 'FcFontSetDestroy'
/usr/bin/ld: note: 'FcFontSetDestroy' is defined in DSO /usr/lib/libfontconfig.so.1 so try adding it to the linker command line /usr/lib/libfontconfig.so.1: could not read symbols: Invalid operation

   docview.lpr(42,1) Error: Error while linking
   docview.lpr(42,1) Fatal: There were 1 errors compiling module, stopping

obviously silly me forgot something essential (again) )

I sincerely hope that finally DocView will get fully integrated in the Lazarus IDE on the default distribution.

This does sound great.

-Michael

Marco van de Voort wrote

Afaik docview does not work within the IDE at all, only via the external tools option?

There is no reason it can't work within the Lazarus IDE. I simply find it easier using the External Tools option of Lazarus IDE, MSEide, Delphi IDE, etc. Using the External Tools options means "no need for recompiling the IDE" just to get context sensitive help, plus it will work with any IDE or programmer editor.

Graeme Geldenhuys wrote

On 15 December 2011 17:48, Marco van de Voort wrote: > Afaik docview does not work within the IDE at all, only via the external > tools option? There is no reason it can't work within the Lazarus IDE.

I did not understand what Marco meant by "the lazarus internal help registration". Docview does do context sensitive help in the Editor, but maybe there is even more that is supported for integrated rather than external tools.

"no need for recompiling the IDE"

In fact I don't see a problem with this. You need to recompile the Lazarus IDE when adding/updating GUI components, so this is nicely supported.

-Michael

Marco van de Voort wrote

Graeme started working on it when CHM was already mostly operational.

"mostly operational" doesn't entrust a lot of confidence.

 Most of his original arguments were based on disk sizes and little implementation gotchas, not on functionality. I still don't see the point of inf.

For the record, disk size (even though the size difference is huge) was largely a bonus feature. The speed of INF was a major contributor (considering CHM is just an archive of very verbose HTML files). Also the fact that any non-Microsoft CHM viewer absolutely sucks, and that all but one [lhelp] of those are written in C/C++ [thus I can't contribute] was another point to consider. LHelp's output also looks terrible and is much slower than most CHM viewers.

I work 99% of the time under Linux, and the Linux CHM viewers all suck. Slow, limited features, prone to crash etc. Creating DocView gave me full control: the programming language I know and love, something I can maintain, advanced searching [which is super fast], runtime concatenation of INF files [extremely handy], auto Index generation [configurable in the Option dialog], bookmark support, and very importantly, inline help annotation support [something I use very often].

In our previous episode, Graeme Geldenhuys said:

> And because the format isn't dead. Didn't Microsoft drop CHM format too? ;-)

Only for own use. Afaik it is still recommended for 3rd party usage in Windows 8.

Anyway, INF is far from dead - in fact it is making a comeback with fpGUI. :) Also eComStation still exists, OS/2 installs still exist, and fpGUI based projects all use INF too

Yes, and I still have access to a PDP too, so that is a real lively community too :-)

You wanted to express your own view on "dead", which I don't share.

In our previous episode, Graeme Geldenhuys said:

> Graeme started working on it when CHM was already mostly > operational. "mostly operational" doesn't entrust a lot of confidence.

Compared to somebody saying he is resurrecting some old OS/2 technology, it is a miracle of confidence.

No, at the time, you kept raving about it. Only when you started implementing more features, your tune changed.

The speed of INF was a major contributor (considering CHM is just an archive of very verbose HTML files).

And INF is just an archive or whatever markup it uses.

Also the fact that any non-Microsoft CHM viewer absolutely sucks, and that all but one [lhelp] of those are written in C/C++ [thus I can't contribute] was another point to consider. LHelp's output also looks terrible and is much slower than most CHM viewers.

Yes, but that was because other people decided to roll their own. And I tried docview on windows and IMHO it was unusable.

gave me full control: the programming language I know and love, something I can maintain, advanced searching [which is super fast],

All that was available for CHM too, PLUS the generation facilities.

Michael Schnell wrote

> There is no reason it can't work within the Lazarus IDE. I did not understand what Marco meant by "the lazarus internal help registration". Docview does do context sensitive help in the Editor, but

He meant for help inside the IDE dialogs. For example: pressing F1 (or clicking the Help button) inside the Environment Options dialog. Again, there is no technical reason why DocViewer can't be registered inside Lazarus IDE - I just don't see the point, so didn't bother creating such a add-on package. Why do I say this? Because currently that is just a stupid point to raise, because Lazarus IDE help is ONLY available online in the wiki site. So neither LHelp (or any other CHM viewer) or DocView (INF viewer) is much use there - until Lazarus IDE actually uses a help format better suited than the wiki site.

In our previous episode, Graeme Geldenhuys said:

No I didn't. There is a helpsystem (for all help) abstraction inside Lazarus. docview bypasses that. This means that having docview and some other helpfile type can't be searched together, while in the case of CHM it can.

I'm not sure that is a good thing though.

that is just a stupid point to raise, because Lazarus IDE help is ONLY available online in the wiki site. So neither LHelp (or any other CHM viewer) or DocView (INF viewer) is much use there - until Lazarus IDE actually uses a help format better suited than the wiki site.

The wiki help used to be downloadable using a tool, but that failed after a wiki engine update (or some other anti-bot/spam measure in the engine/webserver)

Otherwise I would have already transformed the help into CHM.

Marco van de Voort wrote

> For the record, disk size (even though the size difference is huge) > was largely a bonus feature. No, at the time, you kept raving about it.

At the time I (like many others) had a very limited monthly Internet data bundle size (150MB to be exact) - so the size of downloads was a very important point too. Now I have access to an uncapped Internet account - so the size is not so much a issue for me any more, though it could still be for others.

And I tried docview on windows and IMHO it was unusable.

Maybe you just used a very old version of DocView. Either way, I would love to hear more about those unusable problems you experienced. If you don't mind, would you please email them to me in private - I would like to improve the DocView experience in any way I can.

All that was available for CHM too, PLUS the generation facilities.

At the time I implemented DocView and INF support, the CHM code in FPC had no Index support, dog slow TOC support and many other issues. But I believe most of those issues have been addressed over the last 2 or so years. Either way the "crap Linux CHM viewers" problem still persists.

Marco van de Voort wrote

> gave me full control: the programming language I know and love, > something I can maintain, advanced searching [which is super fast], All that was available for CHM too, PLUS the generation facilities.

There seems to be some great tools for chm in the debian repo. One of the apps (archmage) can even serve chm contents on an http server (standalone or apache).

Henry

I have used a HTML-to-INF converter in the past too. Creating a offline "archive" file is not so much the problem. One major problem still remains though... a wiki site is a spaghetti mess of topics and information. No structure at all, thus causing huge amounts of outdated or duplicated information. Not to mention the fact that the wiki site we are talking about, contains information from two separate projects: FPC and Lazarus.

Anyway, this is a topic that should rather be discussed [yet again] in the Lazarus mailing list, not here.

In our previous episode, Graeme Geldenhuys said:

Sorry, no time, no interest, got a working helpsystem :-)

> All that was available for CHM too, PLUS the generation facilities. At the time I implemented DocView and INF support, the CHM code in FPC had no Index support, dog slow TOC support and many other issues.

They were not all problems in the CHM package, rather than the systems that read them. Yes, binary index and TOC improved speed, but it was more something from bringing down from 0.9s to 0.3s

But I believe most of those issues have been addressed over the last 2 or so years. Either way the "crap Linux CHM viewers" problem still persists.

That can't be a reason to start INF because when you started with INF, there were not even crap linux viewers for it.

Henry Vermaak wrote

There seems to be some great tools for chm in the debian repo.  One of the apps (archmage) can even serve chm contents on an http server (standalone or apache).

IBM and other third party members did that with the INF format too. IBM still has some of those sites available online.

In our previous episode, Henry Vermaak said:

I don't like using full browsers for help. They are relatively slow and don't provide as convenient access to the parts that make a helpsystems a helpsystem (index, TOC, search).

Still, I'm apparently the only one, since most new helpsystems are client server based on hidden webservers afaik.

Yes, it's definitely not ideal. I do like having tabs of multiple help topics open at the same time, though.

Henry

Marco van de Voort wrote

Sorry, no time, no interest, got a working helpsystem :-)

That's what I thought... Just spreading FUD.

That can't be a reason to start INF because when you started with INF, there were not even crap linux viewers for it.

You are wrong. chmsee, chmview, gnochm, xchm, kchmviewer etc all existing long before I started working on DocView. Do a Google search to find the history of each of those projects - that's if you have the time and interest. ;-)

That does look like a nice candidate for creating an external tool for Lazarus from (though pascal based tools seem more appropriate).

-Michael

In our previous episode, Graeme Geldenhuys said:

Crap viewers for INF I meant.

In our previous episode, Henry Vermaak said:

The Windows CHM system supports something like that, but it is not under full control of the user. It is more that the CHM can open multiple windows for e.g. special indexes.

If I had infinite time I'd investigate that a bit deeper for overviews of string routines, filehandling etc. (one of the things the current help is lacking most IMHO. Fpdoc should probably get some tagging system)

From past discussions with Graeme, I remember that he also responded that

INF has some windowing functionality.

Henry Vermaak wrote

There seems to be some great tools for chm in the debian repo.

Do you know if they provide support for "loading" multiple CHM files simultaneously for providing combined search capabilities and can do appropriate search ("and" / multi word phrases / maybe "or" / ...)

-Michael

Marco van de Voort wrote

The Windows CHM system supports something like that, but it is not under full control of the user. It is more that the CHM can open multiple windows for e.g. special indexes.

Of course, for a work in progress (such as the FPC/Lazarus help) it would be nice to provide the user with the choice to either use local help files or to dynamically pull them from the software provider's website (I don't know if docView supports this).

-Michael

Michael Schnell wrote

Sorry I cant see that due the the companies firewall blocking homeip. :-(

A few have reported this before. Just four more months and I'll have my own new domain, and not a DynDNS one. :)

You'd rather attach the picture to the message. :-)

I'm not sure about the size limit of attachments - hopefully 16KB is not too big for this mailing list.

Michael Schnell wrote

Thanks for you "help on help".

It's all mentioned in the docview.inf help file that is included with the binary download of DocView. :)

I have no idea why you keep struggling to compile projects, but from the above message, it seems you are missing the 'libfontconfig1-dev' package. If not, move your response the the fpc-pascal mailing list, or the fpgui.support newsgroup please. I'll try and help you further there.

I sincerely hope that finally DocView will get fully integrated in the Lazarus IDE on the default distribution.

I doubt it, DocView is not written with the LCL framework. But anybody is welcome to port the UI of docview to the LCL framework.

Marco van de Voort wrote

I don't like using full browsers for help. They are relatively slow and don't provide as convenient access to the parts that make a helpsystems a helpsystem (index, TOC, search).

+1

In that case, you're still wrong. IBM's iview.exe, which is a Windows INF viewer that can run happily under Linux WINE, is very crap too. ;-) I checked the file date of iview.exe, which is 2001-08-13 (though the copyright notice says 1994) - so it was also available way before I started DocView. No Linux INF viewers existed before DocView [that I know of].

Marco van de Voort wrote

The Windows CHM system supports something like that, but it is not under full control of the user. It is more that the CHM can open multiple windows for e.g. special indexes.

I've never seen this in CHM help files, but I have seen it in HLP help files (Delphi 7 and Kylix 3's HLP files did that). In Borland's case, they placed Categories (eg: file management routines) in a separate window that stayed open.

From past discussions with Graeme, I remember that he also responded that INF has some windowing functionality.

Correct. Multiple windows and customizable toolbar buttons are supported in the INF format - but to date DocView doesn't support that functionality. It should be added as soon as fpGUI's MDI support stabilises.

Marco van de Voort wrote

The Windows CHM system supports something like that, but it is not under full control of the user. It is more that the CHM can open multiple windows for e.g. special indexes.

Just curious.

I remember years ago I had an application that used HLP help (Win95 days). The application had a "tutor" mode - teaching the end-user how to use certain features of the application. The HLP help viewer displayed a popup window with instructions. As soon as the user completed one instruction in the application, the "tutor" window automatically updated to the next instruction. It is as if the application and help viewer communicated with each other. I've seen this done in OS/2 as well.

Do you know if CHM supports this?

Marco van de Voort wrote

I think such webservers are mainly for local use, not remote.

OK, Then an "update" button (downloading the changed helpfile(s) (or their diffs) would be helpful.

-Michael

In our previous episode, Graeme Geldenhuys said:

The Windows CHM help is instrumentable. But it is also said to be mostly a first time effort, with MS already directing resources to htmlhelp2 (and later 3), so many parts don't work reliably or are not implemented, and doing it is horribly underdocumented.

The trouble is that the successors (which I didn't like, too many loose files) never was distributed for general use (only for Windows, VS and Office internal help)

I never tried to instrument CHM beyond simple lookup, but from what I know from reading CHM webpages with some effort you can do quite some instrumentation. Usually by using different aspects of CHM access:

there are three ways to access the htmlhelp(=chm) system:

- via the API (see winunits-base example dir for examples)
- via the hh.exe commandline utility
- via an OCX, originally meant for in browser use.

and then using mostly API, but hh for stuff that doesn't function properly.

But most of the info I have on this is from win98 period.

In our previous episode, Michael Schnell said:

> I think such webservers are mainly for local use, not remote. OK, Then an "update" button (downloading the changed helpfile(s) (or their diffs) would be helpful.

Currently CHMs are typically generated only twice an year, and the URL is always the same.

Graeme Geldenhuys wrote

I have no idea why you keep struggling to compile projects,

Because I thought that during a discussion, I should use the latest version of DocView. So I tried to recompile the project (which of course deleted the executable file)

but from the above message, it seems you are missing the 'libfontconfig1-dev' package.

Yep. But I can't seem to easily install it. The RPM requires devel(libdl) which I also don't have.

I seem to remember that I did compile docview some time ago, but I may be wrong. In fact it does not come with an svn update.

-Michael

Michael Schnell wrote

Because I thought that during a discussion, I should use the latest version of DocView. So I tried to recompile the project (which of course deleted the executable file)

...[snip]...

Yep. But I can't seem to easily install it. The RPM requires devel(libdl) which I also don't have.

Yeah, it seems you development platform isn't setup correctly. I use Ubuntu on all my systems, which are DEB based, so I can't comment on RPM packages sorry.

In a pinch, you can however download the latest binary of DocView from the fpGUI SourceForge project files. I supply binaries for Linux and Windows (the 'docview-xxx' files). This was released 2 weeks ago.

http://sourceforge.net/projects/fpgui/files/fpGUI/0.8/

I seem to remember that I did compile docview some time ago, but I may be wrong. In fact it does not come with an svn update.

1) I don't use a SubVersion repository for fpGUI.
2) I don't include binaries in the source code repository. The only exceptions are the
wipfc (INF compiler) binaries which I got from the OpenWatcom project.

Graeme Geldenhuys wrote

http://sourceforge.net/projects/fpgui/files/fpGUI/0.8/

This of course did work.

Thanks !
-Michael