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.
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.
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).
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.
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).
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.
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(...)
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