MSDN khuyên rằng chức năng RegisterWindowMessage() chỉ được sử dụng để đăng ký các tin nhắn được gửi giữa các quá trình. Nếu một tin nhắn là cần thiết để gửi trong một quá trình nó có thể được lựa chọn một cách an toàn từ phạm vi WM_APP thông qua 0xBFFF.Có thể lạm dụng RegisterWindowMessage dẫn đến cạn kiệt tài nguyên không?
Tuy nhiên trong codebase của chúng tôi, tôi thường thấy rằng RegisterWindowMessage() được sử dụng cho các thư chỉ được gửi trong một quá trình. Tôi cho rằng điều này đã được thực hiện vì sự đơn giản của việc sử dụng RegisterWindowMessage() vì nó không yêu cầu phân phối thủ công các định danh thông báo trong phạm vi WM_APP..0xBFFF. Tôi có hiểu chính xác rằng nếu nhiều ứng dụng được chạy trên một máy và tất cả chúng đều gọi RegisterWindowMessage() với các chuỗi khác nhau, chúng có thể loại bỏ phạm vi nhận dạng tin nhắn được phép trả lại bởi RegisterWindowMessage() và một số trong số đó trả lại một giá trị cho thấy một thất bại? Điều gì có thể là một lý do hợp lệ để sử dụng các thông điệp RegisterWindowMessage() trong trường hợp các tin nhắn phạm vi WM_APP..0xBFFF sẽ đủ?
Không biết về điều đó lỗi trong C++ Builder/Delphi! Nasty ... –
C++ Builder/Delphi (VCL) tạo tên tin nhắn từ 'HInstance' (' GetModuleHandle') và ID chủ đề.Đối với thực thi bình thường, 'HInstance' không thay đổi và phạm vi của các ID luồng bị giới hạn, không chắc rằng ứng dụng VCL làm cạn kiệt bảng nguyên tử. Đáng tin cậy hơn là nó trong trường hợp DLL được xây dựng trong VCL. Hoặc khi tập tin thực thi có ASLR (yêu cầu chứng nhận Windows 8 là gì). –