确定 Popup 是否位于 Excel 前台

发布于 2024-12-23 11:48:54 字数 521 浏览 3 评论 0原文

我正在为 Excel 编写 VSTO 加载项，我注意到，如果我锁定工作表并使用密码保护它（因此只有我的加载项可以写入它，但用户可以查看它），如果用户尝试编辑他们收到“此工作表已锁定”弹出窗口。如果该提示仍在等待用户输入，则加载项尝试写入工作表，Excel 将崩溃。写入工作表的操作包括取消对工作表的保护、写入数据，然后再次锁定它。该插件通过串行端口从外部源捕获数据，以便可以随时写入数据。

重新创建： 1. 使用插件锁定工作表。 2. 用户尝试编辑工作表内容 3. 提示用户无法编辑工作表的内容，因为工作表已锁定。 4. 数据进入串行端口，并且在用户有机会确认抛出的提示之前，加载项会尝试解锁、写入数据并锁定工作表。 5.Excel字节灰尘。

有什么建议吗？我正在考虑维护隐藏的“主”工作表和可见工作表，并仅使用 Excel 公式或命名范围来引用隐藏工作表。然而，这可能会受到用户的编辑和潜在的数据损坏。数据必须尽可能不可编辑。

更新：我对捕获 COMException 感到满意，这样它就不会杀死 excel，但是一般的“catch (Exception ex)”似乎没有帮助。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

时光沙漏 2024-12-30 11:48:54

在 VBA 中，您可以使用 UserInterFaceOnly:=True 保护工作表。这意味着代码仍然可以写入工作表。从此链接看来，VSTO 插件也是如此。

回复收藏 0 原文

卷耳 2024-12-30 11:48:54

您可以进行检查以确保工作表处于交互模式或活动单元格不为空，如果检查失败则退出执行写入操作的功能

 private bool IsExcelInteractive()
    {
        try
        {
            Globals.ThisAddIn.Application.Interactive = Globals.ThisAddIn.Application.Interactive;
            return true;
        }
        catch
        {
            return false;
        }
    }

You may put check to ensure sheet is in interactive mode or active cell is not null, if check fails exit function that perform write operation

 private bool IsExcelInteractive()
    {
        try
        {
            Globals.ThisAddIn.Application.Interactive = Globals.ThisAddIn.Application.Interactive;
            return true;
        }
        catch
        {
            return false;
        }
    }

回复收藏 0 原文

慈悲佛祖 2024-12-30 11:48:54

当涉及到 COMException 时，问题显然

catch(Exception)

不能作为一般的包罗万象。添加该行

using System.Runtime.InteropServices;

然后添加

catch(COMException)

到我的 try...catch 块中可以让我更好地处理错误。将其与一些代码混合起来，在使用后重试失败的操作几次

SendKeys.SendWait("{ESC}");

似乎会让事情变得更好。然而，盲目地将转义键发送到最前面的程序可能会导致一些问题，但是我不能坐在无限循环中等待可能会或可能不会注意的用户来清除屏幕上的问题。它似乎会导致串行端口停止缓冲数据，如果处理得不够快，就会将其丢弃。

The issue was apparently

catch(Exception)

does not function as a general catch all when it comes to a COMException. Adding the line

using System.Runtime.InteropServices;

and then adding

catch(COMException)

to my try...catch blocks allows me to handle the errors better. Mix that with some code to retry the failed action a few times after using

SendKeys.SendWait("{ESC}");

seems to make things better. However, blindly sending the escape key to the forefront program can cause some issues however I cannot sit in an endless loop waiting for a user who may or may not be paying attention to clear up the issue on the screen. It seems to cause the serial port to stop buffering data and just dropping it if it's not handled fast enough.

回复收藏 0 原文