Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Window contents while dragging / resizing
Message
De
07/02/2014 06:44:16
 
 
À
07/02/2014 06:39:38
Information générale
Forum:
Visual FoxPro
Catégorie:
Fonctions Windows API
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2012
Network:
Windows 2008 Server
Database:
MS SQL Server
Application:
Web
Divers
Thread ID:
01593391
Message ID:
01593610
Vues:
30
Agreed, what is changed should be changed back when the change is no longer needed. My point was only that sometimes it makes sense to make the change. And clearly MS recognizes this and made such behavior possible by providing an API function.

>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.
In the End, we will remember not the words of our enemies, but the silence of our friends - Martin Luther King, Jr.
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform