Equivalent for UI::WebDialog.Show call back method of Skp2016?

Okay, I ran the test.

I see that all callbacks work the first time (by clicking the buttons in the dialog.)

Then afterward,…

Confirmed!

I didn’t realize when I read your first post, that you were speaking of an error with the UI::HtmlDialog class’ global sketchup JS object.

I suspect it is because you have defined a global JS function named “callBack” and then expect that with in the sketchup object for it to call it’s local function of the same name, rather than the global JS function you defined. Ie, perhaps you are confusing Chromium.

Let me try renamed the global method … nope that did not work either.

Looks like you may have found a “bugger”.

Playing around trying various things I could not get it to work.
Ie, using charset=“UTF-8” and html5.

I even tried reloading the webpage in the show() method.

Interesting that you are getting different results on Windows than I am getting on Mac. I thought Chromium was supposed to be the same on both? Maybe it is because of something I did while “cleaning up” the code…

Thank you both for examining and testing my code.

  1. The initialize form code runs every time I open and close the dialog, not just the first time. An alert placed before the first callBack displays each time.

  2. I updated the code to implement the format and organization recommended.

  3. The work around is to create a new instance of the dialog each time it is open.

Yes, but we should not have to. For the workaround we’ll need to save state at each closure, and restore things when the dialog is reopened.

The boilerplate code for executing scripts when HTML document is ready for it is something that really needs to be added to the documentation. Being able to add the current settings to a form is vital when creating dialogs.

Today I can write this code myself (I more or less re-invented the method in this thread without knowing about it) but when I started experimenting with WebDialogs years ago I wouldn’t be able to. I feel the threshold to becoming a plugin developer steadily increases which in the long run is really bad for the community.

@thomthom

Has this (callbacks are disconnected when dialog is closed) been logged as a bug ?

Yes.

We have issued logged to provide better WebDialog/HtmlDialog examples. (Ping @ChrisFullmer)

2 Likes

Is it too late to implement a HtmlDialog#show behavior that matches the one of WebDialog? It would cause newer extensions that use HtmlDialog with this feature not be compatible with SU17 but it would reduce the amount of boilerplate code required, which is especially useful for new devs.

I’ve made a subclass of HtmlDialog myself where #show works just as it does for WebDialog and from an API user perspective I can’t see why this was abandoned.

2 Likes

I thought it was for feature matching on the two platforms…

how does your subclass handle cross platform differences?

john

What cross platform differences is there to handle with HtmlDialogs? :open_mouth:

the platform differences where with WebDialog…

so if you modify HtmlDialog to match it then show and show_modal will again differ…

john

Oh dear. I haven’t worked with WebDialogs for a long time now and had forgot about all these Mac quirks :open_mouth: .

The goal I have no is to replicate the webDialog functionality when it isn’t bugged. However since I’m also using WebDialogs for backward compatibility in my plugin I need to look into these issues as well.

I’m sorry to bother you… but I have been searching quite extensively for the ability to close the HtmlDialog box automatically when an item is clicked on the html form. I have gotten the Sketchup and HtmlDialog communications to go seemlessly but every time I try to close the dialog box from Sketchup, nothing seems to work. Could you send me a snippet of how you get the dialog box to close?

Thanks,
Scott

I answered you in the other topic thread. (Your problems relate to non-understanding of basic Ruby.)

Please follow forum guidelines and do not cross post questions.