Przygotowanie aplikacji napisanych w Visual Basic 0 do uaktualnienia do Visual Basic. Net



Pobieranie 131.22 Kb.
Data01.05.2016
Rozmiar131.22 Kb.

Przygotowanie aplikacji napisanych w Visual Basic 6.0 do uaktualnienia do Visual Basic .NET


Microsoft Corporation

Streszczenie
Dokument ten zawiera wskazówki dla programistów piszących w języku Microsoft Visual Basic, planujących przeniesienie aplikacji do Visual Basic .NET. Opisano w nim narzędzie Visual Basic .NET Upgrade Tool i omówiono podstawowe wytyczne pozwalające na bezproblemowe uaktualnienie kodu aplikacji Visual Basic 6.0 do Visual Basic .NET.
Długość dokumentu — około 25 stron drukowanych

Spis treści


Wprowadzenie
Charakterystyka języka Visual Basic .NET
Dlaczego w Visual Basic .NET nie zachowano 100% zgodności wstecz
Uaktualnianie do Visual Basic .NET
Równoczesna praca w Visual Basic 6.0 i Visual Basic .NET
Zalecenia dotyczące architektury
   Aplikacje oparte na przeglądarce internetowej
   Projekty aplikacji klient-serwer
   Aplikacje jednowarstwowe
   Dane
Uaktualnianie
   Zamiana Variant na Object
   Zamiana Integer na Short
   Składnia właściwości
   Zamiana Visual Basic Forms na Windows Forms
   Interfejsy
Raport z aktualizacji i komentarze
Wskazówki dotyczące programowania
   Używaj wczesnego wiązania
   Do przechowywania dat używaj typu Date
   Specyfikuj bezparametrowe właściwości domyślne
   Unikaj propagacji wartości Null
   Stosuj tablice indeksowane od zera
   Stosuj stałe zamiast jawnie podawać ich wartości
   Tablice i łańcuchy stałej długości w typach definiowanych przez użytkownika
   Unikaj stosowania przestarzałych funkcji
   Interfejsy Windows API
   Uwagi dotyczące stosowania formularzy i kontrolek

Wprowadzenie


Dokument zawiera zalecenia dla programistów piszących w języku Microsoft Visual Basic, planujących przeniesienie aplikacji do Visual Basic .NET.

W środowisku programowania Visual Basic .NET można otwierać projekty Visual Basic 6.0 i uaktualniać je do technologii Visual Basic .NET. W większości przypadków po przeniesieniu projektu do Visual Basic .NET konieczne jest wprowadzenie w nim pewnych zmian. Celem tego dokumentu jest wskazanie takich metod projektowania i opracowywania bieżących projektów Visual Basic, które pozwolą zminimalizować liczbę zmian koniecznych do uaktualnienia tych projektów do technologii Visual Basic .NET. W dokumencie — wszędzie gdzie było to możliwe — użyto nowych konstrukcji języka VB.NET, jednak dokumentu tego nie należy traktować jako podręcznika programisty Visual Basic .NET.


Charakterystyka języka Visual Basic .NET


Visual Basic .NET to nowa wersja języka Visual Basic. Unowocześnienie nie polegało na prostym dodaniu kilku funkcji do języka Visual Basic 6.0. Firma Microsoft zdecydowała się całkowicie przeprojektować produkt tak, aby dużo łatwiejsze stało się tworzenie przy jego użyciu aplikacji rozproszonych, takich jak aplikacje internetowe czy n-warstwowe aplikacje biznesowe. Visual Basic .NET zawiera dwie nowe biblioteki interfejsów użytkownika (Windows Forms i Web Forms) oraz nową wersję biblioteki ADO, umożliwiającą dostęp do danych w trybie offline. Język został uproszony — usunięto niepotrzebne już słowa kluczowe, poprawiono bezpieczeństwo typów i udostępniono konstrukcje niskiego poziomu, na których szczególnie zależało zaawansowanym programistom.

Wymienione cechy otwierają przed programistami korzystającymi z języka Visual Basic nowe możliwości. Programiści, korzystając z Web Forms i ADO.NET, mogą teraz szybko tworzyć skalowalne witryny internetowe; obsługa dziedziczenia pozwala zaliczyć język do grupy języków zorientowanych obiektowo; biblioteka Windows Forms natywnie obsługuje ułatwienia dostępu i dziedziczenie wyglądu, a wdrażanie aplikacji jest w tej chwili tak proste jak przekopiowanie plików wykonywalnych i komponentów z folderu do folderu.

Visual Basic .NET jest w pełni zintegrowany z innymi językami Microsoft Visual Studio .NET. Każdy składnik aplikacji można teraz napisać w innym języku programowania, a na dodatek — dzięki dziedziczeniu międzyjęzykowemu (cross-language inheritance) — klasy napisane w jednym języku mogą dziedziczyć po klasach napisanych w innych językach. Za pomocą zunifikowanego debugera można wykrywać błędy w aplikacjach napisanych w kilku różnych językach, bez względu na to, czy aplikacje uruchamiane są lokalnie, czy na komputerach zdalnych. Niezależnie od użytego języka programowania, Microsoft .NET Framework dostarcza bogaty zestaw interfejsów API dla środowiska Microsoft Windows® i dla Internetu.

Dlaczego w Visual Basic .NET nie zachowano 100% zgodności wstecz


Przy projektowaniu Visual Basic .NET rozważano dwie możliwości — zmodernizowanie istniejącego kodu w sposób umożliwiający poprawne działanie w środowisku .NET Framework albo opracowanie języka od podstaw tak, aby w pełni wykorzystywał wszystkie cechy i funkcje nowej platformy. Aby udostępnić funkcjonalność, o którą najczęściej prosili użytkownicy (na przykład dziedziczenie czy wielowątkowość) oraz zapewnić pełny i swobodny dostęp do platformy, a także umożliwić pisanie w języku Visual Basic aplikacji internetowych nowej generacji, zdecydowano się na wybór drugiej możliwości, czyli opracowanie języka od podstaw, specjalnie dla nowej platformy.

Wiele spośród nowych funkcji, dostępnych w bibliotece Windows Forms, można było dodać do istniejącej bazy kodowej jako nowe kontrolki i dodatkowe właściwości, jednak odbyłoby się to kosztem innych cech dostępnych w Windows Forms — na przykład bezpieczeństwa i dziedziczenia wyglądu.

Jednym z głównych celów Microsoft było zapewnienie pełnej interoperacyjności kodu napisanego w Visual Basic z kodem napisanym w innych językach programowania, takich jak Microsoft Visual C#™ czy Microsoft Visual C++®, i umożliwienie programistom języka Visual Basic wykorzystania wszystkich funkcji i możliwości platformy .NET Framework w sposób prosty, bez uciekania się do różnych obejść programistycznych, które były na przykład potrzebne do korzystania z interfejsów Windows API. Obsługa typów danych, tablic, typów definiowanych przez użytkownika, klas oraz interfejsów w języku Visual Basic jest obecnie zgodna z językiem Visual C++ i wszystkimi innymi językami współpracującymi ze wspólnym środowiskiem uruchomieniowym CLR (Common Language Runtime). Z tego powodu konieczne było usunięcie z języka pewnych cech, takich jak łańcuchy stałej długości i tablice o indeksie początkowym innym niż zero.

Visual Basic stał się teraz językiem w pełni zorientowanym obiektowo. Inne modyfikacje objęły usunięcie niektórych nieintuicyjnych i niespójnych elementów, na przykład GoSub/ReturnDefInt.

W rezultacie język Visual Basic został całkowicie zmodyfikowany. Nadal jest najbardziej wydajnym narzędziem do tworzenia aplikacji dla Windows, a na dodatek stał się najlepszym narzędziem do tworzenia witryn internetowych nowej generacji.

Uaktualnianie do Visual Basic .NET


Visual Basic .NET pozwala na przejście od tradycyjnego programowania dla Windows do tworzenia aplikacji internetowych i aplikacji n warstwowych kolejnej generacji. Z tego powodu istniejący kod źródłowy należy uaktualnić tak, by możliwe było wykorzystanie wszystkich zalet i możliwości języka Visual Basic .NET.

Konwersja wykonywana jest automatycznie w momencie otwarcia projektu Visual Basic 6.0 w środowisku programowania Visual Basic .NET. Kreator uaktualniania krok po kroku przeprowadza użytkownika przez proces uaktualnienia kodu i tworzy nowy projekt Visual Basic .NET (stary projekt pozostaje niezmieniony). Jest to proces jednokierunkowy — projektu Visual Basic .NET nie da się otworzyć w środowisku Visual Basic 6.0.

Uaktualnienie projektu polega na uwzględnieniu w kodzie źródłowym wszystkich zmian wprowadzonych w składni języka i utworzeniu interfejsu Windows Forms na podstawie interfejsu z projektu Visual Basic 6.0. W większości przypadków, po automatycznym uaktualnieniu kodu trzeba jeszcze wprowadzić pewne zmiany. Jest to konieczne, ponieważ niektóre obiekty i funkcje nie mają swoich odpowiedników w Visual Basic .NET lub ich odpowiedniki za bardzo się różnią, by konwersja mogła zostać przeprowadzona automatycznie. Po zakończeniu procesu uaktualniania, programista może także chcieć zastosować w programie nowe funkcje, dostępne w języku Visual Basic .NET.

Na przykład Windows Forms obsługuje kotwiczenie kontrolek, dlatego można usunąć większość starego kodu napisanego w języku Visual Basic 6.0, dotyczącego zmiany wielkości formularza:





Ilustracja 1. Obsługa kotwiczenia kontrolek w VB.NET

Aby ułatwić programiście wprowadzenie wszystkich koniecznych zmian, w trakcie aktualizacji do projektu dodawany jest raport, w którym wyszczególnione są wszelkie zaistniałe problemy. W uaktualnionym kodzie wstawiane są komentarze zwracające uwagę programisty na instrukcje wymagające modyfikacji. Komentarze te są wyświetlane w oknie listy zadań (Task List) jako zadania „TO DO”, dzięki czemu programista widzi, co jeszcze musi zmienić w kodzie i może szybko odnaleźć instrukcje wymagające modyfikacji, klikając dwukrotnie na odpowiednim zadaniu. Z każdym zadaniem i pozycją w raporcie skojarzony jest temat pomocy, z którego można dowiedzieć się, dlaczego modyfikacja tego fragmentu kodu jest konieczna i co dokładnie należy zrobić.

Stosując zalecenia podane w tym dokumencie, programista może zminimalizować, a w niektórych przypadkach wyeliminować konieczność wprowadzania zmian w kodzie po uaktualnieniu projektu do Visual Basic .NET. W większości przypadków wskazówki te to po prostu dobre zwyczaje programowania. Istnieją jednak obiekty i własności, które nie mają swoich odpowiedników w nowej wersji Visual Basic, dlatego — jeśli w przyszłości planowane jest uaktualnienie projektu do Visual Basic .NET — należy unikać ich stosowania w kodzie Visual Basic 6.0.

Równoczesna praca w Visual Basic 6.0 i Visual Basic .NET


Środowisko programowania Visual Basic .NET obsługuje uaktualnianie wyłącznie projektów Visual Basic 6.0. Jeżeli chcemy konwertować projekty Visual Basic utworzone w wersjach od 1 do 5, zalecane jest wcześniejsze załadowanie ich w Visual Basic 6.0 (z aktualizacją kontrolek Microsoft ActiveX®), a następnie skompilowanie i zapisanie projektu przed uaktualnieniem go do Visual Basic .NET.

Visual Basic .NET i Visual Basic 6.0 mogą być zainstalowane na tym samym komputerze i uruchamiane w tym samym czasie. Analogicznie, aplikacje napisane w Visual Basic .NET i aplikacje napisane w Visual Basic 6.0 także mogą być instalowane i uruchamiane na tym samym komputerze. Komponenty napisane w Visual Basic .NET mogą współpracować z komponentami COM, napisanymi we wcześniejszych wersjach języka Visual Basic lub w innych językach programowania. Na przykład napisane w Visual Basic 6.0 kontrolki ActiveX można wykorzystywać w formularzach Windows Form w Visual Basic .NET, obiektów COM, utworzonych za pomocą Visual Basic 6.0, można używać w bibliotekach klas w Visual Basic .NET, a do plików wykonywalnych tworzonych w Visual Basic 6.0 można dodawać referencje do bibliotek Visual Basic .NET.

Sposób działania komponentów skompilowanych w Visual Basic .NET nieznacznie różni się od sposobu działania komponentów skompilowanych w Visual Basic 6.0. Z uwagi na to, że obiekty Visual Basic .NET są zwalniane poprzez proces odzyskiwania pamięci (garbage collection), niszczone obiekty w rzeczywistości usuwane są z pamięci dopiero po pewnym czasie. Pozostałe różnice dotyczą zamiany typu Variant na typ Object. Zostało to opisane w dalszej części tego dokumentu. W rezultacie wprowadzonych zmian, aplikacje napisane w Visual Basic .NET pod względem uruchomieniowym będą zachowywały się podobnie — ale nie identycznie — jak ich odpowiedniki napisane w Visual Basic 6.0.

Visual Basic .NET nie wymaga binarnej kompatybilności pomiędzy komponentami Visual Basic .NET a komponentami Visual Basic 6.0. System wersjonowania i instalowania komponentów jest teraz lepiej rozwiązany — pliki mogą być instalowane przez zwykłe skopiowanie ich do właściwego folderu (narzędzie RegSvr32 nie jest już potrzebne), a uaktualnianie komponentu do nowej wersji polega na zastąpieniu starego pliku nowym. Konieczne jest tylko zapewnienie zgodności nowych wersji klas z wersjami starszymi.


Zalecenia dotyczące architektury


Architektura platformy .NET została znacznie ulepszona w stosunku do wcześniejszych architektur — pozwala na lepszą obsługę skalowalności i obsługę aplikacji rozproszonych poprzez dostęp do danych w trybie offline, transport komunikatów oparty na protokole HTTP i wdrażanie aplikacji przez kopiowanie plików (nie ma już konieczności rejestrowania komponentów). Aby w jak największym stopniu wykorzystać te funkcje, architekturę aplikacji należy projektować tak, jakbyśmy projektowali architekturę dla aplikacji Visual Basic .NET.

Aplikacje oparte na przeglądarce internetowej


Visual Basic 6.0 i Microsoft Visual Studio® 6.0 oferowały kilka technologii tworzenia aplikacji intranetowych i internetowych, działających w przeglądarce internetowej:

  • aplikacje Webclass,

  • projekty DHTML,

  • dokumenty ActiveX,

  • Active Server Pages (ASP).

W Visual Basic .NET wprowadzono technologię ASP.NET — rozszerzoną wersję ASP i rozbudowano architekturę o interfejs Web Forms, który można traktować jak strony HTML ze zdarzeniami znanymi z języka Visual Basic. Aplikacje ASP.NET są aplikacjami wykonywanymi po stronie serwera.

Poniżej znajduje się lista wytycznych i wskazówek dotyczących architektury aplikacji Visual Basic 6.0 opartych na przeglądarce. Wskazówki te powinny ułatwić późniejszą migrację do Visual Basic .NET:



  • Wskazane jest, by aplikacje tworzone były z uwzględnieniem wskazówek Microsoft dotyczących architektur wielowarstwowych — do tworzenia interfejsu użytkownika należy używać ASP, a logikę biznesową aplikacji można umieścić w obiektach COM napisanych w języku Visual Basic 6.0 lub Visual C++ 6.0. Technologia ASP jest w pełni obsługiwana w Visual Basic .NET, a aplikacje mogą być rozszerzane z wykorzystaniem ASP, ASP.NET oraz biblioteki Web Forms. Obiektów COM, napisanych w Visual Basic 6.0 lub Visual C++ 6.0, można używać bez wprowadzania żadnych zmian. Można je także uaktualnić do Visual Studio .NET.

  • Aplikacje DHTML zawierają strony DHTML i działające po stronie klienta biblioteki DLL. Aplikacji tych nie można automatycznie uaktualniać do Visual Basic .NET. Zalecanym rozwiązaniem jest pozostawienie ich w środowisku Visual Basic 6.0.

  • Dokumenty ActiveX nie są obsługiwane w Visual Basic .NET i — podobnie jak projekty DHTML — nie mogą być automatycznie uaktualniane. Zalecanym rozwiązaniem jest pozostawienie takich aplikacji w Visual Basic 6.0 lub zastąpienie dokumentów ActiveX kontrolkami użytkownika (gdy jest to możliwe).

  • Dokumenty ActiveX w Visual Basic 6.0 oraz aplikacje DHTML mogą współpracować z technologiami dostępnymi w Visual Basic .NET. Na przykład możliwe jest nawigowanie pomiędzy stronami Web Forms, utworzonymi w Visual Basic .NET, a stronami DHTML zbudowanymi w Visual Basic 6.0.

  • Obiekty Webclass nie istnieją już w Visual Basic .NET. Aplikacje Webclass można uaktualnić do ASP.NET, jednak po przeprowadzeniu uaktualnienia należy jeszcze dokonać kilku zmian. Istniejące aplikacje Webclass mogą współpracować z aplikacjami ASP i aplikacjami Web Forms napisanymi w Visual Basic .NET, ale w przypadku nowych projektów zalecane jest wykorzystanie platformy Windows DNA i technologii ASP wraz z obiektami biznesowymi napisanymi w Visual Basic 6.0.

Więcej informacji na temat tworzenia aplikacji o wielowarstwowej architekturze można znaleźć w witrynie Microsoft Windows DNA.

Projekty aplikacji klient-serwer


Visual Basic 6.0 oferował kilka technologii tworzenia aplikacji typu klient-serwer:

  • Visual Basic Forms,

  • obiekty warstwy pośredniczącej Microsoft Transaction Server (MTS)/COM+,

  • kontrolki użytkownika.

W języku Visual Basic .NET interfejsy użytkownika tworzy się przy użyciu nowej biblioteki — Windows Forms. Biblioteka ta korzysta z innego modelu obiektowego niż biblioteka Visual Basic 6.0 Forms, ale obydwie biblioteki są w dużym stopniu zgodne. W czasie uaktualniania projektu interfejsy utworzone przy użyciu biblioteki Visual Basic Forms są konwertowane i na ich podstawie powstaje nowy interfejs korzystający z biblioteki Windows Forms.

W Visual Basic .NET poprawiono obsługę komponentów usług warstwy pośredniczącej MTS oraz COM+. Zunifikowany debuger podczas wykonywania aplikacji krok po kroku pozwala na przejście do komponentu MTS/COM+, a następnie na powrócenie do aplikacji klienckiej. Za pomocą zunifikowanego debugera można także wykonywać krokowo komponenty MTS/COM+ napisane w języku Visual Basic 6.0 (pod warunkiem, że komponenty te zostały skompilowane do kodu natywnego, bez optymalizacji i z dołączeniem informacji symbolicznych dla debugera).

W Visual Basic .NET wprowadzono także nowe komponenty warstwy pośredniczącej — usługi sieciowe XML. Usługi te działają w oparciu o ASP.NET, a do transportu danych wykorzystują protokół HTTP, co umożliwia przekazywanie wywołań metod poprzez zapory połączenia sieciowego (firewall). Usługi przekazują i zwracają dane w postaci XML. Ponieważ język XML jest branżowym standardem, z funkcjonalności usług sieciowych XML mogą w łatwy sposób korzystać inne języki i platformy. Usługi sieciowe XML nie obsługują transakcji MTS, jednak komponenty MTS/COM+ warto zastąpić usługami XML Web Service wszędzie tam, gdzie konieczne jest zapewnienie współpracy z innymi platformami, ale nie jest potrzebna obsługa transakcji rozproszonych. Chociaż nie ma automatycznej metody takiej konwersji, zadanie to jest trywialnie proste i można je wykonać w ciągu kliku minut jako operację typu przeciągnij i upuść, już po uaktualnieniu projektu do Visual Basic .NET.

W czasie uaktualniania projektu, kontrolki użytkownika są uaktualniane do kontrolek Windows Forms, nie są jednak konwertowane ustawienia z niestandardowych zakładek właściwości i przypisania skrótów klawiszowych.


Aplikacje jednowarstwowe


W Visual Basic 6.0 możliwe było tworzenie aplikacji jednowarstwowych kilku typów:

  • jednowarstwowe aplikacje bazodanowe,

  • dodatki Visual Basic,

  • programy narzędziowe i gry.

Przykładem jednowarstwowej aplikacji bazodanowej jest napisana w języku Visual Basic aplikacja przechowująca dane w bazie Microsoft Access. Takie aplikacje można automatycznie uaktualnić do Visual Basic .NET, jednak obowiązują tu pewne ograniczenia (więcej informacji na ten temat można znaleźć w sekcji Dane w dalszej części tego dokumentu).

Ponieważ środowisko programowania Visual Basic .NET jest w pełni zintegrowane ze środowiskiem programowania Visual Studio .NET, model rozszerzeń Visual Basic .NET jest teraz niezależny od języka. Wszystkie dodatki Visual Basic .NET są równocześnie dodatkami Visual Studio .NET, co pozwala na automatyzację często wykonywanych czynności i rozszerzanie funkcjonalności dowolnego języka wchodzącego w skład Visual Studio .NET. Można na przykład napisać dodatek Visual Basic .NET, który zmienia kolor formularza Windows Forms, utworzonego w Visual C#, lub dodaje komentarze do klasy napisanej w języku Visual Basic. Zapewnienie takiej funkcjonalności wymagało rezygnacji ze starego modelu rozszerzeń, dlatego obiekty rozszerzeń stosowane w konwertowanych aplikacjach wymagają przystosowania do korzystania z nowej funkcjonalności.

Wiele aplikacji można zaliczyć do kategorii programów narzędziowych. Aplikacje narzędziowe do manipulowania plikami, ustawieniami rejestru itp. najprawdopodobniej będzie można uaktualnić bez wprowadzania żadnych dodatkowych zmian. Po uaktualnieniu aplikacji, ich funkcjonalność można rozszerzyć o wiele nowych funkcji — na przykład obsługę wyjątków można wykorzystać do przechwytywania błędów systemu plików, a klasy dostępu do rejestru, obecne w .NET Framework, można wykorzystać do zarządzania rejestrem. Warto pamiętać, że w przypadku aplikacji takich jak gry, których działanie zależy od specyficznej charakterystyki wydajnościowej Visual Basic 6.0, konieczne będzie wprowadzenie pewnych modyfikacji, uwzględniających charakterystykę wydajnościową Visual Basic .NET. Do pisania gier w Visual Basic .NET można wykorzystać Microsoft DirectX® 7 lub nową wersję GDI. GDI+ wprowadza wiele nowych funkcji, włącznie z obsługą efektu przezroczystości (alpha blending) dla wszystkich podstawowych elementów graficznych 2D, obsługą efektu wygładzania krawędzi (anti-aliasing) i rozszerzoną obsługą formatów plików graficznych.

Dane


Visual Basic 6.0 oferował kilka sposobów dostępu do danych:

  • ActiveX Data Objects (ADO)

  • Remote Data Objects (RDO)

  • Data Access Objects (DAO)

W Visual Basic .NET wprowadzono rozszerzoną wersję ADO o nazwie ADO.NET. Biblioteka ta umożliwia dostęp do danych w trybie offline, a stosowana w aplikacjach rozproszonych charakteryzuje się większą wydajnością niż ADO. Wiązanie danych w ADO.NET w przypadku kontrolek Windows Forms pozwala na odczyt i zapis danych, a w przypadku kontrolek Web Forms — wyłącznie na odczyt danych.

DAO, RDO i ADO nadal można używać w kodzie Visual Basic .NET, trzeba jednak zastosować pewne drobne zmiany (omówione w tym dokumencie w sekcji poświęconej językowi). Visual Basic .NET nie obsługuje wiązania danych DAO oraz RDO z kontrolkami, kontrolek danych oraz dostarczanych przez RDO połączeń użytkowników. Jeśli aplikacje zawierają wiązania danych DAO lub RDO, zalecane jest nieaktualizowanie tych aplikacji albo przekształcenie wiązań danych DAO oraz RDO na wiązania danych ADO przed uaktualnieniem projektu do Visual Basic .NET (wiązania danych ADO są obsługiwane przez bibliotekę Windows Forms). Informacje przydatne w przeprowadzaniu uaktualnienia do ADO można znaleźć w pomocy do języka Visual Basic 6.0.

Reasumując, w projektach Visual Basic 6.0 najlepiej stosować ADO.

Uaktualnianie


Podczas aktualizacji kodu, Visual Basic .NET tworzy nowy projekt i przeprowadza większość wymaganych zmian językowych i obiektowych. Poniższe sekcje zawierają kilka przykładów ilustrujących sposób uaktualniania kodu.

Zamiana Variant na Object


We wcześniejszych wersjach języka Visual Basic dostępny był typ danych Variant. Zmienne tego typu mogły przechowywać wartości dowolnego prostego typu danych (poza łańcuchami o stałej długości) albo wartość Empty, Error, Nothing lub Null. W Visual Basic .NET funkcjonalność typów danych VariantObject połączono w jednym typie danych — Object. Zmiennym typu Object można przypisać wartości każdego prostego typu danych, wartość Empty, Nothing, Null lub wskaźnik na obiekt.

W trakcie przenoszenia projektu do Visual Basic .NET, wszystkie zmienne, zadeklarowane jako zmienne typu Variant, zamieniane są na zmienne typu Object. Także w trakcie wstawiania kodu do edytora, słowa kluczowe Variant zamieniane są na Object.


Zamiana Integer na Short


W Visual Basic .NET typ danych Short ma postać 16-bitowej liczby całkowitej, a typ Integer ma postać 32-bitowej liczby całkowitej (typ Long ma teraz 64 bity). W trakcie przenoszenia projektu, typy zmiennych są odpowiednio zmieniane:

dim x As Integer

dim y as Long

jest zamieniane na:

dim x As Short

dim y as Integer


Składnia właściwości


Składnia właściwości w Visual Basic .NET jest bardziej intuicyjna ze względu na zgrupowanie metod GetSet. Deklaracje właściwości są uaktualniane tak, jak pokazano w poniższym przykładzie.

Property Get MyProperty() As Integer

MyProperty = m_MyProperty

End Property

Property Let MyProperty(NewValue As Integer)

m_MyProperty = NewValue

End Property

jest zamieniane na:

Property MyProperty() As Short

Get


MyProperty = m_MyProperty

End Get


Set

m_MyProperty = Value

End Set

End Property


Zamiana Visual Basic Forms na Windows Forms


Visual Basic .NET korzysta z nowej biblioteki formularzy i kontrolek — Windows Forms, która natywnie obsługuje ułatwienia dostępu i pozwala na edycję menu w miejscu. Istniejące formularze Visual Basic Forms są uaktualniane do Windows Forms.



Ilustracja 2. Edytowanie menu w miejscu (kliknij aby uzyskać powiększenie)

Interfejsy


We wcześniejszych wersjach Visual Basic, interfejsy klas publicznych zawsze były ukryte dla użytkownika. W Visual Basic .NET można je przeglądać i edytować w edytorze kodu. Podczas przenoszenia projektu można wybrać, czy deklaracje interfejsów dla klas publicznych mają zostać utworzone automatycznie.

Raport z aktualizacji i komentarze


Po uaktualnieniu projektu dodawany jest do niego raport, zawierający informacje o wszystkich zmianach, jakie należy jeszcze wprowadzić w uaktualnionym kodzie. Dodatkowo w kodzie umieszczane są komentarze wskazujące miejsca, w których potencjalnie mogą wystąpić problemy. Komentarze te są także automatycznie wyświetlane w liście zadań środowiska Visual Studio .NET (task list).



Ilustracja 3. Do kodu Visual Basic dodawane są komentarze, wyświetlane także w liście zadań (kliknij aby uzyskać powiększenie)

Wskazówki dotyczące programowania


Wskazówki zawarte w tej sekcji pozwolą zminimalizować liczbę zmian, jakie trzeba będzie wprowadzić w kodzie po skonwertowaniu projektu do Visual Basic .NET.

Używaj wczesnego wiązania


Zarówno Visual Basic 6.0 jak i Visual Basic .NET obsługują późne wiązanie obiektów, czyli deklarowanie zmiennej typu Object, a następnie — w czasie działania aplikacji — przypisanie jej instancji klasy. W procesie uaktualniania projektu późne wiązanie może jednak utrudnić ustalenie domyślnych właściwości obiektu lub sprawić problemy w przypadku, gdy model wiązanego obiektu uległ zmianie i właściwości, metody i zdarzenia wymagają konwersji. Załóżmy, że mamy formularz o nazwie Form1, zawierający kontrolkę etykiety o nazwie Label1. Poniższy kod spowodowałby ustawienie tekstu etykiety na „PewienTekst”.

Dim o As Object

Set o = Me.Label1

o.Caption = "PewienTekst"

W języku Visual Basic .NET, w bibliotece Windows Forms, odpowiednikiem właściwości Caption kontrolki etykiety jest właściwość Text. Podczas uaktualniania kodu, wszystkie wystąpienia właściwości Caption są zamieniane na Text, ale ponieważ obiekt późno wiązany tak naprawdę nie ma przypisanego typu, Visual Basic nie może ani wykryć typu obiektu, ani ustalić, czy jakieś właściwości wymagają konwersji. W takich przypadkach kod trzeba samodzielnie zmodyfikować po przeniesieniu projektu do Visual Basic .NET.

Jeśli powyższy kod zmienimy tak, by wykorzystywał wczesne wiązanie, zostanie on uaktualniony automatycznie:

Dim o As Label

Set o = Me.Label1

o.Caption = "PewienTekst"

Gdy jest to tylko możliwe, zmiennym należy przypisywać właściwy typ obiektu, a nie deklarować je jako zmienne typu Object.

Jeśli w kodzie Visual Basic 6.0 stosowane są zmienne typu Variant i typu Object, przy przypisywaniu zmiennych, przeprowadzaniu jakichkolwiek operacji na tych zmiennych oraz przy przekazywaniu ich do funkcji należy korzystać z jawnych konwersji. Nie jest na przykład jasne, jakie znaczenie ma mieć operacja „+” w poniższym kodzie.

Dim Var1 As Variant

Dim Var2 As Variant

Dim Var3 As Variant

Var1 = "3"

Var2 = 4


Var3 = Var1 + Var2 'NIEJASNE -- jakie były intencje?

Czy zmienne Var1 i Var2 powinny być dodane jako łańcuchy czy jako liczby całkowite?

Uruchomienie kodu z powyższego przykładu może w Visual Basic .NET spowodować błąd czasu wykonania. Problem można rozwiązać, stosując w ostatniej linii powyższego przykładu jawną konwersję:

Var3 = CInt(Var1) + CInt(Var2) 'DOBRZE -- jawna konwersja

W Visual Basic .NET istnieje możliwość przeciążania funkcji na podstawie typu parametrów. Na przykład funkcja Environ ma teraz dwie formy:

Environ( Expression As Integer) As String

Environ( Expression As String ) As String

Visual Basic .NET ustala, którą funkcję należy wywołać na podstawie typu parametru. Jeśli do funkcji Environ() przekażemy liczbę całkowitą, to wywoływana jest wersja z parametrem całkowitoliczbowym; jeśli do funkcji przekażemy łańcuch, to zostanie wywołana wersja dla łańcucha znaków. Kod, który przekazuje do przeciążonej funkcji zmienne typu Variant lub Object, może w Visual Basic .NET spowodować błędy czasu wykonania. Zastosowanie jawnej konwersji (jak pokazano w poniższym przykładzie) powoduje, że kod po przeniesieniu do Visual Basic .NET będzie działał poprawnie.

Dim a As String

Dim v As Variant

v = "Path"

a = Environ(CStr(v)) 'DOBRZE -- jawna konwersja

Stosowanie jawnych konwersji obiektów późno wiązanych to dobry zwyczaj. Dzięki temu można łatwo ustalić, jakie intencje miał autor kodu i znacznie szybciej przenieść projekt do Visual Basic .NET.

Do przechowywania dat używaj typu Date


Wcześniejsze wersje Visual Basic obsługiwały zapisywanie dat i operacje na nich w zmiennych typu Double. W Visual Basic .NET nie należy przeprowadzać takich operacji, ponieważ daty nie są wewnętrznie przechowywane jako liczby typu double. Poniższy kod jest całkowicie poprawny w Visual Basic 6.0, ale może spowodować błędy kompilacji w Visual Basic .NET:

Dim dbl As Double

Dim dat As Date

dat = Now

dbl = dat 'VB.NET: wartości typu date nie można przypisać do zmiennej typu double

dbl = DateAdd("d", 1, dbl) 'VB.NET: nie można używać double w funkcjach operujacych na datach

dat = CDate(dbl) 'VB.NET: CDate nie pozwala na konwersję double na date

Środowisko .NET Framework pozwala na konwersję pomiędzy typami double i date z zastosowaniem funkcji ToOADateFromOADate. Jednak — gdy projekt jest przenoszony do Visual Basic .NET — trudno ustalić intencje autora kodu, który do przechowywania dat zastosował zmienne typu double. Aby uniknąć wprowadzania zmian w kodzie w Visual Basic .NET, do zapisywania dat należy zawsze używać typu Date.


Specyfikuj bezparametrowe właściwości domyślne


W Visual Basic 6.0 wiele obiektów posiada właściwości domyślne, dzięki czemu można nie podawać nazw tych właściwości. Na przykład domyślną właściwością obiektu TextBox jest Text, dlatego zamiast pisać:

MsgBox Form1.Text1.Text

można zastosować formę skróconą:

MsgBox Form1.Text1

Właściwość domyślna jest ustalana w trakcie kompilacji kodu. Właściwości domyślne można także stosować wraz z późnym wiązaniem, jak zrobiono to w poniższym przykładzie:

Dim obj As Object

Set obj = Form1.Text1

MsgBox obj

W przykładzie wykorzystującym późne wiązanie, właściwość domyślna jest ustalana w czasie działania programu i w oknie komunikatu MsgBox wyświetlana jest wartość właściwości domyślnej kontrolki Text1 typu TextBox.

Visual Basic .NET nie obsługuje domyślnych właściwości bezparametrowych i konsekwentnie nie pozwala na stosowanie takich skrótów w kodzie. W trakcie uaktualniania projektu, Visual Basic .NET uzgadnia bezparametrowe właściwości domyślne, ale nie potrafi tego zrobić w przypadku obiektów późno wiązanych, których właściwości domyślne uzgadniane są w czasie wykonywania aplikacji. W takich przypadkach trzeba samodzielnie uaktualnić kod. Dodatkowym utrudnieniem jest fakt, że wiele bibliotek implementuje właściwości domyślne przy użyciu właściwości o nazwie _Default. Wlaściwość _Default odgrywa rolę pośrednika, przekazującego wywołania do prawdziwej właściwości domyślnej. A więc w trakcie uaktualniania projektu niektóre właściwości domyślne zostaną odczytane jako właściwość _Default. Kod będzie nadal poprawnie działał, ale będzie dużo mniej zrozumiały niż kod jawnie używający odpowiedniej właściwości. Z tego powodu należy unikać stosowania w kodzie Visual Basic 6.0 bezparametrowych właściwości domyślnych. Zamiast kodu:

Dim obj As Object

Set obj = Me.Text1

MsgBox obj 'Korzystanie z właściwości domyślnej

MsgBox Me.Text1 'Korzystanie z właściwości domyślnej

należy użyć:

Dim obj As Object

Set obj = Me.Text1

MsgBox obj.Text 'DOBRZE – właściwość domyślna użyta w sposób jawny

MsgBox Me.Text1.Text 'DOBRZE – właściwość domyślna użyta w sposób jawny

W Visual Basic .NET nie są obsługiwane bezparametrowe właściwości domyślne, są jednak obsługiwane właściwości domyślne sparametryzowane. Różnica pomiędzy tymi dwoma typami właściwości polega na tym, że sparametryzowana właściwość domyślna zawsze posiada indeks. Przykładem może być właściwość domyślna obiektu ADO recordset — kolekcja Fields.

Dim rs As ADODB.Recordset

rs("CompanyName") = "JakaśFirma"

rs!CompanyName = "JakaśFirma"

Powyższy kod jest tak naprawdę skróconą wersją następującego kodu:

Dim rs As ADODB.Recordset

rs.Fields("CompanyName").Value = "JakaśFirma"

rs.Fields!CompanyName.Value = "JakaśFirma"

W tym przypadku właściwość Fields jest sparametryzowana, dlatego zastosowanie jej jako właściwości domyślnej w Visual Basic .NET jest dopuszczalne. Właściwość domyślna (Value) właściwości Fields jest jednak właściwością bezparametrową, dlatego powyższy przykład po skonwertowaniu do Visual Basic .NET wygląda następująco:

Dim rs As ADODB.Recordset

rs("CompanyName").Value = "JakaśFirma"

rs!CompanyName.Value = "JakaśFirma"

W tym przykładzie i w większości innych, właściwości domyślne są uzgadniane w trakcie uaktualniania projektu, a więc jawne używanie ich w Visual Basic 6.0 jest po prostu dobrym zwyczajem programistycznym. Należy jednak unikać stosowania właściwości domyślnych w przypadku typu danych ObjectVariant, ponieważ nie ma możliwości uzgodnienia ich i trzeba je samodzielnie poprawić po uaktualnieniu projektu.


Unikaj propagacji wartości Null


Wcześniejsze wersje Visual Basic obsługiwały propagację wartości Null. Propagacja wartości Null polega na tym, że wynikiem wyrażenia, w którym użyto wartości Null, zawsze będzie wartość Null. W każdym wierszu poniższego przykładu zmienna V będzie miała wartość Null.

Dim V


V = 1 + Null

V = Null + Right$("JakiśTekst", 1)

V = Right("JakiśTekst", 0)

Propagacja wartości Null nie jest obsługiwana w Visual Basic .NET. Wyrażenie 1+Null wygeneruje w Visual Basic .NET błąd niezgodności typów. W Visual Basic 6.0 istniały dwie wersje funkcji LeftLeft$ zwracała łańcuch znaków, a Left zwracała zmienną typu Variant, która mogła mieć przypisaną wartość Null. Z kolei Visual Basic .NET posiada tylko jedną wersję — funkcję Left, która zawsze zwraca łańcuch.

Aby zachować zgodność zarówno z Visual Basic 6.0 jak i z Visual Basic .NET, powinno się zawsze pisać dodatkowy kod sprawdzający, czy zmienna ma wartość Null, a nie polegać na propagacji wartości Null. Co więcej, w Visual Basic .NET następujące funkcje nie zwracają już wartości Null:

Chr

Mid

Command

Oct

CurDir

Right

Date

RTrim

Environ

Space

Error

Str

Hex

Time

LCase

Trim

LTrim

UCase

Propagacja wartości Null jest często wykorzystywana w aplikacjach bazodanowych, w których trzeba sprawdzać, czy pole w bazie zawiera wartość Null. W takim przypadku wartości wyników należy sprawdzać przy użyciu funkcji IsNull() i w zależności od zwróconego przez nią wyniku przeprowadzać odpowiednie operacje.

Podobny problem dotyczy konkatenacji wartości Null z łańcuchem. Korzystając w programie z obiektów baz danych, często stosuje się zabieg konkatenacji wartości pola z „pustym łańcuchem”, co zapewnia zamienienie wartości Null na pusty łańcuch. Na przykład:

MyString = rs!Field1 & ""

Technika ta jest nadal obsługiwana w Visual Basic .NET. Wynikiem konkatenacji wartości Null z pustym łańcuchem (przy użyciu operatora &) jest pusty łańcuch.


Stosuj tablice indeksowane od zera


W Visual Basic 6.0 istniała możliwość definiowania tablic, których ograniczenia zakresu indeksowania były dowolnymi liczbami całkowitymi. Istniała także możliwość stosowania polecenia ReDim w celu zamiany zmiennej typu variant w tablicę. Zachowanie interoperacyjności języka Visual Basic .NET z innymi językami wymaga, by dolna granica indeksowania tablic była równa zero. Polecenia ReDim nie można używać, jeśli wcześniej zmienna nie została zadeklarowana przy użyciu Dim As Array. Ogranicza to nieco dostępne sposoby definiowania tablic, pozwala jednak na przekazywanie tablic pomiędzy kodem Visual Basic .NET a kodem napisanym w dowolnym innym języku .NET. Omawiane ograniczenie pokazano w poniższym przykładzie:

Dim a(1 To 10) As Integer 'Dolny zakres indeksowania w Visual Basic .NET musi wynosić 0

Dim v

ReDim v(10) 'W VB.NET nie można użyć ReDim bez wcześniejszego Dim



Dim b(10) As Integer 'DOBRZE – tworzy tablice 11 liczb typu integer

ReDim b(5) As Integer 'DOBRZE – można użyć ReDim w stosunku do tablicy

'zadeklarowanej wcześniej przy użyciu Dim

Efektem ubocznym tej zmiany jest usunięcie z języka polecenia Option Base 0|1.

Gdy projekt jest przenoszony do Visual Basic .NET, z kodu są usuwane deklaracje dolnych zakresów indeksowania tablic. Jeśli tablica była indeksowana od zera, to jest pozostawiana bez zmian. Jeśli jednak indeksem początkowym tablicy była liczba różna od zera, to dolny zakres indeksowania jest usuwany, a w kodzie wstawiane jest ostrzeżenie, co widać w poniższym przykładzie.

Dim a(1 To 10) As Integer

Powyższy kod modyfikowany jest w następujący sposób:

'UPGRADE_WARNING: Lower Bound of array a was changed from 1 to 0

Dim a(10) As Integer

W wielu przypadkach uaktualniony kod będzie działał poprawnie. Jeśli jednak działanie aplikacji zależało w jakiś sposób od dolnego zakresu indeksowania wynoszącego 1, to trzeba wprowadzić pewne zmiany. Polecenia Dim, ReDimLBound oznaczane są w kodzie ostrzeżeniami, ułatwiającymi programiście zapoznanie się ze zmianami wprowadzonymi w czasie uaktualniania projektu.

Z tego powodu jako dolnego zakresu indeksowania tablic w kodzie napisanym w Visual Basic 6.0 należy używać zera, a przy deklarowaniu tablic należy unikać stosowania polecenia ReDim. Należy także unikać stosowania polecenia Option Base 1.

Stosuj stałe zamiast jawnie podawać ich wartości


Pisząc kod należy starać się używać stałych, a nie przypisanych im wartości. Jeśli w czasie działania aplikacji chcemy na przykład zmaksymalizować formularz programu, należy użyć:

Me.WindowState = vbMaximized 'DOBRZE – użyto nazwy stałej

zamiast:

Me.WindowStyle = 2 'Unikaj jawnego stosowania wartości

Me.WindowStyle = X 'Unikaj stosowania zmiennych

Zgodnie z tą samą zasadą należy stosować stałe TrueFalse zamiast wartości -1 i 0.

W Visual Basic .NET uległy zmianie wartości — a w niektórych przypadkach także nazwy — pewnych właściwości i stałych. Gdy projekt jest przenoszony do Visual Basic .NET, większość stałych jest konwertowana automatycznie. Jeśli jednak w kodzie zamiast nazw stałych jawnie wpisujemy wartości lub zmienne, to nie zostaną one automatycznie uaktualnione. Używanie nazw stałych minimalizuje liczbę zmian, które trzeba będzie wprowadzić w kodzie po jego uaktualnieniu.

Tablice i łańcuchy stałej długości w typach definiowanych przez użytkownika


Wprowadzenie zmian, dzięki którym tablice i struktury języka Visual Basic .NET są w pełni kompatybilne z odpowiednimi konstrukcjami w innych językach składających się na Visual Studio .NET, spowodowało, że w języku tym nie są już obsługiwane łańcuchy stałej długości. W większości przypadków nie stanowi to żadnego problemu, ponieważ istnieje klasa zapewniająca obiekty naśladujące zachowanie łańcuchów stałej długości.

Dim MyFixedLengthString As String * 100

Powyższy kod jest uaktualniany w następujący sposób:

Dim MyFixedLengthString As New VB6.FixedLengthString(100)

Łańcuchy stałej długości powodują jednak pewne problemy, gdy są stosowane wewnątrz struktur (zwanych typami definiowanymi przez użytkownika). Problem istnieje, ponieważ klasa łańcucha stałej długości nie jest automatycznie tworzona przy tworzeniu struktury. Dodatkowy problem polega na tym, że tablice stałej wielkości także nie są tworzone przy tworzeniu struktury je zawierającej.

Gdy kod jest uaktualniany, typy użytkownika zawierające łańcuchy lub tablice stałej długości zostają oznaczone komentarzem informującym, by przed użyciem struktury zainicjować zawarty w niej łańcuch lub tablicę stałej długości. Można jednak uchronić się przed koniecznością wprowadzania tych modyfikacji, zmieniając w Visual Basic 6.0 struktury tak, by korzystały ze zwykłych łańcuchów zamiast z łańcuchów o stałej długości i z niezainicjowanych tablic zamiast z tablic stałej wielkości.

Private Type MyType

MyArray(5) As Integer

MyFixedString As String * 100

End Type


Sub Bar()

Dim MyVariable As MyType

End Sub

Powyższy kod można zamienić na kod zamieszony poniżej:



Private Type MyType

MyArray() As Integer

MyFixedString As String

End Type


Sub Bar()

Dim MyVariable As MyType

ReDim MyVariable.MyArray(5) As Integer

MyVariable.MyFixedString = String$(100, " ")

End Sub

Unikaj stosowania przestarzałych funkcji


Następujące słowa kluczowe zostały usunięte z języka Visual Basic .NET, dlatego należy unikać ich stosowania:

  • Def

  • wyliczone GoTo/GoSub

  • GoSub/Return

  • Option Base 0|1

  • VarPtr, ObjPtr, StrPtr

  • LSet

Każde z tych słów zostało omówione bardziej szczegółowo w dalszej części tego artykułu.

Def


We wcześniejszych wersjach Visual Basic, polecenia DefBool, DefByte, DefInt, DefLng, DefCur, DefSng, DefDbl, DefDec, DefDate, DefStr, DefObj oraz DefVar były stosowane w sekcji deklaracyjnej modułu do definiowania zakresów zmiennych odpowiedniego typu. Na przykład:

DefInt A-C

Powyższa linia określała, że wszystkie zmienne, których nazwa zaczynała się od litery A, B lub C, są zmiennymi typu integer. Zamiast korzystać z poleceń Def, należy jawnie deklarować zmienne.

wyliczone GoTo/GoSub


Polecenia wyliczone GoTo/GoSub mają następującą postać:

On x GoTo 100, 200, 300

Nie są one obsługiwane w języku Visual Basic .NET. Zamiast nich należy stosować polecenie If oraz konstrukcję Select Case.

GoSub/Return


Polecenia GoSub oraz Return nie są obsługiwane w Visual Basic .NET. W większości przypadków można je zastąpić poprzez utworzenie funkcji lub procedury.

Option Base 0|1


Wyrażenie Option Base 0|1 było stosowane do określania domyślnej dolnej granicy zakresu indeksowania tablic. Polecenie to zostało usunięte z języka, ponieważ Visual Basic .NET obsługuje wyłącznie tablice indeksowane od zera. Tablice o innej dolnej granicy zakresu indeksowania są obsługiwane poprzez klasę opakowywującą.

VarPtr, ObjPtr, StrPtr


Funkcje VarPtr, VarPrtArray, VarPtrStringArray, ObjPtr oraz StrPtr były nieudokumentowanymi funkcjami używanymi do sprawdzenia adresu pamięci, pod którym została zapisana zmienna. Funkcje te nie są dostępne w Visual Basic .NET.

LSet


W Visual Basic 6.0 polecenie LSet było stosowane do przypisania wartości zmiennej typu zdefiniowanego przez użytkownika do innej zmiennej o innym typie zdefiniowanym przez użytkownika. Funkcjonalność ta nie jest już dostępna w Visual Basic .NET.

Interfejsy Windows API


Z wielu interfejsów API można korzystać dokładnie tak samo jak w Visual Basic 6.0, należy jednak pamiętać, by odpowiednio dopasować typy danych. Typ danych Long z Visual Basic 6.0 to typ danych Integer w Visual Basic .NET, a typ danych Integer z Visual Basic 6.0 to typ danych Short w Visual Basic .NET. W trakcie uaktualniania projektu zmiany te wprowadzane są automatycznie, a proste wywołania API działają dokładnie tak samo, jak działały w Visual Basic 6.0.

Private Declare Function GetVersion Lib "kernel32" () As Long

Function GetVer()

Dim Ver As Long

Ver = GetVersion()

MsgBox ("System Version is " & Ver)

End Function

Powyższy kod konwertowany jest na następujący kod:

Private Declare Function GetVersion Lib "kernel32" () As Integer

Function GetVer()

Dim Ver As Integer

Ver = GetVersion()

MsgBox("System Version is " & Ver)

End Function

W Visual Basic .NET uaktualniono nie tylko numeryczne typy danych. Na przykład nie są już obsługiwane łańcuchy o stałej długości. Podczas konwersji łańcuchy takie zastępowane są klasą opakowującą. W wielu przypadkach w Visual Basic 6.0 operacje przeprowadzane na łańcuchach o stałej długości można równie dobrze przeprowadzić z wykorzystaniem zwykłych łańcuchów.

Private Declare Function GetUserName Lib "advapi32.dll" Alias _

"GetUserNameA" (ByVal lpBuffer As String, ByRef nSize As Long) As Long

Function GetUser()

Dim Ret As Long

Dim UserName As String

Dim Buffer As String * 25

Ret = GetUserName(Buffer, 25)

UserName = Left$(Buffer, InStr(Buffer, Chr(0)) - 1)

MsgBox (UserName)

End Function

Lepiej jest zapisać powyższy kod korzystając ze zwykłego łańcucha, którego długość jawnie ustawiamy na 25 znaków:

Dim Buffer As String

Buffer = String$(25, " ")

Taki kod zostanie uaktualniony do Visual Basic .NET w następujący sposób:

Declare Function GetUserName Lib "advapi32.dll" Alias _

"GetUserNameA" (ByVal lpBuffer As String, ByRef nSize As Integer) As Integer

Function GetUser()

Dim Ret As Integer

Dim UserName As String

Dim Buffer As String

Buffer = New String(CChar(" "), 25)

   Ret = GetUserName(Buffer, 25)

    UserName = Left(Buffer, InStr(Buffer, Chr(0)) - 1)

    MsgBox(UserName)

End Function

Przekazywanie łańcuchów do wywołań API w Visual Basic .NET jest lepiej rozwiązane, ponieważ można opcjonalnie (z wykorzystaniem słów kluczowych ANSI oraz UNICODE) zadeklarować sposób, w jaki łańcuchy mają zostać przekazane.

Trzy typy wywołań API wymagają dodatkowych zmian. Pierwszy typ wywołań to wywołania API, do których przekazywane są typy danych zdefiniowane przez użytkownika, zawierające łańcuchy stałej długości lub tablice bajtowe. W Visual Basic .NET może być konieczne dodanie atrybutu MarshallAs (z przestrzeni nazw System.Runtime.InteropServices) do każdego łańcucha stałej długości lub do każdej tablicy bajtowej w typie zdefiniowanym przez użytkownika. Drugi typ wywołań to wywołania, w których w poleceniu Declare zastosowano zmienną typu As Any. Taka konstrukcja nie jest obsługiwana w Visual Basic .NET. Zmienne typu As Any były często wykorzystywane do przekazywania zmiennych, które albo zawierały łańcuch znaków, albo miały wartość Null. Problem ten można ominąć deklarując dwie formy API — jedną ze zmiennymi typu long, drugą z łańcuchami. Na przykład API GetPrivateProfileString posiada parametr lpKeyName, który zadeklarowany jest przy użyciu As Any:

Private Declare Function GetPrivateProfileString Lib "kernel32" Alias

"GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal

lpKeyName As Any, ByVal lpDefault As String, ByVal

lpReturnedString As String, ByVal nSize As Long, ByVal

lpFileName As String) As Long

„As Any” można usunąć deklarując dwie wersje API — przyjmującą zmienne typu long i przyjmującą łańcuchy:

Private Declare Function GetPrivateProfileStringKey Lib "kernel32" Alias

"GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal

lpKeyName As String, ByVal lpDefault As String, ByVal

lpReturnedString As String, ByVal nSize As Long, ByVal

lpFileName As String) As Long

Private Declare Function GetPrivateProfileStringNullKey Lib "kernel32"

Alias "GetPrivateProfileStringA" (ByVal lpApplicationName As String,

ByVal lpKeyName As Long, ByVal lpDefault As String, ByVal

lpReturnedString As String, ByVal nSize As Long, ByVal

lpFileName As String) As Long

Gdy chcemy do interfejsu przekazać wartość Null, stosujemy wersję GetPrivateProfileStringNullKey. Zastosowanie takiego rozwiązania gwarantuje, że funkcja zostanie automatycznie uaktualniona do Visual Basic .NET.

Ostatnim typem wywołań, który może wymagać wprowadzenia zmian, są wywołania API wykonujące operacje takie jak tworzenie wątków, przejęcie procedury obsługi okna (Window subclassing), kolejkowanie komunikatów i inne zadania tego typu. Niektóre z tych funkcji mogą spowodować w Visual Basic .NET błąd czasu wykonania. Wiele z tych interfejsów API ma swoje odpowiedniki w Visual Basic .NET lub w .NET Framework. Wszystkie takie przypadki trzeba rozpatrzyć i naprawić indywidualnie.


Uwagi dotyczące stosowania formularzy i kontrolek


Visual Basic .NET zawiera nową bibliotekę do tworzenia interfejsów aplikacji — Windows Forms. Biblioteka ta jest w dużym stopniu zgodna z biblioteką dostępną w Visual Basic 6. Istnieje jednak kilka ważnych różnic — wyszczególniono je poniżej.

  • Biblioteka Windows Forms nie obsługuje kontrolki pojemnika OLE. Należy unikać stosowania tej kontrolki w aplikacjach pisanych w Visual Basic 6.0.

  • W Windows Forms nie ma kontrolki Shape. Kontrolki prostokątne i kwadratowe zostaną zastąpione kontrolkami etykiet, a kontrolki o kształcie owali i kół nie zostaną uaktualnione. Należy unikać stosowania tych kontrolek w aplikacjach.

  • W Windows Forms nie ma kontrolki Line. Linie poziome i pionowe zostaną zastąpione kontrolkami etykiet. Linie ukośne nie zostaną uaktualnione, dlatego należy unikać ich stosowania.

  • Windows Forms zawiera nowy zestaw poleceń graficznych, zastępujący metody klasy Form, takie jak Circle, CLS, PSet, Line oraz Point. Nowy model obiektowy jest zupełnie inny niż model wykorzystany w Visual Basic 6.0, dlatego metody te nie mogą być uaktualnione.

  • W przypadku kontrolki Timer, ustawienie wartości właściwości Interval na 0 nie wyłącza zegara — okres jest automatycznie ustawiany na 1. W projektach Visual Basic 6.0 — zamiast przypisywać wartość 0 właściwości Interval — należy właściwość Enabled ustawić na False.

  • Biblioteka Windows Forms zawiera dwie kontrolki menu: MainMenu i ContextMenu, a w Visual Basic 6.0 istniała tylko jedna kontrolka Menu, którą można było otworzyć jako MainMenu lub ContextMenu. Kontrolki Menu uaktualniane są do kontrolek MainMenu, ale nie można ich użyć jako ContextMenu — wszystkie menu kontekstowe ContextMenu trzeba utworzyć na nowo.

  • Windows Forms nie obsługuje DDE (Dynamic Data Exchange).

  • Windows Forms nie obsługuje metody Form.PrintForm.

  • Chociaż w bibliotece Windows Forms dostępna jest funkcjonalność „przeciągnij i upuść”, to model obiektowy znacznie różni się od modelu dostępnego w Visual Basic 6.0. Dlatego właściwości i metody związane z funkcjonalnością przeciągnij i upuść w Visual Basic 6.0 nie są uaktualniane.

  • Platforma .NET Framework zawiera poprawiony obiekt schowka (System.Windows.Clipboard), który oferuje większą funkcjonalność i obsługuje więcej formatów danych niż obiekt schowka w Visual Basic 6.0. Jednak ze względu na różnice w modelach obiektowych, polecenia dotyczące schowka nie są uaktualniane automatycznie.

  • Aby mieć pewność, że po uaktualnieniu rozmiary formularzy zostaną zachowane, nie należy zmieniać domyślnego trybu skalowania okna (właściwość ScaleMode powinna mieć wartość twips). W trakcie uaktualniania, Visual Basic .NET przelicza współrzędne formularza z twipsów na piksele.

  • Biblioteka Windows Forms obsługuje wyłącznie fonty typu true-type i open-type. Jeśli aplikacja korzysta z innych czcionek, to zostaną one zamienione na domyślną czcionkę systemową, a całe formatowanie (wielkość, pogrubienia, pochylenia, podkreślenia) zostanie utracone. Dotyczy to także domyślnej czcionki VB6 — MS Sans Serif. Z tego powodu — jeśli tekst w aplikacji jest formatowany — zaleca się stosowanie czcionki Arial zamiast czcionki MS Sans Serif.








©absta.pl 2016
wyślij wiadomość

    Strona główna