McScotty
Members-
Content Count
19 -
Joined
-
Last visited
Community Reputation
0 Neutral-
OK thanks for your time on this.
-
My question was that I thought setting PopUpParent was the same (more or less) as setting WndParent in the CreateParams. Clearly that is not the case but I really want to know why setting WndParent corrects a bug in the taskbar thumbnail that a standard Delphi application suffers from ordinarily if the dialog is not destroyed.
-
Yes sure. Example 1 is the one with the issue on the taskbar, run the code and click on button then OK dialog. hover mouse over taskbar and then the thumbnail image and you will see the closed (hidden) dialog is now visible, but will disappear again if you click on the thumbnail. Example 2 is the same code, but the dialog has been modified to override the create process by adding Params.WndParent:=application.Handle; Run the code as above and voila, no dialog is shown in the taskbar. Example1.zip Example2.zip
-
My understanding of the PopUpParent is that I can use it or I can use CreateParams and set the WndParent myself which results as the same thing. If I set the PopUpParent to the main form it appears correctly, but still suffers from the showing the dialog in the thumbnail preview. However if I use CreateParams and set Params.WndParent:=application.Mainform.Handle; This does not suffer from the issue with the thumbnails. Why is it behaving differently?
-
Maybe I am not making myself clear. In the properties of the dialog, I set PopUpParent := Form1, is that that what I am supposed to do? Not the main form. Regardless, doing this does not solve the issue that I have discovered,. The code I put in CreateParams does however.
-
Hi David. I did try setting popupparent to the main form, but that makes no difference either, but to be fair, it is a property that I have ignored, and actually thought it had to do with popup menu's until I looked into it. What I was referring to was that on each dialog window, if the creating is overriden by adding a CreateParams as follows, that seems to fix the issue, but I am unsure why, or if this is a safe way to get round the issue. procedure TOKRightDlg.CreateParams(var Params: TCreateParams);begin inherited; Params.WndParent:=application.Handle;end; I appreciate that closing down the dialog is a valid way to get round the problem, and if Embarcadero will not fix this in Widows 10, I am happy to live with a work-around. I can largely do this by freeing the dialog, but on some, I would prefer not to have to do it, as I never had to do it before on Windows 7. I am happy to put the above in the get round the issue if I can't or dont want to free the dialog, providing it is safe to do so. I would even settle for an option to turn of the live thumbnail preview of just my app, is that an option at all?
-
I have tried various application.mainform.handle and just application.handle To be fair I am a bit mixed up as it works differently in 10.3 than it does in 2007, not sure what way around it is, but either way, it certainly looks like it works. I would just like to know by doing so, it fixed the issue and is not likely to cause anything else to go wrong. Thanks.
-
Yeah that is entirely possible but I have only heard of it with Delphi apps. It might be there is a simple solution that can be invoked such as forcing the thumbnail to redraw, I am not aware how to do that but I would be interested in if its possible, and if it will be another work-around.
-
I have reported this to Embarcadero and I see that other people have reported similar issues back on 2008 and as yet still no fix or further information. Hopefully someone can comment on my possible solution and say if they think it is safe to do what I proposed as a possible work-around rather than having to release the dialog. Thanks everyone for your comments so far.
-
Thanks for your advice, as I said I agree that releasing the dialog will do the trick and I am able to do this easily on some of the dialogs, others I would prefer I could populate once and then re-use so I would have liked it if there was a solution. Perhaps it is the one I have already suggested myself, I just want to know that I am not doing something stupid that will cause issues later on. I wish the they had fixed this bug in 10.3 though, its not very good that this issue persists now that W10 has been around for a few years.
-
Well I agree destroying the dialog does indeed solve the problem, but it does not resolve the issue that has surfaced with Windows 10. I still stand by populating the combobox once for any instance of an application is better because you only need to populate once, not every time, regardless of where you get the data from. To me that seems like unnecessary processing.
-
It depends where the data comes from, connecting to a DB will take a bit of time and it depends on how much data you are getting in the first place. Also if you want a dialog to remember your last selection this is easy to do by simply not releasing the dialog. Also it avoids unnecessary processing, if you can do it once, that should be the best way to do it, rather than multiple times Anyway, this thread is about a bug that appears to be in Delphi since at least D2007 up to current version that is only exposed in Windows 10 and if/what are the possible solutions/work-arounds that can be achieved without having to release the dialog.
-
Indeed that is what I have been doing, by not releasing the dialog, and just re-using. However by doing so, this bug surfaces in Windows 10, hence the original question.
-
The downside is simply speed. If you have to fill a combobox with names for instance, doing this only once per application session is advantageous rather than destroying and having to fill the combo boxes again and again... So this appears to be a specific bug in Delphi regarding Windows 10 and no know official fix other than closing the dialog so it can't be used again unless re-created. If this is the official response, then it means there is little point in ever using the oncreate event in a dialog, which to be fair, I thought was the whole purpose of doing something only once, not every time you show the dialog. I have to say I am a bit disappointed that this is the case in 10.3 Rio. I can however understand why it happens in D2007 as it predates Windows 10.
-
The reason I use the OnCreate in some forms is to fill comboboxes with names from a database for example. I only want to do this once per invocation of the form so I just re-use the existing form rather than destroy it and having to go through the same process again every time I want to show the dialog. Is there a better way to do this that I am not aware of?