Newsgroup: it.comp.lang.visual-basic
Titolo: Eliminazione di controlli a run-time e evento paint

Il mio attuale problema:
ho un form con una griglia (mshflexgid e/o datagrid) che mi scompare quando
nascondo il form nella taskbar e poi lo ricarico.
Per ovviare al problema ho messo una chiamata ad una sub che me la mostra
nell'evento paint del form e tutto funziona. Giusto per conoscenza: inserita
nell'evento resize del form, questo non ne vuole sapere di riapparire dopo
essere stato nascosto.
Dicevo che tutto funzionava finchč non ho utilizzato una seconda sub che
crea e cancella label a run-time, e quando arrivo al momento di cancellarne
una mi da "errore '365'. Impossibile scaricare in questo contesto".
Dopo aver spulciato alcuni vecchi post ho trovato la soluzione, anzi, la
causa: bug!
praticamente sono incappato di nuovo in una di quelle cose mostruose che
fanno a casa MS, ovvero non č possibile scricare controlli a run-time se
nell'evento resize esiste un istruzione "unload" o cose simili che non
riguardavano il mio caso ( nuovo caso, visto che nell'articolo di ms non si
parla affatto dell'evento paint).
Ho del cdice anche nel resize del form, ma commentando la chiamata (alla
sub) nel Paint tutto funziona, quindi il problema č lě.
Sapreste dirmi come aggirare questo problema? magari evitando di girare il
coltello nella ferita fcendo battutini sulle grid e cose varie, alrimenti mi
impicco con il mouse :-)
Grazie.

 varie, alrimenti mi impicco con il mouse :-)
Nell'unico modo possibile: Evitando quel che non si può fare in quell'evento
e rimandandolo a un evento successivo che non lo impedisca, magari
aiutandosi con variabili posizionate da una parte e lette dall'altra.

 aiutandosi con variabili posizionate da una parte e lette dall'altra.
Perfetto. Nessuna variabile. Inserita chiamata nell'evento MouseMove del
form (dove già controllo che tasto è stato premuto sull'icona nella taskbar
e quando mostrare il form). Forse farà qulche check di troppo, comunque...
Non trovavo l'evento successivo, che già avevo utilizzato : -
Ciao e grazie.

 (alla sub) nel Paint tutto funziona, quindi il problema è lì.
ma non e' che essendo M$ basta incapsulare il codice in una sub pubblic e
richiamarla lo stesso dal _paint ? sai... qui tra bug e by design , la
programmazione e' 50% (_)_)
-- 
-Gigio@Work(?)-

 'sta sub no.
no , non hai capito, tu hai qualcosa tipo in
form_paint
    unload pippo
hai detto che se commenti sta riga tutto funziona vero ?
Adesso crei una sub public :
public sub Scaricabarile
    unload pippo
end sub
e la chiami al posto del commento nella form_paint
form_paint
  '  unload pippo
  scaricabarile
lo so che non e' logico , ma stiamo sempre parlando di M$ , leggetevi
l'articolo di ieri su PI e poi ditemi se esiste logica ... !
-- 
-Gigio@Work(?)-

"Gigio2k [work]" wrote:
Non propriamente, non ho nessun unload, per questo dicevo di aver scoperto
un nuovo caso (potrei aver combinato un casino io, ma non credo).
ho una treeview1 su form1, in base all'elemento selezionato nella tw appare
una griglia (mshfg o datagrid) e si popola.
Quando riduco ad icona nella taskbar e poi riapro il form la griglia non è
più visibile, ho così pensato di eseguire la sub che la mostra e popola,
ovvero treeview1_click, mettendola nel paint del form.
é andato tutto bene finchè non sono incappato in questo bug che riguarda
l'unload con il resize e/o paint associato all'eliminazione di controlli a
run-time.
Commentando il codice nel resize continua a non funzionare, commentando
quello nel paint funziona; nel Paint ci ho messo altre chiamate ad altre
funzioni (non sub) e funziona, con treeview1_click (che però contiene
l'unload delle label) no.
Ho spostato la chiamata in un altro evento e adesso funziona.
sub form1_paint
    call sub1
end sub
sub sub1
    unload label1
end sub
da errore, mentre
sub form1_mouseMove
    call sub1
end sub
sub sub1
    unload label1
end sub
però così muosemove viene generato ventuordicimila volte, pasienza.
tra un poco proporrò al sc un insieme di progetti con tutti i bug e cose
strane che ho incontrato nell'ultimo mese, sarà un successone :-)
Ciao, SK

 (che però contiene l'unload delle label) no.
Questo perche', nello stack di chiamate, l'origine della catena e' stata
comunque un evento paint, e il codice non e' ancora rientrato... se non vuoi
alterare la successione logica del tuo codice, una possibile soluzione e'
rendere l'unload dei controlli asincrono tramite un timer....
Puoi chiamarlo bug, Lupo diceva ironicamente che e' "by design", ma se e'
stato creato e documentato uno specifico codice di errore per questa
situazione, probabilmente e' davvero una scelta voluta; nella mia beata
ignoranza dei meccanismi interni che regolano le form di VB, penso sia stata
una forma di protezione per evitare che in alcuni eventi delicati tipo il
disegno della form (paint e resize sono legati a filo doppio) venissero
distrutti "a tradimento" contolli ed eventualmente handle di finestra...
Just my 2 cents
-- 
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

 distrutti "a tradimento" contolli ed eventualmente handle di finestra...
Grazie mille, spiegazione esaustiva. E se hai letto come ho risolto senza
bacchettarmi, vuol dire che condividi, vero? :-P
Ciao, SK

pazienza, scusate. "pazienza" non "pasienza".  : - (

 questa situazione, probabilmente e' davvero una scelta voluta;
Ne sono convinto e mi torna pure.
Il mio "by design", per una volta, non era affatto ironico, ma voleva
correggere quel "bug" che non č.