Send() doesn't work when trying to Alt+Printscreen

[christian.blackburn@…]

Hi Gang,

I'm able to Send("{PRINTSCREEN}") without problems, but Send("!{PRINTSCREEN}") fails to capture the current window whether I've compiled ANSI or Unicode. Can someone else test this out?

Thanks,
Christian Blackburn

[J-Paul Mesnage]

can you give a complete description as for instance the osvesion the window which is not capture how your script copy the capture info.
In fact just follow the sticky directive. the old sticky is still a valid check list.
Thanks

[christian.blackburn@…]

I'm using Windows XP Pro SP2 and am logged in as an admin user.

[christian.blackburn@…]

Hi JPM,

I didn't include more source code, because I didn't want to pick apart my program. If you try executing the the alt+Printscreen command and then pasting it into MS Paint you'll notice that the entire window isn't included (regardless of the window). Then try printscreen and notice the difference. I only see a point in provide step by step here if you were unable to reproduce the problem, were you?

Thanks,
Christian Blackburn

[J-Paul Mesnage]

Replying to christian.blackburn@yahoo.com:

Hi JPM,

I didn't include more source code, because I didn't want to pick apart my program. If you try executing the the alt+Printscreen command and then pasting it into MS Paint you'll notice that the entire window isn't included (regardless of the window). Then try printscreen and notice the difference. I only see a point in provide step by step here if you were unable to reproduce the problem, were you?

Thanks,
Christian Blackburn

Thanks for the osversion but definitly you have to described how you us the alt-printscreen info as what I can say I use it without any problem. I have not cristal ball SantaClaus just forget about it

[anonymous]

Sleep(2000)
Send("!{PRINTSCREEN}")

In my tests this correctly captures just the active window.

[J-Paul Mesnage]

Replying to anonymous:

Sleep(2000)
Send("!{PRINTSCREEN}")

In my tests this correctly captures just the active window.

still a lot of think can go wrong with such script.
Please post a complete reproduction script with the way you use the info capture with the !PRINTSCREEN and what is captured.

[anonymous]

Hi JPM,

I'm sorry for not providing a repro. This is the simplest version of the code that
is causing me problems:

Opt("TrayOnEventMode", 1)
Opt("TrayAutoPause", 0)
Opt("WinTitleMatchMode", 4)

$mnuCaptureWindow = TrayCreateItem("Capture &Window")

TrayItemSetOnEvent($mnuCaptureWindow, "mnuCaptureWindow")

Func mnuCaptureWindow()
	Send("!{PRINTSCREEN}")
	Run(@SystemDir & "\mspaint.exe")
	WinWaitActive("untitled - Paint")
	WinMenuSelectItem("last", "", "&Edit", "&Paste")
EndFunc

While 1
Wend

Although I can't understand why I'm getting only a fraction of the active window, I suspect it's somehow related to the mouse being active (up/down) at the moment the printscreen is initiated. That being said sleep() doesn't seem to provide any amelioration.

Thanks,
Christian Blackburn

[anonymous]

On second thought, it's probably an issue with the tray icon functionality.

[J-Paul Mesnage]

Replying to anonymous:

On second thought, it's probably an issue with the tray icon functionality.

The script cannot work as the active window is non deterministic when you click on the tray icon menu.

[J-Paul Mesnage]

I close it as everything is working as it should for me with the proposed script.

[anonymous]

Hi JPM,

I just tried this on two more systems one Windows XP Home SP2 and one Windows 2000 Pro SP4. Please make sure you're not counting part of the active window as a valid capture the whole problem here is that when the contents are pasted into Microsoft paint you don't see the whole window just some fraction of it and you should see the whole window. Can someone else try to reproduce this?

What's happening (partial window):
​ftp://seierson.dyndns.org/Public/AutoIt%20Bug22%20(With%20Script).png

What should be happening (whole active window):
​ftp://seierson.dyndns.org/Public/AutoIt%20Bug22%20(Without%20Script).png

Thanks,
Christian Blackburn

[Valik]

A better question is this, can *YOU* reproduce it when you use a non-flawed script? You are reacting to an event where focus has changed and is it the process of changing again. Essentially you have a race condition in your code. You're lucky you're not getting a capture of the notification area or something. Try using a Sleep() or something before the Send(). Windows needs a little bit of time to automatically give focus back to the right window.

[junkew@…]

I feel it has more to do with the window that is active.
When you have the menu in your tray and you choose capture window the actually active window is the menu which was shown which then quickly dissapears and then somehow alt+printscreen seems not to function properly anymore.

Sleep does not seem to help.

I could reproduce the behavior (dutch windows XP version)
See below code which gives a proper screenshot. Solution is to add code to activate window you want to have screenshot on.

Opt("TrayOnEventMode", 1)
Opt("TrayAutoPause", 0)
Opt("WinTitleMatchMode", 4)

$mnuCaptureWindow = TrayCreateItem("Capture &Window")

TrayItemSetOnEvent($mnuCaptureWindow, "mnuCaptureWindow")

Func mnuCaptureWindow()

	Run(@SystemDir & "\mspaint.exe")
WinWaitActive("naamloos - Paint")
	Send("!{PRINTSCREEN}")
WinWaitActive("naamloos - Paint")
	WinMenuSelectItem("[ACTIVE]", "", "Be&werken","&Plakken")
EndFunc

while 1
WEnd

[Valik]

I'm closing this again. I repeat: this is not an AutoIt bug. If you don't believe me, run the script but this time click "Script Paused". Now without changing focus, press Alt+PrintScreen. Open Paint and paste the image. Notice that you get the exact same results. In fact, you can do this with any program that has a context menu entry which doesn't do anything visible. I just tested using a program I had running that happened to have just such a menu item. I can reproduce the problem without AutoIt being part of the equation.

You need to understand, the focus changes when you invoke the context menu. I thought perhaps Windows restored focus back to the last window but it doesn't, so focus is wherever Windows puts it. As mentioned above, you must set focus where you want it to be. If you don't know where it should go, then you'll have to write some clever code to determine where it should go. But this is not an AutoIt bug.

Resolving as no bug.

[anonymous]

Hi Valik,

Sorry I didn't catch that the first time. I did just try as you suggested and am disgusted by this bug in Windows :(. I will have to do just as you suggested write a clever script to put focus back on the previous window. It'll probably be fairly easy since it's just a z-order issue.

Thanks,
Christian