Em Qui, 2005-11-17 às 14:18 +0200, Alexander Todorov escreveu:
Hi folks,
can you tell if there is a good crypto class for FPC / Lazarus ?
What do you use for crypting your stuff ?
Any opinions are welcome.
Take a look at http://sourceforge.net/projects/tplockbox
Luiz
Micha Nelissen escreveu:
On Sat, 01 Apr 2006 18:06:31 +0200
Joost van der Sluis [EMAIL PROTECTED] wrote:
Further I have a question: now sqldb uses a linked-list record buffer,
the RecordCount and RecNo properties are something strange.
What should I do with recordcount? I can add a counter
In revision 3138 TDataset.Clearbuffers call InternalInitRecord to empty
the ActiveBuffer. I have two comments:
- In DoInsertAppend InternalInitRecord will be called twice: one through
ClearBuffers and other through InitRecord
- ClearBuffers is called in First, Last, Resync: in this situations
Joost van der Sluis escreveu:
On Mon, 2006-04-03 at 21:29 -0300, Luiz Americo Pereira Camara wrote:
In revision 3138 TDataset.Clearbuffers call InternalInitRecord to empty
the ActiveBuffer. I have two comments:
- In DoInsertAppend InternalInitRecord will be called twice: one
The attached patch fix an field recognition issue in TSqlite3Dataset
Luiz
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Micha Nelissen escreveu:
On Mon, 10 Apr 2006 12:33:18 +0200
Joost van der Sluis [EMAIL PROTECTED] wrote:
If you don't want to limit, then set .Filtered := false; and use
FindFirst etc.
wich won't work with current sqldb, since filtering there simply adds a
'where' part to the query.
J. Peter Mugaas escreveu:
On Tue, 11 Apr 2006 11:24:39 +0200 (CEST), Daniël Mantione wrote:
Op Tue, 11 Apr 2006, schreef Marco van de Voort:
Over the years several indy bugs have been fixed, and nobody
knows the
Several zlib bugs I meant here of course, some quite
Jonas Maebe escreveu:
On 18 apr 2006, at 15:18, Okulov Rostislav wrote:
Warning: You are using the obsolete switch -OG
Warning: You are using the obsolete switch -Opnr, please use -Opname
Nice.
What name should I use now to compile under needed processor?
cputypestr : array[tcputype]
Daniël Mantione wrote:
In 16 bit days it was considered acceptable to typecast pointers into
records and just increase their offset. However, it was not portable.
Making your code portable requires some effort. This kind of code is just
one example of things you should not do in portable code.
Graeme Geldenhuys wrote:
[...note I cross posted this to the lazarus mailing list, because it
doesn't really belong in the FPC-devel mailing list...]
OK, I see what you mean, Vincent. What about... basically the LGPL
header with the modification.
I think is good enough. I would just add a
Aleš Katona wrote:
I agree. I'm starting to feel sick of all the compat crap you guys put
up with playing the bitch of delphi. The problem is that now delphi is
the bitch of .net so I think wisest would be to implement 100% compat up
to delphi 7 and be done with it. Then just document the fact
Daniël Mantione wrote:
Op Tue, 23 Jan 2007, schreef Luiz Americo Pereira Camara:
Ale? Katona wrote:
I agree. I'm starting to feel sick of all the compat crap you guys put
up with playing the bitch of delphi. The problem is that now delphi is
the bitch of .net so I think wisest would
While porting some Delphi code i found some differences in the
declarations of COM interfaces.
1) In IEnumFORMATETC.Next(Celt:ULong;Out Rgelt:FormatEtc;Out
pceltFetched:ULong):HResult; Delphi expects pceltFetched to be a PInteger
win32 documentation:
*HRESULT Next( ULONG*/ celt/*,* *
Luiz Americo Pereira Camara wrote:
While porting some Delphi code i found some differences in the
declarations of COM interfaces.
1) In IEnumFORMATETC.Next(Celt:ULong;Out Rgelt:FormatEtc;Out
pceltFetched:ULong):HResult; Delphi expects pceltFetched to be a
PInteger
win32 documentation
Micha Nelissen wrote:
[EMAIL PROTECTED] wrote:
The Parameter X not used hint is specially annoying in the case you use
many callback functions like the used in LCL (TNotifyEvent and alike).
Perhaps it's an idea to not show this hint by default for methods
declared in the published
Daniël Mantione wrote:
Perhaps, a possible way out is to make the LCL more plug-inable. For
example, the LCL needs to support many graphics formats, and the code
ending up in the program has to be designed to support them all; you don't
know what ends up in the resource files. As a solution
Marco van de Voort wrote:
Dani?l Mantione wrote:
But I'll leave this up to the Lazarus team. They have talented developers,
and I'm sure they are brainstorming about ideas to reduce the exe size.
However, Lazarus developers do the engineering balancing too and weigh exe
size against
Joost van der Sluis wrote:
Hello everybody,
I'm happy to announce that release 2.1.4 aka 2.2.0 beta is out. We ask
our users to test the changes made in the last few years. This beta will
be available for about two months, whereafter 2.2.0 will be released.
Helping us to test version 2.1.4 now,
Darius Blaszijk wrote:
I think the 'MatchesMask' function belongs in strutils or sysutils.
(a copy of it exists there anyway :/)
Sure? I searched the rtl and couldn't find the function. I agree it
should live there, but afaict it doesn't yet. I found the code in
fpunit.pp which was used in
Daniël Mantione wrote:
Op Tue, 13 Nov 2007, schreef Graeme Geldenhuys:
For those that don't follow the Lazarus mailing list.
It was brought to our attention by a ex-Borland employee (Steve
Trefethen), that FPC contains some stolen code from Delphi. Especially
Delphi 4 5.
The full
Graeme Geldenhuys wrote:
procedure TMyApplication.TestRefCountedObjects;
var
LO: TInterfacedObject;
LStart: Cardinal;
LCount: Cardinal;
i: integer;
begin
LCount := 0;
LStart := tiGetTickCount;
while tiGetTickCount - LStart (CTestRunTime * 1000) do
begin
LO :=
Daniël Mantione wrote:
Op Wed, 26 Dec 2007, schreef Fabio Dell'Aria:
Why is so hard deide to add package support?
Iss only a new feature, if one do not need it can simply do not use it!
It would require to ship the rtl as dynamic library, which is unstable
in its interface, causing DLL
Florian Klaempfl wrote:
Luiz Americo Pereira Camara schrieb:
It would not be possible to ship the compiler and rtl as is today and
let the user/programmer decide if his project will use packages?
Or necessarily, if the change is done, the only option will be use
packages instead of unit
Daniël Mantione wrote:
Did i miss something, technically? Is necessary to compile with rtl
packages to distribute custom packages?
Yes. Well, unless you want the RTL statically linked into each
package, which will not work in a compatible way due the one
heap/multiple heaps issues.
There
Michael Schnell wrote:
When you press 'install' in the package editor, the following happens:
- The IDE calls 'make IDE OPT=-Cn' to compile the IDE (not the
LCL, not any component) without final linking. This is needed for
packages using the IDE sources directly. FPC will only recompile what
Daniël Mantione wrote:
Op Tue, 26 Feb 2008, schreef Luiz Americo Pereira Camara:
Yury Sidorov wrote:
The patch removes packed record for some platforms.
IMO packed can be removed for all platforms. It will gain some speed.
I'd like to understand more this issue.
Why are non packed records
Luiz Americo Pereira Camara wrote:
TVirtualNodePacked = packed record
Index,//Offset 0 ChildCount: Cardinal; //Offset 4
NodeHeight: Word; //Offset 8
States: TVirtualNodeStates; //Offset 10 *
Align: Byte; //Offset 14 ** CheckState: TCheckState
Vinzent Hoefler wrote:
Are enumeration types 1 or 4 bytes in Delphi? If they are one byte, it
looks quite different (and I'm not sure about all the types used here,
some seem to be sets, some enumerations). But at the first glance it
seems, they used both packed records to either ensure
Jonas Maebe wrote:
On 29 Feb 2008, at 01:55, Luiz Americo Pereira Camara wrote:
One more question:
The VirtualTreeView tries to make the fields of the (packed) record
aligned at dword boundary by grouping together smaller (one or two
byte fields) or adding dummy fields. Does this trick
Tomas Hajny wrote:
On Wed, April 16, 2008 03:39, Luiz Americo Pereira Camara wrote:
In response to bug report 0010959, i've uploaded a patch to fix the
issue, but the reporter closed the bug before the patch was applied.
So, i'd like to someone to apply the patch so i can send more
Vincent Snijders wrote:
Luiz Americo Pereira Camara schreef:
In response to bug report 0010959, i've uploaded a patch to fix the
issue, but the reporter closed the bug before the patch was applied.
So, i'd like to someone to apply the patch so i can send more
improvements to sqlite3ds
I
Marco van de Voort wrote:
I looked into Luiz' updated headers for Cairo
(http://bugs.freepascal.org/view.php?id=11175), and while they are ok in
principle (improvements, beautification),
the splitting up into multiple
units,
This is necessary to cross platform.
and some changes like the
Daniël Mantione wrote:
Op Sat, 30 Aug 2008, schreef Marco van de Voort:
So then you can (hopefully) pretty much do
{$ifdef unix} // in reality it is more complicated than ifdef unix,
but for
now..
TNativeString = type ansistring (CP_UTF8);
{$else}
TNativeString = type TUnicodeString;
Graeme Geldenhuys wrote:
(AFAI understand, a Widechar is just 16 bit, it would need to
be 32 bit if surrogates were allowed in Widestrings).
Good question and I have been wondering about this myself. In D2009
SizeOf(Char) = 2, so I have no idea how that works with surrogate
pairs. Can
Jonas Maebe escreveu:
If people want to rely on what they are used to in non-unicode
environments, then they cannot directly use unicode strings. They'll
first have to assign it or typecast it to a non-unicode string and
then operate on that string. At least if there's any data loss in that
While discussing if is worth using const parameters for string and
double types in a Lazarus bug report (
http://bugs.freepascal.org/view.php?id=12642 ), it was noticed that does
not make difference using constant parameters or not for double types.
So is this the expected behavior or a bug
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
While discussing if is worth using const parameters for string and
double types in a Lazarus bug report (
http://bugs.freepascal.org/view.php?id=12642 ), it was noticed that
does not make difference using constant parameters
Jonas Maebe escreveu:
On 16 Nov 2008, at 14:52, Florian Klaempfl wrote:
Luiz Americo Pereira Camara schrieb:
Maybe the documentation
(http://www.freepascal.org/docs-html/ref/refsu50.html#x126-13300011.4.4)
can be modified to clarify this since the statement:
A constant argument is passed
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
My point was that this could be a missing optimization opportunity:
pass by reference a 8 bytes parameter when the pointer size is 4.
Don't forget that this makes an extra memory access.
I will do my question in a simpler way
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
My point was that this could be a missing optimization opportunity:
pass by reference a 8 bytes parameter when the pointer size is 4.
Don't forget that this makes
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
My point was that this could be a missing optimization
opportunity: pass by reference a 8 bytes
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
My point was that this could
Graeme Geldenhuys escreveu:
On Fri, Nov 21, 2008 at 11:08 PM, Graeme Geldenhuys
[EMAIL PROTECTED] wrote:
I thought you guys might find this interesting. It's a new 27 page
document describing Unicode support in D2009.
http://dn.codegear.com/article/38980
Seeing that I don't own D2009
Sergei Gorelkin escreveu:
Well, with exclusion of the class helper for TStrings (notable is
that they call it a hack themselves :) the design looks rather clean.
Since each string stores its element size, both ansi and unicode
strings are probably handled with common set of procedures,
Graeme Geldenhuys escreveu:
Hi,
I have added a Roadmap section in the following wiki page. If you find
anything missing or not 100% implemented, please add it to the wiki
page.
http://wiki.freepascal.org/FPC_Unicode_support#Roadmap_of_RTL_Unicode_support
I started a wiki page to list the
Hi Joost,
Thanks for applying the patch of
http://bugs.freepascal.org/view.php?id=12677 .
About your comments:
The patch does a lot more.
No. It does only the described. See below.
But mostly cosmetical.
Almost all changes were necessary. From 29 changes only 3 were
cosmetical. Very
Michael Van Canneyt escreveu:
On Sun, 23 Nov 2008, Graeme Geldenhuys wrote:
On Sun, Nov 23, 2008 at 6:21 PM, Florian Klaempfl
[EMAIL PROTECTED] wrote:
Also I whish to know which basic unicode functions will be supported
by FPC, only upper/lower, or maybe some more like decompose,
Joost van der Sluis escreveu:
Op zondag 23-11-2008 om 14:48 uur [tijdzone -0300], schreef Luiz Americo
Pereira Camara:
Almost all changes were necessary. From 29 changes only 3 were
cosmetical. Very far from mostly.
It's easier if you send in patches without any layout-changes
Joost van der Sluis escreveu:
Op zondag 23-11-2008 om 18:31 uur [tijdzone -0300], schreef Luiz Americo
Pereira Camara:
AFAIK is not possible to have a method argument and a property with the
same name in mode objfpc. Let me know if this changed recently. So the
is necessary to rename
Marco van de Voort escreveu:
In our previous episode, Martin Friebe said:
most cases, it is slowly time to abandon too simplistic thinking about
strings. The best solution is to minimize editing, and localize them in
certain parts of the code, keeping most of the code encoding agnostic.
Martin Friebe escreveu:
Marco van de Voort wrote:
In our previous episode, Martin Friebe said:
I agree, using RTlString will probably help fpc to optimize your exe
for each OS.
But, using RTLString means you do not know, if you have UTF8 or not.
Correct.
Because UTF8 behaves
Martin Friebe escreveu:
All the code
Widestring := RtlFunction;
Utf8string := RtlFunction;
will run, it may just perform badly.
Yes and no.
Let's assume the platforms windows and unix having UnicodeString
(UTF-16) and UTF8String as native types respectively.
You choose to use
Marco van de Voort escreveu:
In our previous episode, Luiz Americo Pereira Camara said:
string[index], copy, pos, length have always been part of Pascal.
So keep using ansistring? It doesn't change.
Not true if fpc will follow Delphi. The new AnsiString type
Graeme Geldenhuys escreveu:
On Mon, Dec 1, 2008 at 10:03 PM, Mattias Gaertner
[EMAIL PROTECTED] wrote:
and it avoids unneeded conversions.
I understand it 'avoids unneeded conversions' *inside* the RTL, by
adding implicit conversions to the code accessing the RTL.
This is
Marco van de Voort escreveu:
In our previous episode, Felipe Monteiro de Carvalho said:
This is the part I like about this approach. The most likely fixed
encoding to be adopted would be UTF-16, and something not very nice
would happen to Lazarus users in UNIXes:
LCL (UTF-8) -- RTL
Felipe Monteiro de Carvalho escreveu:
I think it's the other way around. If you know what encoding is
expected you have a more predictable result. You know where a
conversion will take place. For example:
MyUTF8String := MyRTLString;
So we get an error that characters are being lost, but only
Luiz Americo Pereira Camara escreveu:
Initially i'm not in favor of using RTLString,, IMO LCL should choose
an encoding UTF16 or UTF8 and then let the compiler convert only the
system calls.
The complete phrase: Initially i'm not in favor of using RTLString, IMO
LCL should choose
Martin Schreiber escreveu:
On Tuesday 15 September 2009 18:04:33 Luiz Americo Pereira Camara wrote:
In my view, to get the fpc unicode support in a good state would be
necessary to implement the encoding field in the string type so
converting strings can be done system independently (seems
Graeme Geldenhuys escreveu:
Luiz Americo Pereira Camara het geskryf:
Yes. RTLString would be just an alias to UnicodeString in win32 and
UTF8String in unixes
Bad news for Michael. :-) We would have to have serious documentation on
all the string types supported by FPC - I'm loosing
Graeme Geldenhuys escreveu:
2009/9/17 Luiz Americo Pereira Camara pascal...@bol.com.br:
RTLString would not meant to be used in client applications. Would be useful
only in functions that interact with system calls like the RTL ones having
two benefits: avoiding extra encoding conversions
The cited revision fixes a bug that prevents proper work of Lookup
fields in TSqlite*Dataset
Luiz
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Luiz Americo Pereira Camara escreveu:
The cited revision fixes a bug that prevents proper work of Lookup
fields in TSqlite*Dataset
Reminder
Luiz
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo
Ivo Steinmann escreveu:
Vincent Snijders schrieb:
Maybe it is better to generate a foobar_dyn.inc based on the
foobar.inc or generate both foobar.inc and foobar_dyn.inc from a
common file format (maybe even the original header file)
[..]
Most libraries are translated by a tool like h2pas
Vincent Snijders escreveu:
Luiz Americo Pereira Camara schreef:
I think that creating a tool to translate a static header to a dyn
header should be easy to create (i'm not talking to convert c header
directly ;-)).
Should do the following right? Correct me if i'm wrong:
Static function
Joost van der Sluis escreveu:
On Mon, 2009-11-02 at 17:13 -0300, Luiz Americo Pereira Camara wrote:
I can write such tool.
I have made such a tool, which I used for the database-bindings. I don't
know if I still have it tough, and it was very rough.
But it's easy doable, indeed
Ivo Steinmann escreveu:
are you also on irc in #fpc @freenode? I'm often online there with nick
Aison
I don't use irc often, but should do if necessary.
I will try to do the tool this weekend and keep you informed even if is
not used.
Luiz
Marco van de Voort escreveu:
We have placed the first release-candidate of the Free Pascal Compiler
version 2.4.0 on our ftp-servers.
You can help improve the upcoming 2.4.0 release by downloading and
testing this release. If you want you can report what you have done here:
Martin Schreiber escreveu:
On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote:
Did you look into the code in cpstrnew branch? I did.
And which changes are exactly the reason for your concerns?
More checks and more complicated address calculation. OK, you can say you
Graeme Geldenhuys escreveu:
JoshyFun wrote:
(Windows only I think, and I do not know if Lazarus exclusive)
Is there any way to add a cancel button to the window that show leaks
?
It's not specific to Lazarus or Windows. As Vincent said, rather output
to file using an environment
Revision 14441 fix a regression introduced after the changes in how
boolean values are stored in wordbool variables (it was storing 65535).
I hope it has time to merge into 240
Luiz
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
dar...@emadar.com escreveu:
I try to resolve http://bugs.freepascal.org/view.php?id=15308
Is not that fixed by svn rev 14490?
problem is with str
str(1.0:10,s); writeln(s);
str(1.05:10,s);writeln(s);
str(1.05e2,s);writeln(s);
give results (:
1.000E+00
1.0E+
While trying to get the RGB values (bytes) of a TFPColor i got confused
about the format of TFPColor
Some hardcoded colors (unit FPImage) like colGray, colTea sets the high
byte value of Red, Green, Blue fields with the corresponding byte value
of RGB and leaves the low byte with 0.
Other
Mattias Gaertner escreveu:
On Tue, 16 Feb 2010 17:15:37 -0300
Luiz Americo Pereira Camara luiz...@oi.com.br wrote:
or
colGray be redefined as colGray : TFPColor = (Red: $8080; Green:
$8080; Blue: $8080; Alpha: alphaOpaque) ??
Yes, although this rarely makes a difference
Mattias Gaertner escreveu:
On Wed, 17 Feb 2010 04:39:26 -0300
Luiz Americo Pereira Camara luiz...@oi.com.br wrote:
Mattias Gaertner escreveu:
On Tue, 16 Feb 2010 17:15:37 -0300
Luiz Americo Pereira Camara luiz...@oi.com.br wrote:
or
colGray be redefined as colGray
Mattias Gaertner escreveu:
On Wed, 17 Feb 2010 06:52:25 -0300
Luiz Americo Pereira Camara luiz...@oi.com.br wrote:
fpimage is not documented at all AFAIK.
It's not loosing bits if your information, in previous mail, about
TFPColor format is correct.
Defining colGray, and related
I added EditMask property to TField in fpc trunk. To be Delphi
compatible i created a type TEditMask in MaskUtils unit, so the need to
put MaskUtils in the uses of db.
After trying to compile (make install) the following error occurs
(maskutils not found). Some notes
- fcl-base is a
Luiz Americo Pereira Camara escreveu:
I added EditMask property to TField in fpc trunk. To be Delphi
compatible i created a type TEditMask in MaskUtils unit, so the need
to put MaskUtils in the uses of db.
After trying to compile (make install) the following error occurs
(maskutils not found
Marco van de Voort escreveu:
L.s.
the FPC team plans to start preparations for a 2.4.2 this month.
By this message I would like to encourage everybody to test recent
snapshots as much as possible, and also to see if previously made fixes are
propagated correctly.
Note that not all 2.5.1
Joost van der Sluis escreveu:
On Fri, 2010-05-14 at 23:52 +0200, Marco van de Voort wrote:
In our previous episode, Luiz Americo Pereira Camara said:
By this message I would like to encourage everybody to test recent
snapshots as much as possible, and also to see if previously made
Until a few moments ago i would say yes because it seems logical and fpc
raises an exception when trying to set the value programatically.
But while investigating why TAutoIncField.ReadOnly always returns false,
i found that, regardless of FReadOnly being set to true in the
constructor, this
Michael Van Canneyt escreveu:
On Wed, 19 May 2010, Luiz Americo Pereira Camara wrote:
Until a few moments ago i would say yes because it seems logical and
fpc raises an exception when trying to set the value programatically.
But while investigating why TAutoIncField.ReadOnly always returns
Joost van der Sluis escreveu:
On Wed, 2010-05-19 at 00:32 -0300, Luiz Americo Pereira Camara wrote:
Until a few moments ago i would say yes because it seems logical and fpc
raises an exception when trying to set the value programatically.
But while investigating why TAutoIncField.ReadOnly
Joost van der Sluis escreveu:
On Wed, 2010-05-19 at 14:14 -0300, Luiz Americo Pereira Camara wrote:
I'm just confused by the exception that is raised (autoinc fields are
read only) when trying to set a value and by the code in the
TAutoIncField constructor that initializes FReadOnly
Michael Van Canneyt escreveu:
On Thu, 20 May 2010, Florian Klaempfl wrote:
I've no opinion if it's usefull to add or not, I use TPersistent+ too
little but my concern is: if I create an observer for an instance, I'd
expect to get notified about every change to the instance. But I cannot
see
Luiz Americo Pereira Camara escreveu:
I added EditMask property to TField in fpc trunk. To be Delphi
compatible i created a type TEditMask in MaskUtils unit, so the need
to put MaskUtils in the uses of db.
For the record, i've found the problem. The db unit is recompiled while
compiling
The result is get with a direct typecast Variant String. In this case
if Variant is Null an exception will occur.
Is this the desired behavior or should be changed to a call to VarToStr?
Luiz
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Luiz Americo Pereira Camara escreveu:
The result is get with a direct typecast Variant String. In this
case if Variant is Null an exception will occur.
Is this the desired behavior or should be changed to a call to VarToStr?
Sorry. Wrong list
Luiz
Marco van de Voort escreveu:
In our previous episode, Hans-Peter Diettrich said:
Honestly, a .NET back-end is less useful than e.g. a Java back-end, and
requires much work in the front-end for assembly compatibility (uses).
Next a new debugger-interface is needed, and a VCL.NET. All in all
Hi,
I've playing a bit with fpWeb and have some suggestions and questions:
- In TFPWebAction.DoHandleRequest if request is not handled by OnRequest
and inherited, the content is copied to the response and handled is
checked by the response content.
- FContensts will be always created even
Michael Van Canneyt escreveu:
On Fri, 30 Jul 2010, Luiz Americo Pereira Camara wrote:
Hi,
I've playing a bit with fpWeb and have some suggestions and questions:
- In TFPWebAction.DoHandleRequest if request is not handled by
OnRequest and inherited, the content is copied to the response
Michael Van Canneyt escreveu:
On Tue, 3 Aug 2010, Luiz Americo Pereira Camara wrote:
Michael Van Canneyt escreveu:
On Fri, 30 Jul 2010, Luiz Americo Pereira Camara wrote:
Hi,
I've playing a bit with fpWeb and have some suggestions and questions:
- In TFPWebAction.DoHandleRequest
Michael Van Canneyt escreveu:
I agree that the contents/content properties should be reduced to 1
property. But this is a change which will break backwards
compatibility.
AFAIK the fpWeb interface is still in progress. Anyway, better
change now than later.
The question is: which one ?
Michael Van Canneyt escreveu:
On Wed, 25 Aug 2010, Sven Barth wrote:
Am 24.08.2010 12:23, schrieb Michael Van Canneyt:
I do have the start of a reporting engine; However, I recently had a
look at
JasperReports, and want to rework what I have to use their XML
format as
a start.
I don't
Marco van de Voort escreveu:
Hello,
We have placed the first release-candidate of the Free Pascal Compiler
version 2.4.2 on our ftp-servers.
It does not compile the following program
It works with both 240 and 251
Luiz
You can help improve the upcoming 2.4.2 release by downloading and
Mattias Gaertner escreveu:
On Tue, 26 Oct 2010 17:31:48 +0200
zeljko zel...@holobit.net wrote:
One note: IntersectRect in lazarus worked OK until we decided to use
Types.IntersectRect, old implementation from GraphType looks much better than
current fpc one.
Then it is probably
zel...@holobit.net escreveu:
Quoting Luiz Americo Pereira Camara luiz...@oi.com.br:
Mattias Gaertner escreveu:
On Tue, 26 Oct 2010 17:31:48 +0200
zeljko zel...@holobit.net wrote:
One note: IntersectRect in lazarus worked OK until we decided to
use Types.IntersectRect, old implementation
michael.vancann...@wisa.be escreveu:
On Tue, 23 Nov 2010, Hans-Peter Diettrich wrote:
Andrew Brunner schrieb:
That would not be an issue as Int64 is available under all flavors
of FPC. I don't see the hold up in adding a patch for Data field.
There is just one unit to change. What makes
Michael Van Canneyt escreveu:
On Tue, 23 Nov 2010, Luiz Americo Pereira Camara wrote:
michael.vancann...@wisa.be escreveu:
On Tue, 23 Nov 2010, Hans-Peter Diettrich wrote:
Andrew Brunner schrieb:
That would not be an issue as Int64 is available under all flavors
of FPC. I don't see
On 31/1/2011 09:00, Felipe Monteiro de Carvalho wrote:
Hello,
I decided to put the patch here since it is so small.
It is rather trivial, just adds a bunch of virtual markers and some
methods with empty implementations, as to make them optional. I think
the behavior looks ok for me, if the
Hi,
As pointed in bug http://bugs.freepascal.org/view.php?id=19075
converting from vardate variants (variants with TDateTime values) to
string is done differently in Delphi and fpc. According to
http://support.embarcadero.com/article/35913 the conversion is done with
the default OS format
1 - 100 of 195 matches
Mail list logo
