I am working on something similar so I found this mail. Here is my
solution, maybe someone can use it:
TDNAColor = packed record
case Integer of
0: (
b : Byte; //blue
g : Byte; //green
r : Byte; //red
a : Byte; //alpha
);
1: (
l :
Incidentally, while working with the TfpgColor type, I've come up with a
rather sloppy, but (for the time being) usable solution. I keep
a fixme comment in the code, because it may very well blow up in my
face sometime.
type
TfpgIntColor = TfpgColor;
TfpgRecordColor = record
blue,
Hi,
I'm looking at starting the conversion of fpGUI Toolkit's own Canvas
and Image classes, to using the TFPCustomCanvas and related image
classes.
Looking at TFPColor as defined below I looked at using something
similar to this in fpGUI, but soon realized that published properties
of
On Tue, 5 May 2009, Graeme Geldenhuys wrote:
Hi,
I'm looking at starting the conversion of fpGUI Toolkit's own Canvas
and Image classes, to using the TFPCustomCanvas and related image
classes.
Looking at TFPColor as defined below I looked at using something
similar to this in
On Tue, May 5, 2009 at 9:30 AM, Michael Van Canneyt
mich...@freepascal.org wrote:
When designing FPCanvas and so on, streaming was not taken into consideration
at all. The point was to be able to represent all possible colors, independent
of a GUI system or streaming system.
Fair enough
En/na Graeme Geldenhuys ha escrit:
On Tue, May 5, 2009 at 9:30 AM, Michael Van Canneyt
mich...@freepascal.org wrote:
When designing FPCanvas and so on, streaming was not taken into consideration
at all. The point was to be able to represent all possible colors, independent
of a GUI system or
On Tue, 5 May 2009, Luca Olivetti wrote:
En/na Graeme Geldenhuys ha escrit:
On Tue, May 5, 2009 at 9:30 AM, Michael Van Canneyt
mich...@freepascal.org wrote:
When designing FPCanvas and so on, streaming was not taken into
consideration
at all. The point was to be able to represent
On Tue, May 5, 2009 at 11:48 AM, Luca Olivetti l...@ventoso.org wrote:
I'm not sure, but I think that if it is a visual component, changing its
color it should invalidate/redraw itself.
With 4 properties it will be redrawn 4 times instead of just one.
* When loading a stream from *.lfm files,
Graeme Geldenhuys schreef:
Anyway, fpGUI doesn't use streaming of form files by default. Forms
are defined via normal code (and redraws are limited to only once
while initializing a form). But I want to make sure fpGUI can support
streaming if required in the future or if LCL-fpGUI is developed.
On Tue, May 5, 2009 at 1:08 PM, Vincent Snijders
vsnijd...@vodafonevast.nl wrote:
Under what circumstances are properties of fpGUI classes streamed when
LCL-fpGUI is developed?
I haven't delved much into the LCL widgetset internals, so I might
have this wrong. I would have thought streaming
Graeme Geldenhuys schreef:
On Tue, May 5, 2009 at 1:08 PM, Vincent Snijders
vsnijd...@vodafonevast.nl wrote:
Under what circumstances are properties of fpGUI classes streamed when
LCL-fpGUI is developed?
I haven't delved much into the LCL widgetset internals, so I might
have this wrong. I
On Tue, 5 May 2009 13:15:02 +0200
Graeme Geldenhuys graemeg.li...@gmail.com wrote:
On Tue, May 5, 2009 at 1:08 PM, Vincent Snijders
vsnijd...@vodafonevast.nl wrote:
Under what circumstances are properties of fpGUI classes streamed
when LCL-fpGUI is developed?
I haven't delved much
On Tue, May 5, 2009 at 1:25 PM, Vincent Snijders wrote:
An LCL form is streamed and LCL properties and components are set. When
creating a handle (widget reference) an fpGUI object will be created by the
TFpGuiWidgetSet interface, but that is done without streaming.
Ah ok - now I get it.
On Tue, May 5, 2009 at 1:36 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
No.
Only the widgetset independent LCL properties are set. The LCL
interfaces then reads/sets the widgetset properties.
Thanks for explaining...
fpgui needs published properties when you want to edit
On Tue, 5 May 2009 13:59:13 +0200
Graeme Geldenhuys graemeg.li...@gmail.com wrote:
On Tue, May 5, 2009 at 1:36 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
No.
Only the widgetset independent LCL properties are set. The LCL
interfaces then reads/sets the widgetset properties.
On Tue, May 5, 2009 at 2:30 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
If you don't like the lfm format, write a TReader/TWriter for your
format.
I don't have issues with the LFM format, it's the extra file I have an
issue with, plus a few others... see below.
Yes, this has the
On Tue, 5 May 2009 15:14:02 +0200
Graeme Geldenhuys graemeg.li...@gmail.com wrote:
On Tue, May 5, 2009 at 2:30 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
If you don't like the lfm format, write a TReader/TWriter for your
format.
I don't have issues with the LFM format, it's
On Tue, 5 May 2009 17:10:01 +0200
Graeme Geldenhuys graemeg.li...@gmail.com wrote:
On Tue, May 5, 2009 at 4:21 PM, Mattias Gaertner wrote:
* If a component changes, a simple search and replace can fix
all your code.
This works in lfm too, doesn't it?
I don't know, Delphi didn't.
On Tue, May 5, 2009 at 6:08 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
There are ways to use a single include file. For example:
-
{$I unit1.lfm}
constructor TForm1.Create(TheOwner: TComponent);
begin
RegisterComponentInit(@InitTForm1,TForm1);
inherited
On Tue, 5 May 2009 20:05:34 +0200
Graeme Geldenhuys graemeg.li...@gmail.com wrote:
On Tue, May 5, 2009 at 6:08 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
There are ways to use a single include file. For example:
-
{$I unit1.lfm}
constructor
I just noticed that this thread has gone off-topic for this mail list.
My apologies.
Mattias
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
21 matches
Mail list logo
