Delphi XE , showmessage..

bonjour a tous ,

Je suis en train de passer une application développée sous D7 et XP => XE et W7.

J'ai un comportement bizarre avec les forms crées dans des DLLs.
Quand je crée la form et que j’exécute un ShowModal, je vois bien la form s'afficher, mais elle repasse de suite sous la fiche appelante, alors que la fiche appelante n'est plus active.

L'utilisation d'un "BringToFront" de la form crée fonctionne que dans certain cas et on dirait que la form appelante récupère un focus alors qu'elle n'est pas active.

Le code me semble correct est surtout est fonctionnel sous D7 et XP.

Quelqu'un a t il eux se problème ou quelque chose de semblable ?

Bon, c'est pas exactement le même cas. Je suis passé de D7 à XE2 mais je suis resté sous XP : Un ShowModal s'exécute normalement et reste au dessus (sans modification notable du code).

Oui je confirme,
mon problème n'existait pas quand je suis passé de D7 à XE pour uniquement sous XP.

et j'ai rien trouvé pour corriger cela sauf un stayOntop !

Peut-être un bug de XE sous Windows 7 ?

Mais si personne d'autre ne rencontre ce problème ??? :arf:

peut-être une piste là http://stackoverflow.com/questions/1...odal-is-called

Re bonjours

Toujours pas résolus !

Pour plus d'info, cela n'arrive que si l'application appelante (Application ou DLL) demande l'ouverture d'une fiche se trouvant dans une (autre) DLL.

Cela n'arrive pas avec toutes les fiches qui se trouvent dans des DLL, et ne j'arrive pas a voir les différences entre ces diverses fiches.

La seule piste a ce jour : cela semble arriver à toutes les fiches qui ont un menu.

Je croyais avoir résolu le problème en passant ma fiche en "stayOntop" plein écran, mais je ne vois plus les boites de dialogues ! donc "stayontop" impossible!

si des idées vous traverse la tête , je suis preneur !

Pense que ShowModal fait une bidouille sur toutes les Fenêtre d'une application via la fonction DisableTaskWindows
Si on lit son code, on voit d'ailleurs qu'ils ont eu des soucis sous XP :mouarf:
Cela envoie une message WM_ENABLE (via l'API EnableWindow) à chaque HWND du THREAD en cours via EnumThreadWindows !
Il du coup facile de faire une WndProc pour avoir des fenêtres qui refuse le WM_ENABLE (voir code plus bas)

Une fois terminée, cela rétabli le tout avec EnableTaskWindows

Faudrait voir si l'affectation du Application->Handle pour lier la DLL avec son Application ne permettrait pas d'améliorer le comportement du DisableTaskWindows et de EnumThreadWindows

Tu ne joue pas avec les TForm dans différents threads ???

Citation:

---

EnumThreadWindows Enumerates all nonchild windows

---

le code sur StackOverFlow : Form is hidden behind other forms when ShowModal is called avec sa bidouille du WndParent dans CreateParams ne pourrait-il pas empirer le phénomène ?

Si on lit le TCustomForm.CreateParams on constate que le fsModal dans FormState force un PopupMode à pmNone
Si MainFormOnTaskBar, allors le WndParent c'est la MainForm
Sinon c'est l'Application
Cela peut-il jouer aussi ?
Faudrait donc modifier MainFormOnTaskBar dans le DPR de l'EXE et les DPR des DLL aussi ???

Je travaille en C++Builder XE3, sous Seven
Je maintiens un groupe d'application qui utilise bcp de DLL avec ShowModal, je n'ai jamais constaté de fenêtre récalcitrante à cela (sauf celle de vidéo qui je force dans cet état)

Pour ton histoire de Menu,
Est-ce un MainMenu ?
J'avoue qu'à part la fenêtre principale, je n'ai rarement de MainMenu sur des fenêtres modales, je n'ai qu'une seule application conçu pour du multi-écran où chaque fenêtre a un MainMenu et chaque fenêtre est prévu pour être en plein écran sur chaque moniteur (appli de vidéo-surveillance)
A part un Merge de MainMenu qui normalement ne s'applique en MDI, je ne vois pas ce qui peut nuire au Modal

Est-ce un PopupMenu ?
là je ne vois pas du tout !



Code qui permet qu'une fenêtre SDI ne soit pas bloqué même si une Modale survient, utile pour une fenêtre de Trace ou de Débug.
En gros, c'est presque reproduire ton bug mais volontairement :mouarf:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

//--------------------------------------------------------------------------- void __fastcall TFrmDebugSQLBrowser::FormNewWindowProc(Messages::TMessage &Message) { // Traitement normal des autres message. FormOldWindowProc(Message);   // Interception de l'évènement WM_ENABLE if (Message.Msg == WM_ENABLE) { if (Message.WParam == FALSE) ForceEnabled(); } else if (Message.Msg == CM_FORCEENABLED) EnableWindow(this->Handle, TRUE); }   //--------------------------------------------------------------------------- void TFrmDebugSQLBrowser::ForceEnabled() { if (CheckBoxForceEnabledModal->Checked) PostMessage(this->Handle, CM_FORCEENABLED, 0, 0); }

---

une autre variante pour un monitoring en temps réel qui tourne "en parallèle" de l'application peu importe si l'utilisateur se balade de modale en modale, il doit pouvoir cliquer dans ces fenêtres

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

//--------------------------------------------------------------------------- void __fastcall TFrmMonitoringMvtZones::NewWindowProc(Messages::TMessage &Message) { // Traitement normal des autres messages FOldWindowProc(Message);   // Interception de l'évènement WM_ENABLE pour l'Anti-Modale si la fenêtre est StayOnTop if (FormStyle == fsStayOnTop) { if (Message.Msg == WM_ENABLE) { if (Message.WParam == FALSE) PostMessage(Handle, CM_FORCEENABLED, 0, 0); } else if (Message.Msg == CM_FORCEENABLED) EnableWindow(Handle, TRUE); } }

---

Merci ShaiLeTroll et aux autres pour votre temps..

comme je reste assez dubitatif sur la résolution réelle de mon problème, je vais vous décrire ma démarche , peut-être cela aidera t il quelqu'un un jour !

Pour répondre à ShaiLeTroll, le pourquoi des menu dans des dlls:
En fait Il faut simplement considérer certaines de mes DLL comme des applications "quasi" autonomes. Elles sont des options fournies à plusieurs de nos applications, par exemple on pourrait vendre une CAO électronique et un module de simulation en option, ben ce module (simulation) serait une DLL optionnelle à la CAO.

Pour Rappel
Les appels à des fiches modales ou pas dans même module (application ou DLL) fonctionne bien.
Mon problème existe quand les ouvertures de fiches sont d'un module à un autre (application => DLL , DLL = autre DLL).
Visuellement, on voit la fiche appelée s'afficher complétement et à la fin de son affichage, on la voit passer sous la fiche appelante. "Bringtofront" inefficace..

Comme je le disais plus haut, les 3 fiches (sur une 15ene) qui fonctionnaient mal, avait un menu (de chez TMS - Tadvmenu), et je les mettais peut-être cause. J'ai donc fait un copier/coller de ce menu dans une fiche qui fonctionnait et après avoir collé le menu la fiche fonctionnait toujours. Donc le menu n'est pas en cause.

J'ai donc progressivement vidé ma fiche non fonctionnelle de ces composants et de son code, jusqu’à ne plus rien avoir !! juste la fiche vide et sa création dynamique. Et problème identique !!

J'ai donc aussi progressivement vidé une fiche fonctionnelle ce coup ci de ces composants et son code, après avoir retirer le "OnShow" , cette fiche fonctionnelle ne l'était plus !!

Après une recherche dans le "OnShow", il s’avère que cela fonctionne seulement, quand je place un "Application.ProcessMessage".
Comme si je devais m'assurer de vider les messages Windows liées à la fiche appelante ou qu'ils soient bien traités ! comme si la fiche appelante reprenait son focus pour finir un traitement !

N'ayant pas vu cela jusqu’à présent sous XP de D3 à D7.. je n'ai trouve que cette réponse a mon problème qui me laisse... mais bon me permet de résoudre mon problème.

juste une idée comme ça...est-ce qu'il est envisageable d'utiliser des TFrame dans la DLL et de les placers dans un TForm de l'exe ? il suffit d'envoyer à la DLL le Handle de la Fiche et de créer la TFrame avec CreateParented.

ça permettrait à l'exe de gérer toutes les fenêtres et aux DLL de se charger de leur contenu.

juste une idée comme ça ...