4 ms·

I've done this to demo or give instructions before. There are some caveats, sometimes it doesn't record tool tips or contextual menus. It also will not record m

I've done this to demo or give instructions before. There are some caveats, sometimes it doesn't record tool tips or contextual menus. It also will not record more than one program at a time, even if they are on the same monitor. It will record the program you were focused on when you first started recording. So forget showing off a drag and drop, etc. I'd like to see them expand this to not be Xbox branded and to just be like the "snipping" feature (which I use all the time.)

soylentcola 10y ago
Agree completely. It's a great feature and would remove much of the need for dedicated applications like Fraps or Camtasia Recorder for people who just do the occasional screen recording. I tried doing this at one point early after the Win10 release (I think just to record a browser session) and there was something I didn't like about it. Sadly I forget what it was. Maybe it was that the Xbox app/recorder would always want to launch or run now that it thought that program was a "game" or maybe it was some hotkey conflict. Either way I disabled it and await it someday becoming a more useful feature.
- gambiting 10y ago
  My problem with it is that as soon as I enable it, my mouse speed changes to the speed of light, and goes back as soon as I switch it off. It's literally unusable. So far I found no way to fix it.
- partiallypro 10y ago
  I've never had that problem of it wanting to launch randomly, and the keyboard shortcut to launch it is fairly hard to do by accident. I just want it to record everything on the screen and allow me to change focus. I actually like the simplicity, so I hope they don't go overkill if they do anything more to it.
developer2 10y ago
>> sometimes it doesn't record tool tips or contextual menus Welcome to the abysmal implementation of interactive controls. For some awful historical and technical reason, most standard UI controls - such as dropdown menus - are laid out on top of your application's window by the operating system. That UI control is not part of your application; it is implemented as a separate window by the operating system which positions it on top of your application window in the requested x/y location. The screen capturing is designed to capture a single window, and so only captures your application without these separate windows that display elements like a dropdown menu. It really is a disgusting hack. In any reasonable implementation, these controls would be inlined within your application, not outsourced to the operating system. This is the same reason why it took so long for browsers to support styling of form elements, such as changing the background color of a dropdown. The operating system simply provided no way to allow for this. I'm not sure if the modern browser implementation with styled form elements still works with the operating system, or if they are required to bundle their own controls in order to have full control over their rendering. My Google-fu is failing me. Does anyone know why standard operating system controls are laid out by the operating system, rather than by the application using a standard library that keeps them inline to the app itself?
- mkl 10y ago
  It's not historical, or technical; it's the only sensible way to do it. Context menus, dropdowns, tooltips, etc. often need to protrude outside the application window, so they must be separate windows.
  - developer2 10y ago
    I don't understand that logic. There is no reason why a window should not be able to directly own a control that protrudes beyond its outermost border. At a bare minimum, the "child window" used to implement an element should directly be descended from the "parent window" of the application so that any attempt to capture an image of the parent window includes all child windows. This was clearly a limitation of the chosen implementation rather than an inherent limitation of all possible implementations.

soylentcola 10y ago

Agree completely. It's a great feature and would remove much of the need for dedicated applications like Fraps or Camtasia Recorder for people who just do the occasional screen recording. I tried doing this at one point early after the Win10 release (I think just to record a browser session) and there was something I didn't like about it. Sadly I forget what it was. Maybe it was that the Xbox app/recorder would always want to launch or run now that it thought that program was a "game" or maybe it was some hotkey conflict. Either way I disabled it and await it someday becoming a more useful feature.

gambiting 10y ago
My problem with it is that as soon as I enable it, my mouse speed changes to the speed of light, and goes back as soon as I switch it off. It's literally unusable. So far I found no way to fix it.
partiallypro 10y ago
I've never had that problem of it wanting to launch randomly, and the keyboard shortcut to launch it is fairly hard to do by accident. I just want it to record everything on the screen and allow me to change focus. I actually like the simplicity, so I hope they don't go overkill if they do anything more to it.

developer2 10y ago

>> sometimes it doesn't record tool tips or contextual menus Welcome to the abysmal implementation of interactive controls. For some awful historical and technical reason, most standard UI controls - such as dropdown menus - are laid out on top of your application's window by the operating system. That UI control is not part of your application; it is implemented as a separate window by the operating system which positions it on top of your application window in the requested x/y location. The screen capturing is designed to capture a single window, and so only captures your application without these separate windows that display elements like a dropdown menu. It really is a disgusting hack. In any reasonable implementation, these controls would be inlined within your application, not outsourced to the operating system. This is the same reason why it took so long for browsers to support styling of form elements, such as changing the background color of a dropdown. The operating system simply provided no way to allow for this. I'm not sure if the modern browser implementation with styled form elements still works with the operating system, or if they are required to bundle their own controls in order to have full control over their rendering. My Google-fu is failing me. Does anyone know why standard operating system controls are laid out by the operating system, rather than by the application using a standard library that keeps them inline to the app itself?

mkl 10y ago
It's not historical, or technical; it's the only sensible way to do it. Context menus, dropdowns, tooltips, etc. often need to protrude outside the application window, so they must be separate windows.
- developer2 10y ago
  I don't understand that logic. There is no reason why a window should not be able to directly own a control that protrudes beyond its outermost border. At a bare minimum, the "child window" used to implement an element should directly be descended from the "parent window" of the application so that any attempt to capture an image of the parent window includes all child windows. This was clearly a limitation of the chosen implementation rather than an inherent limitation of all possible implementations.