Information générale
Catégorie:
Fonctions Windows API
Versions des environnements
Network:
Windows 2008 Server
Should have written "changing permanently" - overriding for own program action IMO is ok if mentioned edge cases stemming from Murphy are taken care of. Designing an OS to handle such settings globally without giving us a chance to isolate to the calling process is !#?, but out of our hands. Still no reason to change such behaviour without a reset to pre-dragaction value ;-)
>There are several valid reasons for overriding this feature (and other Windows-wide settings). For example, an ActiveX control draws a graphic/chart in a window. The resizing of the window cause the ActiveX to re-draw the chart (obviously) and will fire it over and over again as the user continues to hold the mouse button down and continues resizing. This creates screen flicker and is not visually appealing. By switching the Full Window Draw setting off this does not occur and instead the window can be smoothly resized and, when the resize is finished i.e. the user lets go of the mouse, the ActiveX control gets a single resize event fired and the chart/graphic is re-drawn. This is even more valuable under a terminal services environment where the network has to handle all those screen redraws during resizing.
>
>
>
>>With you on not changing Windows settings on the users machine willy-nilly. But an alternate approach might be to change the setting at start of the action, resetting when manual (mouse-pressed!) task is done. Existing danger opportunity of app erroring out while dragging without calling a reset function in error handler or machine blue-screening, sure, but might be handled with special reset code on next app start - even down to including a message about not resetting due to error and reccommending reset via app. ***Not*** saying I think this is a prudent way in general ;-)
>>
>>>I said nothing about Microsoft. I'm talking about providing a good user experience. Changing Windows settings that affect every program is not a good idea. It causes confusion. Users will see their applications suddenly behaving differently and have no idea what happened or how to revert to the old experience.
>>>
>>>>You always repeat the Microsoft SOP. But you never inquire as to the possible unique scenarios under which such changes might be applicable, allowable, and/or useful.
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement