I’m looking for a way to hide the htmldialog. Finally, I tried win32API, but it easily caused crashes.I used these two win32API to hide htmldialog, FindWindowA and ShowWindow.This seems to be caused by another thread doing the task. It doesn’t crash when I don’t have threads, or it doesn’t crash when I don’t use win32API.
I have no experience with win32API … but there is a “similar” topics e.g.:
How to hide or dock HtmlDialog? Is c extension only the solution? - Developers / Ruby API - SketchUp Community
You may need to post a little more details …an example code or so…
Edit:
BTW: from c:\Program Files\SketchUp\SketchUp 2021\Tools\RubyStdLib\Win32API.rb
# for backward compatibility
warn "Win32API is deprecated after Ruby 1.9.1; use fiddle directly instead", uplevel: 2
__
A little off topic: You regularly create topics in the wrong category. I will gladly move it (if I see it), but it would be better if you also pay attention to this initially.
This topic also belongs to the [Developers] [Ruby API] category. I moved it. 
From either SU 2022 or 2023 onward, all window objects are Qt class objects.
SketchUp has moved away from using the “ancient” MFC framework, so using Win32 API calls (via whatever interface) will no longer work.
Also, in the Ruby 3.x releases, the "Win32API.rb" file has been finally removed, meaning that there is no longer a Win32API wrapper class for the Fiddle library.
This means that if you need your extension to work in future SketchUp releases that will use a Ruby 3 version, your code will need to use Fiddle directly, or you will need to define a Win32API wrapper class WITHIN your own extension namespace module.
But again, the usefulness of making Win32 system calls is reduced quite a bit in current and future SketchUp builds.
To do this in Ruby, simply use UI::HtmlDialog#close. This does not destroy the dialog object, just closes it’s window.
To reopen it, you must reattach all the UI::HtmlDialog object’s callbacks. This is why I often recommend attaching callbacks within a method that can be called multiple times.
You might also need to reset the HTML for the dialog before you call show again.
Of course, your code also needs to keep a persistent reference to the dialog object.
You cannot set the dialog size to [0,0] as there is a minimum size so that the caption bar is always shown.
The set_position method has some open bugs at present, but beyond this it is difficult to move a dialog window offscreen because the API does not (yet) give us access to the number of displays, the size of the virtual desktop and where the origin of the virtual desktop is in relation to SketchUp’s application window.
In the past some coders have tried using HUGE coordinates like [20000,20000]. I don’t know if the Qt framework will allow this. (Ie, outside the bounds of the virtual desktop.)
I think that Thomas has said many times that the SketchUp Ruby API is not thread safe.
Thank you for your answer. I have seen this topic. It is not the effect I want, but it seems that I can only use the method in this topic.
I will pay attention to the wrong category of questions you mentioned, I am really sorry.
1 Like
Thank you for your attention, I just learned that the ruby api is not thread safe. I have now tried the set_position method you mentioned, and it currently works well.
Off topic: I would like to know if some APIs will be expanded after changing Qt classes, such as hiding windows.
If your dialog saves it’s settings using a preferences key, make sure that you reset the position back onscreen before SketchUp closes or else the next time SketchUp loads and shows the dialog it can be lost off-screen confusing the user into thinking that the extension does not work or has not loaded correctly.
OK, thanks for reminding