?
?

Hans-Peter Diettrich hat am 11. Juli 2011 um 18:38 geschrieben:

Can you provide an example??
?
?

2) An event handler, implemented in the frame and added to one of its components, cannot be set when the form is loaded.?

Please create a bug report.?
?
?

The .lfm contains only the method name, perhaps the object name is missing?

?
Can you give an example? ?
?
?

3) Sometimes it helps to remove the frames, and to add them again, but not always.?

Helps for what??
?
?

4) Events seem to be triggered while the frame is *loaded*.?

Can you give an example??
?

?

Some more bugs, with components inside the frame: 5) Clearing a combobox.Text doesn't work, at runtime the control always contains its Name.?

Please create a bug report with an example.?
?

I don't know this component well, but that's probably a bug. Please report.? ?

?

See for example unit fileutil function DeleteDirectory.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110711/6a600f68/attachment.html>

In working with an frame I get any number of errors :-( [Win32]

It looks to me as if the (main) form resource is not updated properly, at the right time:

1) Frame.alClient (alLeft...) is not really honored. The frame is marked as occupying the according space in the container form, but its components are not (always) resized.

2) An event handler, implemented in the frame and added to one of its components, cannot be set when the form is loaded. The .lfm contains only the method name, perhaps the object name is missing?

3) Sometimes it helps to remove the frames, and to add them again, but not always.

4) Events seem to be triggered while the frame is *loaded*.

Some more bugs, with components inside the frame:

5) Clearing a combobox.Text doesn't work, at runtime the control always contains its Name.

6) How to use an DirectoryEdit?

Which is the right event to use for reacting after the user has choosen a directory? I tried EditingDone, but this event is triggered already when the component is loaded[4].

Can the dialog be opened by code?

And a last question: what's the preferred procedure for scanning a directory? FindFirstFile etc. look a bit window-ish to me.

DoDi

Screenshot or project?

Just now?

   inline MyDocs: TFileList
     Height = 493
     Align = alLeft
     ClientHeight = 493
     TabOrder = 2
     inherited edRoot: TDirectoryEdit
       Width = 228
       OnEditingDone = edRootEditingDone <------------#2, #4
     end
     inherited lbDirs: TComboBox
       Text = 'lbDirs' <----------------- #5, is blank in OI
     end
     inherited lbFiles: TListBox
       Height = 419
     end
   end

To make the project compile and run.

See above.

Obviously the form.lfm duplicates/overrides the frame.lfm settings, sometimes. Perhaps I find something reproducible...

> And a last question: what's the preferred procedure for scanning a > directory? FindFirstFile etc. look a bit window-ish to me. See for example unit fileutil function DeleteDirectory.

Thanks :-)

DoDi

?
?

Hans-Peter Diettrich hat am 12. Juli 2011 um 14:13 geschrieben:

AFAIK: No. ?
It was implemented with Delphi in mind.?
?
?

When I have a form with embedded frames, and then modify an frame, what changes are transparent to the forms where the frame is already used??

Frames work very similar to inherited forms.
?
The IDE does not yet propagate changes in real time. You have to close a form and reopen it to see changes to ancestors/frames.? Of course it is planned to eventually propagate some changes in real time. See below. ?
?
That means: before you change a property of a frame, close all open forms using that frame.?
?
The lfm files store only the differences. When loading a form the inherited forms/frames lfm are applied one after the other.? To create the diff TWriter needs the ancestor. That's why the IDE opens the ancestors and keeps them open.
?
?

E.g. adding methods should not be a problem, while changes to the GUI may not be reflected properly (as expected) in the container forms??

Most properties are no problem most of the time. And any property can be a problem.?
?
?

Here is a start:
http://wiki.lazarus.freepascal.org/IDE_Development#Frames ?
?
Mattias
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110712/0857a05b/attachment.html>

A general question, Before I start submitting bug reports:

Does there exist documentation about frame *development*?

When I have a form with embedded frames, and then modify an frame, what changes are transparent to the forms where the frame is already used?

E.g. adding methods should not be a problem, while changes to the GUI may not be reflected properly (as expected) in the container forms?

Should a form.lfm contain settings for *components* in the frame, after such settings are changed in the frame itself? It looks to me as if the form tries to retain the previous settings, and the designer inserts according overrides in the form.lfm.

Example:

During development of the form's GUI I notice that a combobox contains its name in the Text property. Since this is unwanted in general, I modify the combobox.Text in the *frame*. Can I expect that this change is reflected in the *form* immediately, or after closing and reopening the form designer?

Does it make a difference, whether the form is open in the designer, or whether the form.lfm is open in the editor (view form as...), when properties of an embedded frame are changed inside the frame?

It would help a lot when there existed documentation about what's going on in the form and frame designers, so that a user can know what (possibly unwanted) behaviour is by design, how to avoid it, and what can be considered a bug.

DoDi

That means: before you change a property of a frame, close all open forms using that frame.

Very good idea :-)

Here is a start: http://wiki.lazarus.freepascal.org/IDE_Development#Frames

Fine :-)

Now I'll resume my current work and keep all suggestions in mind. Perhaps it was me who caused the strange effects ;-)

DoDi