If a framework exposes functionality provided by a lower layer, how hard should the framework try to insulate you from all the quirks and limitations of the lower layer?
Instinctively, of course, you would say, “The framework should insulate me completely.” But be careful what you ask for. If a framework insulated you completely, then every limitation of the underlying layer needs to be worked around in some manner or other. This would mean writing a lot of code to emulate missing functionality or removing a limitation, just in case somebody using the framework actually runs into that limitation.
Let’s take for example the ToolTip.AutoPopDelay property. The ToolTip class is a Windows Forms wrapper around the Common Controls ToolTip window class. If you look at the documentation for the TTM_SETDELAYTIME message, you’ll see that the delay time (iTime) is passed in the low word of the lParam parameter. Consequently, it is limited to a 16-bit value, and in this case, it’s a signed 16-bit value since negative values for iTime have special meaning (as noted in the documentation).
Since the maximum value for a signed 16-bit integer is 32767, the maximum value you can set for the delay time is a little over 32 seconds.
So if you try to set your ToolTip.AutoPopDelay to something longer, like 60 seconds, you will find that the delay time is not properly set, since the ToolTip class merely passes the delay value through to the underlying control. And until you understood the underlying control, you would never understand why.