Tomas Hajny schrieb:
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
Marco van de Voort schrieb:
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
michael.vancann...@wisa.be schrieb:
I repeat: you didn't search very well.
Yes, I was not lucky enough :-(
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
Andrew Brunner schrieb:
I got it to work by declaring the Callback Event Type in the
Storage.Folders area and declared that type in the other unit which
linked just fine.
It appears that the references cannot be located from outside that namespace.
That's why I wonder what namespaces are
I just tried to extend the programs in the fpdoc folder, morphing the
program files into unit files by conditional compilation:
{$IFDEF DoDi}
unit ...;
interface
{$ELSE}
program ...;
{$ENDIF}
etc., no problem so far.
Then I wrote my own MkSkel program, using MakeSkel as a unit. Also fine :-)
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 :-(
Michael Van Canneyt schrieb:
Now I'll try to further extend MkSkel by using FPDoc projects, so that
the correct input specifications are used, including all compiler
options. Then it will be easy to check the RTL and other packages for
updates, and to create the skeletons for all contained
Michael Van Canneyt schrieb:
FindFirst may be usable, but is very clumsy for this simple request.
Nevertheless, it is the only option.
For example FileAge also calls FindFirst.
Then it shouldn't be a problem to add an according FileSize function to
the RTL?
DoDi
Michael Van Canneyt schrieb:
BTW is it really required to add -Fi., so that the parser finds
include files in the current directory (of the unit file)?
To my knowledge, it should not be necessary ?
MakeSkel currently complains about missing dw_htmlchm.inc, when
creating the skeletons for
Tomas Hajny schrieb:
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 :-(
What exactly do you
FPDoc doesn't find targets for these links:
math.TRoundToRange - range types never become part of the documentation!
type TRoundToRange = -37..37;
I suspect that fpdoc wants an type name after the =, which here
doesn't exist. Applies to all range types, not only this one.
system.Power -
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
FPDoc doesn't find targets for these links:
math.TRoundToRange - range types never become part of the documentation!
type TRoundToRange = -37..37;
I suspect that fpdoc wants an type name after the =, which here
Michael Van Canneyt schrieb:
The addition of the win and win32 includes IMO was not a good decision,
instead the parser should use the Linux target (as you assume) instead
of the actual platform.
I don't think the parser is the problem.
The problem are the (platform dependent) arguments,
Michael Van Canneyt schrieb:
The LCL problem is not related to new syntax, all units parse without
errors. But document creation crashes on screen.inc
FontEnumProc = function (var ELogFont:TEnumLogFont; var
Metric:TNewTextMetric;
FontType:longint; Data:LParam):longint; extdecl;
What
Michael Van Canneyt schrieb:
And as long as it is not 100% documented, it will not be added.
In other words, the windows unit will probably never make it in the
official docs.
At least TSystemTime is declared there, used in GetLocalTime (Win32
platform). Dunno about other types or
Michael Van Canneyt schrieb:
2. Placy a dummy routine which returns 'now' in sysutils.inc
{$IFNDEF FPC_HAS_NOWUTC}
function NowUTC : TDateTime;
begin
Result:=Now;
end;
{$ENDIF}
IMO the dummy routine should return some error value, e.g. zero or NaN,
that makes it clear to the user that
Sven Barth schrieb:
Just as a sidenote: unit Dos is platform independant (every (full)
target has one and the common parts reside in dos.inc and dosh.inc in
%fpcdir%\rtl\inc)
Ah, thanks.
Then Go32v2 is the (MS?)Dos platform?
Looks now as if platforms reside in the rtl subdirectories,
Jonas Maebe schrieb:
On 09 Dec 2011, at 13:47, Michael Van Canneyt wrote:
I know nothing about OS/2-eCS, but the same arguments as for Go32V2
apply as far as I am concerned. If all these platforms can guarantee
returning correct UTC time, I do not see why we would not introduce it.
Afaik
Michael Van Canneyt schrieb:
At least TSystemTime is declared there, used in GetLocalTime (Win32
platform). Dunno about other types or constants, used in other Win32
RTL and FCL units (winsocks...).
If you'd check carefully TSystemTime is declared and documented in
sysutils.
Not in the
michael.vancann...@wisa.be schrieb:
Does there exist a chance (trick) to use the input files of a different
installation, without copying the description files?
If you use the make command to generate the docs, simply pass the
FPCSRCDIR command line parameter.
eg: make rtl.chk fcl.chk
Marco van de Voort schrieb:
In our previous episode, Sven Barth said:
The -v option should become more verbose, just for hunting such bugs.
And the messages should go to stdout instead of stderr, at least on
Windows (with poor redirection capabilities).
StdErr redirection works in Windows the
michael.vancann...@wisa.be schrieb:
Yes, but changing this will break existing code ?
Such code can be considered broken, deserves an fix anyhow.
Yes, it cannot do both at the same time, unless we add a property
PaintLikeTCanvas or something like that.
Hm. I would reverse the property.
Marco van de Voort schrieb:
But when I tried to build the LCL, fpdoc crashes badly in
THTMLWriter.AppendProcType (SIGSEGV). I tried to catch this error by
try-except, but then Windows kills fpdoc. Running from the commandline
at least reveals the Element as FontEnumProc.
I'll have to
michael.vancann...@wisa.be schrieb:
Currently the following steps are required to build the project file
and the docs:
1. make whatever -n mydocs.bat
2. edit mydocs.bat to make fpdoc create an project file
3. mydocs.bat
4. edit the mydocs.xml project as required
5. fpdoc mydocs.xml
2+3 could
Marco van de Voort schrieb:
That's a known issue. IIRC a workaround was to compile fpdoc without
optimization.
Sorry, that didn't help :-(
So what was your commandline to build the checkout ?
Argh, I did updates regularly, but forgot to rebuild the compiler etc. :-(
But rebuilding only
Felipe Monteiro de Carvalho schrieb:
Yes, in the case of the rectangle drawing I think it was a typo by who
implemented the current rectangle in fcl-image, I have done various
similar typos in my coding and they don't mean I really wanted to
redefine rectangle.
But the TCanvas line is trully
Makeskel expects another(?) semicolon after win\wininc\func.inc:
function GetRandomRgn(aHDC: HDC; aHRGN: HRGN; iNum: WINT): WINT;
stdcall; external 'gdi32';
function ...
Perhaps it cannot parse the external directive?
FPDoc seems to suffer from the same problem, it creates an all-empty
Felipe Monteiro de Carvalho schrieb:
On Wed, Dec 7, 2011 at 9:28 AM, zeljko zel...@holobit.net wrote:
Note that xxx_boundingRect() functions of qt are marked as slow (I guess
it's case when you deal with eg 1000 rects in region and you must calculate
lower TopLeft and high BottomRight) in their
In my current tests I found empty classes (no members listed), e.g.
Classes.TFPList. The Declaration shows:
Source position: classesh.inc line 170
type TFPList = class end;
This line reads in the source code as
TFPList = class;
with the declaration following in line 188 ff.
TFPList =
Felipe Monteiro de Carvalho schrieb:
On Wed, Dec 7, 2011 at 11:27 AM, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
IMO the fastest implementation paints everything to a bitmap, then masks the
painting with the region. This should be faster than clipping every single
drawing primitve
michael.vancann...@wisa.be schrieb:
Hm. It should work correctly; At least, it did so in the past. I will need
to check this.
The platform also seems to be involved. When I changed the
win32\classes.pp into unix\classes.pp, many classes disappear entirely
from the docs (TFileStream,
Michael Van Canneyt schrieb:
Wait, did you try this on FPC trunk sources ? That won't work.
2.6.0 sources should be OK.
Ah!
Does there exist a chance (trick) to use the input files of a different
installation, without copying the description files?
I'll try --descr-dir, because
Michael Van Canneyt schrieb:
Wait, did you try this on FPC trunk sources ? That won't work.
2.6.0 sources should be OK.
I could build RTL and FCL docs from 2.4.2 without major problems (the
trunk Makefile was not fully compatible with the old directory structure).
But when I tried to build
Michael Van Canneyt schrieb:
You can just remove the option tags from the project file, or
manipulate the options with the tool I made earlier.
Still waiting for a description of your tool.
BTW, I couldn't find Imports used in building the documentation any
more. Did I miss something?
Hans-Peter Diettrich schrieb:
BTW, I couldn't find Imports used in building the documentation any
more. Did I miss something?
Sorry, the reference was not found because mkfpdoc is missing from the
fpdoc project files - please add it.
DoDi
Graeme Geldenhuys schrieb:
On 3 December 2011 17:26, Marco van de Voort mar...@stack.nl wrote:
And the contents in the XML is _NOT_ dependent where exactly those files
are, as long as fpdoc can find them.
Exactly my point. fpdoc cannot generate documentation without knowing
where the the
Currently fpdoc stores many options in the project files, but this can
cause problems. Once a boolean option is stored as True, e.g.
option name=hide-protected value=true/
it cannot be turned off by a different commandline option :-(
This raises the question, which options should be stored in
Graeme Geldenhuys schrieb:
On 4 December 2011 20:09, Hans-Peter Diettrich wrote:
Currently fpdoc stores many options in the project files, but this can cause
problems. Once a boolean option is stored as True, e.g.
option name=hide-protected value=true/
it cannot be turned off by a different
Michael Van Canneyt schrieb:
I did several things:
1. Enable various log levels in parser and scanner. It uses an event
handler.
(writing to terminal is not possible)
2. Route all this logging through the TPasContainer.
I tried to remove all direct writes from all backends and other
Graeme Geldenhuys schrieb:
On 4 December 2011 16:17, Hans-Peter Diettrich wrote:
I thought about such a simplification, too, but you'll get some objections:
I believe I already have. ;-)
How then do you want to document files for different platforms?
(needs to supply different source
Michael Van Canneyt schrieb:
Waiting for a commit of these extensions, and for a description of
your mkfpdocproj tool...
Everything was already committed in rev. 19755.
Now it has arrived here, and it really looks great :-)
One comment on ParseOption:
else if s = '--show-private' then
Michael Van Canneyt schrieb:
All I did now was add some options for its manipulation,
based on the problems Hans was experiencing when he tried to build the
FPC docs.
Right, I'm impressed that almost all of my wishes have been implemented
now. I was quite pessimistic after the first
Michael Van Canneyt schrieb:
I still miss a required package option (variation of --import?),
describing the packages whose content files are required to build a
dependent package documentation. Since the location of these packages
can differ on every machine, the user should be alerted when
Michael Van Canneyt schrieb:
You remember my -n and -v options?
Absolutely, and I'll gladly accept patches implementing those 2 things
in fpdoc.
If you could separate those out from your other work, that would be much
appreciated. If not, send whatever you have, and I'll try to extract it
Tomas Hajny schrieb:
When ever required, the platform or widgetset specific *units* deserve
their own documentation (sources) in the first place. Then it's only a
minor effort to create specialized fpdoc projects, which use the right
units and create the documentation for them. Every user
michael.vancann...@wisa.be schrieb:
Speed is also an option. If we start allowing macros, then as an end result
the macros must be processed in the whole XML file. The documentation
XML is rather big; the project file is small.
In true unix philosophy, I think it is better to have many small
Michael Van Canneyt schrieb:
The patch changes nothing to the content of the docs, it just makes sure
that the parser finds all files on Windows.
If there are any platform-specific identifiers, the docs have always
contained the linux-specific ones.
The patch changes nothing about this.
Graeme Geldenhuys schrieb:
I'm not sure how the Makefiles in the FPC_Docs repository generates
fpdoc parameters, but I found that I only need to specify the search
paths in the first --input parameter.
This doesn't look correct to me, at least not for the trunk fpdoc and
the RTL
Michael Van Canneyt schrieb:
If there are any platform-specific identifiers, the docs have always
contained the linux-specific ones.
I'm just about to create a Windows version of the RTL docs. In contrast
to the assumption, that one XML file could hold descriptions of multiple
modules, I
I'm not yet familiar with the new string model, and compiling fpdoc
results in a lot of Unicode conversion warnings.
When somebody tries to eliminate these warnings, DOMString deserves a
closer look - should it become an UnicodeString instead of WideString?
BTW Where can I learn more about
Michael Van Canneyt schrieb:
This means that we can document platform-specific items in additional
files, which are automatically merged with the other descriptions. The
description file specifications can be extended by a platform
attribute, so that problems arising from multiple (platform
Sven Barth schrieb:
Out of curiosity: How could/would one create one documentation of source
which supports multiple platforms, but where there are identifiers that
are only available for some platforms? (like our RTL)
Right, that's a problem - but how many identifiers are really affected?
Michael Van Canneyt schrieb:
One objection is for instance that your proposal will cause all XML
files to be loaded both when FCL and RTL documentation are created.
Already included: all XML files are discarded, when they don't
contribute to the current package :-)
Because of the loose
See Mantis #20786 for details.
The first problem was the use of single quotes in the generated fpdoc
commandline, which are not handled properly by the Windows shell. I
fixed this manually, by editing the Makefile.
Next I get the following error messages:
../rtl/unix/sockets.pp(20,15):
Felipe Monteiro de Carvalho schrieb:
On Wed, Nov 30, 2011 at 9:14 PM, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
Now you hear some, most probably from the first user of fpdoc on Windows ;-)
If you were, then this file would not exist:
Examples which *happen* to work are not a proof
michael.vancann...@wisa.be schrieb:
Perhaps linux/sockets.pp should be replaced by win/sockets.pp?
Or should the Makefile supply the Linux/Unix include directories,
instead those of the current platform (Windows)?
The latter. The paths must be appended, but I already committed a fix for
FPDoc issues many warnings about unknown link targets. Some of these
seem to result from intrinsic types, e.g. for PSmallInt the target
SmallInt does not exist. It doesn't look good when the docs do not
include the most basic types, like Boolean, Byte, Char, Pointer etc. :-(
The same problem
michael.vancann...@wisa.be schrieb:
(so rtl/xxx/yy.html referencing fcl/zzz/ooo.html is done by generating a
link to ../../fcl/zzz/ooo.html )
But this is an html format problem, not a fpdoc problem.
I thought the cross-references are done based on the location of the cxt
file, and all links
Sven Barth schrieb:
I'm not sure how far non-rectangular clipping regions are supported by
all widgetsets, and wouldn't rely on such a capability.
You are aware that TFPCustomCanvas can be used for widgetset independant
canvases as well? Also Felipe said that he'll need it for his
michael.vancann...@wisa.be schrieb:
You should understand the problems of Windows users. Until now they
cannot produce local documentation, due to several bugs in the
Makefiles, fpdoc and related tools. This is a bad situation for
documentation writers, which cannot test their work
Hans-Peter Diettrich schrieb:
Unfortunately there remain some problems, e.g. the FPC documentation
cannot be created on Windows, what is one reason for the extended
project option, but doesn't allow me to debug this feature with real
life projects (RTL...).
A make -n rtl.chk test.txt
michael.vancann...@wisa.be schrieb:
On Mon, 28 Nov 2011, Hans-Peter Diettrich wrote:
I just implemented and option to create an XML project from the
commandline arguments. This should allow to create projects from the
scripts and Makefiles, used to build the documentation for the
standard
michael.vancann...@wisa.be schrieb:
A make -n rtl.chk test.txt succeeded, at least. Now I suspect some
Windows or RTL commandline limitations, which seem to truncate the
long command lines created by the scripts (4890 chars for rtl.chk).
This is a problem of windows, yes.
Argh :-(
Try
michael.vancann...@wisa.be schrieb:
2. Try to separate things. You coded a change in package selection
handling, please don't mix this with the change for writing a package
file. It makes it more difficult to debug when bugs arise.
How can I create patches for different topics, when the
Tomas Hajny schrieb:
The current limit of the default MS Windows shell is 8 kB according to
information found on Microsoft pages (among others). Are those 4890
characters mentioned above Unicode (UTF-16) characters (thus breaking the
limit)? Anyway, it might be possible to use a different
michael.vancann...@wisa.be schrieb:
When this were the *only* code in the fpdoc program file, another
project could create a derived class, with a possibly specialized Run
method, without touching the declaration or implementation of
TFPDocApplication.
That would conflict with the GUI
In my review of the fpdoc project option some questions popped up. The
most important question: should fpdoc be usable for creating online help
only, or should it also allow users to create offline documentation on
their local machine? When a user can create documentation files for
local use,
Michael Van Canneyt schrieb:
That would conflict with the GUI TApplication instance, so I really
don't see the point of this exercise.
Then another error in the logic exists: CreateDocumentation should be
a method of TFPDocProject, not of TFPDocAplication.
Why ? TFPDocProject is just
I just implemented and option to create an XML project from the
commandline arguments. This should allow to create projects from the
scripts and Makefiles, used to build the documentation for the standard
libraries. See Mantis #20769.
Unfortunately there remain some problems, e.g. the FPC
On Win7 I encounter the following fatal error on make clean all of
trunk (19693):
D:/lazarus931/fpc/2.4.2/bin/i386-win32/mv.exe -f ./pp.exe ppc386.exe
D:/lazarus931/fpc/2.4.2/bin/i386-win32/mv.exe: cannot remove
`ppc386.exe': Permission denied
There exists a pp.exe in the current (compiler)
Florian Klämpfl schrieb:
Anti virus?
This was my first guess as well, but deactivating online-scanning didn't
help. So I uninstalled BitDefender completely, and now it worked :-)
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Michael Schnell schrieb:
As already said, my request at this time is not considering
implementation before agreeing on a decently clear definition of what
should be provided and what is supposed top happen when.
IMO such a separation is of no use. If you want an new string type, then
make it
DaWorm schrieb:
Perhaps a little extra compiler magic could be used? If the base
definition of a string (the hidden stuff before the data) contains not
only a field with the encoding, but a flag indicating the disposition of
the encoding, then when a string type is aliases, that disposition
Michael Schnell schrieb:
Obviously a system of hard coded string types (such as A) is not what
everybody (but some) wants (e.g. as there would need a lot of such types
and because EMB decided implementing dynamic typing).
It's the best system, performance-wise. An application should not use
Michael Schnell schrieb:
On 11/16/2011 02:56 PM, Hans-Peter Diettrich wrote:
Delphi uses the native/generic AnsiString(0),
A native /generic type is exactly what is _not_ available in the A)
suggestion of definitions. Here a type name stands for exactly one
encoding variant. No dynamic
Marco van de Voort schrieb:
Note that the Delphi2009 definition is theoretically capable of combining one
and
two bytes in one type (like Yury's). Afaik there is no consensus why
Embarcadero kept the two types separate, though I can think of several
reasons:
- performance
- backwards
Sven Barth schrieb:
It's basically a 64-bit type now. Here's ReactOS' implementation of
GetTickCount64 (which is called by GetTickCount):
[...]
You notice the loop regarding SharedUserData again? ;) (though this time
it also contains a call to YieldProcessor and a comment regarding the
loop)
Sven Barth schrieb:
According to Delphi help a TDateTime of 0.0 represents 12/30/1899 12:00
am, while Wikipedia states start counting the seconds from the Unix
epoch of 1970-01-01T00:00:00 UTC.
You are aware that the definition of TDateTime and that of the Unix
timestamp are not supposed to
Sven Barth schrieb:
var
st: TSystemTime;
dt: TDateTime;
begin
GetLocalTime(st);
dt := SystemTimeToDateTime(st);
Writeln(FormatDateTime('c', dt));
GetSystemTime(st);
dt := SystemTimeToDateTime(st);
Writeln(FormatDateTime('c', dt));
Readln;
end.
=== source end ===
As long as
Sven Barth schrieb:
Am 03.11.2011 02:39, schrieb Hans-Peter Diettrich:
IMO we have to face a problem very similar to Ansi/UTF-8/16: A TDateTime
variable can contain local time in a number of timezones (Ansi), or UTC
values (UTF), which must be interpreted accordingly, e.g. in
DateTimeToStr
Sven Barth schrieb:
FPC's Now on Windows uses GetLocalTime as well. For its implementation
please take a look here:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/time.c?revision=52912view=markup
(line 277ff)
That code doesn't make sense, without additional
zeljko schrieb:
This is what MSDN says about GetTickCount:
Retrieves the number of milliseconds that have elapsed since the system
was started, up to 49.7 days (what they do after 49.7 days ? ).
When the DWORD overflows, Win9x stops to work properly. NT uses an
bigger data type, at least
Pete Cervasio schrieb:
Splitting the TDateTime into year, month etc. is done by a DecodeDate...
function, that *assumes* that TDateTime contains a local time. When you
feed it an UTC time, the result is unusable.
What? How does it assume it's in local time? It assumes it has received
michael.vancann...@wisa.be schrieb:
The call will not be merged. Instead, you can just add
ReadTimezoneFile(GetTimezoneFile);
GetLocalTimezone(fptime);
to your code (and add units 'unix' and 'baseunix').
What will happen if these are called on other platforms, which don't
have timezone
Luca Olivetti schrieb:
Al 02/11/11 09:31, En/na Mark Morgan Lloyd ha escrit:
But even in this case, what should happen if the user (or NTP) explicitly
changes the system clock? Ultimately, what matters for relative timing is
ticks-since-boot.
From the link posted before:
Sven Barth schrieb:
The solution mentioned above is a workaround for 2.4 where no fix is in
place. Newer versions of FPC (maybe even 2.6, I don't know about that)
will get an improved/fixed version of Now (how exactly seems to still be
debated).
ACK
Also note that on platforms like Windows
Vinzent Höfler schrieb:
On Wed, 02 Nov 2011 07:35:30 +0100, Felipe Monteiro de Carvalho
felipemonteiro.carva...@gmail.com wrote:
Maybe that would be something interresting to add. Programs that want
to measure time differences could use it instead of hacking Now.
Well, all what's needed is
Ludo Brands schrieb:
debated). Also note that on platforms like Windows this would be a
unnecessary call as there the current(!) timezone bias is
located in a
shared memory area which is mapped into each process by the kernel.
Apparently not everything is that transparent under windows:
Michael Van Canneyt schrieb:
We'll simply need to store the next moment when the DST correction
changes, compare the result of gettimeofday with that and re-base the
time calculation. If we decide to add some check for the timestamp of
the timezone file - that would make Date(), Time() and
Michael Van Canneyt schrieb:
The timezone itself does not change, unless you physically move the
machine from, say, Belgium to Russia.
Then we should include a GPS query, for the actual geographic position,
and adjust the local time accordingly ;-)
DoDi
Felipe Monteiro de Carvalho schrieb:
On Tue, Nov 1, 2011 at 12:08 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
This is something that normally doesn't happen unless you move your system
from one timezone to another or during system setup
In many countries the time zone changes 2
zeljko schrieb:
Am I the only one who produces 24/7 services with fpc in the world (and
around) ? ;)
You seem to be the only one who provides such services based on *local*
time, with 23..25 hours per day ;-)
DoDi
___
fpc-devel maillist -
zeljko schrieb:
Also this confirms something what happens sometimes when ntpd changes
time ...
Any hints ? What to do ? Any workaround ?
Why don't you use UTC, it should be insensitive to DST and other changes.
DoDi
___
fpc-devel maillist -
Craig Peterson schrieb:
In Delphi XE2 on OS X AnsiString does *not* map to UTF-8. On an English
system it maps to Windows-1252. If you want to convert an array of
AnsiChar to a WideString you need to cast it as a UTF8String first. By
default DefaultSystemCodePage is 1252, not 65001.
Apart from the mentioned implementation flaws, I came across severe
problems with the new AnsiString *model* in general. Let's play around
with the Pos() function, which certainly is an inevitable part of any
stringhandling.
A general function
function Pos(SubStr: T1; Str: T2): integer;
Paul Ishenin schrieb:
A general function
function Pos(SubStr: T1; Str: T2): integer;
should return the character index of SubStr in Str, i.e. Str[i] should
definitely be the begin of SubStr within Str.
Just think of Pos() as it only compares bytes.
Ah, that may be correct for the old
Paul Ishenin schrieb:
What's CP_NONE? Value and purpose?
RawByteString codepage. Value $ and purpose - inform that string has
no codepage assigned. I think at the moment compiler does not produce
strings of codepage $ anymore but before it did. So now we can
probably clear the RTL
Marco van de Voort schrieb:
In our previous episode, Michael Schnell said:
deal seems to be an attempt to avoid an own development, what already
failed with both Kylix and Delphi.NET.
instead of Kylix they now with XE2 provide FPC and instead of Delphi.NET
they sell Prism. Both are 3rd party
After the test program, sent by Paul, I was playing more with
AnsiStrings in Delphi XE, with catastrophic results :-(
At least when MBCS enter the scene, and UTF-8 is widely used in FPC and
Lazarus and is the preferred string type on Linux, incredible bugs show
up. With
var
a: AnsiString;
Michael Schnell schrieb:
On 10/13/2011 10:52 AM, Sven Barth wrote:
So you suggest that in Delphi XE, UnicodeString is _not_ a new String
Type ?
I don't know what you describe as new string, but UnicodeString
was introduced as a new type in Delphi 2009 and String was made an
alias to
301 - 400 of 951 matches
Mail list logo
