Hi,
you might also want to take a look at https://code.google.com/p/thtmlviewer
It's still actively developed, so the CSS parser should be more advanced than
the one of TurboPower IP.
dliw
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Hi,
FYI, created wiki page http://wiki.lazarus.freepascal.org/SWIG to bundle
information.
It would of course be very welcome if somebody got the current version into
main SWIG so it is more easily usable
The wiki page is a good idea, things have to be clarified though.
I don't know in how far
@dliw: wasn't the Object Pascal module based on the Modula 3 module?
IIRC recent posts on the swig mailing lists did indeed indicate the
Modula 3 module was buggy in current SWIG.
Sorry, you're right - it was based on Modula - I did mix it up.
Thanks for this correction.
Important point for variant 2: less overhead.
Right, that's the biggest plus in my eyes.
Or is this meanwhile standardized ?
Unfortunately not. It starts in different name mangling - as already said here
- and other (small) differences.
So working on a cross-platform project in C++ with
Hi,
If you need xpath, you might also want to look at my Internet Tools (
(http://benibela.de/sources_en.html#internettools), they contain a basically
complete XPath 2 implementation
I already implemented all I need with fcl-xml, but thanks for the hint anyway.
:)
d.l.i.w
Hi,
working with fcl-xml some questions came together. Every hint is appreciated.
1.
No matter what I do and which (short valid) xml file I use - getElementById
is always nil (tested with trunk and latest stable 2.6.2) and the same applies
to TXMLDocument.IDs.
I tried with ReadXMLFile and
Hi,
The XMLTextReader creates the map, and passes it on to the final document.
// Trunk
procedure TLoader.ProcessXML(ADoc: TDOMDocument; AReader: TXMLTextReader);
begin
[...]
doc.IDs := reader.IDMap;
reader.IDMap := nil;
end;
// 2.6.2
=== snip ===
doc.IDs := FIDMap;
FIDMap := nil;
Maybe the bug is that it checks case sensitive:
procedure TXMLTextReader.ParseAttlistDecl;
...
Found := FSource.Matches(AttrDataTypeNames[dt]);
ParseAttlistDecl isn't called a single time...
- to me it sounds like Parse Attribute *declaration* - and I don't have a
DTD (the file
A little side note to my statement:
and I don't have a DTD
In this case the behaviour of the parser is even right...
W3C:
Note: Attributes with the name ID or id are not of type ID unless so
defined
--
Using Xpath I believe would be something like this:
I was missing an If:
function ElementById(id: string; doc: TXMLDocument): TDOMElement;
var
v: TXPathVariable;
begin
[..]
end;
This does indeed work - thank you :)
It's an acceptable solution for me, as I will need XPath anyway.
Is this worth a feature request / bug on mantis?
Yes.
Issue #24032
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
We were only joking around with the name. :)
Fully understood, but just to be sure :D
d.l.i.w
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Hi,
first of all: no matter what - stay with 'Free Pascal' - I don't think there
would be any advantage renaming a project - except for the whole project
loosing its identity.
My experience is that most people don't even know Pascal - I wouldn't say
Pascal as a language has a bad reputation.
Well, I have planned a inline-to-external conversion for fpdoc for exactly
this reason.
That's nice to hear...
[Sorry for late reply]
d.l.l.i.w
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Hi,
concerning the string topic, for me (using fpc since 2.0.4 on a regular basis;
TP experience ~ average user) there really should be an decision what way to
go as early as possible.
I'm not ranting and I know, that I'm not in the position to demand anything...
[I would really like to help,
Hi,
Users can define the internal type with e.g. {$STRING UTF8} for their
*whole* project.
Should that (*whole* project) include also the 3rd party units (with
available sourcecode)?
Yes, that's the idea...
... the only problem is, that many still use old style hacking, this of
course
Hi,
thanks for the quick reply.
So the direction seems to be quite clear...
... unfortunately this seemingly wasn't communicated clearly enough to the
surroundings.
Because of the requirement for backwards compatibility with FPC itself,
we'll make 2 RTLs: one backwards compatible, one with the
Hi,
thx, got it...
There will always be conversion if
1) a unit specifies a string type by itself.
2) the unit comes in compiled form.
One more question:
If a particular unit (maybe 3rd party) does not define its string type, what
string type is used:
(a) the type defined in project,
(b) a
Hi,
that's great news...
Thanks for the effort to clarify,
d.l.i.w
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Hi,
as the question whether inline or external source docs are the way to go
(again?) came up, here are my thoughts (currently searching for the best
solution :) ):
I personally prefer external docs (and thus started to use fpdoc);
reasons are uncluttered source, less scrolling and (if you
Hi,
http://members.upc.nl/s.grewar/swig_2.0.8_to_swig_delphi.diff
Hm, this really doesnt look good.. :(
I did run make maintainer-clean before packing - and hoped this would remove
all this autogenerated stuff - apparently this wasn't the case [although the
size of the whole thing went down
Hi,
here it is:
http://downloadit.pf-control.de/dl.php?ref=swig
Unfortunately I made the mistake and did the work on a non version controlled
folder - therefore it is whole swig and not just a patch :(
Feel free to move the file to any other - possibly more central - place and
hopefully there
22 matches
Mail list logo
