Controls won't work when using Action from Frame

[trexet]

Hi. Encountered some unexpected behavior while cleaning the main form code and moving actions to a frame.

Steps to reproduce:

• Create a new form, add a button on it
• Create a new frame, add a TActionList with some action (e.g. standard TFileOpen)
• Add the frame to the form, assign the button's action to Frame1.FileOpen1
• Check that the button has it's caption updated according to the action
• Run and see the button having no caption and action

Ctrl-O is still handled correctly.

UPD: Setting action in the runtime (e.g. Button1.Action := Frame1_1.FileOpen1 within form's OnCreate()) seems to do the trick. However, it's still interesting - why doesn't that work the intended way? I suppose that it has to be with the initialization order of the form and the frame.

[egsuh]

Can you post the simple project, including form and frame please?

[trexet]

Here it is.

[egsuh]

I don't know why this happened, but there are two frame names,  Frame1 and Frame1_1 in your form definition. In the unit1.pas and unit1.lfm file, there exists Frame1_1. But in the property inspector of your form, the button's action is TFrame1.FileOpen1 (while the frame name is Frame1_1, in the property inspector).

I tried to change action name of the button to Frame1_1.FileOpen1, but it was not successful. Then I tried to change the name of Frame1_1 to Frame1 in the property inspector, which was not successful either.

So I changed the names (Frame1_1 --> Frame1) directly in unit1.lfm file and unit1.pas, and then it seems to work correctly.

[trexet]

Hm, these names were auto-generated by Lazarus. Maybe it's a bug?

[egsuh]

Hm, these names were auto-generated by Lazarus. Maybe it's a bug?

Possibly. When I try to change the frame name from Frame1_1 to Frame1, the error message is "there is already a form with the name Frame1", and when I try to change button's action name from Frame1.FileOpen1 to Frame1_1.FileOpen1 then it says "Invalid property value". 

I can make this work by changing names in the .pas file and .lfm file, but the caption defined in the Action is not displayed on the button.

Frame1 is defined in the unit2.lfm. I think this is why the frame in form1 is named Frame1_1. Not sure whether this is correct.

[cdbc]

Hi
It's a known problem, with frames created and placed via Object Inspector.
When you've placed a frame on a form 'visually' at design time, it stops recognizing changes. If you do, you're in for all troubles known to man...
I've had(having) great success with creating frames dynamically(and destroying) at runtime, then they're great 'compartementalizers' 
HTH
Regards Benny

[trexet]

Yep, I've played a bit more with Frames in the designer, and noticed that they are pretty buggy. Sometimes I have to delete resource file so that changes can take place.

[af0815]

The Frames are not buggy, they are working perfect.

But the designer of the Frame-Container (this is not the frame) is not able to track all the changes and set it up.
Eg. if you make a doubleclick on the Button in the Frame you say you will override the eventhandling of the frame and this is stored in the lfm, and bound the button to be processed in the Form (not frame yet). If you delete the eventhandler, the binding is not removed and this is your problem. The second problem is the tracking of changes in the designer if something is changed in the frame. You have to close the Form and reopen it. I know such problem in Delphi too for ages :-) So you can say it is Delphi-Compatible :-)

Use Frame dynamic and all is working well.

[MarkMLl]

It's a known problem, with frames created and placed via Object Inspector.
When you've placed a frame on a form 'visually' at design time, it stops recognizing changes. If you do, you're in for all troubles known to man...
I've had(having) great success with creating frames dynamically(and destroying) at runtime, then they're great 'compartementalizers' 

I agree with that. /All/ design time editing has to be done within the context of the frame, not the context of an instantiation of a frame onto a form. That includes event handler assignment, and that might possibly have implications for TActionList etc.

For things that can't be done at frame design time, do them at runtime. Hence

• Add the frame to the form, assign the button's action to Frame1.FileOpen1

...
UPD: Setting action in the runtime (e.g. Button1.Action := Frame1_1.FileOpen1 within form's OnCreate()) seems to do the trick. However, it's still interesting - why doesn't that work the intended way? I suppose that it has to be with the initialization order of the form and the frame.

Basically, this is something that should be documented in the manual.

MarkMLl

[dsiders]

Basically, this is something that should be documented in the manual.

Rather that guess, what specifically does "this" refer to?

[MarkMLl]

Basically, this is something that should be documented in the manual.

Rather that guess, what specifically does "this" refer to?

The fact that frames, and their events, should not be edited after design-time instantiation.

MarkMLl

[dsiders]

Basically, this is something that should be documented in the manual.

Rather that guess, what specifically does "this" refer to?

The fact that frames, and their events, should not be edited after design-time instantiation.

MarkMLl

Thank you. That gives me something specific to look at.