Hi,

Following the RAD discussion, I thought of something.

Often, I subclass a control just to set some properties to other than their default values. (TLabel.AutoSize and TLabel.layout jump to mind).

This can in fact be avoided by having some kind of 'Application-Wide defaults' system.

I imagine something like

TLabelDefaults = Class(TPersistent)
   // Selected properties.
end;

and

Var
   LabelDefaults : TLabelDefaults;

Which are applied as soon as a TLabel control is created.

This would eliminate the need to subclass many controls. Instead of subclassing TLabel, I could do

LabelDefaults.AutoSize:=False;
LabelDefaults.Layout:=tlCenter;

Once in my application (you could even create a separate designer for this in the IDE), and all labels have a different default.

Since the .lfm file only contains properties that are actually set to non-default values, this would work with streaming as well.

Michael.

Op 2011-01-17 13:08, Michael Van Canneyt het geskryf:

This can in fact be avoided by having some kind of 'Application-Wide defaults' system.

Wouldn't Delphi's "Component Template" idea solve this too? As far as I can see Lazarus doesn't support the Component Template idea though.

eg:
In Delphi 7:
1) Place components as you want them on a designer form.
2) Set there properties as you want.
3) Select all those components then select
"Components > Create component template"
4) Give it a name and icon. Done!

Now on the component palette under the "Templates" tab, you will have a new component. Click and drop it on a form to reproduce all that was done before - positioning and properties.

No need to rebuild the IDE or install custom components...

Regards,
- Graeme -

It is not quite the same:

It works, till you need to change the template. (in my case, the defaults).

The template is copied, not 'inherited' or 'initialized'. If I'd need to change something, then I'd need to change it in all locations where I used the template. Not so with the defaults.

Michael.

Depends on how many *different* defaults are required.

We could implement something like the HTML Cascading Style Sheets, and allow for an artificial "Style" property with every control or control-class. "Themes" is another term that comes into mind...

DoDi

Sound much like constructing an frame, as I did in Lazarus recently.

And - oh wonder - no packaging, registration or rebuild of the IDE is required, in order to use frames from the component palette :-)

DoDi

On Mon, Jan 17, 2011 at 2:08 PM, Michael Van Canneyt <

I liked the idea, but to understand it correctly... You placed it in "var", isn't it supposed to be placed on a form like any other TComponent? So once it added, every existing and future TLabel on the form will get new defaults unless they're explicitly changed by the user? And if the persistent is deleted all default will be back to objects default.

There are some challenges I think, for example how to behave with inheritance since in this case both component and default can be inherited and changed in the form.

Also I thought that it would be useful to implement them like TField in database components. So for example make Defaults properties in the form that works like Fields in TDataSet descendants so on any placed component if there is registered corresponding TComponentDefault found, it's automatically added to Defaults designer or rather say as TField works, it simply added to form while also supported effectively by specially created designer. I know that it's more work to do in this case, but implementing this way will allow more convenient usage, since starting some number of defaults randomly placed components on the form are harder to track and use.

Max Vlasov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110118/a42cffdf/attachment.html>

No, I actually meant a var, because I want it to be application-wide.

You could of course implement a 'form local' variant for this as well. The loading code could do something like

If Assigned(GlobalLabelDefaults) then
   ApplyDefaults(GlobalLabelDefaults);
LocalDefaults:=FindLocalDefaults(TLabelDefaults);
If Assigned(LocalDefaults) then
   ApplyDefaults(LocalDefaults);

There are some challenges I think, for example how to behave with inheritance since in this case both component and default can be inherited and changed in the form.

Not a problem with the global one ?

A good idea as well, but I would like to have an application-wide setting.

Well, with a global and a local version, it works almost like CSS :-)

Michael.

Hmm, Michael, I understand you here, but I think that the main drawback about application-wide (so possibly run-time only) is about losing design-time magic. For example when you have 10 panels, go change some design-time property and they changed their view all at once without even running anything. If they're form-only and design-time, you still can imitate application-wide defaults inheriting from common ancestor and placing all you defaults there, but you will keep this magic at your fingers

Max Vlasov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110118/23eb3e72/attachment.html>

18.01.2011 13:31, Max Vlasov :

So defaults should be designtime to.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110118/e2d4942d/attachment-0001.html>

The whole point is to avoid having to do the same task all over again. Remember, a typical app of mine has more than 1000 forms.

If you set a property at design time, the 'default' is overridden anyway:
- Default is applied at control creation.
- When the control is loaded from stream, control-specific values are set, and override the defaults.

When you use 'per form' defaults, it becomes more difficult, because then you must make sure that first the form defaults are loaded, and only then read the properties. In that scenario, we must check the order of events: all 'defaultable' properties should be set only in the Loaded method, because only in the Loaded event we know whether there is a 'defaults' component.

So my scenario is more simple. But I think both can be implemented, they don't disturb each other.

Michael.

Ok, now I see, your initial idea is really simple and working, the one I suggested maybe needs a little more thinking about worth it or not implementing. I know it can work, but for the time being looks a little bit too complex

For yours I have something in mind. Is it possible to create something similar to TApplicationEvents (in terms of accessing special places in the LCL) and this component that will introduce an event

TOnCreateComponent: procedure (Sender: TObject; Component: TComponent) of
object;

if it's dropped on a form, it can control the place where actual TComponentClass.Create fired and sends this event. In this case anyone can easily do something like:

procedure TForm1.LCLEventsCreateComponent(Sender: TObject; Component:
TComponent);
begin
  if Component is TLabel then
    with Component as TLabel do
    begin
       AutoSize:=False;
       Layout:=tlCenter;
    end else
   if Component is ...
end;

This method should do exactly the things you described. Although it is a form method, it doesn't matter much, it just should be first form to create and never-freed. In this case it should work for any form (like TApplicationEvents does).

Max Vlasov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110118/d36d9ed1/attachment.html>

I could then create a global object that sets this handler. This should be implemented in TReader or in TComponent.AfterCreate, so I can do it myself in the classes unit if necessary.

There is only one drawback in this system: it will be called for all created components. This means that there will be a huge If/then/else, and that there is only 1 handler possible.

My system will be significantly faster, and is easily controllable on a per-component basis.

Michael.

[...] My system will be significantly faster, and is easily controllable on a per-component basis.

and does not interfere at design time, which avoids all kinds of context problems.

Although setting TLabel.AutoSize=false sounds like platform dependency, I guess it can be useful.

Feel free to provide a patch.

Mattias

As for the speed, I think you're more familiar with internals than me so you'd better decide yourself :)

just two things about events that I like a little more:

Just to clarify, did I understand the logic behind your objects correctly, should they self-register somewhere from their create's?

- If objects are self-created, the context of the changes is hidden. It's sometimes very hard to remember why this particular object looks differently to what one saw in the desiginer. Calling some self-registered objects from deep within LCL is just hidding this changes far from the developer.

- Sometimes when one have options to implement or not to implement a brand-new object (TLabelDefaults in your example), it depends on the value of this. So when I have some exotic component I probably will use twice or third times, making additional "else if" is sometimes easier than implementing a new object, even if I understand that the latter is more effective.

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110118/01fa9fa5/attachment.html>

The whole point is to avoid having to do the same task all over again. Remember, a typical app of mine has more than 1000 forms.

In this special case I'd suggest a set of company-specific basic controls and forms, that can not be broken by some other LCL magic.

DoDi

Why is setting autosize=false a platform dependency ?

It's the first thing I do for all labels, always.

Feel free to provide a patch.

I will :)

Michael.

Well, one system doesn't exclude the other. I will implement the event as well. If the event is not set, then the speed will remain as it is now.

Question is, where to call the event ?
- In the streaming system ?
- In the TComponent.AfterCreate ?

The latter means that it is always called, even if you create components in code, but then you have no context - (namely: which form is being loaded)

Michael.

A not autosized label is not adapting to font and caption.

It's the first thing I do for all labels, always.

I guessed so from your example. ;)

Mattias

Yes, of course, that's the whole point of disabling it :-)

Michael.

Yes, and of course, that's not platform independent. :-)

Mattias

Ok, sounds great )

Maybe there will be other votes, but I prefer the first choice, this instrument is more flexible with context, and one can always wrap/filter run-time creation of controls to recalling the same event with nil for unknown things.

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110118/1512f0e6/attachment.html>

I think (csLoading in ComponentState) can be used to distinguish between the two cases.

Michael.

My system will be significantly faster, and is easily controllable on a per-component basis.

It will be pluggable and optional, so does not alter the executable size of who does not use it?

Luiz

Dear members:

i am doing an app. using TDBF, but i have found a problem:

i am trying to introduce a float value, using a DBEdit (first i introduce in an edit and then pass to DBEdit)

i have declared the field as ftFloat, but when i try to Post, a message said that it is not an integer.

i read in the TDBF Manual by Micha Nelissen that i need to declare the property "UseFloatField" as true but I dont know were to do that.

I will appreciate your help.

thanks in advance,

yours,

Ing. H?ctor F. Fiandor Rosario

This can only be done when the 'Default' component is the same class as the component to be loaded. Otherwise, a separate class must be made per class.

This may be not such a bad idea. Simply have an instance of the same class, with properties set to their desired default values.

In such a case, all you need is 1 extra variable per used class.

Comments, thoughts, anyone ?

Michael.

At each layer in LCL do you plan to apply the default values.

Maybe you could add a mechanism to hook the creation of TLCLComponent (an event) and then do the job in another unit. It would cost only one variable more and all overhead would be in a separate unit.

Luiz