Tôi đang cố gắng sử dụng hộp thoại chung GetOpenFileName() để mở một hộp thoại và cho phép người dùng chọn nhiều tệp.GetOpenFileName() với cờ OFN_ALLOWMULTISELECT đặt
Tôi đã đặt cờ OFN_ALLOWMULTISELECT, cũng như OFN_EXPLORER để tôi nhận được hộp chọn tệp "kiểu mới".
Khi tôi thiết lập cấu trúc OPENFILENAME, tôi có ofn.lpstrFile trỏ đến bộ đệm được cấp phát để giữ kết quả và ofn.nMaxFile được đặt theo chiều dài.
Sự cố tôi gặp phải là nếu người dùng chọn quá nhiều tên tệp mà bộ đệm sẽ tràn, lệnh gọi GetOpenFileName sẽ trả về FALSE và sau đó CommDlgExtendedError() trả về FNERR_BUFFERTOOSMALL.
Tốt cho việc phát hiện lỗi và tôi có thể tăng dung lượng bộ đệm để sửa lỗi, nhưng sớm hay muộn người dùng sẽ chọn đủ tên tệp để tràn bộ đệm đó.
Tôi đã nhìn thấy ghi chú trong MSDN nói rằng nếu bộ đệm quá nhỏ, hai byte đầu tiên của bộ đệm lpstrFile sẽ chứa kích thước yêu cầu, nhưng kích thước nó trở về có vẻ quá nhỏ (có thể điều này là chính xác khi OFN_ALLOWMULTISELECT không được đặt). Thêm vào đó, điều này sẽ yêu cầu tôi mở lại hộp thoại! Một ý nghĩ khác tôi đã tạo ra một thủ tục móc thoại, và sau đó phát hiện kích thước của tên tập tin khi tôi nhận được một thông điệp CDN_SELCHANGE thông báo và tự động phân bổ một bộ đệm có kích thước chính xác, nhưng trong khi nó sẽ ghi dữ liệu trong đệm, có vẻ như nhớ giá trị orignal của ofn.nMaxFile.
Có ai biết cách chính xác để phân bổ động bộ đệm để giữ kết quả cuộc gọi GetOpenFile mà không làm cho hộp thoại xuất hiện hai lần không?
Vì vậy, nó chỉ ra rằng bài viết của Martlark là đúng về tiền.
2 sai lầm của tôi là:
1) Tôi quên để thêm MAX_PATH vào kích thước để applcate trong móc, và
2) Điều này chỉ hoạt động trong phiên bản unicode của GetOpenFileName. (Tôi đã biên soạn với UNICODE không phải được xác định)
Tôi đã gặp vấn đề tương tự chính xác này từ lâu trước đây .. Tôi đang cố ghi nhớ cách chúng tôi vượt qua nó cho bạn! – RobS