Discussion :

[zi_omnislasher]

Bonjour,

Je poste ici mais j'ai egalement poste dans le forum windows. C'est peut-etre mal, et dans ce cas me culpa, mais ce forum est plus actif il me semble.

J'ai une question qui me titille depuis quelque-temps, c'est que dans son Framework .NET Microsoft defini des fonctions invoke sur les controls pour tous les languages en specifiant qu'il faut l'utiliser pour recuperer le thread qui a construit le controle. Ils precisent meme quelque part que c'est une regle de windows, qu'un control de doit etre update que par le thread qui l'a cree (illegal cross thread call)

Du coup je me demande... Et alors les autres ils font comment ? Ya-til des equivalents en JAVA? En C++ standard ? (En dehors du Framework .NET ???)

Je n'arrive pas a trouver de vraie information a ce sujet, alors si vous avez des liens ou des explications interessantes.

Merci.

[SirJulio]

Salut,

c'est une regle de design quand tu programmes en .Net, en effet, la propriété CheckForIllegalCall (me souvient plus du nom =p) est juste la pour du debuggage.

Tout d'abord, il est 'logique' qu'un thread d'UI garde le controle sur la modification de ce qu'elle a instancié, ca t'evite instrinsequement les race conditions. Mais la vraie raison, tient de la rencontre entre l'interop sur des composants com et le fonctionnement des thread managés.

Tous nouveaux threads de .Net a par defaut un appartment MTA, sauf si tu precises le contraire avant son demarrage. A coté de ca, certains controls WinForms ne sont que des wrappers de composants Com pour .Net et ces derniers ont des apartments specifiés pour n'autoriser qu'un seul thread à y acceder. C'est pour cela qu'un thread demarrant une appli Winforms doit etre marqué avec l'attribute STAThreadAttribute (qui va forcer l'apartment du thread en STA), et qu'on interdit à un autre thread de modifier des composants d'UI, de fait tu es sur que tout ce qui touchera ton UI (et potentiellement un compo Com wrappé) sera dans un apartment correct, puisque seul le thread createur (sensé etre STA) aura la controle sur ses controls.

Bref, en gros, c'est surtout pour l'interop avec des concepts non-managés (drag&drop, composants Com).

Pour plus d'infos, il y a cette discussion sur TheScripts, qui explique plus en details (pour les windowsiens 'non managé' =p ) le pourquoi du comment.