Une mise à jour des fonctionnalités de RAD Studio 10.4.2, motivée par une analyse montrant une augmentation du nombre de développeurs utilisant le bureau à distance pour le développement pendant Covid, a été une accélération du rendu IDE sur le bureau à distance.
Les principaux problèmes sur lesquels se sont concentrés étaient le gel de l’IDE dans certaines situations (comme lors de la connexion ou la déconnexion d’un bureau distant), le scintillement et quelques AV.
Les éléments QP examinés pour 10.4.2 comprennent:
- Reconnectez une session RDP existante en utilisant les mêmes paramètres d’écran (même machine) RS-99048
- Reconnectez une session RDP existante en utilisant différents paramètres d’écran (par exemple à partir d’une machine différente) RS-103339
- Reconnecter une session RDP existante avec le concepteur FMX ouvert provoque AV.
De plus, il y avait un certain nombre de rapports internes.
Bien que je n’ai pas d’exemple de projet qui puisse être partagé, j’ai la permission de partager quelques notes que l’équipe de R&D d’Embarcadero a fournies sur la base de leurs expériences, et j’espère que cela sera également utile à d’autres développeurs.
La cause première de tous ces problèmes est que tout changement de session RDP (verrouiller, déverrouiller, connecter, déconnecter) a envoyé un changement de paramètre à l’échelle du système (WM_SETTINGCHANGE) provoquant une cascade de messages qui conduit à plusieurs rafraîchissements dans l’EDI. C’était la cause de certains des AV, car entre les messages en cascade envoyés par le système d’exploitation, il incluait le message WM_THEMECHANGED qui déclenchait la recréation de la poignée pour certains contrôles. Cela affectait les concepteurs VCL / FMX lorsqu’ils étaient laissés ouverts et qu’une session était reconnectée via RDP.
L’ API WTS permet de recevoir les notifications de modification de session RDP (WM_WTSSESSION_CHANGE). La gestion de cela permet à l’EDI d’être averti lorsque la session est verrouillée, déverrouillée, connectée, déconnectée, et à partir de là, nous pouvons choisir comment le WM_SETTINGCHANGE est géré et éviter les problèmes de scintillement / repeinture.
Une note de l’équipe de R&D était que l’utilisation de styles VCL sur les services terminaux est plus susceptible de provoquer un scintillement d’une application dans des circonstances normales.
Cet exemple de code squelette (non testé) devrait, espérons-le, fournir des pointeurs dans la bonne direction à tous ceux qui cherchent à ajouter un support similaire dans leurs applications.
[crayon-672a31d39fe8e947438271/]