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 record
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
On Tue, May 5, 2009 at 9:30 AM, Michael Van Canneyt
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 Design without any p
En/na Graeme Geldenhuys ha escrit:
On Tue, May 5, 2009 at 9:30 AM, Michael Van Canneyt
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
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
> > wrote:
> > > When designing FPCanvas and so on, streaming was not taken into
> > > consideration
> > > at all. The point was to be able to represent all poss
On Tue, May 5, 2009 at 11:48 AM, Luca Olivetti 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, no updates o
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
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 will occur when the
pro
Graeme Geldenhuys schreef:
On Tue, May 5, 2009 at 1:08 PM, Vincent Snijders
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 streamin
On Tue, 5 May 2009 13:15:02 +0200
Graeme Geldenhuys wrote:
> On Tue, May 5, 2009 at 1:08 PM, Vincent Snijders
> 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 mig
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
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 components
> visually. At the
On Tue, 5 May 2009 13:59:13 +0200
Graeme Geldenhuys wrote:
> On Tue, May 5, 2009 at 1:36 PM, Mattias Gaertner
> wrote:
> >
> > No.
> > Only the widgetset independent LCL properties are set. The LCL
> > interfaces then reads/sets the widgetset properties.
>
> Thanks for explaining...
>
>
> > f
On Tue, May 5, 2009 at 2:30 PM, Mattias Gaertner
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 big advantage of better
On Tue, 5 May 2009 15:14:02 +0200
Graeme Geldenhuys wrote:
> On Tue, May 5, 2009 at 2:30 PM, Mattias Gaertner
> 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,
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. Does it search LFM's when you do "Find in
Files" and select "all files in project"? I
Sven Barth wrote:
Hmm... if this speeds things up: shall I enclose the problematic places
with ifdefs and send a patch along with the bug report?
Got response yet? If not then yes, please send patches per topic to
ifdef the optional code away.
Micha
__
On Tue, 5 May 2009 17:10:01 +0200
Graeme Geldenhuys 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. Does it s
On Tue, May 5, 2009 at 6:08 PM, Mattias Gaertner
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 Create(TheOwner);
> end;
Wh
On Tue, 5 May 2009 20:05:34 +0200
Graeme Geldenhuys wrote:
> On Tue, May 5, 2009 at 6:08 PM, Mattias Gaertner
> wrote:
> >
> > There are ways to use a single include file. For example:
> >
> > -
> > {$I unit1.lfm}
> >
> > constructor TForm1.Create(TheOwner: TComponent);
> > begin
> > Re
On Tue, May 5, 2009 at 8:36 PM, Mattias Gaertner
wrote:
>>
>> Where is RegisterComponentInit() defined? I search all of Lazarus and
>> FPC 2.2.5 and couldn't find a definition.
>
> Sorry. It's only pseudo code. The functions do not exists yet. Just to
> demonstrate how it could look like.
Oops,
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
22 matches
Mail list logo
