On Wednesday, 29. February 2012 08.55:55 Michael Schnell wrote:
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:
-
On Wed, Feb 29, 2012 at 08:44:20AM +0100, Michael Schnell wrote:
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 with it.
The colleague I mentioned told me that
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
Michael Schnell schrieb:
Maybe he would be better off using ANSIString(0) or ANSIString($) to
be sure that his doing will not be influenced by the locale setting of
the system the code is compiled on or runs on.
AnsiString(0) should be okay, but other encodings may require overloaded
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 =
Am 28.02.2012 08:14, schrieb Michael Schnell:
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
Am 28.02.2012 08:22, schrieb Michael Schnell:
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
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 +, there is not
Am 28.02.2012 14:00, schrieb Michael Schnell:
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
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
--
Sven Barth schrieb:
Before Delphi 2009 you might have been right, but with that version
Embarcadero did a cut and we now need to adapt and live with that.
I dare to disagree. A ByteString only requires a dedicated encoding
(value), which makes it incompatible with other encodings, and thus
Am 28.02.2012 16:13, schrieb Sven Barth:
Am 28.02.2012 15:40, schrieb Hans-Peter Diettrich:
Sven Barth schrieb:
Before Delphi 2009 you might have been right, but with that version
Embarcadero did a cut and we now need to adapt and live with that.
I dare to disagree. A ByteString only
Am 28.02.2012 15:31, schrieb Martin Schreiber:
Am 28.02.2012 16:13, schrieb Sven Barth:
Am 28.02.2012 15:40, schrieb Hans-Peter Diettrich:
Sven Barth schrieb:
Before Delphi 2009 you might have been right, but with that version
Embarcadero did a cut and we now need to adapt and live with
Am 28.02.2012 16:52, schrieb Sven Barth:
Did you look at the 2.7.1 or 2.6.0 implementation of these procs? If the
2.6.0 one then I suggest you to look at the 2.7.1 ones and reconsider
your statement ;)
True. :-)
Do you think 2.7.1 FPC string handling is an improvement compared with
FPC
Am 28.02.2012 16:09, schrieb Martin Schreiber:
Am 28.02.2012 16:52, schrieb Sven Barth:
Did you look at the 2.7.1 or 2.6.0 implementation of these procs? If the
2.6.0 one then I suggest you to look at the 2.7.1 ones and reconsider
your statement ;)
True. :-)
Do you think 2.7.1 FPC string
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 Mon, Feb 27, 2012 at 06:50:38AM +0100, Martin Schreiber wrote:
TDataset.freerecord. That Delphi compatible though in current delphi's that
is probably empty, since tbookmark is tbytes there.
There is no TDataset.freerecord() procedure in FPC trunk AFAIK.
Sorry, freebookmark.
Please
On Monday 27 February 2012 12:22:58 Marco van de Voort wrote:
Please add TDataset.BookmarkStr property:
public
property BookmarkStr: TBookmarkStr read GetBookmarkStr write
SetBookmarkStr;
so in user code we can have a bookmark type with automatic memory
management.
I'll
On Monday 27 February 2012 20:32:29 Marco van de Voort wrote:
On Mon, Feb 27, 2012 at 12:48:29PM +0100, Martin Schreiber wrote:
I'll study if the normal tbookmark can change to tbytes short term. If
not, I'll add the bookmarkstr as deprecated property for time being.
Using TBytes as
On Mon, Feb 27, 2012 at 09:51:41PM +0100, Martin Schreiber wrote:
If so, please also note
the other interface related change:
http://wiki.freepascal.org/User_Changes_Trunk
Thanks. The problem with some of the recent Delphi compatibility changes is
that it breaks Delphi 7
Martin Schreiber schrieb:
Thanks. The problem with some of the recent Delphi compatibility changes is
that it breaks Delphi 7 compatibility.
+1 :-(
IMO at least a stable D7 compatible version/branch is required, which
may be extended to the last Delphi AnsiString version (D2007?). This
On Tue, Feb 28, 2012 at 12:00:14AM +0100, Hans-Peter Diettrich wrote:
Martin Schreiber schrieb:
Thanks. The problem with some of the recent Delphi compatibility changes
is
that it breaks Delphi 7 compatibility.
+1 :-(
IMO at least a stable D7 compatible version/branch is required,
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.
I completely agree and was surprised to read opposite opinions here.
Since 1985 I've been telling people this is my favorite feature so I can
use
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 Sun, Feb 26, 2012 at 10:15 AM, zeljko zel...@holobit.net wrote:
**
On Saturday 25 of February 2012 20:20:51 Max Vlasov wrote:
On Sat, Feb 25, 2012 at 6:48 PM, Max Vlasov max.vla...@gmail.com
wrote:
On Sat, Feb 25, 2012 at 5:36 PM, zeljko zel...@holobit.net wrote:
**
On
On Sun, 26 Feb 2012 13:38:43 +0300
Max Vlasov max.vla...@gmail.com wrote:
[...]
Just yesterday this line didn't produce any search results in Google, today
it leads at least to two bug reports in the tracker )
Don't know whether it would lead to anything, but I exlained by steps :
-
On Sun, Feb 26, 2012 at 08:15:13AM +0100, zeljko wrote:
On Saturday 25 of February 2012 20:20:51 Max Vlasov wrote:
Tried make it from scratch on a machine without fpc and lazarus. Download
both trunk, but 35594 can't compile with
dbgrids.pas(1991,31) Error: Incompatible types: got
On Sunday 26 of February 2012 14:41:13 Marco van de Voort wrote:
On Sun, Feb 26, 2012 at 08:15:13AM +0100, zeljko wrote:
On Saturday 25 of February 2012 20:20:51 Max Vlasov wrote:
Tried make it from scratch on a machine without fpc and lazarus.
Download both trunk, but 35594 can't compile
On Sunday, 26. February 2012 14.41:13 Marco van de Voort wrote:
On Sun, Feb 26, 2012 at 08:15:13AM +0100, zeljko wrote:
On Saturday 25 of February 2012 20:20:51 Max Vlasov wrote:
Tried make it from scratch on a machine without fpc and lazarus.
Download both trunk, but 35594 can't compile
On Sun, Feb 26, 2012 at 6:14 PM, zeljko zel...@holobit.net wrote:
**
Yes, but original post is about 2.4.5 NOT about 2.7.1,
also somebody opened issue at lazarus mantis about it.
zeljko
Sorry about the confusion, my initial plan was testing the fix by zeljko
about lazarus behaviar
On Sun, Feb 26, 2012 at 03:22:32PM +0100, Martin Schreiber wrote:
No. 2.7.x changed tbookmark from binary-data-encoded-in-an-ansistring to an
abstract type for compat of D2006+. The idea is to merge this back to 2.6.1
too. (so fix with fullversion20600)
How does the memory release work?
On Sunday, 26. February 2012 19.38:39 Marco van de Voort wrote:
How does the memory release work? With tbookmarkstr it was done
automatically by the compiler.
TDataset.freerecord. That Delphi compatible though in current delphi's that
is probably empty, since tbookmark is tbytes there.
Hi,
can't make clean all for trunk version under ubuntu with fpc 2.4.5
gtk2winapi.inc(3403,73) Error: Identifier not found
pango_font_family_is_monospace
I also see that in gtk2extrah.inc the inclusion of this symbol is optional
depending on the fpc version. Is this something wrong with my
2012/2/25 Max Vlasov max.vla...@gmail.com
can't make clean all for trunk version under ubuntu with fpc 2.4.5
gtk2winapi.inc(3403,73) Error: Identifier not found
pango_font_family_is_monospace
I also see that in gtk2extrah.inc the inclusion of this symbol is optional
depending on the fpc
On Saturday 25 of February 2012 13:17:53 Max Vlasov wrote:
Hi,
can't make clean all for trunk version under ubuntu with fpc 2.4.5
gtk2winapi.inc(3403,73) Error: Identifier not found
pango_font_family_is_monospace
I also see that in gtk2extrah.inc the inclusion of this symbol is
On Saturday 25 of February 2012 14:04:17 Juha Manninen wrote:
2012/2/25 Max Vlasov max.vla...@gmail.com
can't make clean all for trunk version under ubuntu with fpc 2.4.5
gtk2winapi.inc(3403,73) Error: Identifier not found
pango_font_family_is_monospace
I also see that in
On Sat, Feb 25, 2012 at 5:36 PM, zeljko zel...@holobit.net wrote:
**
On Saturday 25 of February 2012 14:04:17 Juha Manninen wrote:
2012/2/25 Max Vlasov max.vla...@gmail.com
can't make clean all for trunk version under ubuntu with fpc 2.4.5
Yep, ifdef was for fpc 20405 , now it's
On Sat, Feb 25, 2012 at 6:48 PM, Max Vlasov max.vla...@gmail.com wrote:
On Sat, Feb 25, 2012 at 5:36 PM, zeljko zel...@holobit.net wrote:
**
On Saturday 25 of February 2012 14:04:17 Juha Manninen wrote:
2012/2/25 Max Vlasov max.vla...@gmail.com
can't make clean all for trunk
On Saturday 25 of February 2012 20:20:51 Max Vlasov wrote:
On Sat, Feb 25, 2012 at 6:48 PM, Max Vlasov max.vla...@gmail.com wrote:
On Sat, Feb 25, 2012 at 5:36 PM, zeljko zel...@holobit.net wrote:
**
On Saturday 25 of February 2012 14:04:17 Juha Manninen wrote:
2012/2/25 Max Vlasov
43 matches
Mail list logo
