Uma atualização de recurso para RAD Studio 10.4.2, conduzida por análise que mostra um aumento no número de desenvolvedores usando desktop remoto para desenvolvimento durante a Covid, foi a velocidade de renderização IDE sobre Desktop Remoto.
Os principais problemas focados foram o congelamento do IDE em algumas situações (como ao conectar ou desconectar a área de trabalho remota), oscilação e alguns AVs.
Os itens QP analisados para 10.4.2 incluem:
- Reconecte uma sessão RDP existente usando as mesmas configurações de tela (mesma máquina) RS-99048
- Reconecte uma sessão RDP existente usando configurações de tela diferentes (por exemplo, de uma máquina diferente) RS-103339
- Reconectar uma sessão RDP existente com o designer FMX aberto causa AV.
Além disso, havia vários relatórios internos.
Embora eu não tenha um projeto de amostra que possa ser compartilhado, tenho permissão para compartilhar algumas notas que a equipe de P&D da Embarcadero forneceu com base em suas experiências e espero que isso seja útil para outros desenvolvedores também.
A causa raiz de todos esses problemas é que qualquer alteração de sessão RDP (bloquear, desbloquear, conectar, desconectar) enviou uma alteração de configuração de todo o sistema (WM_SETTINGCHANGE) causando uma cascata de mensagens que leva a vários redesenhos no IDE. Esta foi a causa de alguns dos AVs, pois entre as mensagens em cascata enviadas pelo SO incluía a mensagem WM_THEMECHANGED que estava acionando a recriação do identificador para alguns controles. Isso estava afetando os designers VCL / FMX quando eles foram deixados abertos e uma sessão foi reconectada via RDP.
A API WTS fornece uma maneira de receber as notificações de alteração de sessão RDP (WM_WTSSESSION_CHANGE). Gerenciar isso permite que o IDE seja notificado quando a sessão for bloqueada, desbloqueada, conectada, desconectada e, a partir daqui, podemos escolher como o WM_SETTINGCHANGE é tratado e evitar os problemas de oscilação / repintura.
Uma observação da equipe de P&D foi que o uso de estilos VCL em serviços de terminal é mais provável de fazer um aplicativo piscar em circunstâncias normais.
Este exemplo de esqueleto de código (não testado) deve fornecer indicadores na direção certa para qualquer pessoa que queira adicionar suporte semelhante a seus aplicativos.
[crayon-67426edb35d99596063409/]