Why should it be true ?
The specs only say something about writing, not about reading.
It is a misconception to think that you can read a stream
and thus restore a component to it's "original designed state".
The behaviour of reading a component from stream is only well-defined
after it was j
On 28 Mar 2008, at 16:58, Martin Schreiber wrote:
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
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
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. But since there is apparently no way to
easily create a si
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.
>
On 28 Mar 2008, at 16:19, Michael Van Canneyt wrote:
On Fri, 28 Mar 2008, Micha Nelissen wrote:
Michael Van Canneyt wrote:
Oh come on! It's not *that* far from a general streaming
mechanism; so I
consider this a design flaw.
IMHO, it's very far, see Mattias' remarks :(
Hmm well the oth
On Fri, 28 Mar 2008, Micha Nelissen wrote:
> Michael Van Canneyt wrote:
> > > Oh come on! It's not *that* far from a general streaming mechanism; so I
> > > consider this a design flaw.
> >
> > IMHO, it's very far, see Mattias' remarks :(
>
> Hmm well the other "fun" thing was that in Delphi y
Michael Van Canneyt wrote:
Oh come on! It's not *that* far from a general streaming mechanism; so I
consider this a design flaw.
IMHO, it's very far, see Mattias' remarks :(
Hmm well the other "fun" thing was that in Delphi you could not have no
default for floats or integers IIRC. Maybe thi
On Fri, 28 Mar 2008, Micha Nelissen wrote:
> Michael Van Canneyt wrote:
> > If you want a general streaming mechanism (javabeans like), then you
> > simply should not use "stored" or "default", then you'll have something
> > that comes close.
>
> Oh come on! It's not *that* far from a general s
Michael Van Canneyt wrote:
If you want a general streaming mechanism (javabeans like), then you
simply should not use "stored" or "default", then you'll have something
that comes close.
Oh come on! It's not *that* far from a general streaming mechanism; so I
consider this a design flaw.
Mich
On Fri, 28 Mar 2008, Micha Nelissen wrote:
> Michael Van Canneyt wrote:
> > > FYI: so before streaming, the "streamer" has to reset the values to their
> > > defaults to stream properly. Unfortenately, there is no function to do
> > > this,
> > > and it's usually done in constructor. Therefore s
Michael Van Canneyt wrote:
FYI: so before streaming, the "streamer" has to reset the values to their
defaults to stream properly. Unfortenately, there is no function to do this,
and it's usually done in constructor. Therefore streaming twice does not work
properly.
This is not correct.
The def
On Fri, 28 Mar 2008, Mattias Gärtner wrote:
> Zitat von Michael Van Canneyt <[EMAIL PROTECTED]>:
>
> >
> >
> > On Fri, 28 Mar 2008, Micha Nelissen wrote:
> >
> > > Michael Van Canneyt wrote:
> > > > It is used in streaming in the classes unit; the streaming mechanism
> > checks
> > > > the actu
Zitat von Michael Van Canneyt <[EMAIL PROTECTED]>:
>
>
> On Fri, 28 Mar 2008, Micha Nelissen wrote:
>
> > Michael Van Canneyt wrote:
> > > It is used in streaming in the classes unit; the streaming mechanism
> checks
> > > the actual
> > > value against this value: if it is the same, the value is
On Fri, 28 Mar 2008, Micha Nelissen wrote:
> Michael Van Canneyt wrote:
> > It is used in streaming in the classes unit; the streaming mechanism checks
> > the actual
> > value against this value: if it is the same, the value is not streamed.
>
> FYI: so before streaming, the "streamer" has to
On 28/03/2008, Martin Schreiber <[EMAIL PROTECTED]> wrote:
> > Unrelated (because I think such declarations are
> > broken for fpu types/values): what code do you have to write so that
> > this default value is actually used?
> >
>
> fcolor is initialized to the default value in constructor. TW
On 28/03/2008, Jonas Maebe <[EMAIL PROTECTED]> wrote:
>
> It compiles again. Unrelated (because I think such declarations are
> broken for fpu types/values): what code do you have to write so that
> this default value is actually used?
fpGUI's UI Designer generates GUI code directly in the .pas
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 that
Michael Van Canneyt wrote:
It is used in streaming in the classes unit; the streaming mechanism checks the
actual
value against this value: if it is the same, the value is not streamed.
FYI: so before streaming, the "streamer" has to reset the values to
their defaults to stream properly. Unfo
On Fri, 28 Mar 2008, Jonas Maebe wrote:
>
> On 28 Mar 2008, at 07:47, Martin Schreiber wrote:
>
> >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,
On 28 Mar 2008, at 07:47, Martin Schreiber wrote:
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_ma
On 28/03/2008, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote:
>
> and TfpgColor is defined as follows:
>
> TfpgColor = type longword;
>
> With FPC 2.2.0 (64bit and 32bit) the code compiles with out issues.
And some predefined colors used in fpGUI are defined as follows:
clSilver= Tfp
On 28/03/2008, Martin Schreiber <[EMAIL PROTECTED]> wrote:
> Hi,
> What is wrong with this code:
Michael Van Canneyt detected a similar issue with fpGUI code and FPC 2.3.1
- It doesn't compile with my 2.3.1 compiler. (64 bit)
Free Pascal Compiler version 2.3.1 [2007/07/04] for x86_64
Copyright
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 =
24 matches
Mail list logo
