Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Error: Gui has no window" when debug adapter evaluates a destroyed Gui object #317

Open
Tracked by #214
SAbboushi opened this issue Jan 18, 2024 · 4 comments
Open
Tracked by #214

Comments

@SAbboushi
Copy link

It seems MyGui.Destroy()

leaves behind a useless Gui object in the MyGui variable https://www.autohotkey.com/boards/viewtopic.php?style=19&t=108635#p483346

I suspect this is what causes the debug adapter to throw "Error: Gui has no window" if/when it tries to evaluate the "destroyed" Gui object when e.g. the Gui object's variable name is visible in the VARIABLES pane (I note that MyGui.base.Hwnd shows as "<error>").

I find this makes it very difficult to debug the script because the error continually displays at breakpoints.

Anything you can do to overcome this problem? My thoughts:

  • Although I can't think of one, I wonder if there are times when a programming error results in a GUI-object-without-a-window in which case this error message would be useful? In which case, I suspect trying to overcome this problem in the debugger adapter would be expensive...

  • I wonder why the Destroy() method

    leaves behind a useless Gui object in the MyGui variable

    which I suspect is the cause of this problem I'm trying to overcome?

  • So far, it seems Lexicos' suggestion to [set MyGui := ""] would prevent this problem when debugging... which would require changing my scripts... which again makes me wonder why the Destroy() method doesn't do that?

Any thoughts?

To reproduce, single step through code and expand "Global" in the VARIABLES pane before executing MyGui.Destroy():

MyGui := Gui()
MyGui.Show("w500 h50")
MyGui.Destroy()

x := 1
@zero-plusplus
Copy link
Owner

zero-plusplus commented Jan 19, 2024

Issue confirmed.
It seems difficult to work around this issue as an error dialogue is displayed when communicating with the debugger.


From this point on, in my opinion, Lexicos' suggestion of MyGui := "" is a reasonable solution.

This is because destroying the GUI and destructors of object have different roles.


If this issue is to be solved by refactoring, it may be helpful to be aware of the Destroy method so that it is unaware of it, as follows.

;  The instance is recovered in garbage collection when it has finished executing createGui and calls the deconstructor __DELETE method, which automatically calls Gui's Destroy method.
createGui()
createGui() {
  instance := MyGui()
}
class MyGui extends Gui {
  __DELETE() {
    this.Destroy()
  }
}

A practical example in a simple application using Gui in AutoHotkey.

The Exit method can be used to destroy AppGui and remove the access method to the instance.

MyApp := App()
MyApp.Run()
MyApp.Exit()

class App {
  gui := ""
  Run() {
    this.gui := AppGui()
  }
  Exit() {
    this.gui := ""
  }
}

class AppGui extends Gui {
  __DELETE() {
    this.Destroy()
  }
}

@Lexikos
Copy link

Lexikos commented Apr 27, 2024

AutoHotkey/AutoHotkey@e06bcb7a suppresses the error dialogs and AutoHotkey/AutoHotkey@2c9e300d allows context_get or property_get to continue when an enumerator throws.

For current/past versions:

In a Gui subclass, you can work around it with

Destroy() {
    this.DefineProp('__Enum', {value: "Destroyed"})
    super.Destroy()
}

or just redefine __Enum when you call Destroy. The workaround can be applied to all Gui objects like so:

Gui.Prototype.DefineProp('Destroy', {call: ((destroy, this) =>
    destroy(this.DefineProp('__Enum', {value: "Destroyed"}))
).Bind(Gui.Prototype.Destroy)})

The debugger does not raise an error or call __Enum if it is not an object.


It is not possible for the extension to suppress errors during evaluation of property_get or context_get because the debugger is already in a break state. Breakpoints (whether -t line or -t exception) are ignored because there is no way within the DBGp spec to notify the client that a breakpoint has been reached in that situation. Normally it is done by responding to the last continuation command, but if the debugger was already in a break state, any continuation commands that have been sent have already received their response.

@SAbboushi
Copy link
Author

Thanks for the details

@zero-plusplus zero-plusplus mentioned this issue Apr 28, 2024
62 tasks
@zero-plusplus
Copy link
Owner

Thanks for the fix.

I will ensure that this issue is fixed in testing before releasing vscode-autohotkey-debug v2.0.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants