[ralfiii]

Creating applications with the MainForm having BorderStyle=bsDialog is problematic.

Sometimes AlphaControls mess up Z-Order and show child windows below main form, sometimes when you launch such an application it hides under applications that are already open.

That's nothing dramatic, simple fix: Use bsSingle instead.

Just wanted to mention in case somebody is having the same problem…

[ralfiii]

Oh, just realized that the workaround doesn't help.

I'll create a demo-app for that problem soon…

[ralfiii]

Ok, the border doesn't seem to be related to the messed up Z-Order.

It seems the problem was that the mainform had FormStyle=fsStayOnTop.

In my problematic case the program starts up with the main form hidden. (so it sits in the try area)

When something happes (e.g. a timer fires) the mainform and an additional info form is show.

Basically like that.

Code:

procedure foo.OnTimer
Show;
TfrmAddInfo.Create(self).ShowModal;

And then the main form (that had the AlwaysOnTop-property set) was then shown on top of the child-form until you clicked the child form for the first time.

And that not always but only when the PC was a bit stressed.

Unfortunately under that circumstances I can't generate a demo app.

[DarrenB]

Hi ralfii,

a while ago I had a similar problem that randomly a main form plus a couple of child forms (not AlphaSkins related) with AlwaysOnTop (fsStayOnTop) set would show issues similar to what you describe. It was driving me crazy as it didn't happen all the time…some times it wouldn't happen for a day of programming and then maybe only one or two times, then six times in a row etc….! I had a few timers working doing various stuff in the background. Didn't seem logical cos it wasn't consistent. Anyway, I just left it cos I couldn't figure it out…reading your post I see you mention that the child forms stay behind the main form even tho they shouldn't…until you click on the child form and the z order is resumed. I was just thinking if maybe during your form initialization process you could use delphi to simulate a mouse click to the child form programatically? This would, in theory, achieve what you have to do manually with the mouse…and if you hardcoded it into the parent form startup process then it should, in theory, get rid of the random effect? And in cases where the random effect didn't occur…a simulated mouse click to the child form shouldn't hurt the 'normal' process. I don't know…just firing an idea out there I guess it would need finessing.

[mol]

Darren, does this help?

http://stackoverflow.com/questions/3549119/how-to-make-sure-a-dialog-is-always-front-of-the-main-window

[DarrenB]

'mol' wrote:

Darren, does this help?

http://stackoverflow.com/questions/3549119/how-to-make-sure-a-dialog-is-always-front-of-the-main-window

Hi mol,

thanks for the link…never knew about PmExplicit at all or what it did!…added it to my old app, it certainly didn't hurt anything, and tested it for a while…looks good so far will randomly test it out further over the next few days.

Went here

http://blogs.embarcadero.com/abauer/2004/02/10/295

to further read up on it….it sounds like it's ideal as my 'problem' forms were all essentially 'floating tool windows'. Thanks v much 🙂

[Author]

Posts