HI
I have an application written in Delphi 2006. I have noticed that when running under windows 7 the application does not receive the WM_SYSCOMMAND message from Aero Shake. However if I run the application as administrator then it does receive the WM_SYSCOMMAND when performing Aero Shake.
I've tried calling ChangeWindowMessageFilter for WM_SYSCOMMAND and get a result of True indicating that the call succeeded but I still can't get the WM_SYSCOMMAND message frmo Aero Shake.
Does anyone know why and how I can fix this?
Thank you
This discussion of the behaviour of AeroSnap/Shake in the presence (or otherwise) of MOVE message handling and/or specific window frame styles may provide some assistance.
I've solved this, in order to get the WM_SYSCOMMAND message you need to elevate the application to at least highestAvailable using an application manifest. After doing this everything works perfectly except that you now get the elevation confirmation dialog when starting the application.
Related
The hotkeys for doing so are:
Alt+Shift - Windows 7 and Win button + Space in Win 8 and 10.
Programmatically I can do that using WM_INPUTLANGCHANGEREQUEST, but it is not the way Windows does that. I am trying to figure out how Windows changes the layout. Using spy++ I figured out that Windows sends WM_INPUTLANGCHANGE message which is changing layout, so I tried it myself:
SendMessage(myHWND, WM_INPUTLANGCHANGE, 0xCC, 0x4190419);
I have keyboard hook bind, when press f1 do the sendmessage to currently active window's active control.
but it didn't work, though the messages in spy++ are thes same:
first one using "Windows hotkey"/"Taskbar" to change layout, it works. Second my message, it did not work. Am I missing something, why message works for "Windows" but not for me.
The WM_INPUTLANGCHANGEREQUEST works, but it freezes some certain apps, and I would like to figure out the way Windows does the layout changing to avoid that.
-- update.
In DxO Photolab 3 it freezes when using WM_INPUTLANGCHANGE in "Export to Disk" Dialog:
When you change layout using "Windows" Method(Keyboard Hotkey/Taskbar):
Works normally, no freezing.
Posting the WM_INPUTLANGCHANGE:
Received the WM_INPUTLANGCHANGEREQUEST and froze:
Also similar freezing I've seen in Skype, MS Office, Adobe After Effects.
From WM_INPUTLANGCHANGEREQUEST,
When the DefWindowProc function receives the
WM_INPUTLANGCHANGEREQUEST message, it activates the new input locale
and notifies the application of the change by sending the
WM_INPUTLANGCHANGE message.
We can view the details through spy++.
Only after the application receives the WM_INPUTLANGCHANGEREQUEST message, it will activate the new input locale, and notifies the application of the change by sending the WM_INPUTLANGCHANGE message.
A simple test:
According to my understanding, what actually works is the WM_INPUTLANGCHANGEREQUEST message, but I have not found an alternative API to complete its work.
For the freezing problem of some certain apps you encountered, I found some similar cases.
Refer #Barmak Shemirani's answer,
Apparently WM_INPUTLANGCHANGEREQUEST fails if the target itself is a
dialog based application (I don't know why!) To solve the problem you
can post WM_INPUTLANGCHANGEREQUEST message to dialog's descendants (in
addition to WM_INPUTLANGCHANGEREQUEST message to the dialog itself)
Updated:
My test code:
#include <Windows.h>
int main()
{
HWND hwnd = (HWND)0x00070EBA; // hwnd of skype
while (1)
{
Sleep(1000);
PostMessage(hwnd, WM_INPUTLANGCHANGEREQUEST, 0, 0);
}
return 0;
}
Result:
I did some googling on this and only found this link Stack Overflow Link which discusses what causes the Socket Notification Sink error.
The application environment is currently Win2003/VS6.0/MFC/C++ we are migrating to Win2012/VS2013/C++/?MFC? (I use question marks as I am not directly involved in the GUI implementation and don't know the roadmap).
In my case I work with one or more applications that for some reason have crashed. This will generate from 1 to 300 "Socket Notification Sink" dialog boxes that must be individually dismissed before recovery can begin.
I am looking for some recommendations:
Methods to clean up on crash to prevent the dialog from occurring.
Methods to instruct the Windows runtime to not generate a dialog box on
error. Redirect errors to a log or error console.
Method to dismiss all the error dialogs with one mouse click/Keystroke
I think this is what you're looking for:
Windows has a registry setting called error mode that controls how the system presents errors to the user. You can use it to have the system skip popping up the dialog box and instead write the information to the event log.
See my answer to this question.
You can also set ErrorMode for your program in code using the SetErrorMode API.
This affects only your program.
I have an ATL app where I want to handle WM_POWERBROADCAST. I have a CMainDlg (CAxDialogImpl) in whose MSG_MAP I defined the handler.
BEGIN_MSG_MAP(CMainDlg)
...
MESSAGE_HANDLER(WM_POWERBROADCAST, OnPowerChange)
...
END_MSG_MAP()
However, the handler isn't invoked when I do things that should invoke it, for instance change power settings or put the machine to sleep.
Any ideas about what might be going on, and how to fix this? Does CMainDlg not get notified of power events, for some reason?
I suspect your dialog not being a top level window (WS_POPUP styled).
Just tested with a WTL AppWizard non modal dialog app that WM_POWERBROADCAST is received (without any registration) on AC plugged/unplugged.
Did you register to receive the power events?
To add to answers above, you might want to use Spy++ tool to make sure the messages of interest are posted to your application in first place. You will also see which windows they are posted to, and if it is your window where you are waiting for this message.
I want to receive a notification in my C++ application when a screensaver is about to start. I tried listening to WM_SYSCOMMAND messages with wParam == SC_SCREENSAVE which some people think should do the trick.
That didn't work. Spy++ even showed that my window didn't receive any WM_SYSCOMMAND message. Interesting thing is when I turned off the monitor I did receive the message with wParam == SC_MONITORPOWER. Am I understanding it wrong? Or did I just miss something?
Edit: For testing I used the default windows screensaver (the one with windows logo).
It appears that I will receive the SC_SCREENSAVE message only when my window has focus. The way around this is to set global hook. That would require me to put the callback function in a separate DLL and there is also this scary message about hooks slowing down the system so I decided to drop the idea of responding to screensaver start.
This is a relatively complex task (although it would be nice if it were easy).
Some of these tests you'll find online only work if your window is in focus. If it's running in the background it may not receive such messages.
Other tests rely on a screensaver program running (check the currently set screensaver, and then watch the process list to see if it's active) but don't work if you go into powersave mode, or if your screensaver is a black screen (ie, no program, just monitor off).
I don't believe there's an ideal way to do this. You might want to go back to the beginning and think more carefully about why you need to detect this state, and what you are trying to accomplish. You might need a different solution.
Probably my answer comes too late.
The MSDN handles screensavers under "Legacy".
On a notebook they waste battery and on a PC they are also useless.
It is better to turn the monitor off than letting it show a screensaver.
As you don't explain exactly what you want to do I don't know if you really need the notification BEFORE the saver starts or if it is enough to get notified when it already has just started.
In the latter case it is easy.
Write a thread that periodically checks:
BOOL b_SaverRunning;
SystemParametersInfo(SPI_GETSCREENSAVERRUNNING, 0, &b_SaverRunning, 0);
We have a service that launches an application that will interact with the logged on user. The application we launch is always run as a specific user for which we have the credentials. We do what is necessary (get active session ID, logonUser, adjust token) and launch the application with CreateProcessAsUser in the winsta0\Default desktop.
Everything is working fine if the color scheme of the Vista PC is Aero - but under the basic and classic color schemes, the application is still launched but none of the windows are painted. There is a new task on the taskbar. If you minimize a window which was in the background and in full screen, then you can see the contour of our ghost app - you can move it around, it will respond to keyboard/mouse input just fine. It's just invisible, not painted.
Does anyone has any idea of what could be happening? Why with the Aero color scheme it's fine but not in the others?
Thanks for any help,
Frank
It sounds pretty weird - you may have hit on an actual bug in Vista since it seems unlikely many other people have tried what you are doing.
First of all I'd make sure the problem doesn't exhibit this behaviour when run by the logged in user directly, just to pin it down to whether it's a Aero/Classic issue or a winstation issue.
Secondly I'd attach to the process with a debugger and make sure the message loop is getting various significant messages, particularly WM_PAINT :)
But this is obscure enough that your only option may be to open a paid support issue with Microsoft.
There may also be a problem if you have user-drawn controls on your form (or your form itself is user-drawn). If you only paint the form if Application.RenderWithVisualStyles is true, you may see this behaviour. So make sure you also render stuff without these styles. More information how your form looks/behaves/etc would be appreciated.