Le contrôle '' n'a pas de fenêtre parente ?

Bonjour;

Code:

---

1 2 3 4 5

if cond then begin LoadKeyboardLayout('0000040c', KLF_ACTIVATE); Application.BiDiKeyboard:= '0000040c'; end;

---

l’exécution de ce code déclenche le message d'erreur: Le contrôle '' n'a pas de fenêtre parente. mais pas tout le temps et pas dans tout les PC
par exemple, ce message ne se déclenche pas dans un PC avec Windows 7 professionnel SP1 32 Bits et se déclenche dans PC avec Windows 10 64 Bits

Bonjour,

Il est clair dans la doc que le comportement de cette API Windows est différent entre les versions < 8 et >=8.
Il faudrait tester la valeur retournée(un Handle) (null en cas d'erreur) avant de faire quoique ce soit d'autre

Code:

---

1 2 3 4 5 6

If LoadKeyboardLayout('0000040c', KLF_ACTIVATE)=Null then // utiliser GetLasterror else begin // traitement end;

---

De plus, il est nécessaire que le processus actuel soit dans une fenêtre avec le focus clavier.

Merci Mr. SergioMaster

le message d'erreur s'affiche toujours

Je n'ai pas de clavier pour faire un test et votre propre code est court.

• Est-ce que ce code s'exécute produit dans une fenêtre contenant un contrôle d'édition ?
• avez-vous vérifié la valeur obtenue par la fonction ?

Bonjour,
Qui a le focus clavier au moment de l'appel ?

Avez-vous songer à utiliser le déboggueur pour voir où se produit l'exception en utilisant le DCU de dégogage ?

Est-ce un gestionnaire d'évènement qui surviendra dans un message qui serait émis par LoadKeyboardLayout, peu probable
Est-ce à l'affection dans Application.BiDiKeyboard, Application n'a pas de Parent, la MainForm n'a pas de Parent, faudrait savoir qu'elle TWinControl SANS nom qui pose problème, encore une fois, un un gestionnaire d'évènement
D'ailleurs, il faudrait pas le faire avant le OnActivate de la MainForm (évidemment gérer si c'est le premier OnActivate différemment des suivants, une substitution de gestionnaire d'évènement est l'idéale)

Saviez-vous que Application.BiDiKeyboard invoque LoadKeyBoardLayout(..., 0) ?
Est-il pertinent de l'invoquer manuellement, même cela pourrait être contre-productif car vous faussez le clavier courant déjà sélectionné.

Avez-vous songer à utiliser séparément LoadKeyBoardLayout en récupérant le HKL (THandle) puis ActivateKeyboardLayout ce qui ce traduit par affecter Application.BiDiKeyboard puis invoquer Application.ApplyBiDiKeyboardLayout, vous ne devriez pas utiliser l'API, mais seulement Application

j’exécute le code dans OnEnter et OnExit d'un TEdit
pas d'erreur dans mon PC ou je développe l'application mais dans un autre PC win 10 64 bits

Citation:

---

Avant Windows 8 : cette fonction affecte uniquement la disposition du processus ou du thread actuel.

À compter de Windows 8 : cette fonction affecte la disposition de l’ensemble du système.

---

Jusqu'à là, aucune surprise que selon la version de Windows qu'il y ait un comportement différent.
Au moins avec un TEdit, on suppose qu'il y a le focus actif ...

Mais on ignore quel moment est l'exception
Sur LoadKeyBoardLayout(KLF_ACTIVATE) pouvant émettre un Message windows et l'exception serait dans la WndProc
Sur BiDiKeyboard qui vu le code est simplement LoadKeyBoardLayout(0), qui a moins d'effet sans le ApplyBiDiKeyboardLayout (soit ActivateKeyboardLayout)

Faut que vous installiez un Delphi sur un Win10 et que vous fassiez le test, je ne vois pas comment vous pourriez vous en sortir autrement.

En attendant, avez-vous tenter un programme minimale, Form1, Edit1 et BiDiKeyboard
Tester sur Win10,
si bug, c'est dans les trèfonds de la VCL, il faudrait utiliser une version de VCL.Forms modifié (pas l'origine, on peut ajouter une unité avec le même nom dans le projet qui permet de remplacer l'original et faire un peu de débogage)
si pas de bug, c'est dans votre code qu'il y a une incompatibilité.


Avez-vous réfléchi sur la pertinence de BiDiKeyboard+ApplyBiDiKeyboardLayout vs LoadKeyBoardLayout(KLF_ACTIVATE) sachant que c'est des opérations identiques et qui ne devraient pas être utilisé simultanément, soit 100% API soit 100% VCL.

Soit

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

var KBHandle: HKL; begin KBHandle := LoadKeyBoardLayout('0000040c', 0); if Assigned(KBHandle) then begin if not Assigned(ActivateKeyboardLayout(KBHandle, 0)) then RaiseLastOSError(); end else RaiseLastOSError(); end;

---

Quand on utilise les API, faut tout de même faire l'effort d'aller jusqu'au bout, de comprendre ce que l'on fait en lisant la documentation, sinon, on passe par le VCL comme le ci-dessous :

Soit

Code:

---

1 2	Application.BiDiKeyboard:= '0000040c'; Application.ApplyBiDiKeyboardLayout();

---

PAS LES DEUX !!!



Et dans les deux approches, je surveillerais les OnMessage voir si après l'utilisation de ce code, il n'y aurait pas un message Windows qui se propagent comme WM_INPUTLANGCHANGEREQUEST ou WM_INPUTLANGCHANGE
Eventuellement redéfinir la WndProc toujours dans la logique de traquer les exceptions

Evidemment, je testerais cela dans un bouton OnClick ... car OnEnter et OnExit donc justement des gestionnaires d'évènement de changement de Focus, n'est-ce pas le pire moment pour une fonction qui justement est impacté par le focus clavier :aie:

Bonsoir Mr. ShaiLeTroll e merci pour vos réponses, j'ai essayer votre code et toujours le même problème.
j'utilise DevExpress 19.1.2 dans l'application et je pense que c'est lui qui fait le problème car une autre application exécute le même code et ne déclenche pas l'erreur

DevExpress :roll: ... D'où la proposition " un programme minimale " pour écarter tout parasite.

Faut donc maintenant vérifier les DCU de Débogage pour mieux cibler l'erreur, probablement l'infame WndProc que DevExpress met en place dès le moindre composant posé sur form, et voir sur leur forum pour avoir un correctif.

Bonsoir;
j'ai exécute le programme pas à pas aprés l'évenement OnExit du TEdit et l'erreur se déclenche dans l'unité Vcl.Forms dans la procedure TApplication.Run a ce niveau:

Code:

---

1 2 3 4 5 6 7 8

repeat try HandleMessage; except HandleException(Self); end; until Terminated;

---

Oui, c'est la boucle de message comme évoqué plus haut, maintenant, il faut :
1- Récupérer le numéro de message et en déduire le nom WM_....
2- Déboguer plus en profondeur pour savoir quelle WndProc provoque l'erreur, surement celle qu'installe DevExpress
3- Remonter l'anomalie à DevExpress si c'est bien dans leur code que cela provoque l'erreur