Newsgroup: it.comp.lang.visual-basic
Titolo: vbnet (lunghetto)


Sent: Tuesday, May 29, 2001 9:44 PM
Subject: VB-2-the-Max Update: Planning for 
VB.NET
 Today (Part II)
VB-2-THE-MAX UPDATE
News, Articles, and Information from VB-2-The-Max
(
http://www.devx.com/devxpress/gurl.asp?i=1X3359375X15611
) the Online
Knowledge Repository for VB Developers, and DevX
(
http://www.devx.com/devxpress/gurl.asp?i=1X3359375X15612
)
Volume 2, No. 22; May 29, 2001
Copyright 2001 DevX, Inc.
_____________________________________________________________
SPONSORED BY COMPUWARE
FREE Technical Paper: "Moving from Visual Basic 6 to 
VB.NET
"
Get a heads up on some of the changes that you need to make to move
existing projects to 
VB.NET
 and find out how to write now for an easier
transition later.
http://www.devx.com/devxpress/gurl.asp?i=1X3359375X15613
_____________________________________________________________
IN THIS ISSUE
* 
VB.NET
 Watcher: Planning for 
VB.NET
 Today (Part II)
* New Entries in the Magazine Bank and KB Bank
* Announcing DevX Knowledge Xchange
* Don't Let Them Crack Your Site
* Missed Any Newsletter Issues?
* Code for a Better User Interface
* Tip Of The Week: Determine Whether the VB IDE Is the Foreground
Process
* Shop the MarketPlace Specials
* What Can I Do Now about .NET
* Want to Maximize Your VB knowledge?
_____________________________________________________________
VB.NET
 WATCHER: PLANNING FOR 
VB.NET
 TODAY (PART II)
This is the second part of an article that appeared in volume 2; No. 18
(April 30, 2001) of this newsletter. It extends the list of which
statements you should avoid in your VB6 apps today to ease the
transition to 
VB.NET
 tomorrow.
9) Stay away of controls that aren't supported under 
VB.NET
.
The following VB6 controls aren't supported under 
VB.NET
: Data and RDO
Data control, OLE Container control, diagonal Line controls, and circles
or oval Shape controls. You won't need the regular or the RDO Data
control in 
VB.NET
 (because they wouldn't work with 
ADO.NET
 anyway), so
they aren't an issue. As for the missing Line and Shape controls, you
should replace them with the corresponding graphic methods in the form's
Paint event.
10) Use constants when indexing an element of a control array.
Control arrays aren't supported in 
VB.NET
. In most cases, the Upgrade
Wizard correctly converts the elements of an array of controls into
individual controls (not in an array), but it fails to do so if your
code references an element of a control array using a variable index, as
in
     txtFields(n).Text = ""      instead of txtFields(0).Text = ""
Thus, you should revise your code so that only constant indexes are
used.
11) Don't use As Any in Declare statements.
While 
VB.NET
 supports the Declare statement, it doesn't support the As
Any clause that you use in VB6 to suppress type checking and use the
same Declare with different data types. To prepare for the transition
you should use only strongly-typed Declare statements. For example, the
SendMessage declare uses an As Any argument, in order to let you pass
either a string or a Long to the last argument:
    Declare Function SendMessage Lib "user32" Alias "SendMessageA" _
        (ByVal hwnd As Long, ByVal wMsg As Long, _
        ByVal wParam As Long, lParam As Any) As Long
To prepare for 
VB.NET
 you should replace the above statement with the
following pair:
    Declare Function SendMessageByString Lib "user32" Alias
"SendMessageA" _
        (ByVal hwnd As Long, ByVal wMsg As Long, _
        ByVal wParam As Long, ByVal lParam As String) As Long
    Declare Function SendMessageByLong Lib "user32" Alias "SendMessageA"
_
        (ByVal hwnd As Long, ByVal wMsg As Long, _
        ByVal wParam As Long, ByVal lParam As Long) As Long
and replace all the calls in code accordingly.
12) Don't use the ItemData property.
VB.NET
 ListBox and ComboBox controls don't support the ItemData
property, thus any VB6 code that uses them will have to be revised when
ported to the newer version. Instead of using the ItemData property,
store the relevant information inside a parallel array, and reference
the array items using the ListBox element's index. In other words,
element 0 of the array should contain the ItemData for the first value
in the listbox, element 1 for the second value in the listbox, and so
on. This technique has the added benefit of letting you store any type
of values (if you pick a suitable data type for the array), whereas the
ItemData property can only store Long values.
13) Don't use LSet to make assignments between UDTs of different type.
VB6 supports (or better, tolerates) assignments between UDTs of
different types, using the LSet command. This advanced, and admittedly
rarely used, technique isn't supported under 
VB.NET
, thus you have one
more reason not to use it.
14) The NewIndex property isn't supported.
VB.NET
 Listbox and Combobox controls don't support the NewIndex
property, so you should avoid using it. In VB6 the NewIndex property was
often used together with the ItemData property (which is gone as well,
see point 12 above), so in most cases you have few reasons for using
NewIndex under 
VB.NET
.
15) Encapsulate access to the Forms, Printers, Print, Clipboard, App
objects. The above objects aren't supported in 
VB.NET
, which in most
cases offers alternative (but not always perfectly equivalent) objects.
To help the migration of your code to 
VB.NET
 you should never reference
those objects from the main program. Instead, create a wrapper procedure
that does the operation you mean to perform (e.g. enumerate printers,
print to the default printer, do a copy or paste operation), so that
you'll have to upgrade only a few procedures when you switch to 
VB.NET
.
16) Forget about twips--start thinking pixels.
All .NET languages work with pixels exclusively, and twips aren't
recognized any longer. Start working with pixels today and the
transition will be smoother tomorrow.
-- Francesco Balena (
fba...@vb2themax.com
)
OTHER DEVX NEWSLETTERS THAT MIGHT INTEREST YOU:
HOTLINKS NEWS (Weekly update covering what's new and exciting on DevX)
VB Update (Biweekly newsletter covering VB and .NET issues)
.NET Update (Our newest monthly newsletter focusing on .NET)
Web Design Update (Monthly newsletter covering Web design issues)
Web Development Update (Biweekly newsletter covering Web design issues)
Database Dev Update (Biweekly newsletter covering DB2, SQL Server, and
all other databases)
Wireless Development (A Biweekly newsletter covering this year's hottest
technology)
To sign up, or to see a list of all available e-mail newsletters, go to:
http://www.devx.com/devxpress/gurl.asp?i=1X3359375X15629
-------------------------------------------------------------
HOW TO SUBSCRIBE OR UNSUBSCRIBE
Your e-mail address is in our mailing list. To subscribe or unsubscribe
to any DevX newsletter, go to
http://www.devx.com/free/newsletters/

 recognized any longer.
___________________________
Questo sarebbe un upgrade ? Non sarebbe il caso di chiamarlo
downgrade, o mi sfugge qualcosa ?
Bye, G.

 downgrade, o mi sfugge qualcosa ?
E' un ottimo sistema per lasciare spazio alle terze parti. Sempre che sia
ancora possibile produrre add-on da parte di terze parti...
Ciao
*Roby*


[...]

 > downgrade, o mi sfugge qualcosa ?
Secondo me sarà solo questione di abitudine ... sono convinto che sia stato
fatto un passo avanti .. speriamo !
Saluti

 tonnellate di codice
Già, la tragedia è questa (indipendetemente dai *grandi* passi avanti).
Ma pensa alle S.H. che hanno prodotto procedure mastodontiche in VB con
investimenti miliardari!
Ciao, Simone

 E' un ottimo sistema per lasciare spazio alle terze parti.
spazio, si'.
loculi, per l'esattezza.
ciao, a.

http://www.numega.com/library/dmpapers/vb6net_vb.shtml

 Ciao, Simone
Se VB .NET non sara' 100% portabile, presento grandi cambiamenti...
Io spingero' per l'uso di tools piu' garantiti sul lungo periodo, e dato che
abbiamo applicazioni in delphi 3 e stiamo per acquistare delphi 4, posto che
l'interfaccia sia sufficientemente usabile penso che switchero' su quella.
Spero che in Borlaqnd decidano di mettere una immediate window e una set
next statement, a quel punto mi sentirei davvero a casa :P
Ciaotutti,
Asterix

 next statement, a quel punto mi sentirei davvero a casa :P
Eh, eh ... credo che Inprise trarrà grandi benefici :-)
Tra l'altro riflettevo su un fatto che nessuno ha ancora rimarcato: se
davvero sarà possibile compilare solo a livello intermedio con 
VB.NET
,
molte tipologie d'applicazione saranno troppo penalizzate nelle prestazioni
rispetto a VB6 e Delphi...
Ciao.

 arrays e oggetti come printer ecc.)
I motivi sono dovuti al totale ridisegno dell'architettura di VB.
VB.NET
 e' "costretto" a seguire cio' che e' stato pensato e
concepito per .NET.
I controlli classici del VB non esistono piu', non esistono piu'
ocx, dll Active-X, ecc... (anche se per compatibilita' e' sempre
possibile utilizzarli).
Ora esiste solo una libreria di classi da utilizzare. Cosi' non
esistono piu' file .frm, .cls, .bas, ma solo semplici file di testo
(.vb) e tutto e' semplice codice.
Dato che la libreria di classi e' condivisa da tutto .NET (puoi in
VB utilizzare classi scritte in C#, in managed C++, e viceversa) per
non perdere l'interoperabilita' fra tutti i linguaggi che 
VB.NET
sara' costretto a subire modifiche cosi' sostanziali.
Tutto cio' porta ad un'inevitabile incompatibilita' fra codice VB
"vecchio" e codice 
VB.NET
, ma fare altrimenti avrebbe escluso il VB
da tutta l'architettura, costringendolo IMHO a morire molto in
fretta.
Quello che non mi convince affatto, sono alcune scelte (dettate
dalle proteste dei programmatori VB) di tornare indietro su alcune
modifiche sintattiche del linguaggio, tra le quali la piu'
importante e' la vecchia dichiarazione di un Array.
Per cui (ma non e' solo per questo ovviamente) ho deciso di
tralascare totalmente VB per dedicarmi al C# (e al C++ ovviamente
;-)).
Ciao.

 rispetto a VB6 e Delphi...
Non e' cosi'. E' vero che tutte le applicazioni .NET (VB, C#,
ecc...) verranno compilate in IL (Intermediate Language), ma cio'
non causa problemi di prestazioni. Al momento dell'esecuzione del
programma questo viene compilato in codice nativo della piattaforma.
Se cerche tra i post passati vedrai che c'e' un piccolo test in cui
un applicazione 
VB.NET
 (beta 1) nella lettura di un milione di righe
di un file di testo (per un totale di una 50ina di MB) ottiene gli
stessi tempi di due programmi in C e in C++, circa 3 secondi tutti e
tre, contro gli oltre 40 dell'equivalente in VB6 (utilizzando le
funzioni del VB) ed i 13 circa del prog. VB6 che utilizzava il File
System Object..
Ciao.

 System Object..
Questo è davvero interessante, però mi piacerebbe vedere confronti
prestazionali su calcoli a virgola mobile.
Ciao, Simone

 vedere confronti prestazionali su calcoli a virgola mobile.
Scrivi un po' di codice che vorresti testare che faccio la prova.
Ciao.

 Scrivi un po' di codice che vorresti testare che faccio la prova.
E' una parola :-)
Mi sarebbe piaciuto testare degli algoritmi numerici per risolvere equazioni
differenziali e integrali, ma non è roba molto pratica da convertire!
Ti ringrazio per la disponibilità, magari appena avrò tempo di testare la
Beta di 
VB.NET
 farò delle prove e vi faccio sapere.
Ciao, Simone

 compilato/interpretato.
Questa te la risolvo io :)
La compilazione non e' JIT, il codice viene compilato una sola volta (da IL
a nativo) all'atto della prima esecuzione della porzione di codice medesima
o dell'installazione del programma (secondo la scelta del programmatore mi
pare).
Se si opta per una compilazione JIT-style la prima esecuzione sara'
ovviamente piu' lenta, le successive avranno la velocita' di un codice
nativo normale.
Ciaotutti,
Asterix

 ha scritto nel messaggio
news:9f4tij$24osb$1...@ID-68324.news.dfncis.de...


 codice prodotto.
... omissis...
Sei stato chiarissimo come sempre Alfonso, ma...
non avevo seguito il thread... che fatica capire a cosa ti riferivi...
:-)
ciao
ugo

 non è roba molto pratica da convertire!
Convertire da cosa?
Ciao.

 capito ? Quindi è velocissimo, come quello del C!
Cerca di mantenere la calma ciccio... vedrai che sopravviverai ad altre
legittime richieste simili alla mia.
Simone

 Pertanto ha le stesse prestazioni di un normale eseguibile in C/C++.
Ok, come ha scritto *Alessandro* quindi.
E' bene precisare che anche con Java è possibile imporre la compilazione
nativa all'atto del caricamento dei bytes-code in memoria.
Ciao, Simone

 Sei stato chiarissimo come sempre Alfonso
Sě, ma idee chiare sulla differenza tra codice compilato in forma
intermedia (vedi bytecode) ed esecuzione brutalmente interpretata non le ha.
Se avesse fatto tests in quel senso saprebbe che l'esecuzione di BytesCode
(o di P-Code) č estremamente piů veloce rispetto all'esecuzione *veramente*
interpretata dei cosiddetti linguaggi di script.
Ciao, Simone

 > Sei stato chiarissimo come sempre Alfonso
[...]

 wrote in message
X%uR6.47$ZZ....@news.infostrada.it...



Guarda che č esattamente quello che ha detto...
ciao
ugo

 Alfonso
:D
ciao
ugo

 compilati in linguaggio intermedio.
E io che ho scritto? :)
Ciaotutti,
Astericchio :)

 > IL
[...]

 sono calmissimo.
Ostia!

 Guarda che č esattamente quello che ha detto...
Non proprio.
Simone

 brutalmente interpretata.
Omnis Studio, Filemaker, Access (se si usano le vecchie macro) sono esempi
di linguaggi di script "brutalmente" interpretati a Runtime a partire da un
formato di memorizzazione simil ASCII.
Un codice salvato in forma meta-compilata è tradotto in un set d'istruzioni
ridotte e risparmia un mucchio di lavoro alla virtual machine.
Dato che sul web trovi una vasta ed esaustiva letteratura sulle tecnologie
di compilazione P-code e/o ByteCode, ti consiglio d'informarti prima
d'andare avanti con la *polemica*.
Simone

 Infatti non ce l'avevo con te. :))
Beh, visto che l'oggetto era  "[!] Avete un pň di confusione..."  non
sembrerebbe che tu ce l'avessi solo con me.
Impariamo l'italiano, e studiamo qualcosa in piů sui linguaggi interpretati,
compilati, meta-compilati.
Soltanto dopo mettiamoci a far casino sui ng.
Simone


"Non SOLO",  non "non proprio".
ciao
ugo

 Impariamo l'italiano, e studiamo qualcosa in più sui linguaggi


 ha scritto nel messaggio
news:FRPR6.6503$ZZ.2...@news.infostrada.it...


 sull'argomento, e quindi un po' di chiarezza fa sempre bene.
Ok, sei stato semplicemente e gratuitamente maleducato ... ecco perchè me la
sono presa.
Ciao, Simone

 disponibili solo al momento del bisgono
Sono comunque perplesso. Supponiamo che per leggere la directory della
propria applicazione invece di:
sMyDir = App.Path
si debba fare:
sMyDir = Applications(VBNETMyApp).Paths.Executable
Non potevano comunque gestire una classe App che facesse da wrapper?
Io capisco la necessità di passare ad una sintassi comune tra diversi
linguaggi, ma scrivere dei wrapper è sempre possibile, e risolve una marea
di problemi agli utilizzatori, altrimenti finisce che ognuno di noi trova
costretto a scrivere il proprio wrapper, e lo spreco di tempo moltiplicato
per i milioni di sviluppatori sarebbe mostruoso.
Ciao
*Roby*

 to rewrite any code that uses the standard vb. constants
No, dai, ma perchè? Questa è pura e semplice cattiveria.
Ottima notizia invece sia l'editor di menù migliorato, che la nuova
proprietà dei controlli che permette di gestire facilmente il resize delle
form, ma mettendo sul piatto vantaggi e svantaggi, non saprei dire da che
parte penda la bilancia..
Ciao
*Roby*


Io prevedo un passaggio VB6->VB8oppure VB6->Delphi.
Sinceramente date le premesse usero' VB6 finche' potro' poi cerchero' un
altro linguaggio.
Ciaotutti,
Asterix

 sMyDir = Applications(VBNETMyApp).Paths.Executable
sMyDir = Application.StartupPath
http://msdn.microsoft.com/library/default.asp?URL=/library/dotnet/cp
ref/frlrfsystemwinformsapplicationmemberstopic.htm per tutto cio'
che riguarda la classe Application.
Ciao.

sMyPath=Application.StartupPath
Il problema sta nel fatto che esistono due versioni per Debug e retail
quindi il risultato è diverso tra Debu e Runtime..
Ciao
Corrado


E' ovvio, sono due eseguibili diversi. D'altra parte in VB6 durante
la fase di debug (dall'IDE) restituisce il percorso di VB, non
dell'applicazione (perche' il processo e' quello dell'IDE).
Ciao.

 dell'applicazione (perche' il processo e' quello dell'IDE).
Quello che dici vale solo se non salvi l'applicazione,ma appena salvi il
progetto App.Path di VB6 ritorna il percorso dove hai salvato il progetto (e
ci mancherebbe), quindi tra RunTime e Debug non cambia nulla.
in VBNet invece avrai notato che esistono due diverse directory (debug e
retail) ove il compilatore scrive l'eseguibile quindi
Application.StartupPath di VBNet ritorna a seconda della situazione
...\Debug oppure ...\Retail
Ciao
Corrado

 ...\Debug oppure ...\Retail
Certamente, ma e' ovvio e giusto che sia cosi'. Ti restituisce il
percorso dell'eseguibile che hai lanciato, che e' appunto o la
versione debug o la versione retail (che si trovano in differenti
directory). Sinceramente non vedo quale siano i problemi che un
simile comportamente debba causare.
Ciao.

 simile comportamente debba causare.
Nessuno, basta saperlo!, in VBNet sono tante le cose che bisogna sapere...
;-)
Ciao
Corrado

 Nessuno, basta saperlo!, in VBNet sono tante le cose che bisogna
sapere...
Basta sapere che App.Path (in VB) e Application.StartupPath (in
VB.NET
) restituiscono il percorso dell'eseguibile. Questo basta.
Oltretutto ho visto (e' gia' un po' che uso C# m non piu' 
VB.NET
)
che le dir Debug e Release ci sono in C# , in VB le versioni debug e
release dell'eseguibile sono nella stessa dir (bin).
In ogni caso, C# o VB, quando installerai l'applicazione le dir
Debug e Release non esisteranno piu'.
Ciao.