Michael Van Canneyt wrote:
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...
Crude as it may seem, it is a lesser of two evils. Having an application
with 10 forms, localized into 10 languages means that you have 100 files
to maintain. If any one of these 100 gets outdated (in terms of
adding/deleting objects; merely changing properties is not so
dangerous), application will most probably not run at all.
Otoh, the ability to update resources independently of code is probably
valuable for closed-source projects.
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
Theming may also be implemented by using string substitution mechanism.
All you have to do is declare styles that are referenced by name (and
this is also key point of fpGUI!).
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.
A working implementation with code can be found in MCK project (part of
KOL/MCK).
It writes auto-generated code into a separate file that is included by
main source
and is not intended to be edited by users. Probably that file is regenerated
on every save, but I am not sure.
Sergei
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
