Wrong work with focus?

[p.n.a]

Hello.

 

If i start "imgburn" from my program using command line (i try to burn iso image), it shows "title"(where we choose actions type) window foreground, then you destroy this window, and start "working"(with progresses, device combo box, e.t.c.) window. But initially main window of my programm is foregroung (and maximized),

and when you create "working" window it turns out "under" my window = i do not see you working window.

 

Maybe, the reason is that after you destroy your tittle window, Windows looking for (and find main window of my program) any other window and set focus to it.

When you create your "working" window , Windows does not set it foreground (it lies under my main window).

 

I think, for proper work, you can change call sequence: first you must create "working" window, after - destroy "tittle window".

 

Thank you.

Good luck.

[LIGHTNING UK!]

It's all the same window.

[p.n.a]

Ok.

But, you create first "greeting"(window with words "Imageburn loading...please wait..") window, it plays (you can change "title" window for "greeting" window in my previous post) the role of ''tittle" window in my previous post.

[LIGHTNING UK!]

That would defeat its very purpose.

 

It's shown whilst the other forms are being created.

 

If I start the program from a maximised DOS box I don't see any problem with the z-order. ImgBurn is the foreground application and its windows are completely visible.

[p.n.a]

The feature is that we do not know which window get focus (from Windows) after you destroy your "greetin window". This is absolutly unpredictable!

When you destroy "greeting" window and after (instantly) create "working" window, Windows think whom to give focus. If Windows choose your window it will be foregraund, if it choose mine window first, your window will be under mine main window. That is why it can works with any (mine or DOS's) windows, correct (if Windows choose your window first) and incorrect (if Windows choose mine or DOS window first) a. Unfortunatly, it is specific of Windows OS.

 

To solve this proplem (if you want) you can ,as i said, create "gretting" window....after create working window, and (instantly) after destroy "greeting" window.

 

Now, you do (as i thing:)) this: create greeting window...then (when working is prepared) destroy greeting window and after(!) create working window.

[LIGHTNING UK!]

The main window is actually shown before the splash screen is destroyed.

 

Are you sure the issue isn't just with your app? There are lots of apps that call on ImgBurn and I've never heard about or seen this problem until you just mentioned it.

[p.n.a]

I'm not sure 100%...but there were such problems before...Meybe i'am wrong...

 

"splash window" = greeting window?

As I understand, you destroy "greeting" window ....and after create main window?

[LIGHTNING UK!]

Here's the current order of things... (oh and remember this is a Borland program with its 'hidden' window)

 

1. Create and display the splash screen (the 'loading... please wait' one)

2. Create some global lists, critical sections etc for use in the program

3. Create the forms that aren't created as and when they're needed

4. Show the main form (this should then be the foreground window, receive focus and be 'active')

5. Destroy the splash screen

6. Continue running the program.

 

I've never had a case where the program has loaded behind any other application.

 

My development environment runs in a maximised window and I must have had it 'Run' ImgBurn tens of thousands of times now.

[p.n.a]

Ok. Thank you.

[p.n.a]

ps: I do not know what may be wrong with my app now....becouse I just call CreateProcees(...) and do nothing (do not interact with interface etc) after...

[LIGHTNING UK!]

I assume you're using 'SW_SHOWNORMAL' in the StartupInfo structure?

 

Does the same thing happen if you use ShellExecute instead of CreateProcess?

[p.n.a]

It does not work with/with out WS_SHOWNORMAL.

But it starts work CORRECT, if a call WaitForinputIdle(hProcess,8000) after CreateProcess(...).