Lập trình trong môi trường .NET - Visual studio.NET – Phần 3 docx

Lập trình trong môi trường .NET
Visual studio.NET – Phần 3


Cửa sổ properties
Một cửa sổ khác, được gọi là Properties, xuất xứ từ IDE của VB. Chúng ta
biết rằng cửa sổ properties hiển thị và cho phép bạn sửa đổi hầu hết mọi giá
trị khởi tạo của các thuộc tính đối với những control mà Visual studio.NET
có khả năng phát hiện bằng cách đọc mã nguồn của bạn.
Cửa sổ Properties cũng có thể thấy những sự kiện. Bạn có thể nhìn thấy sự
kiện bằng cách click lên icon giống như một tia sáng ở trên đầu cửa sổ.
Trên đầu cửa sổ Properties là một list box cho phép bạn chọn control nào để
quan sát hoặc chỉnh sửa. Chúng tôi chọn Form1, lớp form chính trong dự án
BasicForm, và cho chỉnh sửa thuộc tính text " Basic Form - SAMIS hello".
Nếu bạn cho kiểm tra lại mã nguồn, bạn có thể thấy hiện chúng ta đã chỉnh
sửa mã nguồn, thông qua giao diện thân thiện hơn:
this.AutoScaleBaseSize = new System.Drawing.Size(5, 13);
this.ClientSize = new System.Drawing.Size(292, 268);
this.Controls.AddRange(new System.Windows.Forms.Control[]
{this.textBox1});
this.Name = "Form1";
this.Text = "Basic Form - Hello!";

Không phải tất cả các thuộc tính mà bạn thấy trên cửa sổ Properties sẽ được
ghi rõ trên mã nguồn. Rõ ràng khi bạn thay đổi trị của một thuộc tính nào đó
trên cửa sổ Properties thì một câu lệnh cài đặt rõ ra thuộc tính này sẽ xuất
hiện lên mã nguồn của bạn và ngựơc lại
Cửa sổ Properties được xem là cách tiện lợi nhất để có cái nhìn về tất cả các
thuộc tính của một ô control nào đó.
Cửa sổ Class view
Khác với cửa sổ Properties, cửa sổ Class view xuất xứ từ môi trường triển

khai Visual studio.NET, cửa sổ class view được xem như là trang tab của
cửa sổ Solution Explorer, cho thấy cây đẳng cấp của các namespace và các
lớp trong đoạn mã của bạn. Nó cho một tree view mà bạn có thể bung ra để
xem namespace nào chứa những lớp nào, và trong lớp chứa những thành
viên nào.

Một chức năng hay của class view là nếu bạn click phải lên tên của bất cứ
mục tin nào bạn có thể thâm nhập vào đoạn mã nguồn, bạn chọn mục Go To
Definition, trên trình đơn shortcut, thì trên code editor sẽ hiện lên đoạn mã
định nghĩa mục tin này. Hoặc bạn double click lên mục tin bạn cũng được
kết quả như trên. Nếu bạn muốn thêm một phần tử cho Form : Bạn click
phải trên tên form sau đó chọn add phần tử bạn muốn thêm(Add Method,
Add Property, Add Indexer hoặc Add Field.
Pin Buttons
Khi khảo sát Visual studio.NET, có thể bạn nhận thấy có nhiều cửa sổ mà
chúng tôi mô tả có vài chức năng mang dáng dấp của những thanh công cụ.
Đặc biệt, ngoại trừ code editor, thì các cửa sổ có thể docking. Có một icon
pin cạnh nút minimize nằm ở góc phải phía trên mỗi cửa sổ. Icon này khi
chúc đầu xuống, thì cửa sổ này hoạt đọng như một cửa sổ bình thường mà
bạn đã quen. Nhưng khi icon này nằm ngang, thì cửa sổ này chỉ hiện lên khi
nó có focus. Nhưng khi nó mất focus, nghĩa là con trỏ chỉ vào chỗ khác, thì
cửa sổ biến mất, thu mình lại qua phía tay phải hoặc tay trái.
Xây dựng một dự án
Building, Compiling và Making
Trước khi ta đi sâu vào việc xem xét những lựa chọn khác nhau liên quan
đến việc xây dựng một dự án, thiết tưởng ta nên làm sáng tỏ những từ ngữ
liên quan đến tiến trình biến mã nguồn của bạn thành một loại đoạn mã khả
thi. Bạn thường biết đến 3 từ: compiling, building, making. Nguyên nhân của
những từ ngữ khác nhau là do việc chuyển một mã nguồn thành một mã khả
thi đòi hỏi không chỉ một bước mà thôi. Trên C++ chẳng hạn mỗi tập tin

nguồn phải được biên dịch riêng lẽ, cho ra một tập tin đối tượng, mang dáng
dấp đoạn mã khả thi nhưng mỗi tập tin đối tượng chỉ liên hệ với một tập tin
nguồn. Muốn cho ra một mã kết sinh các tập tin đối tượng này phải liên kết
lại một tiến trình mà người ta gọi là linking. Tiến trình phối hợp thường gọi
là xây dựng (building) đoạn mã theo từ ngữ windows. Tuy nhiên, theo từ
ngữ C#, thì trình biên dịch phức tạp hơn nhiều có khả năng đọc và xử lý tất
cả các tập tin nguồn như một khối. Do đó, đối với C# không có giai đoạn
liên riêng lẽ nên trong phạm trù C# các từ compiling và building coi như
giống nhau.
Còn từ making cũng có nghĩa là xây dựng nhưng nó không được dùng trong
phạm trù C#. Từ này xuất xứ từ những máy tính mainframe, cho biết khi một
dự án gồm nhiều tập tin nguồn, thì có một tập tin riêng lẽ được viết ra chứa
những chỉ thị dành cho trình biên dịch biết cách xây dựng một dự án. Tập tin
riêng rẽ này được gọi là make file, do đó từ này tiếp tục được dùng như là
chuẩn trên Unix hoặc Linux. Các tập tin make thường không cần đến trên
Windows, mặc dù bạn có thể viết chúng hoặc yêu cầu Visual Studio.NET
kết sinh chúng nếu bạn muốn.
Debug build và Release Build
Khi bạn gỡ rối chương trình, bạn thường muốn chương trình khả thi có một
cách ứng xử khác đi khi bạn cho phân phối chương trình. Khi phân phối
chương trình ngoại trừ việc chương trình phải chạy tốt không có lỗi, nó còn
phải có kích thước càng nhỏ càng tốt và còn phải chạy thật nhanh. Rất tiết là
những đòi hỏi trên không hợp với nhu cầu gỡ rối chương trình, với nhiều lý
do sau đây.
Tối ưu hoá
Hiệu năng cao của đoạn mã phần lớn là do việc trình biên dịch đã tối ưu hoá
đoạn mã. Đây có nghĩa khi biên dịch, trình biên dịch sẽ nhìn vào mã nguồn
xem có thể nhận diện những đoạn mà nó có thể thay thế bởi một đoạn mã
khác cho ra kết quả y chang nhưng tối ưu hơn, chạy hiệu quả hơn.
double InchesToCm(double Ins)

{
return Ins*2.54;
}
// later on in the code
Y = InchesToCm(X);
Trình biên dịch có thể thay thế câu lệnh trên bởi:
Y = X * 2.54;
Hoặc chẳng hạn trình biên dịch gặp phải đoạn mã như sau:
{
string Message = "Hi";
Console.WriteLine(Message);
}
Thì nó thay thế bởi
Console.WriteLine("Hi");
Như vậy, ta có thể tiết kiệm những nơi nào có những khai báo tham khảo đối
tượng một cách không cần thiết.
Các ký hiệu Debugger
khi bạn gỡ rối chương trình, thường bạn cần xét đến trị của những biến mà
bạn sẽ khai báo chúng theo tên trên mã nguồn. Khổ nỗi là chương trình khả
thi EXE lại không chứa tên biến, vì trình biên dịch đã cho thay thế bởi
những vị chỉ ký ức. .NET đã thay đổi tình trạng trên bằng cách cho trữ vài
tên trên assembly nhưng chỉ một số nhỏ liên quan đến các lớp và phương
thức.
Các chỉ thị gỡ rối extra trên mã nguồn
Khi bạn đang gỡ rối chương trình, trong đoạn mã của bạn sẽ có phụ thêm
những dòng lệnh cho phép hiển thi những thông tin cốt tử liên quan đến gỡ
rối. Lẽ dĩ nhiên là trước khi gữi đi phân phối chương trình của bạn, bạn
muốn cho gỡ bỏ những dòng lệnh extra này. Bạn có thể làm điều này bằng
tay nhưng tốt hơn là bạn cho đánh dấu những dòng lệnh này làm thế nào
trình biên dịch sẽ bỏ qua khi biên dịch sẽ bỏ qua khi biên dịch đoạn mã cần

được gửi đi. Chúng ta đã biết qua phần tiền chỉ thị (preprocessor directive),
các chỉ thị này có thể dùng phối hợp với thuộc tính Conditional, xem như là
điều kiện biên dịch.
Cuối cùng bạn thấy là trình biên dịch một phiên bản dùng cho ra một sản
phẩm phần mềm khác so với phiên bản đang được gỡ rối. Visual studio.NET
thực hiện việc này bằng cách trữ nhiều chi tiết hơn để có thể hỗ trợ hai loại
xây dựng khác nhau. Những bộ chi tiết khác nhau về thông tin xây dựng
đựoc gọi là Configuration. Khi bạn tạo một dự án mới, Visual studio.NET sẽ
tự động tạo cho bạn hai cấu hình được cho mang tên là Debug và Release :
 Debug configuration: thường sẽ cho biết cho cần tối ưu hóa, thông tin
gỡ rối extra sẽ hiệu sẽ chỉnh sửa trên đoạn mã khả thi, và trình biên dịch giả
định là chỉ thị tiền xử lý debug hiện diện trừ khi nó được ghi rõ ra là
#undefined trong mã nguồn.
 Release configuration: thường cho trình biên dịch biết là phải tối ưu
hoá và như vậy sẽ không có những thông tin extra liên quan đến gỡ rối và
trình biên dịch không được giả định là bất cứ chỉ thị tiền xử lý hiện diện
trong đoạn mã .
Chọn cấu hình
Một câu hỏi được đặt ra là visual studio.NET trữ những chi tiết trên hai cấu
hình, thế thì cấu hình nào sẽ được chọn khi xây dựng một dự án. Câu trả lời
là bao giờ cũng có một cấu hình hiện dịch mà Visual studio.NET phải dùng
đến. Theo mặc nhiên, khi bạn tạo một dự án, cấu hình debug bao giờ cũng là
cấu hình hiện dịch. Bạn có thể thay đổi cấu hình hiện dịch bằng cách ra lệnh
Build/Configuration Manager để hiện lên khung đối thoại Configuration
Manager, rồi chọn mục Debug hoặc Release trên ô liệt kê Active solution
Configuration hoặc trên thanh công cụ chính có ô liệt kê cho phép bạn chọn
debug hoặc Release hoặc Copnfiguration Manager.
Hiệu đính cấu hình
Chọn dự án muốn chỉnh sửa trên cửa sổ Solution explorer, rồi ra lệnh project
/ Properties, hoặc click phải trên dự án để hiện lên trình đơn short cut, rồi

bạn chọn mục properties. Lúc này khung đối thoại Properties pages hiện
lên.

Khung đối thoại này chứa một tree view phía tay trái cho phép bạn lựa chọn
khá nhiều vùng khác nhau để quan sát hoặc chỉnh sửa. Chúng tôi không thể
cho thấy tất cả các lĩnh vực nhưng chúng ta sẽ cho thấy vài lĩnh vực quan
trọng.
Ở hình trên cho thấy hai mắt nút cấp cao: Common properties và
Configuration properties. Ta thấy Common properties/General đối với dự
án Basic ConsoleApp. Bạn có thể chọn tên assembly cần được kết sinh. Mục
chọn Output type ở đây là: Console application, window application và
class library. Bạn có thể thay đổi loại assembly nếu bạn muốn nhưng xem ra
hơi vô lý, vì lúc ban đầu bạn đã chọn rồi trên khung đối thoại New Project.
Hình bên dưới cho thấy cấu hình xây dựng :

Trên đầu khung đối thoại, bạn thấy có một list box " Configuration" cho
phép bạn khai báo cấu hình nào bạn muốn quan sát. Trong trường hợp cấu
hình Debug, ta có thể thấy là những chỉ thị tiền xử lý DEBUG và TRACE
được giả định là có, việc tối ưu hoá không được thực hiện và những thông
tin gỡ rối sẽ được kết sinh.
Nhìn chung, sở dĩ chúng tôi đi vào chi tiết liên quan đến cấu hình, nhưng
phần lớn trưòng hợp ít khi bạn phải điều chỉnh chúng. Tuy nhiên bạn phải
hiểu để chọn đúng cấu hình tuỳ theo việc bạn xây dựng thế nào dự án của
bạn và cũng là điều bổ ích khi biết tác dụng của những cấu hình khác nhau.
Gỡ rối chương trình
Trên C#, cũng như trên các ngôn ngữ đi trước .NET, kỹ thuật chính trong
việc gỡ rối chuơng trình là đơn giản đặt những chốt dừng, rồi sử dụng chúng
để xem xét việc gì xảy ra trong đoạn mã của bạn tại một điểm nào đó trong
khi thi hành chương trình.
Các chốt ngừng:

Bạn có thể đặt các chốt ngừng từ Visual studio.NET lên bất cứ dòng nào trên
đoạn mã hiện đang được thi hành. Cách đơn giản nhất là click lên dòng lệnh
trên code editor, trên biên trái màu xám. Dòng lệnh đổi màu với một chấm
tròn ở biên trái. Lúc này một chốt ngừng được đặt để trên hàng này, làm cho
việc thi hành sẽ tạm ngừng khi Debugger đạt đến hàng này và chuyển quyền
điều khiển cho debuger. Nếu bạn click trên chấm tròn của dòng lệnh này thì
xem như chốt ngừng bị gỡ bỏ, dòng lệnh trở lại màu bình thường của văn
bản.
Các cửa sổ quan sát
Khi một chốt ngừng đã đạt đến, thường thì bạn muốn khảo sát. Lúc này một
ô hình chữ nhật màu vàng hiện lên cho biết trị của biến. Tuy nhiên, có thể
bạn lại muốn sử dụng của sổ Watch window để xem nội dung của các biến
cửa sổ dạng thẻ. Cuối màn hình code editor là một loạt thẻ các cửa sổ Local,
Auto, Watch, Call stack, Breakpoint, Command, Output Các cửa sổ này
chỉ hiện lên khi chương trình đang chạy dưới sự điều khiển của Debugger.
Có 3 loại cửa sổ kiểu tab dùng điều khiển những biến khác nhau:
Autos: cho biết tình trạng của một vài biến được truy xuất khi chương trình
đang thi hành.
Locals: Cho biết tình trạng của biến được truy xuất trong phương thức đang
thực thi
Watch : cho biết tình trạng của bất cứ biến nào mà bạn đã khai báo rõ ra
bằng cách gõ vào tên biến trong cửa sổ Watch.
Biệt lệ
Biệt lệ cho phép bạn thụ lý cách thích ứng những điều kiện sai lầm xảy ra
trong ứng dụng mà bạn muốn phân phối. Nếu được sử dụng đúng đắn, biệt lệ
bảo đảm ứng dụng của bạn kiểm soát tốt hoạt động và người sử dụng không
phải phiền lòng khi nhận những khung đối thoại mang tính quá kỹ thuật. Tuy
nhiên, điều phiền toái là khi gỡ rối, biệt lệ gây không ít khó khăn cho bạn.
Có hai vấn đề:
Nếu biệt lệ xảy ra, thì liền sau đó khi bạn đang gỡ rối thường thì bạn không

muốn biệt lệ được tự động thụ lý bởi chương trình của bạn. Thay vào đó,
bạn muốn Debugger nhập cuộc để xem ra vì sao biệt lệ xảy ra, để có thể gỡ
bỏ lý do sai lầm trước khi phân phối sản phẩm.
Nếu một biệt lệ xảy ra mà bạn chưa hề viết một hàm thụ lý biệt lệ này, thì
.NET runtime sẽ đi tìm tiếp một hàm thụ lý biệt lệ. Tuy nhiên, đến khi .NET
Runtime nhận ra là không có hàm nào, nó sẽ cho chấm dứt chương trình. Và
lúc này, cửa sổ Call Stack cũng sẽ biến mất không còn gì để bạn có thể xem
xét trị của các biến, vì chúng đã ra ngoài phạm vi.