You must have a <!DOCTYPE html> tag as the first line of the document, in order for the <meta> compatibility tag to work.
Add, that, then try different versions beginning with 7 and go up from there.
If you never see the layout return to normal, it may also be that your dialog was always rendering in quirks mode.
Hi Jim, as I can see Dan has already provided detailed explanations about the reason, which causes problems with web-dialogs in previous SU versions after installation of SU2017. I also can confirm that specifying of some “legacy document mode” in an HTML part of a web-dialog was suggested by some SU team engineers as “a recommended (safe) practice” for extension developers recently (in order to ensure rendering mode regardless of SU updates). Alternatively it is possible to edit HTML part to make it work in IE11 (may take more effort than adding of meta tag obviously).
I also have to mention that WebDialog class became deprecated since SU2017 according to new API documentation and it is recommended to use HtmlDialog class now instead. HtmlDialog class uses Chromium instead of IE (Safari) to display dialogs so it is another way to make sure that dialogs appearance will be independent from IE updates.
@super_girl I believe the following tag should make web-dialogs work in SU2016 the same way as they used to before SU2017 installation: <meta http-equiv=“X-UA-Compatible” content=“IE=10”/>
In order to be clear I have to mention that recommendation to use HtmlDialog is relevant for SU2017 only obviously. So you may decide to switch from WebDialog to HtmlDialog while making an extension compatible with SU2017.
There is also another minor change introduced in SU2017, which extension developer should be aware of. In SU2017 a flag for the embedded web control is turned on to be “high-dpi aware”. This change affects old web-dialogs in SU2017 on win when overall zoom scaling specified in screen resolution settings differs from 100%.
@DanRathbun - thanks for commenting and confirming my suspicion. I do have a DOCTYPE tag. I’ll keep playing with meta tags until I figure it all out. It’s possible it’s rendering in quirks mode. It’s tough to trouble shoot as the base html file is just a skeleton, and then all the content is filled in depending on what the user is doing.
@jim_foltz - also thanks for confirming. Do you know of any way to change the registry back and forth between the SU 2016 and SU 2017 version? I’d like to be able to trouble-shoot this and still be able to return to a working version in SU 2016 without having to uninstall and reinstall (and re-do all my preferences each time).
@kirill200777 - I’ll try that meta tag, and I’m looking forward to a bunch of the updates in SU 2017, and sounds like the chromium browser will be good as well. Updating the plugin to run with SU 2017 will take some time though. There are some random things in my code that don’t work in SU 2017 already. For example, object_ids now have so many digits that I can’t store them in an attribute dictionary the same way I did before. I’ll have to go through and replace object_ids with persistent_ids - which will be better overall, but takes time to make sure that it all works and nothing gets broken.
I’ll update when I find a solution.
As I said above, it was set to 9 when SU2015 was released (and not changed for SU2016.)
This wasn’t so recent. As I said, the emulation has changed several times in the past.
So this question and discussions like it occurs every time the emulation setting gets changed in major SketchUp release.
Thomas Thomassen’s WebDialogs: The Lost Manual has had a page on this subject for years.
Yes, but according to my personal observations 10 works fine as well.
Well maybe I should write something like “suggested … again recently” instead of just “suggested … recently” to be more accurate. I just haven’t seen such recommendations before that’s why it appeared as a recent event for me personally. Anyway as for me personally I think that suggestion itself (to force some old rendering mode) is controversial as such. In my opinion it may serve only as a temporary workaround (only to make things work while figuring out how to fix html, css, js part to make it compatible with a latest rendering mode).
That’s right. Looks like the latest commit to the “Collection of unofficial documentation of SketchUp’s WebDialog class” was made 4 years ago (not sure if Thomas had been already a member of SU team at that point).
[UPD] I overlooked that “Doctype Quirks vs Standard vs Superstandard” page was revised in 2014. Anyway the whole manual is still “unofficial” and what is more important mentioned page describes quite opposite situation: as far as I understand it tells how to force more recent document mode (IE8 at that point) instead of default IE7 for SU at that point. And what is even more important referenced page explains why SU forced old document mode at that point (because quote: “some plugins might rely on the IE7 mode”). Current situation (after installation of SU2017) is opposite to referenced technical paper.
I got it working. There were two things that helped:
I removed the “inline” tags from css styles - for some reason this was completely messing up my tables
I used the following tags:
<!DOCTYPE html>
<meta http-equiv="X-UA-Compatible" content="IE=8"/>
specifying anything higher than IE=8 creates a problem where I could not assign an id to any element created using wd.execute_script(script)
So, for transition to SU2017, I’ll look into the html dialog class. Hope my experience and solution can help someone avoid some headaches. Thanks again for all the help.
Edit: When I posted the above, I didn’t realize that there were still some problems. Everything LOOKED right, but it still wasn’t functioning correctly. My onChange() events were not triggering, so anything input into the webdialog forms was not being saved. Fixing this took some serious sleuthing. To summarize, I had to remove any instance in which I modified an HTML element with javascript after creation. So now I’m pretty sure everything is working again.
It is necessary if for example, your plugin will be running on an old SketchUp that is running on a Windows XP machine, which can only support MSIE 8 max.
(moved to end of thread)
@DanRathbun - thanks for your super informative reply. It’ll help me figure out what I need to do further in updating to SU2017.
[details=(Ping message to yogesh about fixing the topic thread.)]@yogesh, you should not have split off those 5 posts. They were not offtopic. It is all caused by the same thing (the browser emulation setting by the installers,) and then you didn’t take my answer along with the split.
The thread is broken now. Can you please repair it ?[/details]
And… I also just noticed that the “Component Attributes” dialog for dynamic components does not work in SU 2016 since the install of SU 2017 - this without any plugins running.
Despite my recent successes, time to uninstall SU 2017. Again.
just update the DC Extension in v16…
john
@john_drivenupthewall - are you saying that this was a known issue, and that they dynamic components version 1.4.2 (updated October 20, 2016) fixes this problem?
there have been reports of updating the su_extensions in v16 has solved some issues…
I’m on a mac so the IE version change has no effect on me…
I would certainly try it before any uninstall…
john
@john_drivenupthewall - thanks. I’ve already uninstalled as things work perfectly with only SU2016 installed. I’ll try updating when I choose to try SU2017 again.
(Thanks yogesh, I just had to manually move my answer to the end of thread.)
Yes, as I explained in the post above:
… the SketchUp installers set a FEATURE_BROWSER_EMULATION version for “sketchup.exe”, and every few releases the MSIE emulation version is raised.
Yes. In older IE versions, Microsoft did not wait for the W3C to add attributes and methods to the HTML DOM, but deployed their own MSIE only named methods (or property calls.)
Eventually the W3C DOM caught up with Microsoft, but chose other names for the same features, methods or properties.
IE would release the next IE version in which they’d deprecate the old IE only method / property names (but leave them active,) and implement the new standard W3C DOM named methods and properties. Ie, they created a “grace period”. (Think of this as IE version 10.)
Then with the release of IE 11, the old IE only methods and properties were discontinued, and all JavaScript code that used the old methods needed to be changed to use the W3C standard method and property calls.
So, this is what the DC extension version 1.4.2 did. It now does “duck-typing” on the DOM objects to see if it should call a standard method (or property) and if not try using one of the old IE only names.
In the case of the error you saw in SU2016, this page at MSDN explains it:
attachEvent method (Internet Explorer) - MSDN - Microsoft
The old attachEvent was an old IE-only non-standard method that was replaced by the W3C standard addEventListener method.
So, this lesson also applies to all developers using WebDialog or HtmlDialog. Write your Js code to test for and use the standard first, and then fallback to the non-standard.
No problem super_girl, just realized that this is you Karen.
Long time no see. Welcome to the new SketchUp Discourse forums!