|
|
| andy |
 Posted: Apr 12 2013, 04:00 AM |
 |
|
Advanced Member
Group: Members
Posts: 35
Member No.: 35896
Joined: 26-December 12
|
With the UScreenCapture device, the Set Capture File menu option and the F2 key do nothing but make the mouse instantly flicker to hourglass and back. It doesn't matter how UScreenCapture is configured or what display mode is used, or if display is even on. This is not a problem for Screen Capture or any other device I've tested.
At present, the only way I can set the capture file is by temporarily changing the device, then changing back after the file is selected.
Interestingly, the Previous/Next File ID and [/] hotkeys work with UScreenCapture.
VirtualDub 1.10.3 32-bit on Windows 7 64-bit |
|
| phaeron |
| Posted: Apr 23 2013, 03:24 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
This is pretty bizarre, as it's just a plain file dialog. Does the set striping system menu item have the the same problem?
|
|
| andy |
| Posted: May 11 2013, 05:12 AM |
|
|
Advanced Member
Group: Members
Posts: 35
Member No.: 35896
Joined: 26-December 12
|
Yes it does.
(Sorry I didn't respond sooner. The forum failed to notify me of your post. I'll have to cruise through all my old posts and see if they've accumulated responses I need to address.) |
|
| phaeron |
| Posted: May 14 2013, 12:15 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Took all afternoon with WinDbg to track down this problem. It's due to a serious problem in UScreenCapture that affects process state in VirtualDub.exe, and thus I can't support use of this driver until the problem is fixed.
The reason that the open dialog doesn't open is because a combo box control doesn't open, which in turn occurs because a call to SetWindowSubclass() fails, which fails because GlobalAddAtom() fails. This is a very basic operation to fail, and that indicates something is screwed up. In this case, it's because UScreenCapture changes the entire process's window station to WinSta0, the window station used by services, presumably in an attempt to be able to capture the lock screen. In Windows Vista and later, window station 0 is protected, so this causes all sorts of havoc, including swapping the atom table and causing all atom-related calls to fail. Basically, this really fubars the program while UScreenCapture is running; it's a miracle that most things hobble along. I was able to reproduce the exact same problem in Microsoft GraphEdit, the DirectShow testing program.
tl;dr, UScreenCapture is screwing things up inside VirtualDub.
|
|
| andy |
| Posted: May 14 2013, 04:28 AM |
|
|
Advanced Member
Group: Members
Posts: 35
Member No.: 35896
Joined: 26-December 12
|
Thank you for the detailed research and write-up. What a shame. At least a workaround exists (set the filename before selecting the capture driver), and yeah, it's a miracle everything else isn't broken. Maybe someday the UStream guys will pick up on your analysis and find a better way of doing things, but I'm not holding my breath. |
|
