-1

EDIT:

This question isn't about briging a window to the front of EVERYTHING, just for my specifc application. I'd like the frame they were interacting with to be behind the new frame. Much like a dialog, except that it is not a dialog. I don't think this is bad practice, something was summoned (in this case via a menu) I expect it to be infront of the window I used to summon it.


I just read How can I ensure that a wxFrame is brought to the foreground? and that didn't work either.

SetFocus(); makes the window want my attention (it flashes in my task bar in the case of my platform, GTK and MATE task bar if that matters)

Raise(); does.... nothing

Show(); shows it, obviously, but despite it's newly created status nothing happens.

Weirdly clicking the window doesn't bring it to the front until after I have done something in the parent despite showing as the thing I am interacting with in the task bar. I am using all the 3 of the above (Show, SetFocus then Raise).

I've read Raise's documentation ( http://docs.wxwidgets.org/trunk/classwx_window.html#a54808c933f22a891c5db646f6209fa4d ) Raise and Lower are "z-order functions" - this suggests that it's supposed to do this. I have never really had much success with it though. I'd be really really nice if the starting frame came to the foreground whenever I run for example, but given the amount of times I press run and the project is built compared to the amount of time spent writing code and the fact creating a new folder even is more frequent, I've put up with it.

It'd be nice to get it fixed!

Addendum

Using Lower on the parent hasn't worked. There will be 64 less a few obvious ways to try this, I really want to avoid stumbling about.

Community
  • 1
  • 1
Alec Teal
  • 5,770
  • 3
  • 23
  • 50
  • Your question is very confusing. What exactly are you trying to do? What actually happens? Where is the code? I suggest you rewrite question so the answers to these questions are clear. ( Oh, and remove all those edits and addendums where you keep changing your mind! ) – ravenspoint Jan 04 '14 at 16:22

1 Answers1

0

I believe ravenspoint, and this is not a good user interface trick, but, if you don't mind a little bit of flashing... and stealing of focus, regardless of where you may be typing, etc, etc, just kinda bad...

ParentWindow->Iconize(false); // restore the window if minimized
ParentWindow->SetFocus();  // focus on my window
ParentWindow->Raise();  // bring window to front
ParentWindow->Show(true); // show the window

And before you do, think about another critical application running with

"Enter the counter measure launch code, impact in 12 seconds: "

and half way through typing, your window decides to pop to the top.

Brian Tiffin
  • 3,978
  • 1
  • 24
  • 34
  • Please see the edit, I desire to raise a frame above it's parent (the thing the user was using to summon this new frame) not in front of everything! Is that bad practice, I've thought nothing of it, perhaps I should stop avoiding "modaless dialogs" and work out what they are? – Alec Teal Jan 03 '14 at 23:28
  • You may need to duplicate a couple of the calls to both child and parent. Without looking, iconize(true) both parent and child, iconize(false) to both, then onlt on child, setfocus, raise and show. This is guaranteed to cause screen flash as windows are iconized. p.s. not an expert, this function advice may be wrong, and is **definitely going to frustrate users**, somewhere, sometime. Far better to reserve a status bar, or area, then to allow popups. If this is only by request, then that sequence using both parent and child should work. _being not expert, high chance of advice fail_ – Brian Tiffin Jan 03 '14 at 23:44