Lazarus
Programming => General => Topic started by: lorenzo on November 07, 2019, 02:53:06 pm
-
Code in the OnClick event handler of a TListBox worked just fine over a couple of days, then the control ceased to activate the code when I clicked on an item in the listbox.
The list box was on a page of a TPageControl on a TFrame within an application created within Lazarus (not converted from Delphi). My operating system is Windows 10, 64 bit. Lazarus version 2.0.4, FPC version 3.0.4.
This is the second time this problem has arisen. The first time I made some efforts to find out 'why' without much success and eventually scrapped the troublesome frame and rebuilt it. Along the way I found that I could set up an OnDoubleClick event which *did* work, even though On(Single)Click had stopped, but after a while that stopped too! This time I have done more searching around, and tried prodding into the .lfm file but am no wiser. I have stopped and restarted Lazarus; tried Run > Build and Run > Clean up and build; rebooted. I cannot see why I have the problem or how to cure it, short of rewriting the TFrame.
I would be very grateful for suggestions.
-
Is the OnClick event handler still assigned to the Listbox?
-
Yes. I can change the OnClick event in the object inspector (hope that's the right name -- on the left of the IDE) -- whatever event is selected fails to have effect when the listbox is clicked.
-
So this happens inside a TFrame? Do you think you can setup a demo project for upload to the forum so that we can have a closer look?
-
Is it a particular compiled version that failed to respond after a few days of runtime, or did it work for several compilation runs, then suddenly cease to operate as it did before?
-
Hi.
Try to check if the event is correctly set on the form containing the frame.
When you insert a frame in a form the event of the frame appears in the Object Inspector with this syntax: The code is not accessible by double clicking on it: if you try to double click a new event procedure is created in the Form in this case: with empty body and the link with the frame's event is broken.
I'm not sure it can help but I discover this in the past.
Regards
Luca
-
Paul - the latter. Developing the application, I repeatedly extended/amended the code and recompiled it. The listbox event fired happily over many cycles of this process, then for no reason that was apparent to me it simply didn't respond to the click. The changes I was working on at the time I noticed the altered behaviour had no direct bearing on the listbox but (because I didn't test every control every time I recompiled) I am not sure when exactly the change kicked in.
L.
-
wp
I made a project to show how I was using frames and listboxes. I haven't yet cracked how to upload the project but meanwhile I have copied a lot of the code into a text file, attached. It shows the content of the .pas and .lfm files for the main unit and for one of the frames.
At this stage the application works fine - clicking a listbox fires the appropriate OnClick event.
I'm now going to explore Luca's suggestion.
L.
-
I haven't yet cracked how to upload the project [...]
See here: Forum: Sharing large pieces of code (https://wiki.freepascal.org/Forum#Sharing_large_pieces_of_code)
-
Luca
Having prodded around a bit, as best I can tell, things seem to be set up properly.
When I select the frame and look at the object inspector, I see the listbox among the list of components; and when the listbox is selected, the lower panel shows (by clicking the down arrow) OnClick events only for controls that are on the frame, including the one tailored for the listbox (which I originally generated by clicking the ... ellipsis button on the object inspector). I think that is all as it should be.
When I select the main form, I can see in the object inspector the tab control and, under it, the various frames and their components. When I select my listbox, I can view the properties/events below. The OnClick field is blank. Clicking the down arrow shows various events on the main form that I could (but don't) select.
One of my reasons for using frames is to compartmentalise my code: I try to keep all the controls and their effects on the frame and not let them sprawl onto other frames and forms.
It was a good thing you prompted me to check this, so thank you for the suggestion.
L.
-
Many thanks to lucamar for steering me to information on uploading projects.
Here is my example project, attached.
L.
-
Hi!
Despite that it is a strange design everything compiles fine and works as it should. (Linux gtk2, Laz 2.06)
The "normal" way to realize this is a pagecontrol with 2 pages for this example.
Put the fish stuff on one page and the birds on the other. You dont have to care about the
visibilty - it changes automatic.
To keep components together there is the GroupBox with a border and a caption and its own color - if needed.
But keep on with your experiments!
Winni
-
Working with frames can be very very confusing in particular when frames are inserted into their container form at designtime because now you can have the "template" frames as well as the instances in the form on the screen. Suppose you want to change a property of the "template" in order to change that property in both instances - then you must activate the frame in the designer and do the change there; when you do the change only in an instance other instances are not affected. Quite often I have a system of serveral frame classes inheriting from each other - then the situation becomes even more confusing.
Therefore, I usually create frames only at runtime - look at attached modified demo. If you open the master frame in the designer only when needed there is little risk that properties or events are changed incidentally.
I also changed the way how the two frames are shown. I added a TNotebook component which is a multipage control, similar to a TPageControl or TTabControl but without tabs (hiding the tabs does not work nicely in all widgetsets).
-
When ever I used frames I get a little upset when making changes to the frame itself it does not change in the forms that are using the frame.. I think if I restart the project the change may take place or reintroduce it . I don't know why I need to do that so I try to stay away from frames.
Also, the last time I checked the OI will not properly generate a unique event when double clicking the event tab for auto generate, it will pick out one that has already been created that's compatible.
basically the naming should use the current Frame instance as part of the event name so if one were to have multiples of the same frame the events can have unique events instead of them all going to the same event handler.
I don't , maybe this will get fixed one day..
-
Thank you for the sample, wp. I will experiment with that approach.
Meanwhile, here is a thing. I have found that renaming a 'dead' listbox revivifies it: the same old onclick event kicks back into life with no changes to the unit/frame other than those the IDE imposes when the name changes. The compiler complains that 'the ancestor for [old name of control]' is missing. I can overcome that by creating a new control with the old name (and no events). The compiler is then content and the re-created control can just be ignored or hidden while the renamed control does the work.
Ho hum.
Thank you to everyone for the attention and thoughts.
L.
-
Meanwhile, here is a thing. I have found that renaming a 'dead' listbox revivifies it: the same old onclick event kicks back into life with no changes to the unit/frame other than those the IDE imposes when the name changes. The compiler complains that 'the ancestor for [old name of control]' is missing. I can overcome that by creating a new control with the old name (and no events). The compiler is then content and the re-created control can just be ignored or hidden while the renamed control does the work.
The risk here is that the revised listbox is being saved in the context of the form, not in the context of the frame. I'm pretty sure I've seen this sort of thing: when frames are good they are very very good, but when they are bad they are horrid :-)
MarkMLl
-
When ever I used frames I get a little upset when making changes to the frame itself it does not change in the forms that are using the frame
Changes made to a frame unit are updated in the form in which the frame is used only after closing and reloading that forrm. Yes, this is very annoying and confusing, and is one of the reasons why I almost always insert frames at runtime. The IDE uses a LOT of frames (see folder ide/frames), and they are always inserted at runtime.
-
I suppose using dynamic frames could save some resources although I've never used them that way..
I kind of think of them as my Library controls stash without making a control..
I have very few frames. The ones I mostly use are for a menu entry that gets used in a lot of different ways but it keeps with the same format so the user does not get confused..
-
wp's post (reply #12) has solved the problem for me. I converted all my use of frames to the scheme wp showed: create frames only at runtime, and use a TNotebook component to contain them. For a month now they have all worked fine, with no recurrence of the problem I described at the top of this thread.
Many thanks to wp, Hero Member indeed!
L.