简体   繁体   English

带有“分析粒子”的dm-script捕获错误

[英]dm-script catch error with “Analyze Particles”

When doing 做的时候

ChooseMenuItem("Analysis", "Particles", "Analyze Particles") 

I sometime get "Invalid index" error window. 我有时会收到“无效索引”错误窗口。 Is there a way to catch that error? 有没有办法捕获该错误? Doing this, 这样做

try {
    ChooseMenuItem( "Analysis", "Particles", "Analyze Particles" )
}
catch {
    okdialog("error")
}

does not catch the error. 无法捕获错误。 The "Invalid index" error is likely an error after the menu action "Analyze Particles" is done. 菜单操作“分析粒子”完成后,“无效索引”错误很可能是错误。 Can anyone point out on how to catch this error? 谁能指出如何捕获此错误? And finding out the origin of this error is a great plus. 并且找出此错误的根源是一大优势。 I am using GMS 1.84. 我正在使用GMS 1.84。

I think the problem you're encountering is that the Particle-Analysis is running (at least partly) on a separate background-thread. 我认为您遇到的问题是,粒子分析正在(至少部分)在单独的后台线程上运行。

I don't believe there is a way to directly catch these exceptions in this case. 在这种情况下,我认为没有办法直接捕获这些异常。

I don't use GMS 1.84 anymore, but I did try things on GMS 3.2 which you might also want to do to understand better what's going on. 我不再使用GMS 1.84,但我确实在GMS 3.2上进行了尝试,您可能还想做一些事情,以更好地了解正在发生的事情。


First, your Try/Catch loop is OK, but if you don't put a 'break' in the catch, then the exception will nevertheless be elevated to the system, once the catch-section is left, ie you often want to do: 首先,您的Try / Catch循环是可以的,但是如果您没有在catch中放置“ break”,那么一旦保留catch部分,异常将仍然被提升到系统中,即您经常想做:

Try{ 
    ... }
Catch{
    ...
    break
}
...

To test how scripting behaves on exceptions from a called method, I first wrote a little script and 'installed' it as menu command, once with and once without background-threading. 为了测试脚本如何处理来自调用方法的异常,我首先编写了一个小脚本,并将其“安装”为菜单命令,一次有背景线程,一次没有后台线程。 I installed them via the File-menu in the Custom menu with command names BT and nBT , respectively: 我通过“ 定制”菜单中的“文件”菜单分别使用命令名称BTnBT安装了它们:

// $BACKGROUND$
Result( "\nStart and wait" )
number i = 0
while( i < 100 ){
    i++
    sleep(0.05)
    if ( ShiftDown() ) break
    if ( OptionDown() ) Throw("Broken")
    Result( "." )
}
Result("\nDone and exit.")

and

Result( "\nStart and wait" )
number i = 0
while( i < 100 ){
    i++
    sleep(0.05)
    if ( ShiftDown() ) break
    if ( OptionDown() ) Throw("Broken")
    Result( "." )
}
Result("\nDone and exit.")

Then I used the 'ChooseMenuItem()' to do the testing in the following script: 然后,我使用“ ChooseMenuItem()”在以下脚本中进行测试:

string name = TwoButtonDialog("Background threaded?", "yes", "no" ) ? "BT" : "nBT"
number success = 0
Try{
    Result( "\n Calling: " + name )
    success = ChooseMenuItem("Custom","",name)
}
catch
{
    Result("\n Caught exception." )
    break
}
result("\n Success: " + success )

Testing with this combination (and using the ALT key to throw an exception in the routine) I could verify that the commands behave as should be expected : 使用这种组合进行测试(并使用ALT键在例程中引发异常),我可以验证命令的行为是否符合预期

  • If the routine started by the ChooseMenuItem command is launched on the main-thread , then the execution of that call 'blocks' the main script until it is completed - either at its end, or when it throws and exception. 如果由ChooseMenuItem命令启动的例程在主线程上启动 ,则该调用的执行会“阻塞”主脚本,直到完成为止-在其结束时或在引发异常时。 The main script correctly catches exceptions and prints the result. 主脚本正确捕获异常并打印结果。
  • If the routine started by the ChooseMenuItem command is launched on a separate (background) thread , then the main-script continues immediately. 如果由ChooseMenuItem命令启动的例程在单独的(后台)线程上启动 ,则主脚本将立即继续。 ChooseMenuItem returns successfully at once (if it could launch the command), and the Try/Catch loop is exited. ChooseMenuItem成功返回(如果可以启动命令),并且退出Try / Catch循环。 Any exception thrown by the called routine on the background thread will not be caught anymore. 被调用例程在后台线程上引发的任何异常将不再被捕获。

As for the origin of the error: The "Invalid index" message points to some object being removed (or kept in scope) by the main-script which is expected to be there (or no longer there) by the called background routine. 至于错误的根源:“无效索引”消息指向被主脚本删除(或保留在作用域中)的某个对象,该对象预期被调用的后台例程存在(或不再存在)。 This could be an image or imageDocument or the display of an image or any object (ROI, mask...) on an imageDisplay. 这可以是图像或imageDocument,也可以是图像或imageDisplay上任何对象(ROI,蒙版...)的显示。

I suspect your main script is doing things like closing images once used? 我怀疑您的主要脚本正在执行诸如关闭曾经使用过的图像之类的事情吗? If the "analysis" is on a separate thread, your main script might be too fast or too slow and get things out of sync. 如果“分析”在单独的线程上,则您的主脚本可能太快或太慢,导致事情不同步。 You might need to add artifical pauses ( sleep() ) and a more sophisticated system of keeping track of images ( using the image-IDs ) in the main script to avoid such things. 您可能需要添加人为的停顿( sleep() )和一个更复杂的系统(在主脚本中使用image-ID来跟踪图像),以避免此类情况。

Using ChooseMenuItem() is a workaround hack solution, so any bug-preventing solution for your problem is likely also a code-hack with some ugly 'creativeness' needed. 使用ChooseMenuItem()是一种变通的hack解决方案,因此,针对您的问题的任何防止错误的解决方案也可能都是需要某种丑陋“创造性”的代码黑客。

Found the partial answer. 找到了部分答案。 I have two commends proceeding ChooseMenuItem("Analysis","Particles","Analyze Particles") , 我有两个建议继续进行ChooseMenuItem("Analysis","Particles","Analyze Particles")

ChooseMenuItem("Analysis", "Particles", "Close") 
ChooseMenuItem("Analysis", "Particles", "Find Particles") 

Error happens at the 2nd commend. 错误发生在第二个建议。 But it is caused by the first commend. 但这是由第一次表扬引起的。 It should be a bug with GMS 1.84, where the "closing" action throw particle index out of sync. 这应该是GMS 1.84的错误,其中的“关闭”操作会使粒子索引不同步。 The error is gone when commenting out the fist commend ("Closing" action). 注释拳头命令(“关闭”操作)时,错误消失了。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM