On 02/29/2012 11:24 AM, Marco van de Voort wrote:
No that is ansistring, with various values filled in for codepage. The
default codepage can be set to the system 1-byte encoding (ansi), and
then it is the same as the D7 one. string is unicodestring, and that
is always utf16.
Taking a brief
On 02/29/2012 11:33 AM, Mattias Gaertner wrote:
Is the wiki supposed to be the upcoming help source, thus invalidating
FPDoc and friends ?
Are you kidding?
fpdoc is great.
There only can be a single source for the help so either FPDoc or
directly managing the Wiki kontent is great not both.
On 02/29/2012 12:08 PM, Sven Barth wrote:
The Wiki is used for documenting e.g. the usage of the IDE. You can't
do this using FPDoc.
This would mean that there never will be any offline help for Lazarus
users.
That would really be a bad thing.
-Michael
--
On 02/29/2012 11:34 AM, Felipe Monteiro de Carvalho wrote:
I think it would be perfectly fine to generate 1 new offline IDE CHM
for each release and ship Lazarus with it.
This discussion is about how to enable non-core members to help
improving the docs.
Your claim would prevent this as the
On 02/29/2012 11:34 AM, Felipe Monteiro de Carvalho wrote:
For SVN users the best option would be the wiki still.
Resulting in their work never can be included in the offline help.
Very bad.
-Michael
--
___
Lazarus mailing list
On 02/29/2012 12:30 PM, Sven Barth wrote:
It won't, because the Wiki is the source for this kind of help and
where editing takes place.
I am sure that this will lead to perfect confusion and help content for
ever unusable (for logical causes not for technical ones.)
-Michael
--
On 02/29/2012 12:36 PM, michael.vancann...@wisa.be wrote:
That your changes are not distributed at once after you've submitted
them is another
matter entirely.
Submitting of course is another matter. I vote for a review by some kind
of committee before submitting.
This is what svn is
On 02/29/2012 12:37 PM, Sven Barth wrote:
(of course nightly snapshots...
Maybe automatic nightly snapshots fed into the svn might be more
workable for potential doc writers than being able to decently review
their work with the next release, but anyway, splitting the help
proceedings in two
On 02/29/2012 12:32 PM, Sven Barth wrote:
Did you read Matthias' answers? He wrote that he's working on a tool
to export the Wiki entries for e.g. CHM, so this is not a problem...
So some part of the offline help is produced by FPdoc and thus
privileged (an non-core member of the community
On 02/29/2012 12:54 PM, Sven Barth wrote:
Michael already wrote in one of the recent discussions that he wants
to create a webpage (using fpweb of course ;) ) that will allow to
edit the FPDoc help entries (I'll try to find the mail).
Also there is always the way that works today: edit the
On 02/29/2012 12:54 PM, michael.vancann...@wisa.be wrote:
Where did you see that fpdoc is priviledged ? Anyone can download and
work
on it, and submit patches.
See my answer to Sven.
-Michael
--
___
Lazarus mailing list
On 02/29/2012 12:57 PM, Sven Barth wrote:
Contributors for source documentation need to edit the fpdoc files
(e.g. those from the SVN checkout) and commit the changes (either as
patch or directly if they have SVN write access).
Regarding that this discussion started in the issue how to allow
On 02/29/2012 01:04 PM, michael.vancann...@wisa.be wrote:
Do you simetimes actually listen to what we say here ?
Seemingly I misunderstood and you are right to be angry .
You can perfectly review your changes in at least 2 ways:
1. Hover the mouse over the identifier in the IDE. The IDE
On 02/29/2012 12:59 PM, Sven Barth wrote:
As already written:
* either use the editor hints of the IDE which work on the FPDoc files
in %laz%\doc\xml
* or build the help files yourself
Obvious best option: * do nothing.
-Michael
--
___
Lazarus
On 02/29/2012 02:53 PM, michael.vancann...@wisa.be wrote:
None of this is an excuse for not contributing.
You are perfectly right, but ... (see my answer to Graeme).
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 02/29/2012 04:15 PM, Reinier Olislagers wrote:
I'm sorry, but then I suggest you stop bothering the list with your
posts...
Agreed.
- Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 02/29/2012 03:40 PM, Hans-Peter Diettrich wrote:
The XE code is the same for AnsiString(0). Other encodings are either
ignored, when functions with RawByteString arguments are present, or
are converted automatically what most probably causes wrong results.
RawByteString =
On 02/29/2012 02:14 PM, Hans-Peter Diettrich wrote:
I don't see a need for combining everything into one help file, be PDF
or CHM.
Not one file but e.g. one multiple-file viewer. It should be possible to
search for information (keyword combinations) across the different files.
-Michael
--
On 02/28/2012 10:24 AM, Sven Barth wrote:
Am 28.02.2012 08:22, schrieb Michael Schnell:
In my projects I usually do something like Type ByteString =
AnsiString for a future migration :) .
type
TByteArray = array of Byte;
???
array of Byte AnsiString.
You can't do
On 02/28/2012 02:13 PM, Sven Barth wrote:
Did you even look at my code?
Sorry, I did not want to be rude, but I understand that this is in fact
_your_ code and not supplied by the RTL which is what this part of the
discussion was about.
Thanks anyway,
-Michael
--
On 02/28/2012 02:43 PM, Sven Barth wrote:
And with the way I described we can at least provide a type that
handles similar to good old AnsiString, but will continue to work even
if String should be changed to UnicodeString in the future.
I just did a component using Delphi 2009 (as I don't
On 02/28/2012 03:40 PM, Hans-Peter Diettrich wrote:
ByteString only requires a dedicated encoding (value), which makes
it incompatible with other encodings, and thus disables all
conversions. Such an encoding doesn't break Delphi compatibility, but
allows to use all stringhandling functions
On 02/28/2012 04:13 PM, Sven Barth wrote:
And instead of introducing yet another type or another special
encoding we could just leverage the features FPC has today and use
TBytes.
I agree, if all features are in place:
- its available out of the box (in the RTL)
- it has all string functions
On 02/28/2012 12:00 AM, Hans-Peter Diettrich wrote:
a stable D7 compatible version/branch is required,
IMHO a compiler switch (Lazarus Project menu option) should be provided
(D7 compatibility or non-Unicode or something like this)
There are decent projects for which a user interface is of
On 02/27/2012 09:51 PM, Martin Schreiber wrote:
A side mark: I don't think using the old ansistring as combined binary
and character buffer is such a bad thing.
+ 1/2
It would be better to have a type that 1:1 allows for all the well known
string operations, replacing Character by Byte:
On 02/28/2012 03:13 AM, Paul Breneman wrote:
so I can use strings as binary communication buffers and let the
compiler deal with everything and it all just works... :)
Yep. There is no logical reason to think other, but the fear that
string is a moving target regarding the unavoidable
On 02/27/2012 09:02 PM, Marco van de Voort wrote:
While GPC is not very active atm, and a case could be made that it is
dead,
They (unfortunately) did not follow FPC on the path to Object Pascal
(Delphi and Apple style). If FPC programs could be compiled using gcc,
we could port Lazarus / FPC
On 02/18/2012 12:02 PM, Marco van de Voort wrote:
That is not a feature of the keyword interface, since e.g. in the CHM
case you can easily lookup TButton.Visible. You just have to gather
the info in the editor. --
I think this is quite exactly what I said. No ?
-Michael
--
On 02/16/2012 04:31 PM, Hans-Peter Diettrich wrote:
Remove crappy or questionable content, instead of only adding a note?
Not a good idea. even questionable/crappy content can be used as a
starter for upcoming doc writers.
So, a comment (such as [?], but plain English and more specific is a
On 02/17/2012 08:11 AM, Graeme Geldenhuys wrote:
Thus, you can't have both CHM and INF help packages installed together.
While I don't know if installing both help packages makes any sense at
all (as the content of both is derived from the same sources and thus
should be equivalent), it
On 02/16/2012 04:48 PM, Sven Barth wrote:
Lazarus is doing this, because in theory (currently not possible*) you
could have the following setup:
* for LCL help use the online documentation
* for RTL help use LHelp (CHM based)
* for FCL help use DocView (INF based)
All three help systems are
On 02/17/2012 09:44 AM, Michael Schnell wrote:
. (If the offline help viewer is not ...
Sorry: online ...
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 02/16/2012 07:36 PM, Hans-Peter Diettrich wrote:
...presented an selection dialog with almost *every* F1 press?
That is why I vote for allowing the user to pre-select the help package
to be used in a menu and/or to use multiple shortcut keys to select the
help package: easier to be
On 02/16/2012 06:14 PM, Hans-Peter Diettrich wrote:
It's not the IDE, it's the Editor that has to determine the context.
??? The editor is part of the IDE
If it finds an identfier (Visible), it must invoke help for its
declaration. If it finds a reserved word, it must invoke the language
Nice try ;-) .
Of course extending the external tool interface is a rather decent
alternative to using the help package interface.
Anyway I feel that the (maybe modified/extended) help package
interface could provide even more appropriate functionality/usability.
-Michael
--
On 02/17/2012 08:24 AM, Felipe Monteiro de Carvalho wrote:
I doubt that the Java backend would ever support building all the
necessary libraries ..
Is Dalvic not compatible with the Touring Machine (
http://en.wikipedia.org/wiki/Turing_machine ) ? :-P
-Michael
--
On 02/17/2012 09:11 AM, michael.vancann...@wisa.be wrote:
Android uses XML files to specify the layout. This is the recommended
way by
Google.
I suppose the Android SDK by Google provides a GUI designer that can be
used here ...
-Michael
--
___
On 02/17/2012 10:27 AM, Sven Barth wrote:
Also the XML layouts allows for a more clean seperation of layout and
code ;)
Which is desirable for appropriately schooled programmers but very
uncommon in the RAD-infected Lazarus and Delphi community ;-) .
-Michael
--
On 02/17/2012 01:25 PM, Marco van de Voort wrote:
Personally I don't like this. It almost forces one to use lhelp, and I
would like to keep the option to use CHM via the native windows support.
??? (AFAIU) The CHM help is installed as a package, while Graeme's
suggestion targets the External
On 02/16/2012 02:17 AM, Bernd wrote:
Its quite interesting and funny to watch
+1
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 02/15/2012 02:02 PM, Marco van de Voort wrote:
There is no CHM help.
http://wiki.freepascal.org/Installing_Help_in_the_IDE#Installing_CHM_Help_for_The_RTL.2C_FCL_and_LCL_in_the_Lazarus_IDE
says:
1) Make sure that the package *chmhelppkg* is intalled.
-Michael
--
On 02/15/2012 05:50 PM, waldo kitty wrote:
once i get past this lhelp stuff, then docview is next on my list to
look at :P
Great ! There might be some limitations and DocView (still) is installed
using the external tool interface not not the help package
interfaces (like chmhelppkg). Maybe
On 02/15/2012 06:38 PM, Andrew Haines wrote:
When you press F1 in lazarus it performs it's own search of what it is
looking for. If it finds something it presents a list of possible
results if there are more than one.
Where does Lazarus (I suppose you mean the IDE ) search ?
If it finds
On 02/16/2012 03:10 AM, Mattias Gaertner wrote:
The token is only one word. It misses the context. It can not
distinguish between a TStrings.LoadFromFile and a
TMemoryStream.LoadFromFile. Or think about the Create. Only if the
search for the specific item fails only then should the help use a
On 02/16/2012 12:49 PM, Mattias Gaertner wrote:
It asks the registered help databases. See View / IDE internals /
About IDE / help.
The help databases do the real search and how they do that is
completely up to them.
IMHO it would be better to have the help viewer do this step (after
being
On 02/16/2012 11:11 AM, Graeme Geldenhuys wrote:
As I mentioned numerous times, I believe the external tools
interface works better with DocView than the help package
integration interface.
The current discussion suggests that the help package interface might be
improved.
The current
On 02/16/2012 01:43 PM, Sven Barth wrote:
.
The IDE has all infos that are necessary to find a certain identifier
OTOH it does not have a clue about the help texts itself, as it does not
know what format the help files the help viewer is about to show.
-Michael
--
On 02/16/2012 02:47 PM, Reinier Olislagers wrote:
In other words, more or less what happens now with lhelp, right?
This is what I supposed would happen. But I donb'rt know if it is true
AFAIU, again, this can be improved by improving the IPC protocol in use;
To me this seems like the
On 02/16/2012 04:23 PM, waldo kitty wrote:
1. the information simply is not in the chm (not good)
or wherever file(s) the attached help viewer uses. (not good either).
Thus the IDE would need to either request the helpdatabase data from
the help viewer, or use the help viewer as a database
On 02/16/2012 04:48 PM, Sven Barth wrote:
* This is because of at least two reasons:
- the CHM package overrides all databases to itself
- DocView does not yet have an integration package
But as The CHM package overrides the database search function, a DocView
(or whatever) package would be
On 02/14/2012 07:33 PM, waldo kitty wrote:
placed the cursor on a pascal keyword (ie: implementation in the
currently opened file from when i opened the lhelp.lpi), pressed F1
and... no help :(
To get context help for pascal language keywords, you need to install a
combined chm file that (in
On 02/15/2012 11:30 AM, Hans-Peter Diettrich wrote:
where is the help for items like 'PadRight', 'AddChar', 'PadLeft',
'AddCharR' and similar??
I just can't find in which units these are declared.
IMHO, the help viewer should do this for you and show any appropriate
occurrence in the any
On 02/15/2012 11:50 AM, Hans-Peter Diettrich wrote:
Nope. Simply download the additional CHM files, and it works as expected.
I once asked how the CHM help can be configured to search across
multiple files. I never got a positive answer. But things might be
improved by now.
Learn to use the
On 02/15/2012 02:02 PM, Marco van de Voort wrote:
There is no CHM help. ...
Sorry for being vague. I learned that the help viewer for the Lazarus
IDE is installed as a package. What I meant is the installable help
viewer that works on CHM files.
That's because the question is vague and
On 02/13/2012 04:20 PM, Michael Van Canneyt wrote:
Despite DocViews obvious intrinsic qualities:
I seriously doubt that, for the simple reason it is not implemented
using the LCL.
Is the CHM viewer based on the LCL ?
I don't know if/how it is possible to create an installable Lazarus
On 02/14/2012 10:32 AM, Lukasz Sokol wrote:
There is also futex (Fast Userspace muTEX) but I don't know much about
that one;
Futex needs a common user space for the code snippets that are to be
synchronized, thus it is perfect for threads but not usable for
system-wide stuff.
-Michael
--
On 02/14/2012 10:44 AM, Graeme Geldenhuys wrote:
That is already on my docview todo list, and should be one of the next
things I implement (in a week or two).
Sounds Great ! Looking forward to testing this.
-Michael
--
___
Lazarus mailing list
On 02/14/2012 10:42 AM, Graeme Geldenhuys wrote:
I don't really see this as a problem. After all, you need to download
the INF or CHM or HTML or PDF offline help anyway.
The distribution (version 1.0) might include those.
Not many people want to go the build your own docs route.
But
On 02/14/2012 11:40 AM, Henry Vermaak wrote:
Look into the pthread man pages for info. I
Usual pthread_mutex() functions are designed for working within a single
process and thus will use Futex, if available and thus will not work
system-wide. I don't know if pthreadlib offers an option for
On 02/14/2012 12:36 PM, Henry Vermaak wrote:
No, you're wrong.
I did a lot of research on pthread_mutex.. and I do know that it uses
Futex when the underlying system provides same (not all Linux
implementations on all architectures do have Futex). Thus unless you
take additional care it can't
On 02/10/2012 09:40 PM, Martin wrote:
Then we need to extend fpdoc. So we can build help (chm or other),
with or without todo/notes
Even better: use a help viewer that allows for dynamically switching
notes on and off or even supports a verbosity level.
-Michael
--
*A general note: *
I am very happy to see these discussions here.
Lazarus is getting a level of maturity and public visibility that ask
for decent documentation at least as much as for code improvement.
Regarding the complexity of the topic (help is necessary for for the
help viewer itself
On 02/11/2012 05:32 PM, Martin wrote:
Notes that appear in the end user output are inappropriate.
Unless the actively decide to see them (e.g. if they intend to become
help writers).
With community based projects there is no sharp difference between users
and contributor. That is the stuff
On 02/12/2012 03:23 AM, Martin wrote:
Documentation rework, removes aprox. 600 occurences of [?] and other
non-sense from the documentation
This does make me shiver.
Who invested those many hours to check if all this in fact was nonsense ?
-Michael
--
On 02/13/2012 10:41 AM, Michael Schnell wrote:
**(IMHO this is one of the greatest advantages of Delphi.)
In fact I was referencing D7, as I don't have a more recent version that
I learned has a reworked (worse ? ) help system.
-Michael
On 02/13/2012 10:13 AM, Lukasz Sokol wrote:
Would it not be a Better Idea (IMHO) to have the frame ready in time
for display and have the rest of the CPU time available for something
else ?
Yep. Burt you would need to take advantage of the screen refresh
interrupt to know the time you can
On 02/13/2012 09:30 AM, Graeme Geldenhuys wrote:
So based on this, fpdoc notes could be displayed or hidden using a
single INF file - simply by toggling the value of the IPF_KEYS
environment variable.
IMHO, multiple verbosity levels are a great idea and even more useful
than just Notes that
On 02/13/2012 12:49 PM, Lukasz Sokol wrote:
Alternatively you can run a timer every 1/f ms with the screen refresh ..
A separate time base unavoidably will lead to jitter.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 02/13/2012 01:55 PM, Hans-Peter Diettrich wrote:
Who invested those many hours to check if all this in fact was
nonsense ?
It was my work of many weeks.
I understood that you inserted the note and somebody else considered
them to be nonsense and removed them.
I guess that the svn
On 02/13/2012 02:56 PM, Michael Van Canneyt wrote:
All that can not be achieved with only a level of verbosity.
But it can easily be achieved by adding attributes to each note, and
reacting on these attributes. This is already implemented in revision
20335.
Great stuff, but Greame stated that
sdl might help: http://www.libsdl.org/
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 02/08/2012 10:00 PM, waldo kitty wrote:
i, personally, see them as the same...
+1
At a final stage (in a perfect world), all PDF-documentation and offline
help, offline help, and great part of the Wiki pages, should be
generated from the same sources. Otherwise maintaining this stuff is
On 02/08/2012 05:27 PM, Mattias Gaertner wrote:
On the other hand the IDE's help interface for pascal sources uses
the codetools to find the declaration and passes a complete path to the
help. For example the external tool only gets LoadFromFile, while a
registered help gets fpc sources,
On 02/09/2012 09:22 AM, Antonio Fortuny wrote:
TEventObject in syncobjs unit does exactly the job.
The documentation on TEventObject suggest that it is for synchronizing
multiple threads of a single process and not for synchronizing multiple
independently running processes.
-Michael
--
On 02/09/2012 10:41 AM, ik wrote:
Disk IO is one of the slowest memory usage that exists (even SSD
drives). RAM is the fastest memory exists today.
That is why the OS uses a RAM cache and does Disk I/O only when viable.
-Michael
--
___
Lazarus
On 02/09/2012 10:53 AM, Antonio Fortuny wrote:
I've made a test on Win32 and the TEventObject is blocking system wide.
Great !
If this feature is really usable on all platforms, the documentation
needs to be updated accordingly.
AFAIK:
System wide inter-process semaphores should be a
On 02/07/2012 06:48 PM, Hans-Peter Diettrich wrote:
This may be a solution, but is not supported by current viewers nor
FPDoc Editor or hints :-(
AFAIK, Graeme is about to do the last steps helping to make DocView a
supported help viewer (i.e. providing an automated script (ow
whatever) that
On 02/08/2012 09:01 AM, Graeme Geldenhuys wrote:
* Help hints over source code, are read directly from the XML files.
This is simply
done because NO HELP SYSTEM IS IN PLACE. Yet another duck-tape solution.
Would DocView as a primary Help viewer be able to support Help hints in
the
On 02/08/2012 09:43 AM, Mattias Gaertner wrote:
* Wiki sites are NOT a solution for Context Sensitive Help.
That's your opinion.
For me, Graeme's argument is very obviously correct.
-Michael
--
___
Lazarus mailing list
On 02/08/2012 12:08 PM, Hans-Peter Diettrich wrote:
How shall these viewers share content?
I don't understand what you are asking.
- Only one viewer is installed at the time.
- Each viewer has it's own file format (online or offline)
- The different file formats are created by appropriate
On 02/08/2012 01:51 PM, Felipe Monteiro de Carvalho wrote:
Anyone has an oppinion of the best way to fix this?
IMHO: (for 1.0, as this seems not like a trivial task):
- define and implement a help viewer interface (this might be based on
the external Tool interface or on packets that need
Why not just use a file ?
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 02/08/2012 03:37 PM, Graeme Geldenhuys wrote:
Also what Linux/Windows/MacOSX CHM help source editors exist so the
BIG port from Wiki-to-CHM can begin?
Would DocView be better on that behalf ?
-Michael
--
___
Lazarus mailing list
On 02/08/2012 03:29 PM, Felipe Monteiro de Carvalho wrote:
This is probably already implemented. I followed the instructions in
the wiki and click in synedit over TButton, press F1 and it opens
TButton in LHelp.
I suppose no current IDE API handles the tooltip help, but maybe I am wrong.
On 02/08/2012 03:36 PM, Felipe Monteiro de Carvalho wrote:
I am indiferent as to help formats per se, but I think we should
distribute CHM+LHelp pre-compiled as default. It has problems, but
those can be fixed and it is in the source tree of Lazarus
Is DocView worse on that behalf ?
-Michael
On 02/08/2012 04:48 PM, Mattias Gaertner wrote:
There are also examples how to register viewers...
This does sound promising :)
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 02/08/2012 04:06 PM, Graeme Geldenhuys wrote:
hense my suggestion to stop using the wiki, and make all those topics
available in a offline format, and only use the offline format from
then onwards.
While converting Wiki content to some help format seems quite
impossible, automatically
On 02/08/2012 04:59 PM, Sven Barth wrote:
DocView is not part of Lazarus source code. Also it would first need
to be converted to LCL (though according to Graeme this should be
rather easy).
I understand that Graeme would be able (and willing) do make a DocView
Packet. Another way would be
On 02/08/2012 05:13 PM, Sven Barth wrote:
, but Felipe is talking about the default for Lazarus.
Yep. The Default supposedly should be a Packet.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 02/07/2012 11:32 AM, Graeme Geldenhuys wrote:
Additional documentation should be the job of the Help Viewer (LHelp,
DocView etc), not the documentation generator.
+1 !
OTOH, AFAI understand DocView is the only supported help viewer that can
search across multiple files.
-Michael
--
On 01/26/2012 08:52 PM, Mark Morgan Lloyd wrote:
where's the idiot's guide to getting the up-to-date files and putting
them where...
Regarding that it's me who is the said idiot (or the advocate for the
idiotic users), I'd like to add, that the end result should be to allow
the idiots to push
On 01/27/2012 12:07 AM, Hans-Peter Diettrich wrote:
Creating own helpfiles is a secret, too :-(
Good point. The script provided by the idiot's guide should be
extendable for additional sources. Of course for this it the guide needs
to provide documentation on the format of the help sources.
On 01/26/2012 08:23 PM, Sven Barth wrote:
You are aware that Lazarus also supports offline help?
Yep. The discussion is on how to generate the offline help from the
current svn sources and on the features of the help viewer (IDE or
external tool).
-Michael
--
On 01/26/2012 06:38 PM, Graeme Geldenhuys wrote:
INF versions
http://sourceforge.net/projects/fpgui/files/fpGUI/Documentation/
OK. I downloaded the zip files, located the newest versions (in
docs_2011.zip) and created symlinks to have DocView find them.
Nearly completed Language Ref -
On 01/26/2012 06:53 PM, Graeme Geldenhuys wrote:
On 26 January 2012 18:05, Michael Schnell wrote:
discussed was _language_ help rather than LCL herl (such as for, in,
array, class, ...)
That's exactly what the Free Pascal Language Reference document describes.
You really should visit
On 01/27/2012 11:04 AM, Graeme Geldenhuys wrote:
A known problem, and you would have know about this too if you opened
the ref.inf file on it's own - the first help topic explains this (the
text in RED on the cover page).
Wow !
UTF sucks whenever you come across it :( .
The fix:
---
In
On 01/27/2012 12:13 PM, Hans-Peter Diettrich wrote:
Did you have a look at examples/FPDocManager?
This does not seem to make sense for me until I know a proven method to
generate the data for some help viewer, integrated in the IDE, that
works on the combined information of current stuff and
On 01/27/2012 11:04 AM, Graeme Geldenhuys wrote:
(the text in RED on the cover page).
FYI: This page is selected when starting DPDOC, but the content is not
displayed. It is only shown when clicking another chapter and then
re-cklicking the chapter.
Maybe easy to be improved...
-Michael
On 01/27/2012 05:19 PM, Torsten Bonde Christiansen wrote:
I'm looking for an easy way to switch between buildmodes, but so far I
can only do it where they are also defined
(Project-Options-Buildmodes).
For me it's ctr-shift F11 (maybe just F11 for you if you are not using
Suse Linux).
On 01/25/2012 10:36 PM, Graeme Geldenhuys wrote:
I don't know how much help CLX or VCL help files would really be to a
LCL developer.
The Delphi help offers with nice hints for the language itself including
context sensitive F1 on language keywords like array or class or
override and such.
1001 - 1100 of 1996 matches
Mail list logo
