Hopefully a simple question: I'm making a timer-style application, and I'd like the application to regain focus when the timer ends. The application successfully pops back up when the timer ends, and I can even see a blinking cursor in the first text box, but when I type something it still goes to the app behind it. I've tried every method I could find in the electron documentation (listed below), and none of them work. Is there another avenue I'm missing, or is this just not possible?
Object.values(windows).forEach((window) => { // windows here stores all the application's BrowserWindows
window.focus();
window.focusOnWebView();
window.webContents.focus();
});
app.focus({ steal: true });
Thanks!
I tried all the documented methods as well and nothing really works (at least in Windows 10).
To bring the app on top I have to toggle AlwaysOnTop like this (renderer process):
let currentWindow = window.require("electron").remote.getCurrentWindow();
currentWindow.setAlwaysOnTop(true);
currentWindow.setAlwaysOnTop(false);
but unfortunately it doesn't help with the app focus.
People say that BrowserWindow::restore() function correctly sets focus back to the app. So you might do something like this (although it looks terrible):
currentWindow.minimize();
currentWindow.restore();
It is interesting that I have a similar problem in my other C++ project, so probably it is something OS-related. To solve the problem in the C++ project I had to call SetForegroundWindow function after activating the window. Since ElectronJS BrowserWindow has a getNativeWindowHandle function that returns Windows HWND handle, maybe you could utilize this if nothing else works.
Good luck!
Related
Good morning, in my application on MacOSX I want to give the user the option "minimize to tray". I use Qt5 and I rewrote the
changeEvent(QEvent *event)
function. There I do something like
switch( event->type() )
{
case QEvent::WindowStateChange:
{
if ( this->windowState() & Qt::WindowMinimized ) {
if( *option minimize to tray enable* ) {
event->ignore();
QTimer::singleShot(0, this, SLOT(hide()));
}
}
break;
}
default:
break;
}
Well, it works on Linux and Windows but the problem is that in MacOSX this code does not work properly and creates a bug. Indeed the window is still minimized in the taskbar (apart from the dock) and furthermore, if the window is resized from the taskbar instead of the tray icon, the GUI is blocked and does not change. The GUI can still send signals but it can not change. I have to reshow the window from the tray icon to unblock the GUI.
Then the question: How can I avoid to minimize the Window in the TaskBar on MacOSX?
Another related question: I have read some forum where some user speaks about a "standard behaviour" in MacOSX, as for example not to close the application when the "x" button is clicked, or not to use tray icon ecc. ecc.... Someone can post a official link how an application should behaves in MacOSX?
Thanks very much to everyone
Well, I don't know Qt, but I know Cocoa quite well. Speaking in terms of the Objective-C API, your hide() call is probably doing the equivalent of -orderOut:. Unfortunately, -orderOut: doesn't work properly for minimized windows. It leaves a "ghost" window in the Dock, which can be unminimized to an actual ghost window. That is, it's just an image of the window, it's not the actual live window.
It does work to call -close. I don't know what the Qt equivalent would be. You have to be careful to avoid some of the secondary consequences that -close has beyond those of -orderOut:, though. For example, some windows are set to release themselves on close, which you'd want to disable. Also, the window delegate's -windowWillClose: method will be called and it should do nothing for a not-really-closing call.
Don't worry that "closing" is more severe or permanent than "hiding" or "ordering out". It's really much the same thing, other than the above-mentioned additional consequences. For example, it is still possible to re-show a window that's been closed, etc.
The question is, does Qt give you the flexibility to do it. Alternatively, this can be considered a bug in Qt, that its hide() implementation uses -orderOut: rather than -close on minimized windows.
Finally, I'll ask if you really want to implement this feature. It's going to confuse users. When you minimize a window, it animates the minimization to the Dock. That gives the user a strong impression of where to find the window. If the window is not subsequently found where it went, the user is not going to know to look elsewhere. Likewise, Exposé/Mission Control shows users the minimized windows of an app in addition to the normal windows. Your supposedly minimized-to-tray windows won't show up there because they're no longer really minimized.
Perhaps just disable minimization. Have the user simply close the window when they're done with it and re-open it from your status item menu.
I have a friend who's working at a company that offers pretty poor support for its developers (scoring a 1/12 on the Joel Test).
Their build process is locked down pretty tight, and depending on the size of project it could take 40+(x2) mouse clicks to deploy. So I thought, "Hey, why not automate it the clicks using the win32api?" (Specifically using Python). I've got him a real nice tool that works just fine except for one issue - the tool that they use has a navigation pane that may or may not be open.
You can open and close it with a button press, but I'm not sure how I could make sure it was either open or closed. It's irrelevant to the build process - the only problem is that it alters where the mouse needs to click on the screen depending on its open status. The application is written in .NET and it exposes a function call that applications are able to use to toggle the panel, so I've been looking around for ideas and so far I've got two of them:
Attach to the process via a debugger and execute the function call somehow.
Take a screenshot at the location of the panels titlebar (which I've got through the win32 API and doesn't appear to change regardless if the panel is hidden or not).
Is there an easier way to figure out the state of this panel? The developers are given an admin account on their machine in addition to their regular account, so I can entertain ideas that require admin access, though I don't think that should be necessary?
UPDATE:
It looks like there's a button that can close the pane. In UIAVerify something shows up as "text" "Navigation" "btnClose". It says its AutomationId is btnClose but it's a ControlType.Text
What technology is this panel built from? Is it standard GDI or WPF? If its GDI, it should have a HWND. You should be able to find this HWND through either a class name or window title. Once you have the HWND, you can get its width.
If its built with WPF, er, I have no idea, but Snoop does this kind of thing, so I know its possible.
i am using the createdesktop api to create a desktop and i would like to take a screenshot or send input mouse/keyboard without dispalying the desktop to the user.any ideeas on how to implement this???
The short answer that I've found is that you can't. You can't take a screenshot of an inactive desktop because there are no paint calls because there are no visible windows to redraw.
You can do a SwitchDesktop() call, screen shot, then SwitchDesktop() back. The user won't notice it, but you likely won't get much in the screen shot because in this short time the windows haven't had time to redraw.
Another thing is, you have to make a new thread to call SetThreadDesktop(). If you use your main thread to do so, it will fail when using a GUI application. SetThreadDesktop() fails when you have a window in the current desktop.
SysInternals has an application to manage multiple desktops (like the linux desktop switch). When your about to pick a desktop to switch to it will show you a thumbnail of the desktop. This thumbnail is not live, it is captured by the last known full redraw when the user is in that desktop. In short, if SysInternals can't do a live screenshot I doubt any of us will.
This is of course based on my own research of this exact feature. If someone has actually gotten it to work I'd love to know so I can't use it too!
Edit: This won't work for invisible desktops, I've looked to my old code, and I see that I needed that for catching screenshot of active desktop (which was not 'WinSta0\Default'), to get handle of active user desktop I've used OpenInputDesktop.
+1 ThievingSix you are right.
Sorry everyone for my misunderstanding.
You need to use SetThreadDesktop (if you are creating desktop by CreateDestkop, then you have handle for it which you pass to SetThreadDesktop). After switching desktop for thread, you can catch screenshot. Good idea would be revert to previous desktop for thread (to not 'break' other/future code).
var
lOldDesktop: HDESK;
begin
lOldDesktop:= GetThreadDesktop(GetCurrentThreadId);
try
if not SetThreadDesktop(ADesktop) then // pass handle to your desktop, or dekstop handle obtained from OpenInputDesktop
{error handle, like RaiseLastOSError or Exit(False)};
// your screenshot/input/mouse code here
finally
if lOldDesktop<> 0 then // GetThreadDesktop can fail (I don't know condition when this GetThreadDesktop(GetCurrentThreadId) could fail)
SetThreadDesktop(lOldDesktop); // revert thread to previous desktop
end;
end;
This code should run in non-main thread, as ThievingSix pointed because SetThreadDesktop can fail in that case. Safe way is spawn thread to make screenshot.
PS. I'm not sure if this will work with "send input mouse/keyboard" (it should), but for screenshot works.
Edit:
More on sessions, window stations, desktops here http://blogs.technet.com/b/askperf/archive/2007/07/24/sessions-desktops-and-windows-stations.aspx
Desktop tool (SysInternals) - http://technet.microsoft.com/en-us/sysinternals/cc817881
I don't really know where to begin. Let's start with the stupid questions:
What language should I use for this? What is suited for the task at hand?
Next, the real ones:
Is there a way to stop the screensaver from starting, short of changing the cursor position? If not, will changing the cursor position even work?
SetThreadExecutionState will prevent the screensaver from coming on or the machine from automatically going to sleep if you pass the ES_CONTINUOUS and ES_DISPLAY_REQUIRED flags.
I wrote an app awhile ago that does exactly what you are asking for. It runs as an icon in the System Tray, not the Taskbar, and uses a global message hook to disable the WM_SYSCOMMAND/SC_SCREENSAVE notification from reaching any applications. If that notification does not reach the DefWindowProc() function, the screen saver will never run.
Your program does not need to be visible in the task bar at all.
You don't even need a program at all, if you can disable the screensaver in the registry.
What you want to do can perhaps be achieved by sending a MOUSE_MOVE event to the desktop window. If you want to use C# (the only language I am current with right now), you can look at this article, but maybe a simple C program using the WinAPI is better suited for this task.
.NET will easily allow you to put an application in the system tray (checkout the NotifyIcon object in System.Windows.Forms.Controls).
I believe you can use the SetCursorPos (http://msdn.microsoft.com/en-us/library/ms648394(VS.85).aspx) API call to prevent the screen saver, just make sure you set them to the current location so you don't actually move the mouse.
I've got two applications I'm developing using Qt on windows. I want the user to be able to press a button in one application which makes the other application come to the foreground. (The programs communicate using QLocalSocket and named pipes.)
Currently I'm using Qt's QWidget::activateWindow() which occasionally brings the application to the foreground, but most of the time it just highlights the program on the taskbar.
Can someone please tell me how to do this, preferably using Qt although failing that using the WIN32 API would be fine.
Unfortunately, I couldn't find a way to do this only with Qt. I solved it using Chris Becke's suggestion of calling SetForegroundWindow from the currently active application.
Are you sure this is not a debugging issue? The deal is, if an application HAS the foreground, it is allowed to change the foreground.
Clicking a button on window A will give that windows thread foreground activation. If it calls SetForegroundWindow (or equivalent) on the other window, that window WILL be given the foreground.
If, on the other hand, it simply sends a message to the other app, which tries to SetForeground on itself, that will fail. AllowSetForegroundWindow is used in situations where a 'legacy' app needs to be given permission - by a foreground app - to take the foreground. Once again, AllowSet... only works if called from a thread that owns the current active foreground window.
On top of the QWidget::activateWindow method, you should call QWidget::raise !
This is what is said here.
I have a similar case.
I have two Qt applications, A and B, which communicate on a socket.
I would like to bring a window of application B up, through a button on application A.
I found that sometimes the widget state is not set correctly, so in the event() function of my applicatons B's widget I did the following:
bool MyWidgetB:event ( QEvent * e )
{
QEvent::Type type = e->type ();
// Somehow the correct state of window is not getting set,
// so doing it manually
if( e->type() == QEvent::Hide)
{
this->setWindowState(WindowMinimized);
}
else if( e->type() == QEvent::Show )
{
this->setWindowState((this->windowState() & ~WindowMinimized) |
WindowActive);
}
return QWidget::event(e);
}
I'm sending a command from application A to B. On receiving it, application B calls the following function on itself:
void BringUpWidget(QWidget* pWidget)
{
pWidget ->showMinimized(); // This is to bring up the window if not minimized
// but beneath some other window
pWidget ->setWindowState(Qt::WindowActive);
pWidget ->showNormal();
}
This works for me, on Windows XP, with Qt 3.3. My MainWidget is is derived from a QWidget.
I have found this is also working with a widget derived from QMainWindow, but with some issues. Like if some other child windows are open.
For such a case I store the position of the child windows and hide them, then use the BringUpWidget function to bring my MainWindow widget, and then restore the child windows.
This is kind of cheesy, but it works for me:
this->setWindowFlags(Qt::WindowStaysOnTopHint | Qt::FramelessWindowHint);
this->show();
this->setWindowFlags(Qt::FramelessWindowHint);
this->show();
Or, if you don't have other flags,
this->setWindowFlags(Qt::WindowStaysOnTopHint);
this->show();
this->setWindowFlags(0);
this->show();
WindowStaysOnTopHint will almost always force the window to the foreground. Afterwards, you don't really want the window to always stay on top, so reset to whatever the previous flags were.
I think the APIs you need are AllowSetForegroundWindow() and SetForegroundWindow(). I don't know what the equivalent Qt calls are.
Use showNormal() to go from an iconified state to a visible state.