I have a problem, I have a TabBar application with 3 tabs, at the start of app if I try to change tab (only on specific tab) the changing is a bit slow, after the first time all is fast, how can I check the time of specific process (method) for find the problem?
Related
OK, I get it: focus stealing is evil. Or at least it is 99.9% of the time. But I really need to steal the focus reliably on Windows 8, and so far I'm thwarted by the hordes of people insisting focus stealing is always evil.
Scenario: we run a custom application on an ordinary PC running Windows 8.1 (soon to be Windows 10). The screen, keyboard and mouse sit roughly 5m off the ground up some stairs that the forklift operator really shouldn't climb. The one input device they have is a numeric keypad on an extender cable down at their level. Everything they need to do they can do from that keypad... so long as some evil program hasn't stolen our application's focus, or some remote user hasn't logged out and left another application with focus.
The application is essentially a maximised desktop application - it fills the screen (but is not strictly a "full screen" or "topmost" application), and therefore allows other applications to appear in front of it when required. But when the mouse goes idle, we want this application to resume its "normal" position in front of all other applications so that it gets focus and the numeric keypad input will work reliably.
On Windows 7, using SetForegroundWindow() (enabled by AllowSetForegroundWindow() works fine - the application can be brought back to the front and resume focus. On Windows 8, SetForegroundWindow() only results in the taskbar icon flashing, but the application does not regain focus, forcing our user to climb the stairs... where the full keyboard and mouse is too tempting for them not to press buttons they shouldn't, and chaos typically ensues.
So please sir: can our (MFC, desktop) application steal back the focus once the mouse has gone idle for 1 minute, because it is more or less the only application that should normally be running anyway. If that is permitted, how do we steal it reliably?
Configure hotkeys on numeric keypad (RegisterHotKey).
Pressing a registered hotkey gives you the foreground activation love by Raymond Chen
After you call the RegisterHotKey function to register a hotkey, the
window manager will send you a WM_HOTKEY message when the user presses
that hotkey, and along with it, you will get the foreground love. If
you call SetForegroundWindow from inside your hotkey handler, the
foreground window will change according to your instructions.
Possible solution (with major limitations): do nothing extra; wait.
One of our service technicians observed that on the third or fourth attempt to regain focus using AllowSetForegroundWindow() and SetForegroundWindow() as had been working on Windows 7, Windows 8 finally allowed our application to regain focus. It is not clear what the conditions are that make this work, or if it works reliably, but we have now observed our application regaining focus from beneath Chrome, from beneath another (self-developed) MFC application, and from beneath a third party application - all desktop applications. Approximately 3-4 minutes needed to elapse in each case before focus was surrendered back to our (desktop) application.
However, we have not witnessed it regain focus from beneath metro applications, and nor do we expect it (e.g. hit the Windows key and leave the system lingering on the Start screen).
In our (restricted) situation, we are willing to take the gamble that our users will not launch a metro application that obscures our desktop application, at least not without restoring our application, since their business relies on it. Our main concern is that one of our busy service technicians will log in remotely, get distracted, and carelessly leave one of our desktop utilities with the focus. Waiting 3-4 minutes appears to be a solution to this specific scenario.
I would try it in this way:
Setup a timer in you application. That checks GetForegroundWindow on a regular basis.
If GetForgroundWindow does not belong to your process (GetWindowThreadProcessId)
If a different process onws the foreground window use AttachThreadInput and attach your input queue to the input queue of the other process.
Now use SetForegoundWindow and detach the thread input again.
Now you can use SetFocus as needed to control the input focus of your program.
Is it possible to alter the layout of the tool-bar icons?
The 'Continue' icon is right next to the 'Stop Debugger' icon, which is a really bad design and I've lost count of the number of times I meant to click continue but have accidentally clicked on the 'Stop Debugger' icon.
To my knowledge it is not possible to rearrange the buttons in the current build.
You have two options:
Build Qt-Creator (or at least the "Debugger Plugin") from Source, and change the UI to your liking.
Open a feature request on https://bugreports.qt.io/ and convince enough people to vote it up.
Consider using the keyboard short cuts. If you can't use a keyboard, consider using the fat "Run" button on the left bar which becomes a Continue button when stopped. This is ~300 pixels away from anything that could Stop debugging.
I have a MFC application (Visual Studio 2010) which dynamically creates and destroys lots of editboxes, drop-down boxes, and buttons, based on the user's consequent input.
I used "Create" function to dynamically create controls, and when deleting controls the system first calls "DestoryWindow" function for each control, and then delete each control pointer.
After iterating certain amount of creating/deleting controls, if I try to "open" the dropdown menu, the system fails to open it and stops responding to my input - but I can add more controls, if I do not try to open the dropdown menu.
Could somebody please let me know how to workaround this strange issue? This one nearly drives me crazy...
Workaround is simple - don't try to "open" that menu :)
Now I assume that you want to FIX the issue. Then you need to figure out what is going on. The system may be non-responsive for multiple reasons, most likely one of these two:
You are in a busy loop in your main UI thread.
You are waiting for an event that never happens. Deadlock, for example.
When your application is frozen, try to attach debugger to it and do Debug -> Break All. Then see what code is executing. If the reason for this "freeze" will not be obvious, please post relevant code.
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.
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.
This is a weird question. I have written a .NET application that starts a process. This process is a MFC application written in c++. For some reason the process does not start doing anything until the form is displayed to the user for the first time. For example, if the process starts minimized I have to un-minimize it (click on it) before it will start doing whatever it's supposed to do. Also, if my application is running and starting this process while the screen is locked the process behaves the same as if it's minimized. It doesn't start doing anything until I unlock the screen and it is displayed to the user for the first time. Like I said, this is a weird question so I hope I'm conveying the problem properly.
Sounds like your functionality is embedded in MFC Windows' load event. If you want the application to be more reactive, move that code to your application class.