Workspace.ComposeDocument 以及 QueryOpen 和 PostOpen 事件
我使用以下代码在另一个表单的操作中创建文档:
Sub Click(Source As Button)
Dim ws As New NotesUIWorkspace
Dim NewItemDoc As NotesUIDocument
Dim ParentUNID As String
ParentUNID = ws.CurrentDocument.Document.UNID(0)
Set NewItemDoc = ws.ComposeDocument("","","Item")
Call NewItemDoc.Document.ReplaceItemValue("ParentUNID", ParentUNID)
End Sub
我在 Item
表单的 QueryOpen
和 PostOpen
事件中有代码处理程序,但是它们根本没有运行。当我使用 @Command([Compose])
时,就被调用了。
调试 LotusScript 时,它不会单步执行这些事件处理程序。
我如何获得 LotusScript 中的等效项? 即如何触发 QueryOpen
和 PostOpen
事件?
I'm using the following code to create a document in an action on another form:
Sub Click(Source As Button)
Dim ws As New NotesUIWorkspace
Dim NewItemDoc As NotesUIDocument
Dim ParentUNID As String
ParentUNID = ws.CurrentDocument.Document.UNID(0)
Set NewItemDoc = ws.ComposeDocument("","","Item")
Call NewItemDoc.Document.ReplaceItemValue("ParentUNID", ParentUNID)
End Sub
I have code in the Item
form's QueryOpen
and PostOpen
event handlers, however they are not running at all. When i used the @Command([Compose])
there were called.
When debugging lotusscript it doesn't step through those event handlers.
How do i get the equivalent in lotusscript?
i.e. How do i get the QueryOpen
and PostOpen
events to trigger?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
根据您的经验,只有两件事。
虔诚地、始终地使用“选项声明”,(始终)在您的子程序、函数和 UI 事件中包含错误捕获。真正节省时间。使用您的代码示例,我用于 UI 错误处理的经典代码是
您可以选择使用打印语句或更复杂的东西来记录错误。必不可少。 LSI_Info 函数(更多信息这里)已经存在了一段时间并且已经对我来说使用从来都不是问题。
其次,当您从 LotusScript 启动新表单时,LotusScript 调试器不会使用新表单运行。这是因为 LotusScript 调试器一次仅在一个“UI 进程线程”上运行,启动一个新的 UI 表单(不是对话框),运行一个新实例。我在这里相当宽松地使用术语“进程线程”,因为我试图区分 UI 表单是相互独立的并且不交互,因此调试器不会遵循新表单。
与对话框的行为不同,对话框的行为是模态的。调试器也不会进入对话框(请记住,您将收到该警告消息),并且当您关闭表单时,调试器将返回到原始表单,因为它直接链接到原始 UI 线程。
Just two things with your experience on this.
Use "option declare", religiously, and always, (always) include Error trapping in your subs, functions and UI events. A real time saver. Using your code sample, the classic bit of code I use for UI error handling is this
you can choose to use print statements or something more sophisticated to log the error as well. Indispensable. LSI_Info function (even more info here to) has been around for some time and has never been an issue for me to use.
Secondly, when you launch a new form from LotusScript, the LotusScript debugger does not run with the new form. This is because the LotusScript debugger only runs on one "UI process thread" at a time, launching a new UI form, (not a dialogue box), runs a new instance. I use the term "process thread" pretty loosely here, because I'm trying to make the distinction that UI forms are independent of each other and do not interact, therefore the debugger does not follow into the new form.
Unlike the behaviour with a dialog box, which is modal. The debugger won't follow into a dialogbox either, (remember you'll get that warning message), and when you close the form, the debugger will return to the originating form because it's directly linked to the originating UI thread.