Modify

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#22 closed Bug (No Bug)

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

Reported by: christian.blackburn@… Owned by: WaitingUserInfo
Milestone: Component: AutoIt
Version: 3.2.10.0 Severity:
Keywords: XP Pro Sp2 Cc:

Description

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

Attachments (0)

Change History (18)

comment:1 Changed 11 years ago by Jpm

  • Keywords osversion? added; Printscreen Screenshot Capture Keystrokes Send() Send Print Screen removed
  • Owner set to WaitingUserInfo
  • Status changed from new to assigned

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

comment:2 Changed 11 years ago by christian.blackburn@…

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

comment:3 follow-up: Changed 11 years ago by 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

comment:4 in reply to: ↑ 3 Changed 11 years ago by Jpm

  • Keywords XP Pro Sp2 added; osversion? removed

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

comment:5 follow-up: Changed 11 years ago by anonymous

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

In my tests this correctly captures just the active window.

comment:6 in reply to: ↑ 5 Changed 11 years ago by Jpm

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.

comment:7 Changed 11 years ago by Jon

  • Resolution set to worksforme
  • Status changed from assigned to closed

comment:8 Changed 11 years ago by Jon

  • Milestone 3.2.11.0 deleted

comment:9 Changed 11 years ago by anonymous

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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

comment:10 follow-up: Changed 11 years ago by anonymous

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

comment:11 in reply to: ↑ 10 Changed 11 years ago by Jpm

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.

comment:12 Changed 11 years ago by Jpm

  • Resolution set to worksforme
  • Status changed from reopened to closed

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

comment:13 Changed 11 years ago by anonymous

  • Resolution worksforme deleted
  • Status changed from closed to reopened

comment:14 Changed 11 years ago by 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

comment:15 Changed 11 years ago by 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.

comment:16 Changed 11 years ago by 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

comment:17 Changed 11 years ago by Valik

  • Resolution set to nobug
  • Status changed from reopened to closed

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.

comment:18 Changed 11 years ago by 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

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The owner will remain WaitingUserInfo.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.