Newsgroup: it.comp.lang.visual-basic
Titolo: Questione di hwnd

Ok, sentite questa, e poi frustratemi.
Situazione. Form mdi, con dentro 1 form
dll activex con dentro una form.
Apro l'mdi ... istanzio la mia dll, facico una
show poi spalmo la dll con una bella setparent
dentro il form dell'mdi.
Succede che se il contenuto della form (dll)
prende il focus, l'mdi appare in stato disabled
perchè ovviamente sono due thread diversi.
La domanda. Si può fare in modo che una dll
venga vista nello stesso thread dell'applicazione
principale?
Ciao
Andrea

 ha scritto nel messaggio
news:41f2954d$0$8203$5fc...@news.tiscali.it...

Dunque, la confusione terminologica è ampia.
Una dll è solo un file fisico, poi quello che c'è dentro è un altro
discorso.
"Spalmare" una dll in un form è come dire che spalmi un'automobile sul tempo
di percorrenza di una strada: non ha senso.
Un form dll activex non so che sia.
Si instanziano oggetti, che sono infatti instanze di classi.
Se instanzi una dll significa che tu in salotto davanti alle poltrone hai lo
scatolone che conteneva il televisore.
VisualBasic è notoriamente mono-thread, quindi la form mdi (mdi è un
aggettivo, non un soggetto) gira sicuramente nello stesso thread.
E ti anticipo dicendo che gira anche nello stesso processo, poichè le dll e
gli ocx sono "in process".
Per quanto riguarda la tua domanda la risposta è NO.
Un form generato in un componente ActiveX non può essere inserito nel form
mdi dell'applicazione principale, anche se qualcuno millantava un sistema
per farlo che nessuno ha però mai verificato.
L'unico sistema è simulare la cosa: crei un form mdi child vuoto nell'app
principale, poi quando chiami il tuo nella dll in realtà trasferisci tutti i
suoi controlli (Control.Container) sul form mdi child e mostri quello.
Per quanto riguarda l'hwnd nel subject non saprei che dire :)
Ciao
--
Qualunque mentecatto può scrivere codice che un computer possa capire.
I buoni programmatori scrivono codice che gli uomini possano capire.
[Martin Fowler]

 Andrea
Andrea

 Per quanto riguarda l'hwnd nel subject non saprei che dire :)
Beh effettivamente il topic non era proprio azzeccato ... volevo scrivere 
questione
di thread :)
Ciao
Andrea

Leggi la risposta che ho dato a Zanna ... comunque si
il problema č che la form contenuta nella dll, una volta
"spalmata" con la setparent dentro una form child dell'applicazione
principale, se prende il focus lei lo toglie all'applicazione principale.
Ciao
Andrea 

 della "form dll" la form child perda di fatto il focus.
Torniamo alla "quisquilie" :)
Che cavolo c'entra il thread (che, ripeto, è sempre e solo uno) con il fatto
che il tuo form non sa di essere un mdi child?


 che il tuo form non sa di essere un mdi child?
Perchè se fosse su di un unico thread molto probabilmente il
casino non succederebbe .. è una mia convinzione? forse, però non
mi spiego altrimenti.
Ciao
Andrea

Ovviamente dimenticato ... sono convinto ... anche sbagliando
perchè è risaputo che le dll-activex sono in-process ...
L'unico modo che c'è è quello di subclassare ...
ma non vorrei arrivare a tanto
Ciao
Andrea 


Non so da dove ti arrivino queste convinzioni, compresa quella che il thread
di appartenenza di un form c'entri col fatto che le dll ax siano in-process,
e tantomeno cosa tu abbia in mente di subclassare, perchè e come questo
risolverebbe il problema.


 mi spiego altrimenti.
Un'altra possibilita' che va considerata e' che Visual Basic
non sia sufficientemente a conoscenza con la sola SetParent
di cio' che vuoi fare tu.
Considera che le finestre di Visual Basic comunicano fra loro
e con il runtime e non basta una SetParent per informare quest'
ultimo che esiste un nuovo child. Bisognerebbe poter esaminare 
la gestione dei messaggi delle finestre di classe ThunderRTForm 
(o qualcosa del genere, le window class di vb, comunque) per
farsi un'idea precisa. Ma vb, si sa, e' un prodotto *chiuso*.
Eviterei giochi cosi' azzardati in applicazioni da distribuire.
Non sono *documentati* ufficialmente, percio' nulla impedisce a
Microsoft di modificare implementazioni interne che mandino a
gambe all'aria eventuali soluzioni piu' o meno sporche che si
possano (*se* si possono) trovare.
IMHO valuterei le seguenti alternative.
1. Se hai davvero bisogno di funzionalita' particolari nella 
gestione delle finestre, scrivi l'applicazione in C/C++, magari 
appoggiandoti a frameworks come MFC o WTL (interessante anche 
quello del nostro nger Stefano HappyMan: semplice ed efficace: 
complimenti!);
2. Accetti il fatto che Visual Basic e' pesantemente basato su COM
e lo utilizzi affinando al massimo l'uso degli strumenti che ti
mette a disposizione.
Pensa al tempo che stai impiegando per cercare una soluzione
estremamente tecnica e, presumo, totalmente ininfluente dal
punto di vista della logica applicativa. Tempo che, immagino,
il cliente non ti paga di sicuro.
-- 
ciao, hal

 il cliente non ti paga di sicuro.
Vero ...
Ciao
Andrea

 Andrea
Andrea

Approfondisci please :)
Ciao
Andrea 

Beh, hai presente Word?
Word lo puoi caricare in un OleContainer e far sembrare che sia la tua 
applicazione. Deve essere, ovviamente, installato, ma si puň fare.
Stavo pensando... se trovi un modo di fargli fare la stessa cosa con la 
tua form ActiveX... cosě dovrebbe funzionare :-)
ciao,
Andrea

 ha scritto nel messaggio
news:mTPId.751079$35.29...@news4.tin.it...

E' sufficiente che il form sia convertito in un controllo ActiveX, a questo
punto anche senza l'ole-control basta una CreateObject() e un
FormMdiChild.Controls.Add().
Personalmente abbandonerei la strada dell'MDI.
Ciao
--
Qualunque mentecatto puň scrivere codice che un computer possa capire.


Ummmm ... effettivamente trasformandola in un ocx poi
diventerebbe tutto più semplice. Essendo un controllo
che deve essere ospitato da un contenitore non si avrebbero
nemmeno più strani problemi di focus, carico scarico di
dll esterne ...
Non ci avevo pensato. Certo, c'è da fare qualche lavoretto
sui metodi privati delle form, ma in compenso si potrebbe
ottenere il risultato voluto: condivisione delle "form".
Ciao
Andrea 

Veramente - sempre sbagliando - intendevo che le dll sono
in process, quindi lavorano sullo stesso thread del chiamante.
Comunque ha forse poca importanza ... valuto sta cosa
del trasformarlo in un ocx o meglio ancora lascio perdere visto
che è tempo non remunerato.
Ciao
Andrea 

 dll esterne ...
Ora va meglio: segui la strada di COM.
Purtroppo, non potendo disporre dell'ereditarieta', questa
e' la strada giusta da percorrere.
Con i suoi problemi, certo, ma non ti tocca riscrivere vb6.exe,
come  in pratica avresti dovuto fare nel caso dell' hWnd.
-- 
ciao, hal