Newsgroup: it.comp.lang.visual-basic
Titolo: User Control e proprietà non modificabili a runtime

Ho creato un UserControl che contiene una TextBox standard.
Il problema sorge con le proprietà non modificabili a runtime della textbox
stessa (come la proprietà ScrollBar).
In pratica vorrei esportare queste proprietà della textbox in modo che
diventassero analoghe proprietà del mio UserControl modificabili a
design-time.
Ho provato con la "property let", ma, quando provo a modificarla a
design-time, mi dice che la proprietà in questione è a sola lettura.
Ovviamente qualcuno dirà, perchè non modifichi direttamente la proprietà
della textbox, invece di cercare di esportarla? Il fatto è che mi
servirebbero più istanze dello stesso controllo con quella proprietà
impostata diversamente...


Il problema è che una volta creato il textbox AFAIK non è possibile cambiare lo
stato di visibilità delle scrollbar.
Mi sa che non hai molte alternative:
- o gestisci tu le scrollbar aggiungendole all'usercontrol come controlli a sé
- oppure crei il textbox "from scratch" con l'API CreateWindow, specificando
WS_VSCROLL e/o WS_HSCROLL nel parametro dwStyle
Bye
Raf

 WS_VSCROLL e/o WS_HSCROLL nel parametro dwStyle
Alla fine ho risolto inserendo due textbox nell'user control e visualizzando
di volta in volta quella richiesta... non è molto elegante ma di meglio non
sono riuscito a fare.
Riguardo alla creazione delle finestra pilotata da me, era quello che avevo
cercato di fare all'inizio, purtroppo alla fine ho dovuto rinunciarci,
infatti il problema dei TAB, che sembrava risolto, in realtà non lo era, per
cui... peccato però, perchè gli user control con le finestre create da me
non mi dispiacevano proprio per niente.

 con le finestre create da me non mi dispiacevano proprio per niente.
Ecco questo invece mi lascia un po' interdetto. Come mai non funzionano?
Bye
Raf

> Ecco questo invece mi lascia un po' interdetto. Come mai non funzionano?
Sembra che il vero problema sia il focus, in pratica VB non riesce ad
accettare che il focus lo possa avere un controllo che lui non riconosce
come proprio (ad esempio una finestra creata con la createwindow).
Non riconosce la finestra che creo io, e, se le passo il focus, lui crede
che il focus lo abbia un altro controllo del form, anche se non è così.
Il risultato è un comportamento per lo meno strano.
Ad esempio, se passo il focus ad una finestra che ho creato con la sudetta
API e poi premo INVIO, lui inesorabilmente mi preme il tasto che lui crede
abbia il focus in quel momento.
Anche subclassando non ho risolto niente, a me sembra che i tasti vengano
processati da VB prima di arrivare alla main window, e ti dirò di più, io
personalmente, sono convinto che la main window (in VB) non sia quella del
form principale, ma sia una finestra nascosta che VB usa per processare i
tasti e gli eventi prima di tutto il resto (questo spiegherebbe come mai,
anche subclassando tutto il subcassabile, alcuni uMSG non si riescano ad
annullare).
Chissà però... adesso che ci penso (se ho ragione e non sto prendendo un
granchio colossale) si potrebbe trovare il modo di subclassare la vera main
window...

 è così.
Mmmmmm... non so se il modello che ti sei fatto sia quello giusto.
Ascolta, io ho fatto così per il mio UserControl "IPAddress" (anche se a dire il
vero non mi ricordo se l'ho scoperto da solo o se l'ho visto da qualche parte):
Nell'evento UserControl_EnterFocus:
SendMessage hwndCtl, IPM_SETFOCUS, 0&, ByVal 0&
Dove hwndCtl è l'handle della finestra creata con CreateWindowEx (dwStyle =
WS_CHILD Or WS_VISIBLE).
Se sostituisci IPM_SETFOCUS (che è il messaggio specifico del controllo
IPAddress) con il generico WM_SETFOCUS, forse funziona...
Prova!
Raf

 Prova!
Ho provato, ma non funziona, per la precisione, quel uMSG informa la mia
finestra che ha ricevuto il fuoco, ma non glielo dà realmente, infatti
l'effetto che ottengo è quello di far lampeggiare il cursore come se la
finestra effettivamente possedesse il focus, il problema è che poi essa non
risponde ai tasti.
Addirittura, se do il fuoco ad un altro controllo, il cursore della finestra
continua a lampeggiare (visto che, non avendo effettivamente mai ricevuto il
fuoco, non riceve nemmeno il messaggio WM_KILLFOCUS).

> Mmmmmm... non so se il modello che ti sei fatto sia quello giusto.
Sinceramente non lo se neanch'io... però è una cosa che ho dedotto da due
considerazioni:
1. Stavo cercando di realizzare un sostituto del Task Manager di Windows e
ho notato che, tutti i programmi VB, anche quelli con un singolo Form,
possiedono in realtà almeno due Top Level Window, nel TaskManager alla fine
ne viene visualizzata solo una, ma sono due.
Lo puoi vedere nel Task Manager che ti dicevo (è il secondo programma):
http://dimio.altervista.org/ita
Se, in "option" selezioni "show all windows", nel TAB "Applications" vedrai
comparire tutte le Top Level Windows, se ci fai caso, vedrai che tutti i
programmi VB (al contrario degli altri) ne hanno due invece di una.
2. Teoricamente, subclassando, anzi, superclassando la main window, dovrebbe
essere possibile intercettare ogni tipo di evento, e, da alcune prove che ho
fatto, sembrerebbe non essere così. Alcuni tasti (come i tasti freccia) a me
sembra che vengano preprocessati comunque.
Secondo me la conclusione più probabile è che il form principale non
corrisponda alla main window... ovviamente potrei benissimo sbagliarmi.


Ma avrai provato (spero) a chiamare l'API SetFocus nell'evento EnterFocus... o
no?
Raf


No no, hai visto abbastanza giusto.
Effettivamente sapevo anch'io che ogni processo VB6 possiede 2 finestre
top-level ad esso associate: una è quella del form principale, l'altra serve a
VB per qualcosa che ora non ricordo...
Inoltre alcuni controlli dei common controls (come ad es. la Toolbar) vengono
"wrappati" da VB6 che crea una finestra container per ciascuna istanza.
Ma non credo che sia questo il problema per il tuo usercontrol
"textbox-replacement".
Guarda, sarei curioso: ti dispiace postare (magari opportunamente "sgrossato")
il codice dell'UserControl che non funziona?
Bye
Raf

> Ma avrai provato (spero) a chiamare l'API SetFocus nell'evento
EnterFocus... o no?
E' la prima cosa che ho provato :-)

 il codice dell'UserControl che non funziona?
Molto sgrossato, eccolo qui:
http://digilander.libero.it/dimio/textbox_user.zip
In realtà questo è solo l'ennesimo tentativo, ognuno dà problemi diversi, ad
esempio, questo sembra tutto ok, ma appena provi a spostarti nella textbox
usando le frecce...


OK, il problema riguarda esclusivamente i tasti freccia.
Ho idea che sia correlato a questo problema:
http://www.kbalertz.com/180402/ActiveX.Control.Ignores.ARROW.Container.aspx
C'è anche scritto un workaround, però occorre capire come adattarlo nel nostro
caso.
Ho anche notato che quando si clicca sull'edit box, l'usercontrol NON riceve il
focus.
Forse con l'utility Spy++ si capisce qualcosa di più... vedrò di fare qualche
prova ulteriore se avrò il tempo.
Bye
Raf
P.S. Ci sarebbero molte altre considerazioni da fare sul codice, ma te le
risparmio perché non rilevanti qui...

 risparmio perché non rilevanti qui...
Se ti riferisci al fatto che non uso l'option explicit e che alcune
variabili le dimensiono con i simboli (&,$,%) è un mio vecchio retaggio e
non mi ha mai dato problemi. Se invece ti riferisci a qualcos'altro sono
tutt'orecchi.

 retaggio e non mi ha mai dato problemi.
Esatto... ma se sai quello che stai facendo, non dico niente, solo... in bocca
al lupo!
Bye
Raf

 al lupo!
Ehm, adesso che mi viene in mente, tempo fa ho perso un pomeriggio per colpa di una variabile digitata male associata al non uso dell'option explicit... ma le vecchie abitudini sono dure a morire :-)