Come da oggetto, come diavolo faccio ad ottenere
questo risultato?
L'idea sarebbe scrivere qualcosa tipo:
Set Controllo.Container = SSTab1.Qualcosa(MioIndice )
Come posso fare?
Grazie
Andrea
P.S. MSDN non sembra aiutarmi granché nella determinazione
della soluzione!
*NON VOGLIO* scatenare polemiche, però che
caspito, M$ non si degna *MAI* di fare cose *UNIFORMI*.
Bisogna *IMPAZZIRE* appresso alle loro *PIPPE MENTALI*.
Volete sapere cosa ho dovuto fare per ottenere questo risultato?
1) Carico la listbox
2) Seleziono il tab con SSTab.Tab =...
3) Set ListBox.Container = SSTab
Non era molto più semplice un meccanismo come:
Set ListBox.Container = SSTab.Items( Index ) ?
Bah, valli a capire...
Andrea
Molto semplicemente, a differenza dei common controls per esempio, il
controllo non e' stato sviluppato da loro ma da Sheridan e poi concesso in
licenza ;-)
Tanto e' vero che si nota a occhio la "mano" diversa, ha un approccio
totalmente diverso dagli altri, e invece di avere collection di oggetti
figli, ragiona per indici, tipo griglia, dove devi ogni volta impostare le
"coordinate" correnti (il tab)
Sinceramente non ho mai capito per quali motivi abbiano voluto/dovuto
includerlo nel pacchetto, quando proprio nei common controls c'e' il
TabStrip che nonostante non funga da contenitore, funziona 100 volte
meglio...
Ciao
--
Luca Dormio - luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown
Ancora peggio...
> Tanto e' vero che si nota a occhio la "mano" diversa, ha un approccio
> totalmente diverso dagli altri, e invece di avere collection di
> oggetti figli, ragiona per indici, tipo griglia, dove devi ogni volta
> impostare le "coordinate" correnti (il tab)
Stamm appost...
> Sinceramente non ho mai capito per quali motivi abbiano voluto/dovuto
> includerlo nel pacchetto, quando proprio nei common controls c'e' il
> TabStrip che nonostante non funga da contenitore, funziona 100 volte
> meglio...
E che guarda caso era stata la mia "prima scelta".
Ho dovuto poi rinunciare proprio a causa del fatto che non era
contenitore( me lo spiegate a che cacchio serve un controllo tab non
contenitore? )...
> Ciao
Ciao
Andrea
E' un po' piů laboriosetto da usare, ma funziona lo stesso: ci metti dentro
n controlli frame (o un array di frame) e li rendi visibili a turno, in
funzione del tab selezionato. La gestione in design time č un po' piů
complicata, e devi regolare le posizioni dei frame al run time, ma alla fine
funziona.
Salutoni
Sergio
Non mi hai ancora spiegato a che serve un controllo Tab non
contenitore... cmq ora vado a chiedere sui server M$, perché
voglio sinceramente capire il motivo di questa scelta...
> Salutoni
> Sergio
Andrea
Questione di abitudine: all'inizio e' un po' strano, ma una volta visto
l'esempio della guida sai tutto quello che ti serve e le 4 righe di codice
che devi scrivere ogni volta per fare funzionare il meccanismo non le noti
piu'
Oltretutto questo sistema da anche alcuni vantaggi; intanto e' un piu'
leggero (i controlli contenitore occupano un po' piu' di risorse), poi e'
molto flessibile e si presta ad alcuni "giochini" utili; per esempio, spesso
ho delle schede in cui solo una parte dei controlli deve cambiare da una
all'altra: e' sufficiente dimensionare diversamente il contenitore di
appoggio (solita Picture o frame senza bordi) e puoi evitare di duplicare i
controlli o dover cambiare il container al volo... tanto per capirci quello
che vedi nelle proprieta' dello schermo di Windows, tra le due schede
'Desktop' e 'Screen saver'
Non avevo questa pretesa, mi limitavo a dire che questa limitazione può
essere aggirata
> ... cmq ora vado a chiedere sui server M$, perché
> voglio sinceramente capire il motivo di questa scelta...
Auguri. Se otterrai un risultato, faccelo sapere.
Salutoni
Sergio
> Sinceramente non ho mai capito per quali motivi abbiano voluto/dovuto
> includerlo nel pacchetto, quando proprio nei common controls c'e' il
> TabStrip che nonostante non funga da contenitore, funziona 100 volte
> meglio...
Che funzioni, non dubito, che sia pratico dubito molto e rilancio.
In effetti, io direi: "non ho mai capito per quali motivi abbiano
voluto/dovuto includere il TabStrib nel pacchetto quando c'era già SSTab".
Sinceramente e senza polemica.
> Questione di abitudine: all'inizio e' un po' strano, ma una volta visto
> l'esempio della guida sai tutto quello che ti serve e le 4 righe di codice
> che devi scrivere ogni volta per fare funzionare il meccanismo non le noti
> piu'
E la visione dei vari "contenitori" in fase di progettazione/design?
Comodissimi, vero? ;-)
Ecco la risposta più interessante( Tom Esh ):
"
It's not exactly intuitive. The reason is probably apparent only if
you've worked with Windows dialogs via the Api (in C for example). The
Tabstrip is essentially just a VB "wrapper" for the core API tab
control, which is also not a container. The reason for that is one of
the ways the core control was designed to be used is to load dialog
"Property Sheets" (each actually a separate dialog resource) depending
on the selected tab. Dialog resources are somewhat like the Api
equivalent of VB Forms. While VB forms duplicate most of the features
of dialogs (and then some), one feature that unfortunately was not
duplicated is the ability to make up a tabbed dialog consisting of
child dialog "pages" that are loaded and displayed as-needed on their
parent dialog (sort of like the SubForm feature of Access). In that
context, all that's required of the tab control is to visually frame
the tab pages and to provide input notification.
Of course if you want a built-in container, there's always the Tabbed
Dialog Control (formerly SSTab). Easier to use in design mode, though
not without a quirk or two of it's own.
-Tom
MVP - Visual Basic
(please post replies to the newsgroup)
"
Se vuoi posto anche quella che ho trovato meno utile, o la
preferisci in privato? :-)
> Salutoni
> Sergio
Andrea
Il fatto e' che "non c'era gia'": il tabstrip e' un controllo nativo a
livello di shell di Windows, SSTab e' stato aggiunto apposta per VB, secondo
me solo perche' in epoca Windows 16bit, quando si cominciavano a vedere le
prime interfacce con i controlli a schede, esisteva un controllo analogo per
VB3 sempre della Sheridan, e in qualche modo si veniva incontro a quelli
abituati con quest'ultimo...
Sinceramente e senza polemica:
- non ho mai visto messaggi che lamentassero problemi particolari sul
controllo TabStrip, ne vedo spesso e volentieri su SSTab
- Non vedo perche', avendo gia' bisogno di ListView, Tree e soci, mi devo
accollare un ulteriore riferimento e distribuire un'altro OCX con *solo*
SSTab, quando lo ho gia' a disposizione nei common control e quando SSTab
non fa nulla in piu', se non semplificare il design... sara' anche piu'
"pratico" a livello di interazione col mouse, ma a livello di interazione
via codice e' parecchio piu' antiquato rispetto agli oggetti del tabStrip
Non e' che non mi farebbe comodo se il tabstrip fungesse anche da
contenitore, ma per quanto mi riguarda i vantaggi di passare a SSTab non
compensano per nulla gli svantaggi.
in altre parole, se in un form metti un controllo tab, e in ogni tab metti
una serie di controlli, indipendentemente dal fatto che tali controlli siano
mostrati o no, essi vengono sempre caricati;
un controllo tab non container viene utilizzato in tutti quei casi di
istanziazione a runtime di singola "pagina" di controlli;
non si tratta sicuramente di una tecnica semplice, ma nel caso di "pagine"
complesse ( delle vere e propie mini-applicazioni ) creando le singole
pagine come UserControl in un ocx esterno ( per ragioni di ordine pratico a
livello di istanziazione), la cosa funziona egregiamente; (se vuoi fare a
meno di ocx e compagnia bella puoi anche "uscire dal seminato" e scomodare
qualche "apetta" per "appiccicare" una form sulla tab... ma questa č
un'altra storia )
ciao
"The DeerBear" <rain...@tin.it> wrote in message
news:b9de8r$i3f7d$1...@ID-170738.news.dfncis.de...
Quote:
> serve a non creare form con una moltitudine di controlli figli;
> in altre parole, se in un form metti un controllo tab, e in ogni tab
> metti una serie di controlli, indipendentemente dal fatto che tali
> controlli siano mostrati o no, essi vengono sempre caricati;
> un controllo tab non container viene utilizzato in tutti quei casi di
> istanziazione a runtime di singola "pagina" di controlli;
mai usata cosi , cmq oramai li metto vicino ai controlli invisibili tipo
Timer winsock ecc.. tutta rimpicciolita
poi metto i miei frame ( che corrispondono ai tab cliccati) in cascata di
solito a sinistra fuori dall'area di sviluppo , guarda per me e' comodissimo
da utilizzare , ho modificato la routine di msdn e ci ho inserito anche le
funzioni di posizionamento del tabstrip ( da cui poi posiziono tutti i
frame )
l'sstab non l'ho mai provato fin'ora appunto perche' "dovevo" tenermelo in
mezo ai piedi , mentre visto che il tabstrip non fa da container lo butto in
giro e tengo tutto ordinato ^_^
--
<Gigio2K>
Sito Comune
Nokia -> I.T.H.N. -> http://www.ithn.it/
VB -> I.C.L.VB -> http://www.it-lang-vb.net/
Quote:
> E la visione dei vari "contenitori" in fase di progettazione/design?
> Comodissimi, vero? ;-)
eh eh , hai toccato la nota critica !!!
Cmq una volta "prese a mano" le dimensioni, metti i frame in cascata e bon !
^_^
E' tutto bello ordinato !!!
> *Lupo* ci ha deliziati con queste righe
>
> Quote:
>> E la visione dei vari "contenitori" in fase di progettazione/design?
>> Comodissimi, vero? ;-)
>
> eh eh , hai toccato la nota critica !!!
> Cmq una volta "prese a mano" le dimensioni, metti i frame in cascata e bon
!
> ^_^
>
> E' tutto bello ordinato !!!
Pensa che nel SSTab quello che disegni in fase di progettazione in ogni Tab
è quello che vedi, clicchi su un'altra linguetta e, magia, vedi (solo ed
esattamente) quel che ci sta dentro e, incredibile, ma vero, quel che vedi
tu è esattamente quello che vedrà il tuo utente.
Io insisto: La mente che ha pensato al TabStrip andrebbe studiata.
Quote:
> Pensa che nel SSTab quello che disegni in fase di progettazione in
> ogni Tab è quello che vedi, clicchi su un'altra linguetta e, magia,
> vedi (solo ed esattamente) quel che ci sta dentro e, incredibile, ma
> vero, quel che vedi tu è esattamente quello che vedrà il tuo utente.
Sarcastico :p
Cmq alletti la mia pigrizia ... ci faccio un pensierino ^_-
> Io insisto: La mente che ha pensato al TabStrip andrebbe studiata.
Ciao Lupotto,
E' vero che il tabstrip è un controllo molto particolare, ma è
anche vero che la presenza e la "conformazione" del tabstrip
hanno un motivo molto valido di essere( leggi la mia reply a Sergio ).
Detto questo, c'è anche da dire che non ci voleva un caspito a
rendere il tabstrip container sin dall'inizio e dargli le stesse
caratteristiche,
oppure di fare in modo che avesse due "modalità" fondamentali di utilizzo
( hai presente la Listbox con i suoi stili? ), no?
Resta poi da vedere se, come al solito, MS per le cose sue usa controlli più
"complessi" che non pubblica e che tiene per se.
Ciao
Andrea
> Lupo wrote:
>
>> Io insisto: La mente che ha pensato al TabStrip andrebbe studiata.
>
> Ciao Lupotto,
>
> E' vero che il tabstrip è un controllo molto particolare, ma è
> anche vero che la presenza e la "conformazione" del tabstrip
> hanno un motivo molto valido di essere( leggi la mia reply a Sergio ).
Ho letto e non contesto.
>
> Detto questo, c'è anche da dire che non ci voleva un caspito a
> rendere il tabstrip container sin dall'inizio e dargli le stesse
> caratteristiche,
> oppure di fare in modo che avesse due "modalità" fondamentali di utilizzo
> ( hai presente la Listbox con i suoi stili? ), no?
Bravo. Intendevo dire _solo_ ed esclusivamente questo. ;-)
Trovata la soluzione che mette d'accordo tutti ^_^
E' il classico uovo di colombo.
Tutto il problema nasce dal fatto che io devo recuperare da un
DB SQLServer dei dati. La cosa bella è che questi dati sono "uniformi",
vale a dire che arrivano tutti dalla stessa tabella, e vengono divisi per
tab.
Ho deciso di usare il Tabstrip ed una *sola* listbox, caricando i dati
corretti al momento del cambio di Tab.
Semplice no?
Ciao
Andrea