HtmlDialog closing by itself


Please don’t ever try C or C++ :scream:


In those languages you are supposed to release objects yourself. In Ruby you are not. And in no language you are supposed to work against an automatic garbage collector by creating arbitrary references that you never intend to use.


You want to override automatic garbage collection to give a resource a lifetime independent of the Ruby variables that reference it, but you consider any means to do so a hack. Sorry, I’m outta here.


@slbaumgartner, I don’t even see the dialog disappearing on mac, it persists without an instance variable…

even after i close it, the dialog is still available…


It’s only cleared if I call GC.start

it was the same with WebDialogs…



You may need to wait for several minutes for the garbage collector to run and closing the dialog. That’s why this is so annoying. The dialog closes seemingly for no reason, without you doing anything to it.


Technically when the last reference goes away the object becomes eligible for GC. GC has an impact on the running code, and there are numerous strategies for when to run it. There is no way to predict when a particular eligible object will get reaped unless you manually invoke GC.


@eneroth3, it’s still there after an hour…

@slbaumgartner, I think the mac version has always been very ‘slow’ at GC



That’s interesting. Maybe the implementation differ between the platforms. Did you do anything else in SketchUp or did you just leave it? Maybe the Ruby interpreter needs to work a it until the garbage collector runs.


I used tools, deleted geometry, opens other dialogs and closed them as well…

stayed there until I typed in GC.start



Not entirely correct. They are related things.

And in the order you specify above, the latter does not need to be done when the former is done.
(The window can be reshown at a later time if it still exists.)

BUT, … in the opposite order, the window should be closed (hidden) just before it is destroyed.
(I’d bet that the WIndows system will hide the window when it is destroyed, if it is still visible.)

Some Windows application frameworks have their own garbage collection independent of (and beneath) the scripting process’ garbage collection.

I agree this is a “hack” because you are making SketchUp’s internal API interface to the CEF keep a reference to the dialog. When the dialog’s window is finally closed (by whatever means,) the interface deletes all the callback references, and the dialog’s window becomes unreferenced internally. But any Ruby reference to the Ruby dialog object can remain valid. This is why UI::HtmlDialog callbacks need to be reattached if the dialog window is reopened.
The old WebDialog interface had issues with memory and garbage collection.

automation is NOT equal to clairvoyance

In order for GC to “automatically” collect (“sweep up”) memory objects,
those objects must be (or become) unreferenced to be eligible for collection.
This makes the opposite true. That OOP objects need to be referenced in order to not be collected.

The proposal that the SketchUp API interface “magically” keep references to dialog objects presents a problem in that the API will not know when to destroy the object. So then SketchUp internally would have a stack of dialog object references taking up space, and the objects never getting GC’d.

Forcing ALL dialog objects to be GC’d when they are closed would force ALL coders into a programming pattern that they may not want.

@slbaumgartner’s example is the simplest solution, and not a hack at all.

@dlg.set_on_closed { @dlg = nil }

Because it is the way that garbage collection in most OOP languages (Ruby included) are designed.

Steve’s example is just one simple line of code.



I give this one last try as you simply don’t want to understand.

The fact that this window magically closes after a minute or so (on PC at least)…

def show_static_info
  dlg = "About Some Extension")
  dlg.set_html("Version: 1.0.0")

…and this is what you have to do to fix that issue doesn’t make any sense whatsoever from an API usage point of view.

def show_static_info
  dlg = "About Some Extension")
  dlg.set_html("Version: 1.0.0")

  # Hack: The Chromium window is closed when its Ruby object is recycled by the
  # Ruby garbage collector.
  # To prevent the window from closing seemingly randomly when the GC runs,
  # make an arbitrary reference to it in a callback.
  # To allow the object to be recycled once the dialog closes, set the variable
  # to nil.
  dlg.set_on_closed { dlg = nil }

I don’t care about technical explanations (or rather excuses). Every bug there has ever been can be explained. There’s always a reason why a computer does what i does. That it can be explained doesn’t mean is is right. The explanation/excuse is besides the point.

The point is that there is an error that is very hard to reproduce (unless you already know what is causing it). The point is that the Ruby developer has to manually push internal actions, that should be outside tge scope of Ruby programming, in the right direction to fix the issue. The point is that the Ruby developer needs to add code that doesn’t add any functionality, just to satisfy the back end implementation of the API.

And please, please never try to design a public API if this is your idea of a sensible implementation.

I’m unsubscribing to this thread now.


I and others here understand your point of view.
We do not agree with your assessment that it is a bug.
We do not agree with your explanation.
We believe it is you that do not understand our point of view.


The actual point is that a developer should be able to release resources he/she allocated when they aren’t needed anymore. The only way to release them is by having a reference to them. Thanks to languages with a garbage collector, you don’t have to worry much yourself about releasing them, the GC takes care of it when you simply don’t reference them anymore, and you, the developer, are unable to clean up yourself.

To resolve the issue, don’t go and add unneeded callbacks, just make the variable persistent, so that you keep ownership of what you created. Make it an instance variable or a class or module variable. But, just like any other variable that gets defined in a block, it will be expected to be released from memory when stepping out of the block, and thus releasing any native resources used.


And here is an example where the programmer (me) explicitly codes a subclass of UI::HtmlDialog that keeps a reference to itself internally whilst the window is open, then releases it when it is closed. (Although this is not the primary purpose of the subclass nor the example. Just thought I’d add it to show that, if it’s desired, it can be done. In a way it is an example of the coder having control and writing his object so it partially controls it’s own persistence. Ie, an external reference will still prevent GC.)