Thảo luận: Ribbon cho XLL - Microsoft không hỗ trợ trực tiếp, vậy mọi người đang xử lý như thế nào? (2 người xem)

[Kiều Mạnh]

Tôi tách từ chủ đề sau từ bài #8 qua đây bàn luận nếu ai có nhu cầu tìm hiểu không làm loãng chủ đề sau

N

Chủ đề 'Thử lập trình XLL add-in bằng C/C++'

27/2/25

Có lẽ rất nhiều người dùng đã quen với các dạng add-in mà Excel hỗ trợ, những dạng phổ biến hiện nay (không tính những add-in chỉ dùng cho các bản Office cũ hơn bản 2007) bao gồm .xlam và .xll, trong đó .xlam được viết bằng VBA, còn .xll được viết bằng C/C++ và một số ngôn ngữ lập trình khác như C#, Delphi, v.v., bất cứ ngôn ngữ lập trình nào hỗ trợ khả năng xuất ra DLL tiêu chuẩn (Standard DLL). Với .xlam, người dùng có thể tương tác sâu rộng với Excel cũng như có thể viết hàm tùy chỉnh (hoặc hàm do người dùng tự định nghĩa, user-defined function) để sử dụng trong bảng tính, trong khi...

• nguyendang95
• Trả lời: 7
• Diễn đàn: Excel và các ngôn ngữ lập trình khác

• 
• 

Keo ChatGPT viết bài sau .... Copy nguyên văn vào đây

Thảo luận: Ribbon cho XLL - Microsoft không hỗ trợ trực tiếp, vậy mọi người đang xử lý như thế nào?​

Chào các Anh/Em,

Trong quá trình tìm hiểu và phát triển Excel Add-in theo chuẩn XLL (Excel C API), mình gặp một vấn đề khá thú vị và muốn mở chủ đề để mọi người cùng trao đổi kinh nghiệm.

1. Microsoft có hỗ trợ Ribbon cho XLL không?​

Theo những gì mình tìm hiểu thì câu trả lời là không.

Một XLL chuẩn chỉ được Excel nạp thông qua Excel C API với các hàm như:

• xlAutoOpen
• xlAutoClose
• xlAutoRegister
• ...

Excel không gọi các interface COM như:

• IRibbonExtensibility
• GetCustomUI()

Điều đó có nghĩa là nếu chỉ viết một XLL thuần theo tài liệu Microsoft thì sẽ không có Ribbon hiện đại.

Đây cũng là lý do vì sao trước đây XLL chủ yếu dùng để:

• UDF (User Defined Function)
• Command
• Menu kiểu Excel 2003 (Excel4 Macro)
• Các API của Excel C

chứ không có Ribbon theo chuẩn Office 2007 trở lên.

---

2. Vậy tại sao Excel-DNA lại có Ribbon?​

Đây là điều khá nhiều người (trong đó có mình trước đây) từng nhầm.

Nhìn bên ngoài:

MyAddin.xll<br>
rất dễ nghĩ rằng:

"XLL hỗ trợ Ribbon."

Nhưng thực tế không phải vậy.

Theo mình hiểu, Excel-DNA đã xây dựng thêm một lớp trung gian, vừa đóng vai trò XLL để đăng ký UDF, vừa tự hiện thực cơ chế COM Add-in để Office có thể gọi Ribbon XML và các callback.

Nói cách khác, Ribbon của Excel-DNA không phải do XLL tự hỗ trợ, mà do framework của Excel-DNA hiện thực thêm.

Mình cũng từng thấy nhiều câu hỏi liên quan đến việc Ribbon trong Excel-DNA không tải hoặc lỗi GetCustomUI() khi đóng gói add-in, cho thấy Ribbon thực chất được cung cấp thông qua lớp framework này chứ không phải là tính năng sẵn có của XLL.

---

3. Nếu không dùng Excel-DNA thì sao?​

Theo mình hiện nay có vài hướng.

Hướng 1 - Tách riêng COM Add-in và XLL​

Excel
│
├── COM Add-in
│ ├── Ribbon
│ ├── TaskPane
│ └── Event
│
└── XLL
└── UDF

Đây có lẽ là cách phổ biến nhất.

Ưu điểm:

• Theo đúng kiến trúc Microsoft.
• Dễ bảo trì.
• Ribbon và UDF tách biệt.

Nhược điểm:

• Phải triển khai hai thành phần.

---

Hướng 2 - Framework kiểu Excel-DNA​

Một framework sẽ đảm nhiệm:

• Excel C API
• COM
• Ribbon
• TaskPane
• Callback

Người dùng chỉ việc viết code nghiệp vụ.

Đây chính là hướng Excel-DNA đang làm.

---

Hướng 3 - Tự xây bridge​

Đây là hướng mình đang quan tâm.

Ý tưởng là tự xây lớp bridge giữa:

• Excel C API
• COM
• Ribbon
• Event
• TaskPane

để cuối cùng người dùng vẫn chỉ cần triển khai một add-in.

Theo mình đây không phải là việc Microsoft hỗ trợ sẵn, mà là do người phát triển tự hiện thực thêm.

---

4. Một câu hỏi mình muốn thảo luận​

Không biết trong diễn đàn có Anh/Em nào đang viết XLL bằng:

• C++
• Delphi
• C++ Builder
• Rust
• Go

không?

Nếu có thì mọi người đang xử lý Ribbon theo cách nào?

• Tách COM Add-in riêng?
• Dùng Excel-DNA?
• Dùng framework khác?
• Hay tự xây bridge?

Mình rất muốn nghe kinh nghiệm thực tế của mọi người, đặc biệt là các dự án thương mại đã triển khai lâu năm.

---

5. Quan điểm cá nhân​

Theo mình, việc Microsoft không tích hợp Ribbon trực tiếp vào chuẩn XLL có lẽ là do hai mô hình này được thiết kế cho hai mục đích khác nhau:

• XLL tập trung vào hiệu năng và UDF.
• COM Add-in tập trung vào giao diện người dùng và khả năng mở rộng Office.

Tuy nhiên, khi phát triển một add-in hoàn chỉnh thì gần như ai cũng cần cả hai.

Vì vậy mình nghĩ đây là một chủ đề đáng để trao đổi:

Nếu chỉ dùng XLL thì mọi người giải quyết Ribbon như thế nào?

Rất mong được nghe thêm ý kiến, kinh nghiệm và các hướng triển khai từ mọi người.

 

[Kiều Mạnh]

Copy Link này cho ChatGPT phân tích

Programming with the C API in Excel

Office developer client VBA reference documentation

learn.microsoft.com

ChatGPT phân tích như sau

Đúng tài liệu này là "kinh thánh" của XLL và thực ra nó còn củng cố rất mạnh cho luận điểm của bạn.

Có vài đoạn rất đáng trích dẫn trong bài viết.

1. Microsoft xác định mục đích của XLL​

The primary reason for writing XLLs and using the C API is to create high-performance worksheet functions. (Microsoft Learn)

Tức là:

Mục tiêu chính của XLL là UDF hiệu năng cao, không phải UI.

---

2. Microsoft nói rõ C API không có các tính năng UI cao cấp​

Đây là đoạn rất quan trọng:

Many Excel features that are exposed via COM... are not exposed to the C API. (Microsoft Learn)

Có thể diễn đạt trong bài như sau:

Theo tài liệu Microsoft, nhiều tính năng của Excel chỉ được công bố thông qua COM (bao gồm các đối tượng, sự kiện và khả năng mở rộng giao diện), không được công bố qua Excel C API. Điều này giải thích vì sao một XLL thuần không thể tự có Ribbon theo cơ chế chuẩn của Microsoft.

---

3. Microsoft còn nói rõ về UI​

Đây là đoạn gần như trả lời trực tiếp câu hỏi Ribbon:

The C API has not been the best choice for customizing the user interface... You can best customize this interface by using managed code resources. (Microsoft Learn)

Đây là bằng chứng khá mạnh.

Có thể viết:

Microsoft cũng cho biết C API không phải lựa chọn tốt để tùy biến giao diện người dùng. Đối với giao diện Ribbon từ Office 2007 trở đi, Microsoft khuyến nghị sử dụng các công nghệ ở tầng cao hơn thay vì C API. (Microsoft Learn)

---

4. COM là giao diện khác​

Trong tài liệu Microsoft phân tách rất rõ:

Excel Programming Interfaces

XLM
│
▼
C API / XLL
│
▼
VBA
│
▼
COM
│
▼
.NET
(Microsoft Learn)

Điều này cho thấy Microsoft xem:

• XLL
• COM

là hai mô hình mở rộng khác nhau, không phải một.

---

Mình sẽ sửa phần kết luận của bài thành như sau​

Theo tài liệu chính thức của Microsoft, Ribbon không thuộc Excel C API mà thuộc cơ chế mở rộng giao diện ở tầng COM/.NET. Vì vậy, một XLL thuần theo chuẩn Microsoft sẽ không có Ribbon. Nếu muốn có Ribbon thì hiện nay thường có ba hướng:

• Tách COM Add-in và XLL.
• Dùng framework như Excel-DNA.
• Tự xây bridge giữa XLL và COM (cách này Microsoft không cung cấp sẵn, do lập trình viên tự hiện thực).

Theo mình, cách viết này rất "chắc" vì không phải là ý kiến cá nhân, mà dựa trực tiếp trên tài liệu chính thức của Microsoft. Nếu trên GPE có người phản biện, họ sẽ phải phản biện trên cơ sở rằng họ đã tự xây thêm một lớp COM/bridge, chứ không thể nói rằng XLL chuẩn của Microsoft vốn đã hỗ trợ Ribbon. Điều đó phù hợp với mục đích mở thảo luận của bạn.