Forum > General
Strange form behavior
dg4fac:
Hi.
In my project I use a form, that is switched to show and hide, depending from another form. So far that worked perfect.
But now, after some changes to the code, this form shows a really strange behavior: it opens, but it doesn't react on mouse-clicks any more. If I click on the form, a sound appears, and the mother's form, that owns and controls this form, toggles. It is just looking like that the form does not receive and treat windows messages any more (which it did before). Changes to the content of the window that the program initiates are correctly displayed, but the window is untouchable for the user.
I have been going through all properties of the form, but no changes helped.
I added the properties as a picture in the attachment.
If necessary, I can pack the whole code into a zip and upload it to one of my webpages. And I have made a video of that strange behavior.
How can I find the reasons for this? Are there any tools that I can see the windows events with?
I am working on Win10 and with Lazarus 2.2.0. Any hints are very welcome.
brgs, gsc
jamie:
Looking at a couple of things here.
If you are showing any form in MODAL form then showing other forms will block input.
so using ShowModal and Show are different.
If that isn't what is happening then maybe it's your use of some sort of unit/package that depends on the window's handle and if you are changing the border style property then the window's handle gets change too. That in itself is a problem in the widget but as I see it that will never get corrected so you will need to reset any code with the new window handle in that case.
dg4fac:
Hi Jamie,
--- Quote from: jamie on April 30, 2022, 02:30:41 pm ---Looking at a couple of things here.
If you are showing any form in MODAL form then showing other forms will block input.
so using ShowModal and Show are different.
--- End quote ---
Yes, I know. I use Show and not ShowModal. I have a number of similiar child windows that I hide/show with checkboxes, but this only happens with one form, all the others behave absolutely nomal and as expected.
--- Quote from: jamie on April 30, 2022, 02:30:41 pm --- If that isn't what is happening then maybe it's your use of some sort of unit/package that depends on the window's handle and if you are changing the border style property then the window's handle gets change too. That in itself is a problem in the widget but as I see it that will never get corrected so you will need to reset any code with the new window handle in that case.
--- End quote ---
No, that is all standard. And it worked fine before I made some minor code changes. So it seems I have to re-build the complete form from scratch. Three or four hours of work.
brgs, gsc
MarkMLl:
--- Quote from: dg4fac on May 01, 2022, 11:54:06 am ---No, that is all standard. And it worked fine before I made some minor code changes. So it seems I have to re-build the complete form from scratch. Three or four hours of work.
--- End quote ---
I've seen something like this. I was converting Delphi code which originally had left control in the main program's initialisation section (to get typed-in commands while all the event-driven GUI stuff worked normally) and got into deep water... I can't remember the exact details but check (a) that you're not reentering an APM and (b) that you've not got a never-exited loop in an idletimer.
Oh, and set yourself up a local copy of Subversion.
MarkMLl
jamie:
using the Application.Processmessages after initiating a form change, display or what ever can cause it to get hung up in limbo because the messages haven't yet arrived to the form for window change states.
I only say this because looking at his example displays of OI's I see something that looks like IO reading and thus is tempting to use the that closed loop method.
Navigation
[0] Message Index
[#] Next page