Đồ án tốt nghiệp - Phân tích thiết kế hệ thống - Nghiên cứu các phương pháp nhận dạng từ dưới cursor mouse trên Desktop Windows

Chia sẻ: Nguyen Hai | Ngày: | Loại File: PDF | Số trang:138

Thêm vào BST

Báo xấu

130
lượt xem 13
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Tham khảo luận văn - đề án 'đồ án tốt nghiệp - phân tích thiết kế hệ thống - nghiên cứu các phương pháp nhận dạng từ dưới cursor mouse trên desktop windows', luận văn - báo cáo, công nghệ thông tin phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Đồ án tốt nghiệp - Phân tích thiết kế hệ thống - Nghiên cứu các phương pháp nhận dạng từ dưới cursor mouse trên Desktop Windows

Đề tài : Nghiên cứu các phương pháp nhận dạng từ dưới cursor mouse trên Desktop Windows. VO MINH TRUC
Lời Mở Đầu gày nay, hầu như mọi công việc hàng ngày liên quan đến cuộc sống của chúng ta đều diễn ra trên máy tính. Từ việc soạn thảo văn bản, gởi nhận thông tin đến việc tra cứu, truy cập thông tin từ hệ thống mạng máy tính toàn cầu Internet đối với người sử dụng là công việc thường ngày và rất phổ biến. Từ đó, sẽ phát sinh vấn đề là người sử dụng sẽ cần tìm hiểu ý nghĩa của một từ, một câu hoặc cần phải dịch một đoạn văn bản, một file dữ liệu nào đó ra tiếng Việt và ngược lại. Đây là một nhu cầu cần thiết và hầu như xảy ra thường xuyên đối với nhiều người, do đó nhận dạng từ đặc biệt là nhận dạng từ trên màn hình trong môi trường Windows là việc làm cần thiết và có ý nghĩa thực tế. Kết quả của việc nhận dạng từ sẽ được dùng để xây dựng nên các ứng dụng khác chẳng hạn như các từ điển được tra cứu theo kiểu tương tác trực tiếp sẽ rất thuận tiện cho người sử dụng bởi vì theo cách này thì cho dù đang ở trong bất kỳ ứng dụng nào khi cần tra cứu thì thao tác trực tiếp ngay trên ứng dụng đang dùng tức là chỉ cần click chuột vào đó chứ không cần phải mở từ điển rồi tra cứu từ đó theo kiểu cổ điển. Vì thế, trong thời gian làm Luận Án Tốt nghiệp được sự hướng dẫn của thầy Lê Tấn Hùng nhóm sinh viên chúng tôi thực hiện đề tài: “ Nhận dạng từ dưới cursor mouse trên deskop Windows. Viết chương trình nhận dạng từ này ”. Trong giai đoạn đầu của Luận Án Tốt Nghiệp chúng tôi đã nghiên cứu được một số vấn đề quan trọng và căn bản có ý nghĩa trong việc thực hiện yêu cầu đã đặt ra của đề tài. Đề tài này chỉ tập trung nhận dạng từ ở dạng text trên desktop của môi trường Windows rồi xuất kết quả ra. Trong thời gian làm Luận Án Tốt Nghiệp nhóm sinh viên chúng tôi đã tiến hành nghiên cứu cơ chế hoạt động và quản lý của hệ điều hành Windows. Nghiên
cứu về phương thức lập trình trong môi trường Windows và các phương tiện mà Windows hỗ trợ khi lập trình. Tham khảo và nghiên cứu kỹ thuật override các hàm giao tiếp của Windows ở chế độ 16 bit và 32 bit. Nghiên cứu cách xử lý các thông điệp trong Windows và tìm hiểu về cách kết xuất văn bản, về chế độ ánh xạ, vấn đề tọa độ . . . và cách xử lý văn bản. Trên cơ sở đó bước đầu chúng tôi đã xây dựng xong một ứng dụng có khả năng nhận dạng được từ trên nền Windows 16 bit được viết bằng ngôn ngữ Visual C++ version 1.5 và hướng phát triển trong thời gian tới là hiện thực nó trên nền Win32. Báo cáo của chúng tôi sẽ lần lượt điểm qua những nội dung mà chúng tôi đã nghiên cứu và tìm hiểu được trong thời gian qua. Sau đó là phần giới thiệu chi tiết về chương trình từ khâu phân tích-thiết kế cho đến phần chương trình nguồn và cuối cùng sẽ là nêu những vấn đề còn tồn tại và hướng phát triển trong tương lai. MỤC LỤC LỜI MỞ ĐẦU 3 CHƯƠNG 1: TÌM HIỂU VỀ LẬP TRÌNH WINDOWS 4 I. Khái quát về lập trình trong Windows 5 II. Thông điệp và xử lý thông điệp 7 III. Giao diện thiết bị đồ họa GDI 11 IV. Cửa sổ trong Windows 15 V. Chương trình Windows tiếp nhận thông điệp chuột 22
CHƯƠNG 2: TÌM HIỂU VỀ HOOK 26 1 - Chuỗi hook 27 2 - Thủ tục hook 27 3 - Các loại hook 28 4 - Sử dụng hook 30 5 - Hook trong Windows 3.x 31 6 - Giới thiệu một số hàm liên quan đến hook 33 CHƯƠNG 3: KỸ THUẬT OVERRIDE HÀM API 36 I. Khái quát về kỹ thuật override 37 II. Lý do sử dụng kỹ thuật override trong lập trình Windows 37 III. Cơ chế hoạt động và quản lý bộ nhớ trên Windows 16bits 38 IV. Cơ chế hoạt động và quản lý bộ nhớ trên Windows 32bits 41 V. Hiện thực kỹ thuật override trên Windows 16bits 45 VI. Một số hàm được sử dụng trong kỹ thuật override 50
CHƯƠNG 4: KẾT XUẤT VĂN B ẢN TRONG WINDOWS 54 I. Kết xuất văn bản trong Windows 55 II. Các hàm căn bản để kết xuất văn bản 55 CHƯƠNG 5: PHÂN TÍCH VÀ THIẾT KẾ CHƯƠNG TRÌNH 66 I. Phân tích vấn đề 67 II. Thiết kế chương trình 68 III. Giới thiệu một số hàm có liên quan 78 IV. Giới thiệu một số cấu trúc dữ liệu có liên quan 92 KẾT QUẢ VÀ HƯỚNG PHÁT TRIỂN 97
Chương 1: TÌM HIỂU VỀ LẬP TRÌNH WINDOWS I - KHÁI QUÁT VỀ LẬP TRÌNH TRONG WINDOWS: 1 - Khái quát về lập trình trong Windows: Môi trường lập trình Windows về cơ bản là dựa trên bộ hàm API (Application Programmer Interface), nó có chức năng như các ngắt trong bảng vector ngắt của DOS, nhưng nó thân thiện hơn ở chỗ cách gọi hàm API giống hệt cách gọi hàm của ngôn ngữ cấp cao, mỗi hàm có một tên gọi hẳn hoi, và tên gọi thường được đặt rất phù hợp với công dụng của hàm (mặc dù có h ơi dài dòng) từ đó tạo khả năng gợi nhớ cao. Với Windows, người lập trình không còn phải lập trình theo kiểu assembly nữa mà lập trình theo kiểu ngôn ngữ cấp cao, mọi hoạt động trong máy ở mức thấp từ hàm API trở xuống thuộc phạm vi của Windows, và Windows không khuyến khích việc các ứng dụng can thiệp vào lĩnh vực này. Bù lại, bằng các hàm API, nó hỗ trợ rất hiệu quả cho người lập trình, giúp khai thác khả năng của thiết bị triệt để, dễ dàng và tiện lợi hơn bao giờ hết. Có thể nói Windows đã mở ra cho người lập trình không gian rộng lớn để phát triển ứng dụng, và hạn chế không gian phát triển hệ thống. Điều này dẫn đến hệ quả là các ứng dụng được tạo ra hết sức dễ dàng, và quan trọng là hệ thống chạy ổn định hơn, không bị treo do lỗi của ứng dụng, không thể xâm nhập, nhưng sẽ rất khó khăn nếu người lập trình muốn trực tiếp điều khiển hoạt động trong máy và phát triển về lập trình hệ thống. - Tìm hiểu hàm Windows API: Windows là một hệ điều hành đa nhiệm (multitasking) mà qua đó các ứng dụng ở trong môi trường Windows sẽ giao tiếp với user thông qua một hay nhiều giao diện. Để truy cập các giao diện này thì các
ứng dụng được xây dựng trên môi trường Windows sẽ sử dụng tập các hàm được gọi là giao diện chương trình ứng dụng API (Application Program Interface). Chương trình của người sử dụng có thể gọi tới các hàm API để truy cập tới mọi tài nguyên của Windows. GDI là một bộ phận của API, giao diện thiết bị đồ họa GDI (Graphic Device Interface) có nhiệm vụ duy trì sự độc lập của Windows đối với các thiết bị đồ họa hay còn gọi là khả năng độc lập thiết bị (device independent) tức là cho phép Windows làm việc với nhiều kiểu thiết bị đồ họa khác nhau. 2 - Thư viện liên kết động DLL (Dynamic Link Library): Thư viện liên kết động là các tập tin được Windows lưu dưới dạng nhị phân chứa các hàm mà mọi ứng dụng trên Windows đều có thể sử dụng. Nét đặc trưng của DLL là nó có thể được sử dụng bởi nhiều ứng dụng tại cùng một thời điểm hay nói cách khác thư viện liên kết động có thể cùng một lúc được gọi bởi nhiều chương trình. DLL là một dữ liệu chia sẻ được (shared data). Có 3 loại DLL khác nhau: - Thư viện liên kết động API: thuộc hệ thống Windows, khi cài hệ điều hành thì nó đã có sẵn. Chúng được nạp khi Windows khởi động. - Thư viện liên kết động third party: do các công ty khác tạo ra trên môi trường Windows, hỗ trợ thêm công tác lập trình trong Windows. - Thư viện liên kết động do chúng ta tạo ra. Windows sử dụng cấu trúc thư viện liên kết động DLL (Dynamic Link Library) nhằm mục đích không sao chép một khối lượng lớn các mã vào trong chương trình như ở các thư viện thông thường. Nhờ cấu trúc động của DLL nên mọi chương trình đều có thể truy cập thư viện trong thời gian thực thi. Các hàm API
được Windows giữ dưới dạng hỗn hợp trong một số DLL. Trong quá trình dịch khi gặp lệnh gọi hàm API từ chương trình ứng dụng thì chương trình dịch không thêm mã này vào module thực hiện mà chỉ thêm các lệnh liên kết (chứa tên của DLL bên trong có hàm cần nạp) và tên hàm đó. Khi thực thi chương trình thì hàm API thực sự mới được nạp vào bộ nhớ để thực hiện. Cùng với sự phát triển của Windows là sự phát triển của lập trình hướng đối tượng, và để hỗ trợ cho việc lập trình hướng đối tượng, Microsoft đã cung cấp cho người lập trình một bộ thư viện các lớp cơ bản để phát triển các ứng dụng hướng đối tượng gọi là MFC (Microsoft Foundation Classes), nội dung của nó bao gồm thông tin về các lớp cơ bản được chuẩn hóa như lớp application; document; view; OLE; cửa sổ; nút bấm; text; v.v…, trong các lớp này mọi thứ liên quan đến nó (bao gồm dữ liệu và các chương trình xử lý của nó) đều được làm hoàn chỉnh, người lập trình chỉ việc lấy ra sử dụng, hoặc có thể thêm bớt một ít tính năng đặc trưng cho đối tượng của mình. Mục tiêu chính của MFC là hệ thống hóa các hàm API, cung cấp một thể thức gọi gọn các hàm API, cung cấp một “khung làm việc” (framework) cực mạnh để người lập trình không cần phải quan tâm đến những đoạn chương trình thuộc về “thủ tục” mà chỉ cần quan tâm đến phần cốt lõi để đạt được mục đích. II - THÔNG ĐIỆP VÀ XỬ LÝ THÔNG ĐIỆP: 1 - Khái niệm: Lập trình trên môi trường Windows khác với lập trình ở các môi trường khác ở điểm là lập trình trên Windows luôn luôn gắn liền với những thông điệp. Mọi hoạt động xảy ra trên một chương trình Windows đều thông qua các thông điệp. Thông điệp sẽ được hệ thống báo cho các ứng dụng biết các tác động từ bên ngoài vào hệ thống Windows. Một cửa sổ có thể gởi đi một thông điệp cho một cửa sổ khác và các cửa sổ đáp ứng lại thông điệp bằng cách gởi đi một thông điệp khác cho một cửa sổ khác.
Trong Windows có 3 loại thông điệp cơ bản: - Những thông điệp tổng quát: có mã nhận diện mang tiền tố WM_ được coi là phần lớn trong ứng dụng và Windows đã cung cấp các hàm để giải quyết. - Những control notification: đây là những thông điệp WM_COMMAND được chuyển từ cửa sổ con tới cửa sổ bố mẹ. - Những nút lệnh: là thông điệp WM_COMMAND phát đi từ trình đơn, từ các nút điều khiển. Đây là loại thông điệp yêu cầu ứng dụng phải thực hiện một công việc gì đó. 2 - Gởi đi các thông điệp: Windows cho phép ứng dụng gởi đi những thông điệp cho mình, cho các ứng dụng khác hoặc cho hệ thống. Có 3 hàm Windows API để gởi thông điệp đi: a) Hàm SendMessage: Cú pháp: LRESULT SendMessage(hwnd, uMsg, wParam, lParam) HWND hwnd; // handle của cửa sổ nhận (đích) UINT uMsg; // thông điệp để gởi
WPARAM wParam; // thông số thông điệp đầu tiên LPARAM lParam; // thông số thông điệp thứ hai - Hàm SendMessage gởi thông điệp tới một hay nhiều cửa sổ. Hàm gọi thủ tục cửa sổ cho cửa sổ và không trở về cho đến lúc thủ tục cửa sổ đã xử lý thông điệp. - Giá trị trả về: cho biết kết quả xử lý thông điệp và phụ thuộc vào thông điệp được gởi. b) Hàm PostMessage: - Cú pháp: BOOL PostMessage(hwnd, uMsg, wParam, lParam) HWND hwnd; // handle của của sổ đích UINT uMsg; // thông điệp gởi WPARAM wParam; // thông số thông điệp đầu tiên LPARAM lParam; // thông số thông điệp thứ hai - Hàm PostMessage gởi (đặt) một thông điệp vào trong hàng thông điệp cửa sổ và rồi trở về mà không đợi cửa sổ tương ứng xử lý thông điệp. Những thông điệp trong một hàng thông điệp được lấy bằng cách gọi hàm SetMessage hay PeekMessage.
- Giá trị trả về: trả về khác 0 nếu thành công, ngược lại 0. c) Hàm SendDlgItemMessage: - Cú pháp: LRESULT SendDlgItemMessage(hwndDlg,idDlgItem,uMsg,wParam,lParam) HWND hwndDlg; // handle của hộp hội thoại int idDlgItem; // mã nhận diện ô điều khiển sẽ nhận thông điệp UINT uMsg; // thông điệp gởi đi WPARAM wParam; // thông số thông điệp đầu tiên LPARAM lParam; // thông số thông điệp thứ hai - Hàm SendDlgItemMessage gởi một thông điệp tới một điều khiển trong hộp hội thoại. - Giá trị trả về: cho biết kết quả xử lý thông điệp và phụ thuộc vào thông điệp được gởi. 3 - Vòng lặp thông điệp: Một thread hoặc một process đẩy một thông điệp ra khỏi hàng đợi bằng cách dùng vòng lặp thông điệp. Vòng loop chính của một ứng dụng đặt tại cuối hàm WinMain() của ứng dụng đó. Vòng lặp thông điệp có dạng như sau:
while GetMessage(&msg,NULL,0,0) { TranslateMessage(&msg); DispatchMessage(&msg); } Sau đây là Sơ đồ dòng thông điệp: Hardware Event Occur System Message Queue System Dispatcher System Dispatcher Thread1 Message Queue Thread2 Message Queue Thread3 Message Queue Thread1 Hook Thread2 Hook Thread3 Hook GetMessage() GetMessage() GetMessage() TranslateMessage() TranslateMessage() TranslateMessage() Dispatch Message() Dispatch Message() Dispatch Message() WndProc() WndProc() WndProc() DefWndProc() DefWndProc() DefWndProc()
Nó mô tả đơn giản hóa quá trình xử lý thông điệp. Thông điệp có thể bắt nguồn từ nhiều cách khác nhau, sơ đồ sau đây sẽ giải thích chi tiết hơn về vòng lặp thông điệp và chỉ ra cách thông điệp được đặt vào hàng đợi như thế nào: Hardware Events Other threads PostMessage() System Message Queue Other threads PostMessage() System Dispatcher Message Sent From Other Threads SentMessage() PostMessage() Thread Message Queue (To Another Thread) TranslateMessage() Message Loop SentMessage() WndProc() Thông điệp không chỉ phát xuất từ sự kiện phần cứng, cũng có thể có thông điệp của chương trình phát xuất từ một chương trình đang chạy. Các threads có thể gởi dữ liệu trở về sau và về trước bằng cách gởi thông điệp. Thông điệp có thể gởi vào hàng đợi bằng hàm PostMessage() , hoặc chúng có thể được gởi trực tiếp cho vòng lặp thông điệp để xử lý ngay lập tức bằng hàm SendMessage(). 4 - Xử lý thông điệp: Việc xử lý thông điệp là yếu tố chính làm cho các ứng dụng Windows vận hành được. Hệ thống và các ứng dụng khác sinh ra các thông điệp cho mọi sự kiện xuất hiện trong hệ thống thông điệp của Windows sẽ cho phép Windows chạy đa
nhiệm trong một thời điểm. Windows 95 và Windows NT mở rộng khả năng của version Windows trước bằng việc cấp phát cho mỗi dòng xử lý (thread) hay mỗi tiến trình (proccess) một hàng đợi thông điệp riêng. Trong version Windows cũ thì tất cả ứng dụng đều dùng chung một hàng đợi thông điệp, vì thế để các ứng dụng khác xử lý thông điệp, ứng dụng phải trả quyền điều khiển về cho Windows mỗi khi nó có thể. Với Windows 95 và Windows NT, điều này không còn nữa. Windows sinh ra thông điệp cho mọi sự kiện phần cứng, ví dụ như người dùng nhấn một phím hoặc di chuyển chuột. Nó gởi thông điệp đến hàng đợi thông điệp của thread thích hợp, nếu thông điệp được dành cho nhiều thread thì nó cũng được đưa vào các hàng đợi của các thread đó. Một thông điệp trên thực tế là một cấu trúc dữ liệu như sau: typedef struct tagMSG { HWND hwd; // handle cửa sổ UINT message; //số chỉ định loại message WPARAM wParam; //được chuyển cho WndProc() LPARAM wParam; //được chuyển cho WndProc() DWORD time; //số mili giây từ lúc bắt đầu POINT pt; //cấu trúc điểm POINT }
III - GIAO DIỆN THIẾT BỊ ĐỒ HỌA GDI (GRAPHIC DEVICE INTERFACE): 1 - Khái niệm: Windows là một hệ điều hành đa nhiệm (multitasking) trong đó các ứng dụng giao tiếp với user thông qua một hay nhiều giao diện. Để truy xuất các giao diện thì chương trình ứng dụng phải sử dụng các hàm Giao diện chương trình ứng dụng. API là tập các lệnh mà một ứng dụng sử dụng để yêu cầu và tiến hành các dịch vụ cấp thấp được thi hành bởi Windows. Giao diện thiết bị đồ họa GDI (Graphic Device Interface) là một phần của API có nhiệm vụ duy trì sự độc lập của Windows đối với các thiết bị đồ họa (cho phép Windows làm việc với nhiều thiết bị đồ họa khác nhau). Windows GDI là một thư viện bao gồm một số hàm giúp kết xuất đồ họa (graphic output) lên màn hình, máy in…GDI sẽ tạo ra: điểm, đường kẻ, hình dạng (shape: chữ nhật, tròn…), chữ văn bản. 2 - Device Context: Ngữ cảnh thiết bị DC (Device Context) là một phần quan trọng của GDI Windows. Một DC là một cấu trúc dữ liệu dài khoảng 800 bytes được Windows duy trì có nhiệm vụ lo lưu giữ những thông tin cần thiết mà ứng dụng sẽ cần đến khi phải hiển thị kết xuất lên một thiết bị vật lý. GDI không bao giờ cho phép ch ương trình làm việc trực tiếp với một DC mà GDI phân phối cho chương trình một handle để nhận dạng một DC cụ thể. Tất cả các hàm API; GDI đều nhận thông số đầu tiên là một handle – hdc.
DC là một công cụ chứa các thuộc tính vẽ, DC cho phép kết nối logic một chương trình về một thiết bị cụ thể nào đó. Ngoài ra do Windows là một hệ điều hành đa nhiệm nên các chương trình không thể truy xuất trực tiếp các thiết bị vật lý để tránh xung đột. Thay vào đó, chương trình Windows phải sử dụng kết nối logic do DC đại diện. Nghĩa là tất cả các chương trình cách tiếp cận này để GDI có thể giải quyết tranh chấp khi 2 chương trình yêu cầu dùng cùng một thiết bị nên DC còn có vai trò làm permission slip. DC lưu trữ thông tin liên quan đến mặt bằng vẽ và những khả năng của nó. Trước khi sử dụng bất kỳ hàm vẽ GDI nào thì điều phải tạo một DC cho thiết bị, và khi sử dụng xong thì phải trả nó về cho Windows nhằm đảm bảo cho hoạt động của hệ thống được thông suốt bởi vì số lượng DC mà Windows quản lý là có giới hạn. DC ở Win16: Ngữ cảnh thiết bị (DC) là một nối kết giữa một ứng dụng Windows, một driver thiết bị và một thiết bị đầu ra (output device). Windows duy trì một cache gồm 5 DC đặc biệt cho hoạt động hệ thống. Ứng dụng phải giải phóng các DC này sau khi sử dụng. Luồng thông tin từ ứng dụng Windows qua DC và device driver tới thiết bị đầu ra: Truy xuất thiết bị đầu ra (Accessing Output Devices): Bất kỳ ứng dụng Windows nào cũng có thể sử dụng hàm GDI để truy xuất một thiết bị đầu ra. GDI chuyển các gọi độc lập thiết bị từ ứng dụng tới driver thiết bị. Rồi driver thiết bị thông dịch các gọi đó vào trong sự hoạt động độc lập thiết bị. Những đặc tính của DC mô tả các đối tượng vẽ được chọn (pens và brushes), font được chọn và màu của nó, cách thức mà đối tượng được vẽ (hay ánh xạ) tới thiết bị, vùng trên thiết bị có sẵn cho output (vùng xén) và những thông tin quan trọng khác. Cấu trúc chứa những đặc tính DC được gọi là khối dữ liệu DC.
Windows Device Output Application Driver Device Windows GDI Device Output Application Device Driver Device Windows Device Output Application Driver Device 3 - Chế dộ ánh xạ (mapping mode): Để duy trì sự độc lập thiết bị, GDI tạo ra output ở không gian luận lý và ánh xạ nó lên màn hình. Chế độ ánh xạ cho biết mối quan hệ giữa không gian luận lý và những pixel trên thiết bị. Có tới 8 chế độ ánh xạ khác nhau nhưng chúng tôi chỉ quan tâm tới chế độ ánh xạ MM_TEXT vì đây là chế độ ánh xạ mặc định. Trong chế độ này một đơn vị luận lý được ánh xạ tới một pixel trên thiết bị hay màn hình. Như vậy đơn vị tính luận lý là pixel và các tọa độ x, y cũng được tính theo pixel, trị x tăng khi qua phải và giảm khi qua trái, trị y tăng khi đi xuống và giảm khi đi lên. Origin của hệ thống tọa độ là góc trái-trên (upper-left) của màn hình. 4 - Hệ thống tọa độ windows: Windows sử dụng các hệ thống tọa độ khác nhau tùy theo hoàn cảnh như:
Hệ toạ độ thiết bị (Device coordinate system) - Hệ toạ độ toàn màn hình (Full screen coordinate system) - Hệ toạ độ vùng client (Client area coordinate system) - Hệ toạ độ toàn cửa sổ (Whole window coordinate system) - Hệ toạ độ logic (Logical coordinate system) Trong phạm vi ứng dụng của đề tài chúng tôi chỉ quan tâm đến các hệ toạ độ : a) Full screen coordinate system: Là hệ thống tọa độ thiết bị liên quan tới trọn màn hình. Tọa độ màn hình được tính theo pixel và chọn tọa độ (0,0) làm góc upper-left của màn hình. Hệ thống này sử dụng khi liên quan đến trọn màn hình trên tọa độ màn hình. Thường vị trí của một đối tượng như con nháy hoặc con trỏ hoặc cửa sổ so với góc upper-left của màn hình thì dùng hệ tọa độ này. b) Client area coordinate system: Cũng là hệ tọa độ thiết bị, nó khác với hệ tọa độ trọn màn hình ở origin của hệ tọa độ. Tọa độ trọn màn hình là tương đối so với upper-left của màn hình còn tọa độ vùng client là tương đối so với upper-left của vùng client. Tọa độ này cũng tính theo device unit (pixel) giống như tọa độ màn hình. Hàm ClientToScreen để chuyển tọa độ vùng client qua tọa độ trọn màn hình.
Hàm ScreenToClient chuyển tọa độ trọn màn hình qua tọa độ vùng client. c) Whole window coordinate system: Gần giống hệ tọa độ vùng client, là tương đối so với góc upper-left của cửa sổ, được sử dụng khi vẽ vùng nonclient của cửa sổ. d) Logical coordinate: Hầu hết các hàm GDI sử dụng hệ tọa độ này. Hệ thống tọa độ logic không phải là hệ thống tọa độ thiết bị, hệ thống tọa độ logic bao giờ cũng được ánh xạ lên một hệ thống tọa độ thiết bị. Hệ tọa độ logic có thể được ánh xạ lên hệ tọa độ toàn màn hình, hệ tọa độ vùng client hoặc hệ tọa độ toàn cửa sổ. Dùng hàm DPtoLP để chuyển tọa độ thiết bị sang hệ tọa độ logic. Dùng hàm LPtoDP để chuyển tọa độ logic sang hệ tọa độ thiết bị. Như vậy điều quan trọng trong việc tính toán sử dụng hệ tọa độ là phải kiểm soát được việc sử dụng các hệ tọa độ một cách đồng bộ bởi vì việc chuyển đổi giữa các hệ tọa độ đã được cung cấp bởi các hàm nêu trên. 5 - Viewport và window: Mapping mode cho biết ánh xạ tọa độ logic và những kích thước được cung cấp khi gọi các hàm GDI qua hệ thống tọa độ thiết bị gắn liền với DC. Tức là mapping mode quyết định GDI ánh xạ việc ánh xạ một window (tọa độ logic) qua một viewport (tọa độ thiết bị). Viewport nghĩa là một vùng hình chữ nhật của hệ thống tọa độ thiết bị được định nghĩa bởi một DC còn window khi sử dụng để qui
chiếu GDI mapping mode là một hình chữ nhật của hệ thống tọa độ logic được định nghĩa bởi một DC. Công thức để chuyển đổi một hệ tọa độ window (logic) qua một hệ tọa độ viewport (thiết bị): xviewport = (xwindow - xwindowOrg)(xviewportExt / xwindowExt) + xviewportOrg yviewport = (ywindow - ywindowOrg)(yviewportExt / ywindowExt) + yviewportOrg Trong đó: (xwindow,ywindow) là điểm trên tọa độ logic được chuyển đổi thành điểm (xviewport,yviewport) (xwindowOrg,ywindowOrg) và (xviewportOrg,yviewportOrg) là origin của vùng hình chữ nhật window và viewport theo mặc nhiên các điểm này được cho về (0,0) trên DC mặc nhiên. Công thức sử dụng 2 điểm cho biết extent của một vùng theo tọa độ logic (xwindowExt,ywindowExt) và của một vùng theo hệ tọa độ thiết bị (xviewportExt,yviewportExt). Tỉ lệ của (viewpot extent / window extent) là hệ số scaling dùng để dịch đơn vị logic qua đơn vị thiết bị. Việc chuyển đổi ngược lại tương tự bằng các biến đổi công thức trên.