2012-03-01 11 views
6

Ho un piccolo problema con i moduli creati all'interno di una DLL.Delphi XE2 che assegna Application.MainForm.Handle a Application.Handle all'interno di una DLL

In pratica, ciò che accade è quando viene visualizzato un modulo (Form1) da una dll (penso che debba rimanere sopra) e si apre un altro modulo (Form2) che si trova a parte dell'applicazione principale (ovvero non vive all'interno della DLL). Se si posiziona il cursore su un controllo su Form2 in modo che venga visualizzato il suggerimento, Form2 andrà immediatamente dietro a Form1.

Questo accade solo con MainFormOnTaskBar è true. Al momento stiamo passando Application.Handle dell'applicazione principale alla DLL e assegnandola a Application.Handle della DLL.

Sono riuscito a risolvere il problema passando invece Application.MainForm.Handle alla DLL da assegnare a Application.Handle nella DLL.

È sicuro? Qualcuno sa il modo corretto per risolvere questo problema?

risposta

5

La soluzione è perfettamente ragionevole. Ho un componente aggiuntivo COM Excel che fa qualcosa di molto simile. In quel codice ho impostato Application.Handle nella DLL per essere l'handle di finestra della finestra principale di Excel. Questo è analogo a quello che stai facendo.

Il problema è che è necessario ottenere correttamente il set di proprietà della finestra. Hai bisogno della catena di proprietà per tornare al modulo principale della tua app. I moduli in una DLL non hanno alcuna conoscenza di quale sia la forma principale e quindi devi fornire quella conoscenza.

Nota che sto parlando del concetto di proprietario della finestra come utilizzato da Windows e non del concetto VCL del proprietario che è completamente diverso. Nella terminologia VCL questo è noto come popup genitore e potresti risolvere il tuo problema impostando esplicitamente il popup popup del modulo DLL come forma principale. Le proprietà rilevanti sono PopupMode e PopupParent. Per i moduli che vivono nell'app principale, il VCL farà in modo che il loro genitore popup sia la forma principale.

Tuttavia, dopo aver parlato esplicitamente di impostazione popup parent, vorrei sottolineare che la vostra soluzione corrente è più semplice e più conveniente.

Ciò che entrambe queste soluzioni fanno è assicurarsi che tutti i moduli ausiliari siano di proprietà del modulo principale. Ciò significa che queste forme sono sempre in cima alla forma principale. Significa che le forme ausiliarie saranno ridotte al minimo se la forma principale è ridotta al minimo. Leggi le finestre di proprietà qui: Window Features.

Per inciso, se si fossero stati utilizzati pacchetti di runtime anziché una DLL, il codice nel pacchetto sarebbe stato connesso allo stesso VCL del modulo principale. Quindi il codice pacchettizzato sarebbe in grado di vedere il modulo principale e impostare il proprietario della finestra in modo appropriato. Questo è certamente uno dei vantaggi dell'utilizzo dei pacchetti. Naturalmente, potrebbe esserci una buona ragione per cui è necessario utilizzare DLL piuttosto che pacchetti.

+0

Grazie per quello. Mi stavo chiedendo se è necessario impostare la proprietà MainFormOnTaskBar su true sull'oggetto dell'applicazione contenuto nella DLL? –

+0

Poiché l'oggetto dell'applicazione nella DLL non ha la forma principale, suppongo che non sia necessario o non debba impostare MainFormOnTaskBar su true sull'oggetto applicazione –

+0

concordato, non è necessario, non che sarebbe effettivamente importante poiché presumo che Application.MainForm non sia assegnato perché non si chiama mai Application.CreateForm. –

Problemi correlati