Newsgroup: it.comp.lang.visual-basic
Titolo: Un'altra notizia su VB6

E' questa, ed è pessima: il nuovo controllo comctl32.ocx non sarà più solo
un 'wrapper' per le funzioni contenute in comctl32.dll, ma implementerà i
common control direttamente nei file ocx. Pare che questo sia avvenuto per
controversie con il team di sviluppo di Internet Explorer che continua ad
aggiornare comctl32.dll in maniera completamente autonoma.
Risultato: fino ad oggi una toolbar in un programma VB, VC++, Delphi,
FORTRAN o quello che volete voi era sempre esattamente la stessa toolbar, lo
stesso codice, contenuto in Comctl32.dll. Da VB6 in poi una toolbar di un
programma VB6 sarà implementata da un codice diverso da quello che useranno
VC++, Delphi, BC++ eccetera. Non so perché si continuino a chiamare Common
control. Naturalmente, anche la documentazione del codice sottostante andrà
a farsi benedire, perché su msdn fino ad oggi abbiamo trovato la
documentazione di tutte le funzioni di comctl32.dll, ma che ce ne faremo,
ora? L'invito, sicuramente ignorato dai più, è di implementare a mano i
common control della dll ignorando i nuovi ocx. Io farò certamente così (o
userò i controlli CCRP, naturalmente). I miei sentimenti nei confronti del
VB in questo momento sono molto vicini a quelli di Roal Zanazzi, con il
quale pure ho dolcemente polemizzato qualche giorno fa.
Commenti?
Domenico

...


saluti

E' una domanda che avrei voluto fare da tempo. Che significa CCRP?
Fabio Guerrazzi.

...


Ho visto il sito. Ottimo. I miei migliori complimenti.
Fabio Guerrazzi.


Beh, mi si tira in causa... :-)
1) Non ci credo (non voglio crederci, meglio).
2) La fonte della notizia?
3) Esistono (l'ho gia chiesto giorni fa per la COMDLG32.OCX) delle classi
scritte in VB4/5 che permettano di ignorare il maggior numero possibile di
OCX?
4) Le CCRP le ho scaricate giorni fa, ma non ho ancora avuto il tempo di
guardarle. Ho solo visto che sono OCX (grrr... :-) e allora... ignorare un
OCX M$ per usarne un'altro? Non e' piu' rischioso?
Dato che le alternative sono poche:
1) si sostituisce il COMCTL32.OCX con delle classi mirror che incapsulano le
chiamate a COMCTL32.DLL
PRO: no OCX aggiuntivo da distribuire
          possibilita' (avendo i sorgenti) di creare versioni modificate
custom dei common-controls.
CONTRO: si perde tutta l'utilita' di VB (le classi non sono controlli
modificabili a design-time)
          ad ogni modifica della COMCTL32.DLL si devono aggiornare le
classi.
2) si usano OCX alternativi
PRO: <non me ne viene in mente nessuno>
CONTRO: la situazione non e' molto differente rispetto all'uso degli OCX di
M$.
P.S. ma perche' diavolo non esistono "classi visuali" scrivibili in codice
VB ed utilizzabili anche a design-time (come in Delphi, C++Builder)?
E pensare che la giornata stava cominciando bene...
--
Roal Zanazzi
z...@iol.it

E pensare che la giornata stava cominciando bene...
Mi dispiace di avertela rovinata.
Saluti,
Domenico

Ciao. Ho visto il sito come dicevo, ho scaricato alcuni CCRP e li ho
provati. Se posso esprimere la mia opinione, sperando di non offendere
nessuno... Indubbiamente sono molto carini, completi e tecnicamente validi,
ma non credi che sia un'inutile dispendio di energie costruire controlli che
hanno si e no il 5% in più di potenzialità rispetto ai controlli M$? Capisco
perfettamente la motivazione che spinge a realizzarli ma  la funzione
principale dell'esistenza di controlli dovrebbe essere quella di facilitare
la scrittura di applicazioni che richiederebbero, senza OCX, parti di codice
ridondante. Perchè  (e qui torno all'oggetto della tua nota) allarmarsi
sulla perdita di alcune caratteristiche degli OCX quando la maggior parte
dei programmatori tende a utilizzarli sempre di meno. Come hai detto tu,
costruirai i Dialog direttamente dalle DLL. E non è giusto così? forse lo
scopo è proprio quello di lasciare separato VB dal Kernel di Windows e dare
la possibilità di creare le applicazioni più personalizzate possibili. Dal
mio modesto punto di vista, gli OCX dovrebbero essere solo uno strumento di
apprendimento, poi ognuno si costruisce le proprie classi, i propri
controlli e si spersonalizza il più possibile dallo standard tecnico e
grafico dei controlli, creando ripeto, applicazioni proprie, e non surrogati
di VB.
Non credi che con questa innovazione si distinguerà ancora meglio il
programmatore bravo da quello scadente?
E poi, secondo me, ci siamo adattati a tutto, non sarà certo questo che ci
impedirà di lavorare.
Fabio Guerrazzi

 Common Control Replacement Project.
[SNIP]
Ne approfitto per fare una domanda; ho provato più volte a scaricare alcuni
controlli CCRP, il file dialog e (mi pare) il timer, il problema è che non
mi riesce mai di registrarli, può dipendere dal fatto che ho VB5 (con SP3)
in versione ITALIANA??
Ciao.
Luca Dormio (
ldo...@tin.it
)

quale pure ho dolcemente polemizzato qualche giorno fa.
  I miei sentimenti piu' che al VB, che mi pare esso stesso vittima
delle diatribe tra i vari team microsoft, vanno (ovviamente in
negativo) a chi dovrebbe vigilare affinche' il software in comune tra
piu' team venga gestito di comune accordo con la massima serieta'.
  Ciao :-)
  Massimo
  Nell'indirizzo, sostituire DIESPAMMERS con MC1258
  In the address, replace DIESPAMMERS with MC1258

...

Ciao.
Non saprei perché non riesci a registrarli, né credo che dipenda dalla
versione italiana. Per il file dialog, che errore ti dà?
Domenico
Luca Dormio ha scritto nel messaggio <01bdb3e6$25393cc0$20ca09c0@luca>...


Corrado
Grazie.
Ciao,
Domenico

di VB.
Forse non ho capito bene: vuoi dire che dopo un po' ognuno dovrebbe
costruirsi l'equivalente del controllo che gli serve in quel momento? se è
così, guarda che è una follia: esiste già dell'ottimo codice in
comctl32.dll, e soprattutto è codice altamente personalizzabile: tutti i
controlli hanno una modalità OWNERDRAW o almeno callback e subclassing per
una completa personalizzazione. Poi, se il sistema operativo cambia, quel
pezzo di sistema operativo che si mostra attraverso il controllo si mostrerà
automaticamente nella sua nuova veste.
Ciao,
Domenico


Forse mi ero proprio spiegato male. Ogni programmatore dovrebbe fare uso dei
controlli che gli ha messo a disposizione M$, sfruttarne le potenzialità
fino all'osso e quando non bastano più fare da sè.
Non so se hai mai sviluppato con dei Case di sviluppo. La generazione di
applicazioni è rapidissima, ma finisce per essere insufficiente per i
vincoli dati appunto dal case. Gli OCX sono un pò così, anche quelli
supersofisticati, finiscono per essere delle confezioni con delle
potenzialità che l'autore gli ha imposto.
E il programmatore che lo utilizza si accorgerà sempre che manca qualcosa.
Ritorno sull'argomento. Microsoft fa bene a spezzare la programmazione VB
con OCX e senza e quindi fa bene a rendere gli OCX slegati dal sistema
operativo.
Per me l'OCX deve essere e deve rimanere solo la vetrina del SO. Se in una
mia applicazione avessi bisogno di un controllo come il tuo (FielDialog)
sarebbe più naturale che, invece di aggiungere componenti, aggiungessi
codice.
Forse non sono stato chiaro per la seconda volta, e forse mi sbaglierò, ma
ho la sensazione che facciamo il gioco di Microsoft, quello di appesantire
inutilmente i nostri PC e anche noi stessi (viaggiamo su velocità di nozioni
impressionante). Comunque sia mi complimento di nuovo con te, che ritengo la
persona più competente e più seria di tutto il NG.
Fabio Guerrazzi

persona più competente e più seria di tutto il NG.
Ti ringrazio davvero molto, ma..... magari!!!
Saluti,
Domenico


Ma certo, fin che c'e' vita c'e' speranza... arghrrgggga aohhhhhhhh  ha
8-|
--
Roal Zanazzi
z...@iol.it