Lý do cho hạn chế chuỗi giao diện .NET UI

Question

Chúng tôi biết rằng không thể thực thi mã điều khiển thuộc tính của bất kỳ phần tử giao diện người dùng nào từ bất kỳ chuỗi nào khác với chuỗi mà phần tử được khởi tạo trên ... Câu hỏi của tôi là: Tại sao ?

Tôi nhớ rằng khi chúng ta sử dụng các thành phần giao diện người dùng COM, (trong COM/Visual Basic 6.0 ngày), tất cả các phần tử giao diện người dùng được tạo bằng cách sử dụng các lớp COM và các lớp đồng lưu trữ tài nguyên của chúng bằng mô hình bộ nhớ. -Local-Storage (TLS), nhưng khi tôi nhớ lại, điều này là bắt buộc vì một cái gì đó liên quan đến cách COM thành phần được xây dựng, và không nên có liên quan đến các yếu tố NET UI. Lý do cơ bản tại sao hạn chế này vẫn tồn tại là gì?

Có phải vì Hệ điều hành cơ bản vẫn sử dụng các lớp API Win32 dựa trên COM cho tất cả các phần tử giao diện người dùng, thậm chí cả các phần tử được thao tác trong một ứng dụng .NET được quản lý?

Answer 1

AFAIK, nó cơ bản hơn cả COM. Nó đi ngay xuống Windows API tốt. Tôi tin rằng các cửa sổ trong Windows dự kiến ​​sẽ được sở hữu bởi một chủ đề, thời gian. Mỗi luồng có bơm thông điệp riêng, gửi tin nhắn đến các cửa sổ mà nó sở hữu. Đó là một cấu trúc khá cơ bản của Windows - có lẽ một chút cổ xưa những ngày này, nhưng cơ bản. Cảm giác của tôi về mối quan hệ này giúp cho khả năng tương tác khi bạn cần tích hợp WPF vào các ứng dụng Windows Forms, hoặc nếu bạn cần khỉ với một đối tượng Windows ở một nơi khác trong ứng dụng của bạn bằng HWND mà bạn có ở đâu đó. Nó cũng có thể là những gì cho phép các phiên bản cũ của Windows (XP) để lưu trữ các ứng dụng WPF mà không có bất kỳ thay đổi kiến ​​trúc lớn nào đối với bản thân hệ điều hành.

Answer 2

Từ http://msdn.microsoft.com/en-us/library/ms741870.aspx:

Về mặt lịch sử, Windows cho phép UI yếu tố để được truy cập chỉ bằng sợi đã tạo ra chúng. Điều này có nghĩa là rằng chuỗi nền phụ trách một số tác vụ dài hạn không thể cập nhật hộp văn bản khi hoàn tất. Windows thực hiện điều này để đảm bảo tính toàn vẹn của thành phần giao diện người dùng. Hộp danh sách có thể trông là lạ nếu nội dung của nó được cập nhật theo chủ đề nền trong khi vẽ.

Answer 3

Có vẻ như bạn đang đề cập đến WPF thay vì lập trình Windows API chung. Tôi không có chuyên gia về WPF internals, nhưng đây là một vài mục về lý do tại sao giữ UI thao tác trong một thread UI là một ý tưởng tốt:

1. Tránh deadlocks. Khi bạn có nhiều chuỗi chạy xung quanh, tất cả tài nguyên được chia sẻ phải được bảo vệ bằng một số loại khóa. Khi có nhiều khóa, có nguy cơ cao bị kẹt trong bế tắc - luồng A sở hữu khóa 1 nhưng đang chờ khóa 2, chủ đề B sở hữu khóa 2 nhưng đang chờ khóa 1. Điều này có thể tránh được theo thứ tự nghiêm ngặt khóa mua lại, nhưng bản chất con người rơi ngắn.
2. Giảm nhu cầu tốn kém về khóa. Nếu bạn có thể yêu cầu tất cả các giao diện người dùng để thực thi trên luồng giao diện người dùng, bạn có thể loại bỏ rất nhiều khóa cần thiết để bảo vệ dữ liệu nội bộ.
3. Giảm nguy cơ tạo các cửa sổ xử lý thuộc sở hữu của chủ đề không có vòng tin nhắn.

Mục cuối cùng là liên quan đến Win API. Khi một cửa sổ xử lý được tạo ra, nó là ràng buộc với thread đã ban hành các cuộc gọi CreateWindow. Tin nhắn được gửi đến cửa sổ xử lý đó sẽ được đặt trong hàng đợi tin nhắn được liên kết với chuỗi đó.Nếu chuỗi đó không xử lý thông báo cửa sổ, cửa sổ sẽ không phản hồi - UI bị đóng băng. Nếu một luồng khác cố gắng SendMessage đến cửa sổ đó, chuỗi đó cũng sẽ bị đóng băng chờ cuộc gọi đồng bộ hoàn thành. Snowballs này khá nhanh chóng vào xấu xí trên tất cả. Đây là lý do tại sao điều quan trọng là phải đảm bảo rằng bạn chỉ tạo các chốt cửa sổ trên các luồng được chuẩn bị để xử lý các thông báo cửa sổ.

Tại sao hàng đợi thông báo của xử lý cửa sổ bị ràng buộc vào một chuỗi cụ thể? Tôi không biết, nhưng tôi chắc rằng câu trả lời không phải là tầm thường.