3 ms·

>> sometimes it doesn't record tool tips or contextual menus Welcome to the abysmal implementation of interactive controls. For some awful historical and techn

>> 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.

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.