Using something like
window.onerror is probably a better option.
But here’s the reg key:
Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\SOFTWARE\SketchUp\SketchUp 2016\WebDialogs] "ShowErrorDialogs"=dword:00000001
This is mentioned in the Release Notes, BTW.
I don’t think the registry trick works in SU2019, at least not for me.
Does anyone know how to bring back JS error pop-ups in SU2019?
you’ll need to set a chrome flag or add js to pop an alert…
@Aerilius posted code here ‘somewhere’…
Just to clarify, this is for IE WebDialogs
The registry setting only works upon MSIE WebBrowser control windows which are (deprecated)
UI::WebDialog class windows.
For these windows it is still possible to use FireBug Lite. Someone and I were discussing it somewhere. Need to find the link for ya’.
UI::HtmlDialog (Chrome Extension Framework) windows you can right-click in the window and choose “Show DevTools”. Errors are displayed in the Console tab or pane.
Ah it was Thomas who I conversed with on this. We discussed it in a dedicated issue of his "WebDialogs: The Lost Manual" GitHub repo … (I had to search the general web to find it and it was the first thing on the list.)
Thanks Dan…I’ll look into Firebug…never used it before
Oh DUH! (Sound of hand smackin’ forehead.)
I just looked in the registry and saw that older versions (2017) had automatically created the
"WebDialogs" subkey (but without the
I then looked at 2018 and 2019, and realized that the installer did not create the empty subkey.
This indicates that this setting has been moved to one of the 2 JSON preference files.
I looked at both and did not see a specific
"WebDialogs" JS object defined.
I’d think the best place would be the
"Windows Only" object of the SharedPreferences.json file.
(This is the one in
But (shrug) who knows? Maybe it goes in the PrivatePreferences.json file ?
(This is the one in
Oh and the value for the attribute is now likely
true | false, instead of
1 | 0.
Might be the same as the attribute that controls the tooltip label, when working not there, but if it doesn’t work, it is there and has a value.
Yes, most settings have moved to the JSON preferences. The code to read this preference is still in the client. (But I’m actually not 100% sure if
PrivatePreferences.json. It may not matter.) I’d have to dig further for the exact details of this.
Perhaps add a note to the Debugging section of …
… and perhaps the initial note in the release notes (where it was originally announced) as well as the