2009-07-12 35 views
7

Tôi muốn viết một ứng dụng có thể có nhiều tài liệu trong một cửa sổ duy nhất thông qua giao diện tab. Tôi có nên tránh kiến ​​trúc NSDocument (mẫu ứng dụng dựa trên tài liệu ca cao) không? Theo như tôi có thể nói, nó chỉ hỗ trợ một hoặc nhiều cửa sổ cho mỗi tài liệu nhưng không hỗ trợ ngược lại.Nhiều tài liệu trong một cửa sổ đơn trong Cocoa

Tôi đã vật lộn với câu hỏi này một lúc và đã xây dựng phần lớn ứng dụng của tôi trên kiến ​​trúc NSDocument nhưng tôi không thể tìm ra cách tốt để liên kết nhiều tài liệu với một cửa sổ đơn.

EDIT: Tôi muốn có cửa sổ tài liệu dự án ngoài các cửa sổ tài liệu cơ bản. Ở mức độ phức tạp này, liệu nó có đáng để hack kiến ​​trúc NSDocument không? Apple đã viết Xcode (hoạt động theo cách này) bằng cách sử dụng kiến ​​trúc NSDocument chưa?

+0

dường như xcode thực sự sử dụng NSDocument, nhưng cửa sổ có nhiều tab trong dự án cũng chỉ là một tài liệu (các dự án) – cobbal

+1

cũng là một công cụ thú vị để thu hút các ứng dụng ca cao. là F-Script http://www.fscript.org/ – cobbal

+0

@cobbal: Thú vị. Điều đó có ngụ ý rằng các tệp văn bản không được biểu diễn dưới dạng NSDocuments không? – titaniumdecoy

Trả lời

3

Tôi đã cố gắng tạo một ứng dụng NSDocument vào một giao diện tab cửa sổ duy nhất cách đây vài năm và kết thúc quá thất vọng sau vài tháng tôi quay lại và cấu trúc lại các phần kiến ​​trúc tài liệu. Nó không phải là không thể, nhưng bạn kết thúc làm việc xung quanh rất nhiều vấn đề mà kết quả cuối cùng hầu như không giống với một ứng dụng NSDocument thích hợp. Nó tốt hơn để chỉ viết lại các bit bạn cần, hơn là kết thúc với rất nhiều mã chỉ để phá vỡ các khuôn khổ Cocoa.

+0

Nó không thực sự nhiều mã như bạn có thể [đọc từ hướng dẫn của tôi ở đây] (http://cutecoder.org/programming/window-multiple-documents/). – adib

4

Sử dụng kiến ​​trúc dựa trên NSDocument không nhất thiết phải là một ý tưởng tồi trong trường hợp này; nhưng nó có thể yêu cầu khá nhiều haquery.

Rất có khả năng bạn sẽ không chỉ phân lớp NSDocument, mà còn hiếm hơn là lớp con NSDocumentController. Một khi điều này được thực hiện, nó sẽ là một vấn đề đơn giản để chiếm quyền điều khiển và tránh các cuộc gọi đến -makeWindowControllers và các phương pháp liên quan đến cửa sổ khác, cho phép bạn bọc tài liệu "cửa sổ" theo bất kỳ kiểu nào bạn muốn, nhưng vẫn giữ lại lợi ích của tài liệu- ứng dụng dựa trên.

2

Một kỹ thuật khác mà tôi chưa thử nhưng có kế hoạch, là có cửa sổ không viền cho mỗi tài liệu. Bằng cách này, một tài liệu có một cửa sổ, có thể hoặc không thể nhìn thấy được.

Sau đó, có cửa sổ trình bao bọc chứa đường viền cửa sổ thực tế và bất kỳ điều khiển nào để chuyển đổi giữa cửa sổ/cửa sổ tài liệu không viền được hiển thị. Cửa sổ tài liệu là một cửa sổ con của trình bao bọc, đảm bảo cả hai sẽ được liên kết khi một cửa sổ được di chuyển/thu nhỏ/đóng/etc.

Đối với mỗi cửa sổ tài liệu không viền, cửa sổ trình bao có một giao diện giữ chỗ, khi thay đổi kích cỡ, sẽ thay đổi kích thước cửa sổ tài liệu và cũng đưa khung nhìn của cửa sổ tài liệu vào chuỗi trả lời (mọi sự kiện được gửi đến giao diện giữ chỗ được gửi đến khung nhìn của cửa sổ tài liệu trước khi được chuyển sang chế độ xem gốc của trình giữ chỗ).

Vẫn còn một số chi tiết nhỏ để giải quyết, nhưng tôi nghĩ cách tiếp cận này sẽ hoạt động tốt.

+1

Đề xuất rất thú vị. – KPM

5

Tôi có cùng một loại dự án - các tài liệu độc lập khác nhau mà tôi muốn trình bày trong một cửa sổ duy nhất, với thanh bên cho phép chuyển đổi giữa các tài liệu - vì vậy tôi đã tự tìm kiếm một chút.

Tôi vừa tìm thấy khách hàng tiềm năng thú vị bằng cách đọc tài liệu tham khảo Document Based App With One Window For All Documents của Cocoadev. Nó xuất hiện, từ câu trả lời của MikeTrent, rằng việc sử dụng NSDocument là một cách rất khả thi để đi. Bạn chỉ cần subclassing NSDocumentController.

Tôi cũng thích Abhi's idea để sử dụng cửa sổ con không viền.

+1

Liên kết đầu tiên bị hỏng – rraallvv

+1

Đã sửa lỗi liên kết. – KPM

Các vấn đề liên quan