Outlook 2010 和 Add-in-Express：如何使插件在停靠在主窗口一侧时可折叠？
我正在使用 Add-in-Express 开发 Outlook 插件的原型，我真正想要的是当插件直接停靠在主 Outlook 窗口内时可以折叠/展开插件表单。我怀疑 Outlook VSTO API 不允许执行此类操作，并且 Add-In-Express 也可能无法执行此操作，但也许有人知道一些可以提供帮助的 hack。
为了澄清我的情况的技术方面：
- 我有 ADXOIFormsManager 和一个 ADXOlForm
- ADXOlForm 的属性 ExplorerLayout 设置为“RightReadingPane”
- ADXOlForm 的属性 ExplorerAllowedDropRegions 设置为“RightReadingPane;DockRight”
现在，当 Outlook 启动时，插件有一个折叠/展开按钮并且可以工作。但是，如果我将插件拖动到第二个允许的停靠区域，该区域基本上是主窗口按钮的右侧就会消失。
那么，是否有可能以某种方式强制折叠/扩展我的插件的功能，而不管对接区域如何，或者这只是它的一种方式，我必须接受它？如果后者是真的，那么 Xobni 插件怎么可能做到这一点呢？他们是否在 WinApi 级别上操作 Outlook 窗口并更改其大小以与 Xobni 配合使用，或者他们只是模拟该行为并仅更改插件大小以使其看起来像以类似方式最小化 待办事项栏是？
更新 我知道根据 Add-in-Express 团队在他们的论坛和文档中所说的，这是 VSTO API 的限制，但我想知道是否有人破解了它。
I'm using Add-in-Express to develop a prototype of our plugin for Outlook and what I really would like to have is possibility to collapse/expand plugin form when it is docked directly inside main Outlook window. I suspect that Outlook VSTO API is not allowing to do such thing and probably Add-In-Express can't do it either but maybe somebody knows some hack that could be of help.
To clarify technical side of my situation:
- I have ADXOIFormsManager with one ADXOlForm
- ADXOlForm has property ExplorerLayout set to "RightReadingPane"
- ADXOlForm has property ExplorerAllowedDropRegions set to "RightReadingPane;DockRight"
Now, when Outlook starts plugin has a collapse/expand button and it works. But if I drag plugin to the second allowed dock region that is basically right side of main window button disapears.
So, is it possible to force somehow collapse/expand functionality for my plugin regardless of docking region or that's just a way it is and I have to accept it? If the latter is true how it is possible that for example Xobni plugin does it? Do they manipulate Outlook's windows on WinApi level and change their sizes to work with Xobni or they just simulate that behavior and just change plugin size to look like it was minimized in similar way
To-Do Bar is?
UPDATE
I know that according to what Add-in-Express team says on their forum and in docs it is limitation of VSTO API but I'd like to know if maybe somebody hack it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
好吧，通过谷歌挖掘确保我想做的事情不能直接使用 Add-In-Express API 完成，所以我选择稍微作弊并模拟所需的行为。
所以，我做了什么：
当然，在展开和折叠状态之间切换时，我必须修复控件的一些布局问题，但基本上我有我想要的：带有展开的基于 Add-In-Express 的插件/collapse 功能，无论插件停靠在何处。
Ok, diggin' through google ensured me that what I wanted to do can't be done directly with Add-In-Express API so I chose to cheat a little and simulate needed behavior.
So, what I did:
Of course I had to fix some layout problems with controls when switching between expand and collapse state but basically I have what I wanted: Add-In-Express based plugin with expand/collapse functionality regardless of place where plugin is docked.
如果您是 Add-in Express 客户，请向他们的支持人员询问您的问题。他们确实是有关其产品和办公环境相关问题的所有方面的专家。 （我的电话总是能得到有效的答复）。
但请注意，Add-in Express 将自己理解为“快速开发产品”，允许 Office 开发人员利用最佳实践在极短的时间内创建高级加载项。另一方面，如果您有一个由 5 名成员组成的开发团队，他们都具有丰富的 C++ 经验，那么您可以使用 Windows Explorer 和 Office 生成高级内容 - 您提到 Xnobi，我可以提到 DMS 环境中的加载项，例如 OpenText eDocs。这不是使用 Add-in Express 开发的（我猜:-)）
If you're an Add-in Express customer, ask your question to their support. They are really experts in all things concerning their product and the connected issues of the Office environment. (I've got my calls always answered with competence).
But please be aware that Add-in Express understands itself as a "Rapid Development Product", to allow Office developers to create high-level add-ins with best practices and in an exceptable time frame. On the other hand, if you have a developer team with 5 members having all a lot of C++ experience, you can produce high-level stuff with Windows Explorer and Office - you mention Xnobi, I can mention add-ins in the DMS environment, like OpenText eDocs. This is not developed using Add-in Express (I guess :-))
您遇到的问题是由于两个窗格（即示例中提到的位置中的窗格）基于两种不同的技术而引起的。尽管这两个窗格具有相似的外观，但其中一个是 Add-in Express 窗格，它对 Outlook 窗口进行了子类化，以便为自己腾出空间；另一种是Office提供的，自定义任务窗格就是它的名字。也就是说，这个问题没有解决方案。
The problem wich you run into is caused by the fact that the two panes (meaning panes in the positions mentioned in your example) are based on two different technologies. Although the two panes have a similar look, one of them is an Add-in Express pane subclassing Outlook windows to make room for itself; another one is provided by Office, Custom Task Pane is its name. That said, the issue has no resolution.