Resetting HTML Dialog Window Location

I have a customer who has somehow managed to move his menu(s) off screen somewhere and now cannot find them.

Initially the size and location is stored with the initial dialog properties to the preferences_key however if the user changes the location and size of the HTML menu it then saves this information.

How would one reset this information back to the default, I don’t think it is stored in the registry anymore on the newer versions of SketchUp.

We’ve run into that bug as well on Windows in SketchUp 2023. In some cases the dialog position ends up being off screen. There is no way to fix the problem except for manually modifying the preferences.json.

It’s at:

C:\Users\UserName\AppData\Local\SketchUp\SketchUp 2023\SketchUp\PrivatePreferences.json

1 Like

If they are on Windows, they can use the ALT+SPACE, then M (or whatever the move command shortcut is for their OS language,) then an arrow key, then wiggle mouse to grab ahold of the errant dialog window.

2 Likes

Jeez, why didn’t I think of that, let me see if he can try that and pull that window back into view.

1 Like

Have you seen this issue in other versions of SketchUp. I have one particular user who seems to be encountering this issue repeatedly but it doesn’t seem to be a widespread issue or at least I’m not seeing it from any other users of my plugins (to my knowledge).

Is this only a SU 2023 issue?

@DanRathbun

@thomthom

@ChrisFullmer

@colin

Lost windows seems to have been around forever, and when I’ve had to figure that out in the past I found what Dan talked about, on forums that were not SketchUp, which makes me think it’s a general Windows issue and not only SketchUp.

Most times it seems to happen to people who are changing a lot from working with two monitors to working with one monitor.

2 Likes

I’m tending to agree with you on this one. I have no other customers using SU 2023 who are encountering this issue, if I did then we would begin to see a pattern. I’m just trying to confirm that SU is not randomly causing people to lose their HTML windows and their toolbars (floating).

For support issues, please use the GitHub issue tracker or email developer-support@sketchup.com. The forum PMs aren’t monitored regulary.

@medeek

I have same issue,
Did you find any solution?

I did something like this, but wondering if there is a better solution:

  1. In the Sketchup defaults I hold value of ‘index’ for all dialogs (Module: Sketchup — SketchUp Ruby API Documentation )
  2. For each dialog I add that ‘index’ in the :preferences_key ( Class: UI::HtmlDialog — SketchUp Ruby API Documentation )
  3. I wrote command to increase that ‘index’ value, so the preferences key would be different
  4. When user have a issue with ‘disappeared dialog’ he can use that command to reset position and sizes of all dialogs inside plugin to default
1 Like

That is actually a really good idea. I may have to implement something similar. I don’t see this problem too often but at least once a month it seems like someone using multiple monitors manages to lose some or all of their HTML dialog windows.

1 Like

Please, before filling the user’s preferences JSON file with orphan dialog entries, try adding a menu command that executes a dialog.center call.

1 Like

Nice idea @DanRathbun

Do you know if sketchup have some kind of getter to get all active html dialogs?
I couldn’t find it

The #visible? method is useful to tell if the dialog is shown and still alive, if the dialog is minimized or not visible on the screen this will still return true .

right, but to use that method you need a object : )

I am thinking how to hold references to currently opened dialogs.
Of course I can hold it on some global variable, but I am not sure if that would be the best option.

You shouldn’t even think of such a thing.
You should keep your reference to your dialogs in your own namespaced extension modules.
Extension requirements

There are many topic about it in the forum.

Typically persistent reference can be an instance variable,
@dialog1 = UI::HtmlDialog.new(...)

or class variable.
@@dialog2 = UI::HtmlDialog.new(...)

1 Like
ObjectSpace.each_object(UI::HtmlDialog).map(&:itself).each do |dialog|
  if dialog.visible?
    dialog.bring_to_front
    dialog.center
  end
end
5 Likes

@dezmo
yes, right. I was thinking about class variable

@DanRathbun

oh god, I have never seen ObjectSpace in the API.
Cool function, thank you!!

edit

I know why, because it is a Ruby function :stuck_out_tongue:

Yes, it’s actually a core Ruby module (with several module methods.)

1 Like

Another Idea. If the user presses the toolbar button to open a window that is already open then bring it front center otherwise open it to the default location. The assumption being that if a user tries to open a window that is already open it’s because they don’t see it.

Changing this:

  def show_specs_dialog
    init_spec_dlg unless @spec_dlg
    @spec_dlg.show unless @spec_dlg.visible?
    @spec_dlg.bring_to_front
  end
  def show_specs_dialog
    init_spec_dlg unless @spec_dlg
    @spec_dlg.center if @spec_dlg.visible?
    @spec_dlg.show unless @spec_dlg.visible?
    @spec_dlg.bring_to_front
  end
2 Likes

To test you’ll likely need to edit the JSON file when SketchUp is closed to some coordinates that are offscreen.

1 Like