2017: webdialog changes

kaas

In 2017, the HtmlDialog is introduced. In previous versions I stored values on html pages in hidden variables and retrieved those using wd.get_element_value('my_val')

This method is deprecated now. Am I right the only (and preferred) way now is to use add_action_callback for passing values/data from javascript to ruby?

TIG

The WebDialog is said to be 'deprecated' in SketchUp v2017, but they will still work - 'deprecated' means there are now better ways to do something, but the older way is not gone !
The new HtmlDialog will only work in SketchUp >=v2017, so if you have a tool which is aimed at users who have <=v2017 then I'd stay using WebDialogs.
Otherwise you need to write two parallel sets of dialog code and detect the version etc...
It might be an idea to experiment to see how you can replace getting hidden variable values, by using the alternative callbacks - even in WebDialogs, let alone in the HtmlDialog where is is made obligatory...
One day we will be forced to do this, but for now to provide backward compatibility for earlier SketchUp versions you need to stay with WebDialogs, and perhaps experiment with version recognition and swapping between the two dialog types in the coming months...

kaas

TIG - thanks for the reply and explanation. The webdialogs still work but I noticed some changes in behavior (scaling issues - maybe due to my crappy code) so I was thinking about migrating to the new dialogs. The plugins are all for my own use (for the moment) but I will remember you suggestions about detecting the version.

kaas

One more question though: is it me or is the new html dialog slightly a bit slower in filling the dialog with content?
I think it is because I have a plugin with a texbox and before, after starting the tool by keypress, I could already start typing and the dialog picked it up - no problem.
With the new html dialog, the first letters I type sometimes are missing. Never happened before with the old dialog.

driven

@unknownuser said:

...The webdialogs still work but I noticed some changes in behavior (scaling issues - maybe due to my crappy code) ...

it may not be your code...

there are reports that v17 sets the version of IE to use in all versions of SU i.e. it has an affect on <v17 as well...

I believe that if you don't have the IE version SU sets then IE will run in compatibility mode for all WebDialogs that don't include meta date...

john

kaas

@kaas said:

...is it me or is the new html dialog slightly a bit slower in filling the dialog with content?....

I'm replying to my own question here: it is definitely slower. Sometimes it takes half a second or so. I have seen it take even more than a second on a fast machine.
Maybe parsing Javascript in another way? css?
I have no clue but for my quick rename plugin its quite annoying. It breaks the workflow. Will test more...

thomthom

@driven said:

there are reports that v17 sets the version of IE to use in all versions of SU i.e. it has an affect on <v17 as well...

Correct. There is a registry key set that affect all installed SU versions. This isn't new to SU2017 + but the new IE mode is more strict than before. The recommendation is to always use a META tag to declare your own IE compatibility with the old WebDialog.

For HtmlDialog, since this is powered by Chromium and everything there is async the new class could not be identical. Each dialog is actually running in its own process - so one need to do all communication async. That leads to different design pattern.

Now, previously, when communicating from WebDialog you have to use skp: actions, it's basically using the URL prototcol to send data and that have limitations:

Size limit
Single string as argument
On Mac you could not make consecutive skp calls without the side effect of potentially cancelling the previous one. You had to create an elaborate pump for the messages to reliably get past.
Encoding issues with skp parameters.

A common way to pass data from WebDialog to Ruby was to put it into a hidden input/textarea field and then make a skp call which in turn called get_element_value.

In HtmlDialog you will be better off using the new callback mechanism. Using the sketchup object. So instead of window.location = 'skp:myCallback' you call sketchup.myCallback.

What's more is that the sketchup. callbacks let you provide multiple arguments. No size limit. No worries about URL encoding. You can use basic types such as array, hash, string, number, boolean etc.

This makes it easy to for instance send data which will be received as a Hash on the Ruby side. So instead of making a skp: call to make Ruby pull data with get_element_value, just send the data directly in the new callback.

kaas

I did some more testing. Can't find the problem but its really more slow. I made a small video showing the difference between v16 and v17. I have seen the 'render' of the menu even much slower in v17 but didn't video capture it. Still the difference should be clear.
Its a html-dialog version of ThomThom's namegroup. This version has focus on the textbar so you can start typing directly after using the shortcut key - but not anymore in v17...

thomthom

Can you share this example? I can forward it internally for investigation.

kaas

@thomthom said:

Can you share this example? I can forward it internally for investigation.
Sure. I also posted it yesterday on the Trimble forum and a fix was suggested by sage John (add autofocus to the input textbox in html). Haven't had time to test it thoroughly though.

See more here:
http://forums.sketchup.com/t/html-dialog-speed/33832/7