Hi,
Is there a way in current FPC to have unicode or wide resourcestrings?
Thanks,
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Friday 29 February 2008 09.02:02 Daniël Mantione wrote:
Op Fri, 29 Feb 2008, schreef Martin Schreiber:
Hi,
Is there a way in current FPC to have unicode or wide resourcestrings?
Thanks,
Resourcestrings are ansistrings, so the answer is no. This is indeed a
shortcoming in a widestring
On Friday 29 February 2008 09.25:18 Daniël Mantione wrote:
Op Fri, 29 Feb 2008, schreef Martin Schreiber:
On Friday 29 February 2008 09.02:02 Daniël Mantione wrote:
Op Fri, 29 Feb 2008, schreef Martin Schreiber:
Hi,
Is there a way in current FPC to have unicode or wide resourcestrings
On Friday 29 February 2008 10.07:29 Daniël Mantione wrote:
Op Fri, 29 Feb 2008, schreef Martin Schreiber:
On Friday 29 February 2008 09.25:18 Daniël Mantione wrote:
Op Fri, 29 Feb 2008, schreef Martin Schreiber:
On Friday 29 February 2008 09.02:02 Daniël Mantione wrote:
Op Fri, 29 Feb
On Friday 29 February 2008 10.49:11 Michael Schnell wrote:
Before I knew about MSEifi I intended to attach the remote GUI on a
per-control base via a propriety protocol (e.g. using RemObjects). But
this would imply handling any program done that way individually, which
of course is not really
On Friday 29 February 2008 11.27:47 Michael Schnell wrote:
Sure, it is the purpose of MSEifi to connect client MSEgui objects and
events with server events and data by the use of an universal client
program.
Sounds good. Let me elaborate a bit more: The program in question needs
to be
:
Martin Schreiber wrote:
There is another alternative to Delphi-Kylix:
http://mypage.bluewin.ch/msegui/
Downloaded and installed.
Firsts tests Worked on the spot !
Even debugging (single stepping).
I'll go on testing tomorrow.
-Michael
;-)
Should I use Windows or Linux ?
Linux of course
On Friday 29 February 2008 10.07:29 Daniël Mantione wrote:
Ideally from my point of view would be if the resourcestrings are stored
in utf-8 if the unit is compiled with -Fcutf8 and decoded by utf8decode
for widestring assignment on runtime independent of the system encoding.
This has
On Sunday 02 March 2008 10.22:32 Daniël Mantione wrote:
Regarding code generation, there is a difference between ansistrings and
resourcestrings, since with a resourcestring load, the compiler must look
into the resourcestring tables to find the ansistring constant.
So it is theoretical
On Sunday 02 March 2008 14.09:47 Daniël Mantione wrote:
Op Sun, 2 Mar 2008, schreef Martin Schreiber:
On Sunday 02 March 2008 10.22:32 Daniël Mantione wrote:
Regarding code generation, there is a difference between ansistrings and
resourcestrings, since with a resourcestring load
On Sunday 02 March 2008 15.31:04 Daniël Mantione wrote:
Then the only possible way to use resourcestrings independent from the
system encoding is to compile all resource units with -Fcutf8 and to
write every assignment as widestringvar:=
Utf8Decode(resourceconstant);?
Would this method
On Sunday 02 March 2008 18.43:01 Florian Klaempfl wrote:
Martin Schreiber schrieb:
What did I wrong?
I'am not sure how this could be made working just a remark: -Fcutf8
influences _only_ the interpretation of string constants when converting
them to unicode.
I thought as much
On Sunday 02 March 2008 18.48:01 Daniël Mantione wrote:
Op Sun, 2 Mar 2008, schreef Florian Klaempfl:
What did I wrong?
I'am not sure how this could be made working just a remark: -Fcutf8
influences _only_ the interpretation of string constants when converting
them to unicode.
Right.
On Sunday 02 March 2008 19.31:37 Florian Klaempfl wrote:
Martin Schreiber schrieb:
On Sunday 02 March 2008 18.48:01 Daniël Mantione wrote:
Op Sun, 2 Mar 2008, schreef Florian Klaempfl:
What did I wrong?
I'am not sure how this could be made working just a remark: -Fcutf8
influences
On Sunday 02 March 2008 19.22:38 ik wrote:
I wonder, do you care also to try BIDI text as well ?
Ido
No, BIDI is out of scope of MSEgui up to now, supporting all European
languages without a headache is a must.
Martin
___
fpc-devel maillist -
Hi,
I try to build a m68k crosscompiler with fixes_2_2:
[...]
/home/mse/packs/standard/svn/fp/fixes_2_2/compiler/ppc -Ur -Xs -O2 -n -Fum68k
-Fusystems -Fu/home/mse/packs/standard/svn/fp/fixes_2_2/rtl/units/i386-linux
-Fim68k -FE. -FUm68k/units/i386-linux -dRELEASE -dm68k -dGDB -dBROWSERLOG
On Thursday 13 March 2008 13.48:55 Jonas Maebe wrote:
On 13 Mar 2008, at 13:24, Martin Schreiber wrote:
I try to build a m68k crosscompiler with fixes_2_2:
m68k is not supported in 2.x at this time. The last version that
supported m68k was 1.0.10a. Every now and then, some people work
On Thursday 13 March 2008 14.16:41 Martin Schreiber wrote:
On Thursday 13 March 2008 13.48:55 Jonas Maebe wrote:
On 13 Mar 2008, at 13:24, Martin Schreiber wrote:
I try to build a m68k crosscompiler with fixes_2_2:
m68k is not supported in 2.x at this time. The last version
On Thursday 13 March 2008 15.14:14 Jonas Maebe wrote:
Seems to be nothing m68k specific?
It probably means that invalid register allocation information is
generated by the m68k code generator. As said: m68k is simply not
supported at this time. Even if it would compile you'd get a lot
Hi,
Please merge the fix for Mantis 10825 (Memory error in
fpc_WideStr_Concat_multi) to fixes_2_2.
Thanks, Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Hi,
Please fix Mantis 10791 (ObjectBinaryToText broken for reals) and merge to
fixes_2_2, it damages the form files. Suggestion: remove the wrong code.
Index: classes.inc
===
--- classes.inc(revision 10339)
+++ classes.inc
On Friday 21 March 2008 14.54:24 Vincent Snijders wrote:
Martin Schreiber schreef:
Hi,
Please fix Mantis 10791 (ObjectBinaryToText broken for reals) and merge
to fixes_2_2, it damages the form files. Suggestion: remove the wrong
code.
Why not let Giulio fix it?
I don't understand
On Friday 21 March 2008 15.09:22 Vincent Snijders wrote:
Martin Schreiber schreef:
On Friday 21 March 2008 14.54:24 Vincent Snijders wrote:
Martin Schreiber schreef:
Hi,
Please fix Mantis 10791 (ObjectBinaryToText broken for reals) and merge
to fixes_2_2, it damages the form files
On Friday 21 March 2008 15.19:57 Martin Schreiber wrote:
10791 was submitted 2008-02-14 and assigned 2008-02-14 to Michael Van
Canneyt. The wrong patch has cosmetic reasons only and can savely be
reverted.
Argh! Correction:
10791 was submitted 2008-02-08.
Sorry, Martin
Hi,
What is wrong with this code:
program rangeerror;
{$ifdef FPC}{$mode objfpc}{$h+}{$endif}
{$ifdef mswindows}{$apptype console}{$endif}
uses
{$ifdef FPC}{$ifdef linux}cthreads,{$endif}{$endif}
sysutils;
type
colorty = type longword;
const
cl_mapped = colorty($9000);
type
ttestclass =
On Friday 28 March 2008 11.23:07 Jonas Maebe wrote:
On 28 Mar 2008, at 07:47, Martin Schreiber wrote:
What is wrong with this code:
[...]
It compiles again.
Thanks!
Unrelated (because I think such declarations are
broken for fpu types/values): what code do you have to write so
On Thursday 27 March 2008 21.50:33 Michael Van Canneyt wrote:
While extensive testing has been done (using the FPCunit testing
framework), and the working of Lazarus with this new code was verified, it
is possible that bugs remain. We would therefor very much appreciate that
if you have code
On Friday 28 March 2008 16.36:35 Jonas Maebe wrote:
Floats not, integers yes, I think ?
FPC cannot deal properly with floats either as far as I can see from
the compiler source code. But since there is apparently no way to
easily create a simple test program, I can't verify this.
AFAIK
On Friday 28 March 2008 16.42:52 Jonas Maebe wrote:
On 28 Mar 2008, at 16:41, Martin Schreiber wrote:
On Friday 28 March 2008 16.36:35 Jonas Maebe wrote:
Floats not, integers yes, I think ?
FPC cannot deal properly with floats either as far as I can see from
the compiler source code
On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote:
Jesus just told me that it is fixed in r10587.
Great, I set the bug to resolved.
Seems like the most obvious bugs are fixed.
Now I wait for the subtle ones to appear ;-)
Here it is the first one:
On Sunday 30 March 2008 01.32:09 Michael Van Canneyt wrote:
On Sat, 29 Mar 2008, Martin Schreiber wrote:
On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote:
Seems like the most obvious bugs are fixed.
Now I wait for the subtle ones to appear ;-)
Here it is the first one
On Sunday 30 March 2008 17.56:40 Michael Van Canneyt wrote:
On Sun, 30 Mar 2008, Martin Schreiber wrote:
On Sunday 30 March 2008 01.32:09 Michael Van Canneyt wrote:
Looks good, thanks. There is a problem with inline components:
http://bugs.freepascal.org/view.php?id=11069
Please delete
On Sunday 30 March 2008 19.21:04 Vincent Snijders wrote:
Martin Schreiber schreef:
Inline is used for subforms, components in a form which inherit from
another form (TFrame in Delphi), in MSEgui every form can be used as
inline component. The ffInline filer flag must be written
On Sunday 30 March 2008 20.48:23 Michael Van Canneyt wrote:
On Sun, 30 Mar 2008, Martin Schreiber wrote:
Inline is used for subforms, components in a form which inherit from
another form (TFrame in Delphi), in MSEgui every form can be used as
inline component. The ffInline filer flag must
On Sunday 30 March 2008 20.42:13 Michael Van Canneyt wrote:
On Sun, 30 Mar 2008, Martin Schreiber wrote:
I'd like to second Colins wish. Please use the same resolving order as
Delphi. MSEide+MSEgui compiles with Delphi7 so the reversed order is an
unnecessary complication and error source
On Monday 31 March 2008 15.00:02 Michael Van Canneyt wrote:
It is like streaming of an inherited form. Lookup the ancestor and write
the property differences.
Nono, when streaming an inherited form, the IDE provides the ancestor
instance when the streaming starts, because it calls
On Monday 31 March 2008 16.13:48 Michael Van Canneyt wrote:
On Mon, 31 Mar 2008, Martin Schreiber wrote:
I am not convinced. By controlling the order of the properties and the
load order of the forms it is possible to control the resolving order.
Does FPC loose on quality if you use
On Thursday 03 April 2008 10.42:02 Michael Van Canneyt wrote:
On Sun, 30 Mar 2008, Martin Schreiber wrote:
On Sunday 30 March 2008 19.21:04 Vincent Snijders wrote:
Martin Schreiber schreef:
Inline is used for subforms, components in a form which inherit from
another form (TFrame
On Thursday 03 April 2008 10.42:02 Michael Van Canneyt wrote:
On Sun, 30 Mar 2008, Martin Schreiber wrote:
On Sunday 30 March 2008 19.21:04 Vincent Snijders wrote:
Martin Schreiber schreef:
Inline is used for subforms, components in a form which inherit from
another form (TFrame
Hi,
I am currently debugging the cleanroom code which is a frustrating matter
because gdb crashes at allmost every breakpoint.
Any hints how to let gdb work more stable with trunk on i386-linux?
I compile with -O- already, gdb version is 6.6.50.20070726-cvs.
Martin
On Thursday 03 April 2008 13.54:32 Martin Schreiber wrote:
Hi,
I am currently debugging the cleanroom code which is a frustrating matter
because gdb crashes at allmost every breakpoint.
Any hints how to let gdb work more stable with trunk on i386-linux?
I compile with -O- already, gdb version
On Thursday 03 April 2008 14.04:44 Jonas Maebe wrote:
On 03 Apr 2008, at 13:54, Martin Schreiber wrote:
I am currently debugging the cleanroom code which is a frustrating
matter
because gdb crashes at allmost every breakpoint.
Any hints how to let gdb work more stable with trunk on i386
On Thursday 03 April 2008 14.04:44 Jonas Maebe wrote:
One thing you can try is using -gw to use dwarf instead of stabs.
It seems sets are displayed as integers with dwarf?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Thursday 03 April 2008 17.18:48 Jonas Maebe wrote:
On 03 Apr 2008, at 17:16, Martin Schreiber wrote:
On Thursday 03 April 2008 14.04:44 Jonas Maebe wrote:
One thing you can try is using -gw to use dwarf instead of stabs.
It seems sets are displayed as integers with dwarf?
$ ppcppc57
On Thursday 03 April 2008 21.33:17 Jonas Maebe wrote:
On 03 Apr 2008, at 19:12, Martin Schreiber wrote:
The compiler crashes with -godwarfsets.
Fixed.
It doesn't crash anymore, thanks.
The display of sets seems to be wrong:
[EMAIL PROTECTED]:~/packs/standard/svn/mse/trunk/apps/ide gdb
On Thursday 03 April 2008 15.02:46 Martin Schreiber wrote:
On Thursday 03 April 2008 14.04:44 Jonas Maebe wrote:
One thing you can try is using -gw to use dwarf instead of stabs.
That helps, thanks a lot!
There are gdb crashes with -gw too:
[EMAIL PROTECTED]:~/packs/standard/svn/mse/trunk
On Friday 04 April 2008 08.37:24 Martin Schreiber wrote:
On Thursday 03 April 2008 15.02:46 Martin Schreiber wrote:
On Thursday 03 April 2008 14.04:44 Jonas Maebe wrote:
One thing you can try is using -gw to use dwarf instead of stabs.
That helps, thanks a lot!
There are gdb crashes
On Friday 04 April 2008 08.48:59 Martin Schreiber wrote:
On Friday 04 April 2008 08.37:24 Martin Schreiber wrote:
On Thursday 03 April 2008 15.02:46 Martin Schreiber wrote:
On Thursday 03 April 2008 14.04:44 Jonas Maebe wrote:
One thing you can try is using -gw to use dwarf instead
On Thursday 03 April 2008 10.58:26 Michael Van Canneyt wrote:
On Thu, 3 Apr 2008, Martin Schreiber wrote:
You used my copyrighted code, the sources look exactly the same. ;-)
A strong case against all these copyright suits... :-)
And we made the same error, see attachment. It is a little bit
On Thursday 27 March 2008 21.50:33 Michael Van Canneyt wrote:
While extensive testing has been done (using the FPCunit testing
framework), and the working of Lazarus with this new code was verified, it
is possible that bugs remain. We would therefor very much appreciate that
if you have code
On Friday 04 April 2008 19.40:30 Jonas Maebe wrote:
And this 6.6 also works fine with stabs.
I tried with gdb 6.8.50:
GNU gdb 6.8.50.20080306
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you
On Saturday 05 April 2008 10.25:45 Martin Schreiber wrote:
Hurray!
Update:
GNU gdb 6.8.50.20080306
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute
On Saturday 05 April 2008 13.32:40 Jonas Maebe wrote:
in a cross-platform way. Does the unix expect utility exist for
Windows?
http://expect.nist.gov/
lists two native windows ports and the cygwin port.
Martin
___
fpc-devel maillist -
On Saturday 05 April 2008 14.33:16 Jonas Maebe wrote:
Fixed. gdb 6.5 also works again. It starts a lot slower than 6.6, so I
guess 6.5 read all debug information on startup (which is why it
crashed immediately) while 6.6 and later only read the debug info as
needed (and hence only crashed
On Saturday 05 April 2008 20.56:01 Jonas Maebe wrote:
It works with gdb 6.6, but indeed not with 6.8. I'll try to find the
cause and file a bug report with gdb if necessary.
I've implemented a workaround in the compiler and submitted a gdb bug
report.
Tested with dwarf and gdb 6.6.50 and
Hi,
We spent some days with debugging MSEide+MSEgui with FPC trunk. Sometimes
there are AV's while calling an interface procedure. Example:
http://homepage.bluewin.ch/msegui/pics/crash.png
I don't know if it is a cleanroom, a FPC trunk or another problem.
I stop cleanroom debugging now until the
On Monday 07 April 2008 09.22:11 Никита Баль wrote:
Does anybody tryed to debug fpc under Lazarus? How?
This is for MSEide i386 and FPC 2.3.1:
http://sourceforge.net/project/showfiles.php?group_id=165409
- 'Project'-'New'-'From Program'.
- Select compiler/pp.pas from your FPC SVN checkout.
-
On Monday 07 April 2008 08.46:46 Michael Van Canneyt wrote:
On Mon, 7 Apr 2008, Martin Schreiber wrote:
Hi,
We spent some days with debugging MSEide+MSEgui with FPC trunk. Sometimes
there are AV's while calling an interface procedure. Example:
http://homepage.bluewin.ch/msegui/pics
Hi,
We try to build a package for MSEide+MSEgui with precompiled units. While
compiling a simple testproject with the precompiled units we get:
Free Pascal Compiler version 2.2.0 [2007/08/31] for i386
Copyright (c) 1993-2007 by Florian Klaempfl
Target OS: Linux for i386
Compiling project1.pas
On Tuesday 15 April 2008 09.26:30 Micha Nelissen wrote:
Martin Schreiber wrote:
Recompiling msesysintf, checksum changed for msefileutils {impl}
Fatal: Can't find unit msesysintf used by msesysutils
Fatal: Compilation aborted
What do we wrong, any hints?
Do you have multiple
On Tuesday 15 April 2008 10.36:24 Jonas Maebe wrote:
On 15 Apr 2008, at 09:05, Martin Schreiber wrote:
Recompiling msesysintf, checksum changed for msefileutils {impl}
Fatal: Can't find unit msesysintf used by msesysutils
Fatal: Compilation aborted
What do we wrong, any hints?
Do you
On Tuesday 15 April 2008 13.25:14 Jonas Maebe wrote:
Another reason might be this: http://bugs.freepascal.org/view.php?id=10551
I tried with fixes_2_2 and trunk, the problem is the same. Should I play with
uses order in msefileutils? Any other suggestion? Could it be related to:
On Tuesday 15 April 2008 20.23:39 Jonas Maebe wrote:
On 15 Apr 2008, at 19:59, Martin Schreiber wrote:
On Tuesday 15 April 2008 13.25:14 Jonas Maebe wrote:
Another reason might be this:
http://bugs.freepascal.org/view.php?id=10551
I tried with fixes_2_2 and trunk, the problem
On Tuesday 15 April 2008 20.42:24 Martin Schreiber wrote:
How can I check if I really produced release units?
I think I produced release units, they are not recompiled with -B.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
On Tuesday 15 April 2008 20.49:39 Jonas Maebe wrote:
I'm actually not sure whether -Ur makes the compiler also disregard
any interface changes, but I think it does. Or are you not compiling
msefileutils with -Ur at this point? (and did you only compile
previous units with -Ur)
I deleted all
On Tuesday 15 April 2008 21.13:41 Jonas Maebe wrote:
On 15 Apr 2008, at 21:05, Martin Schreiber wrote:
Moving msesysintf from implementation uses to interface uses in
msefileutils
fixes the issue.
I know what causes the crc problem: the fact that msesysintf declares
routines as external
On Tuesday 15 April 2008 21.13:41 Jonas Maebe wrote:
On 15 Apr 2008, at 21:05, Martin Schreiber wrote:
Moving msesysintf from implementation uses to interface uses in
msefileutils
fixes the issue.
I know what causes the crc problem: the fact that msesysintf declares
routines as external
On Tuesday 29 July 2008 09.54:54 Graeme Geldenhuys wrote:
A Russian user raised the issue in the fpGUI newsgroups... fpGUI uses
UTF-8 as the internal string encoding. He noticed that the File Dialog
which displays the file sizes with thousand separators were totally
blank. On further
On Wednesday 03 September 2008 11.07:49 Graeme Geldenhuys wrote:
Hi,
I know it's possible, but I can't remember the exact FPC parameters.
How do I see the assembler generated by FPC for my source code?
I need to do some optimisation comparisons looking at the assembler
generated.
eg:
Is
On Wednesday 03 September 2008 12.04:23 Graeme Geldenhuys wrote:
On 9/3/08, Martin Schreiber [EMAIL PROTECTED] wrote:
You could use breakpoints and the (dis-)assembler window of MSEide, it
lists mixed pascal and machine code.
Thanks Martin, I'll take a look.
What I'm trying to find out
On Wednesday 03 September 2008 12.53:09 Graeme Geldenhuys wrote:
On 9/3/08, Martin Schreiber [EMAIL PROTECTED] wrote:
For the people who don't know MSEide attached a screenshot, I hope the
file is not too big. It is with -O3. With inline there is still some
overhead because of the string
Florian,
On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote:
I've continued to work on support of an unicodestring type in fpc. It's
currently in an svn branch at:
http://svn.freepascal.org/svn/fpc/branches/unicodestring
and will be merged later to trunk. The unicodestring type is a
On Friday 05 September 2008 22.50:23 Florian Klaempfl wrote:
If you want to try it yourself, MSEide+MSEgui trunk rev. 2473 has
msestring = unicodestring if compiled with -dmse_unicodestring.
What's the official way to compile MSE?
cd apps\ide
ppc386.exe -Fu..\..\lib\common\*
On Friday 05 September 2008 22.50:23 Florian Klaempfl wrote:
[...]
This should be fixed.
Thanks, FPC and MSEide compile now.
Attached an emergency patch that I could load the MSEgui forms, not finished
and not tested. Is TTypekind = (... tkInterfaceRaw,tkUChar,tkUString)
correct?
Next
On Saturday 06 September 2008 21.08:50 Florian Klaempfl wrote:
Martin Schreiber schrieb:
Next problem is that pmsechar(msestring) returns a NIL pointer if
msestring = ''. As designed? The behaviour of ansistring and widestring
was very useful, I'd like if UnicodeString would behave
On Sunday 07 September 2008 10.58:03 Florian Klaempfl wrote:
Martin Schreiber schrieb:
On Saturday 06 September 2008 21.08:50 Florian Klaempfl wrote:
Martin Schreiber schrieb:
Next problem is that pmsechar(msestring) returns a NIL pointer if
msestring = ''. As designed? The behaviour
On Sunday 07 September 2008 21.23:24 Florian Klaempfl wrote:
Trunk 11723 does not compile:
Trunk or unicodestring branch? Strange, because here it works?
Unicodestring branch, sorry, I should change the directory name of my switched
checkout. Does your unicodestring branch compile?
Martin
On Monday 08 September 2008 04.53:25 Felipe Monteiro de Carvalho wrote:
Hello,
Using TSdfDataset my records are cut to fit 255 chars, even when I
change the new MaxRecordLength property to 2048. This is a very
elusive bug, and I am searching all over for the cause without success
=(
I
On Monday 08 September 2008 14.42:04 Felipe Monteiro de Carvalho wrote:
On 9/8/08, Marco van de Voort [EMAIL PROTECTED] wrote:
That shoulds like a shortstring limit. Is everything in {$H+} or {$mode
delphi} ?
This was my first idea, but I couldn't find anywhere a H+ missing ...
Also, as
On Monday 08 September 2008 19.34:32 Felipe Monteiro de Carvalho wrote:
On Mon, Sep 8, 2008 at 10:51 AM, Martin Schreiber [EMAIL PROTECTED] wrote:
Did you open an existing datafile?
I am always working opening an existing datafile. So, you are thinking
that it calculates the size
On Monday 08 September 2008 20.19:27 Felipe Monteiro de Carvalho wrote:
On Mon, Sep 8, 2008 at 3:14 PM, Martin Schreiber [EMAIL PROTECTED] wrote:
It seems so if you don't define the field size in the TSdfDataset.Schema.
Unlike tmsebufdataset, TSdfDataset stores the data in a record with fixed
On Tuesday 09 September 2008 20.28:05 Luca Olivetti wrote:
El Mon, 8 Sep 2008 20:14:44 +0200
Martin Schreiber [EMAIL PROTECTED] escribió:
Is Sqlite3 no option for you? MSEgui and FPC sqldb both have a
DB-connection component for SQLite3.
FWIW I had the problem of string fields limited
On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote:
I've continued to work on support of an unicodestring type in fpc. It's
currently in an svn branch at:
http://svn.freepascal.org/svn/fpc/branches/unicodestring
and will be merged later to trunk. The unicodestring type is a ref.
On Thursday 11 September 2008 22.33:32 listmember wrote:
procedure TLabel.Paint(...)
begin
if *Caption.IsRTL *then
DrawCaptionRTL(0,0,*Caption.AsUTF8*, flags)
else
DrawCaption(0,0,*Caption.AsUTF8*, flags);
end;
Is not that enough?
What is the gain as
On Thursday 11 September 2008 23.18:07 Florian Klaempfl wrote:
Martin Schreiber schrieb:
On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote:
I have a crash in MSEide startup in a procedure finalization section:
[...]
I saw that you merged unicodestring to trunk. Should I test
On Sunday 14 September 2008 19.22:13 Florian Klaempfl wrote:
Martin Schreiber schrieb:
I tried with trunk, same result. The problem is probably that the second
constant string parameter has a wrong reference count. It is initially 0
instead of -1. The incref call at begin of winfilepath
On Friday 26 September 2008 09.34:44 Graeme Geldenhuys wrote:
Well if you have Utf-8 versions of all basic string processing
functions like Pos, Length, Copy, Insert etc you don't have to think
of encoding or anything. fpGUI uses UTF-8 internally, and I never have
to think about what encoding
On Friday 26 September 2008 12.30:27 Marco van de Voort wrote:
In our previous episode, Martin Schreiber said:
Hmm, you should ask the Russian users for example if they prefer MSEgui
utf-16 internal encoding or Lazarus utf-8.
Users always look short term, and want to change as little
On Sunday 28 September 2008 00.10:43 Graeme Geldenhuys wrote:
On Fri, Sep 26, 2008 at 5:02 PM, Mattias Gaertner
[EMAIL PROTECTED] wrote:
s[i]:='x' doesn't work in UTF-8, nor UTF-16, nor UTF-32.
In short:
A single character for all purposes can not be defined. Unicode can not
be
On Sunday 28 September 2008 20.16:36 Graeme Geldenhuys wrote:
On Sun, Sep 28, 2008 at 12:22 PM, Mattias Gaertner
Is this normalized form used only internally in msegui or must the user
use them too?
I remember when I tried a MSEgui version some time back, that the IDE
itself used that
On Thursday 23 October 2008 13.31:30 Florian Klaempfl wrote:
This is also a simplified view.
- firstly, which real world (!) task really requires to execute an
operation like this, mostly it's something like copy(s,pos(...),...);
- secondly, a properly coded utf-16 application shouldn't do
On Thursday 23 October 2008 13.58:04 Michael Schnell wrote:
Bidi stuff? You are aware of the fact that unicode strings can contain
e.g. bidi markers?
Sorry, never heard of bidi :(
Bidirectional text. Much more important than the hypothetical codepoints above
the BMP. MSEgui does not
On Tuesday 11 November 2008 17.34:36 Graeme Geldenhuys wrote:
All I do know is that only recently did the WideString manager become
usable in FPC. Martin had until recently some issues with bugs in the
WideString manager.
???
The last widestring manager bug I remember was in January 2007 in
On Sunday 23 November 2008 09.26:35 Graeme Geldenhuys wrote:
On Sun, Nov 23, 2008 at 10:19 AM, Mattias Gaertner
[EMAIL PROTECTED] wrote:
On Sat, 22 Nov 2008 23:05:43 +0200
For example the lazarus IDE typically holds 50 to 200mb sources in
memory. If this would be changed to unicodestring
On Sunday 23 November 2008 13.44:02 Mattias Gaertner wrote:
But RTTI only contains published classes, does it not?
AFAIK there are some more elements where is is possible to get a typeinfo
pointer. A compiler specialist can say more. :-)
Does MSEGui read ppu files?
No.
Martin
On Thursday 11 December 2008 19.27:18 Jonas Maebe wrote:
Hello,
I've just merged the whole program optimisation branch into trunk. For
information on what it currently does and how to use it, see
http://wiki.freepascal.org/Whole_Program_Optimization
Great!
Martin
On Monday 02 February 2009 12:00:07 Jonas Maebe wrote:
I've never been beaten by the Linux gurus for submitting Pascal-
related bug reports to gdb, or by discussing them on the gdb Archer
project list (someone from Red Hat recently fixed a bug in the gdb
Archer branch that only affected dwarf
Hi,
The Suse 11.1 i386 supplied linker crashes with FPC produced objects.
Example linking the DE-resource unit in MSEgui i18ndemo:
./ppas.sh
Linking libi18ndemo_de.so
./ppas.sh: line 10: 4825 Segmentation fault /usr/bin/ld -b elf32-i386 -m
elf_i386 -init FPC_LIB_START -fini FPC_LIB_EXIT
On Monday 02 February 2009 16:01:06 Jonas Maebe wrote:
I don't see any beating here either:
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412927
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509873
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473955
Even if they disagree, you
On Tuesday 03 February 2009 10:06:40 Jonas Maebe wrote:
OK, I'll try it.
Where should I report? At Suse because it is a Suse patched ld?
That's indeed your best bet. Here's their bug reporting portal:
http://en.opensuse.org/Submitting_Bug_Reports
Done:
101 - 200 of 513 matches
Mail list logo
