7
Pourquoi les éléments d'interface utilisateur doivent-ils toujours être créés/mis à jour à partir du thread d'interface utilisateur?Pourquoi les éléments d'interface utilisateur doivent-ils toujours être créés/mis à jour à partir du thread d'interface utilisateur?
Dans (presque?) Tous les langages de programmation les éléments d'interface utilisateur peuvent être accédés/modifiés en toute sécurité depuis le thread de l'interface utilisateur. Je comprends que c'est un problème d'accès et de synchronisation simultanés standard, mais est-ce vraiment nécessaire? Ce comportement est-il imposé par les langages de programmation ou par le système d'exploitation? Existe-t-il des langages de programmation dans lesquels cette situation est différente?
ne serait-il pas plus facile pour le cadre de faire le contrôle et de mobiliser l'appel lui-même au lieu de prendre le risque d'avoir quelqu'un qui l'appelle d'une manière dangereuse en premier lieu? le framework .Net aurait pu le faire pour nous au moins ... – ak3nat0n
Je dirais non. Si vous appelez la propriété Texte d'une zone de texte, c'est un jeu rapide. Si vous poussez la manipulation sur le framework, * chaque appel * sera lié par cette pénalité, même si la majorité des mises à jour proviennent du thread d'interface utilisateur lui-même. – jasonh
@zaladane: Je pense qu'il pourrait ne pas être si facile de déterminer (automatiquement) quand le code doit être exécuté sur le thread de l'interface utilisateur. Je préférerais une construction dans la langue (peut-être un peu comme le mot-clé dangereux) pour exécuter un morceau de code spécifique sur le Thread UI. Ce serait un peu plus facile à lire que le code Dispatcher. – Zyphrax