On Mon, 23 Jul 2007, Sergei Gorelkin wrote:
> Michael Van Canneyt wrote:
> >
> > On Mon, 23 Jul 2007, Graeme Geldenhuys wrote:
> >
> > > On 23/07/07, Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
> > > > The .lfm file is not code. It's a resource, which you can replace
> > > > at runtime.
> > > OK, I understand the resource part. It's components that have been
> > > streamed to a file. From this I also assume that it will recreate the
> > > form faster than via code. But on today's computers I don't really
> > > know is that is relevant anymore.
> >
> > No, via code is actually faster. It saves the RTTI lookup etc.
> >
> > > Can you explain the 'replace at runtime' part a bit more. I'm not sure
> > > I understand that statement. :)
> >
> > The form definition is stored in a resource as text. In theory you
> > can replace the resource with another resource. The translation engine
> > of Delphi relies on this, for instance...
> >
> > Suppose I have a form definition:
> >
> > MyForm Object TMyForm
> > Caption = 'A nice form'
> > Width = 200
> > Height = 100
> > end
> >
> > Then it can be replaced in the running binary by e.g. a translated version
> >
> > MyForm Object TMyForm
> > Caption = 'Een leuk venster'
> > Width = 220
> > Height = 110
> > end
> >
> > With adapted width and height (a dutch text is usually longer).
>
> This issue comes (in Delphi) from the absense of layout manager. In fpGUI or
> GTK, you can simply translate the necessary strings, and the form will realign
> itself properly. IIRC, gtk/glade has single XML file in which the strings that
> need translation are marked as such. The translation is done with gettext,
> using .mo files.
Yes, but this is a crude mechanism...
>
> > The alternative version can be loaded from a resource dll, or from
> > file. XML comes to mind: the original author of fpGUI imagined that the
> > original form is stored as XML. It would then be easy to create a second
> > XML 'overload' part which can be used to change the visual appearance of the
> > form. This second XML file could simply be loaded from a file on disk.
>
> A thing that I must mention is "at runtime" and "at initialization" are not
> the same. Typical program state is not limited to form resources, it includes
> non-published properties, manually created objects, etc. At initialization
> time this state is generally known, but later on it is not. All attempts to
> reload resources at the middle of execution that I have seen were a mix of
> hacks with black magic, and work only in particular cases.
Could be, I don't have bad experiences :-)
>
> > Using the constructor method, all this is not possible (well, I suppose you
> > could find a way, but it would be less elegant). Since the form definition
> > is now just text, it can be simply replaced with another text. If the form
> > definition was XML, this would actually be very easy. Now it is slightly
> > more complicated.
>
> Not too much complicated, I believe:
> 1) Declare translatable properties as a separate type
> ( like 'type TTranslateString = type string;' )
> 2) While generating code, wrap strings that are being assigned to such
> properties into gettext call
> ( e.g. Label1.Caption := _('Caption'); )
This is so, but you are limiting yourself to the translation.
The overlaying mechanism could be used to implement rudimentary theming,
for instance. To reuse my example:
Original:
MyForm Object TMyForm
Caption = 'A nice form'
Width = 200
Height = 100
end
Overlay:
MyForm Object TMyForm
Caption = 'Een leuk venster'
Width = 220
Height = 110
Color = clYellow
Icon = <some icon resource>
end
I'm not saying that this is the way to go; All I was saying is that this was
one of the ideas behind using resources instead of using code; it requires
no extra streaming code: it's all already there. What's more, the additional
resources can be inserted later at any time; With code this is harder to do.
You may need to re-generate all existing code, and make sure you don't
destroy any modifications the user made in the code. With resources, it's 1
extra call.
Michael.
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
