WebDialog on Mac (call to Google SU engineers)

thomthom

Testing the other way - making a loop in the Javascript to do 100 window.location = 'skp:callback' and I only register the last callback. All the rest appear to have been suppressed. I only see the async going from the WebDialog to Ruby. Not the other way around.

thomthom

Here's a sample code I used to test:

webdialog.rb

thomthom

I improved the test. Now the Ruby to WebDialog method creates a new DIV element every time, and it insert the DIV into the last inserted DIV. So if the calls are synchronous - all the elements should be nested.

On both PC and OSX - the elements are nested. It still appears to me that it's just the Webdialog to Ruby path that's async. Which means it's related to window.location.

webdialog.zip

jeff hammond

i have no idea what you're actually talking about thomas but i'm glad you are
i fear the day of a great plugin coming out only to hear this once again : "sorry, pc only"

chrisglasier

@thomthom said:

window.location

Yes that's the culprit as I understand what Fredo said and you have demonstrated (to yourself).

thomthom

@chrisglasier said:

@thomthom said:

window.location

Yes that's the culprit as I understand what Fredo said and you have demonstrated (to yourself).

No, he also described .execute_script to be async - which I can't see. From my tests it returns after the Javascript is done, not before.

fredo6

@thomthom said:

@chrisglasier said:

@thomthom said:

window.location

Yes that's the culprit as I understand what Fredo said and you have demonstrated (to yourself).

No, he also described .execute_script to be async - which I can't see. From my tests it returns after the Javascript is done, not before.

Tom,

There are 2 issues which all boil down to the problem of windows.location being asynchronous.

when you execute a script that should call a Ruby call back, the script returns before the call back is executed. This is unfortunately a design problem due to Safari, which I understand the SU team cannot do anything about easily.
in addition, the skp protocol eats up all callbacks and keep the last one, when sent in sequence. So you simply miss some callbacks, even if they were to be recieved asynchronously. This is a problem of implementation by the SU team (it would have deserved a buffering).

I had to find workarounds for both problems in my web dialog implementation in LibFredo6, precisely by buffering the callbacks in a hidden HTML field and synchronizing the Ruby code.

If I have some time, I will check if I could isolate the code for reuse by others. No promise however.

Fredo

thomthom

@unknownuser said:

when you execute a script that should call a Ruby call back, the script returns before the call back is executed. This is unfortunately a design problem due to Safari, which I understand the SU team cannot do anything about easily.

Ah, ok. So the .execute_script is synchronous then. It's just the Javascript to Ruby callback (the skp: protocol) that's async.

So it's then safe to call .execute_script which calls a javascript method that stores the return data in a hidden input field where you then use .get_element_value to return data, correct? This is what I see from my testing - but I just want to make sure I'm not missing some cases here.

fredo6

@thomthom said:

So it's then safe to call .execute_script which calls a javascript method that stores the return data in a hidden input field where you then use .get_element_value to return data, correct? This is what I see from my testing - but I just want to make sure I'm not missing some cases here.

Correct. This is what should be done to solve problem #1.
Can you confirm however, because it's been a while since I did not work on Web dialogs, and I don't want to mislead anybody.

Fredo

thomthom

I've tried with loops of .execute_string followed immediately by .get_element_value where I call a Javascript function to modify an argument I pass to it and fetch the result with .get_element_value. Works fine on PC and OSX.


// #bar is a hidden INPUT element
function foo(i)
{
  document.getElementById('bar').valie = i * i;
}


(2..10).each { |i|
  dialog.execute_script("foo(#{i});")
  x = dialog.get_element_value('bar')0
  puts "i; #{i} - x; #{x}"
}

This seems to work fine.

RonB

Sorry for exhuming this thread, but is there a workaround available now?
Actually i'm facing the same problem as described here and its totally driving me nuts.

I'm hoping for good news.

thomthom

Depends on what you are doing.

One way is to make SketchUp pump for information instead of Javascript pushing information.

Another way, if you need Javascript to push information is to set up a pump-system. You create a stack (an array) of the callbacks from JS to SU you want to perform. A function then takes the first item on the stack and send it to SketchUp. It then waits for SketchUp to send notification back that the message was received. Then the next item on the stack is sent ... and so on.

It requires you to restructure how you pass the information around.

If you give a specific usage example we could probably come up with suitable design.

RonB

hey thomthom, thanks for your quick response.

I do have a website providing two informations for sketchup

the actual needed version of the plugin (provided by hidden input field)
a stream (string) of informations (provided by hidden input field)
needs to be checked directly when the webdialog loads the site and 2) when a button is clicked (because it can be chosen which set of informations to load).

Actually it is working on a PC but not on a Mac.
The Website contains both window.location skp callbacks but the second one is only triggered by button.

thomthom

That sounds like you are sending back before the HTML DOM is ready. If you use jQuery use the 'ready' event to wait for the HTML DOM to be ready.

How have you currently structured the loading event?

RonB

I guess you're right... i do have the skp callback somewhere in between of the page.
I'll try to change it to jquery with the "wait for doc ready"-function and report back here.

to answer your question: I'm creating a webdialog and connect by set_url to an url.
Then i'm showing the dialog and wait for the callbacks.
I hope that's what you was asking.

Aerilius

I again stumbled across this issue, knowing JavaScript continues before the Ruby callback ends, but I didn't think that this async nature prevents subsequent urls to reach Ruby.

Example of the Problem:

w = UI;;WebDialog.new("Test")
w.add_action_callback("1"){|dlg, param| puts("first callback")}
w.add_action_callback("2"){|dlg, param| puts("second callback")}
w.set_html("<html><body><script>window.location='skp;1'; window.location='skp;2';</script></body></html>")
w.show

On Windows:
` %(#000000)[> first callback

second callback]On OSX: > second callback`

Example solution:
Doesn't make anything synchronous, but makes sure all urls reach Ruby.


/* class Scheduler;
 * This class makes sure given functions are not called more frequently than a
 * certain time limit.
 * .queue(function)
 *     Adds a new function. All collected functions will be executed one by one with a time interval inbetween.
 */
Scheduler = function(dt) {
  var scheduled = []; // Array of scheduled functions.
  var t = 0; // Tracks the time of the last function call.
  dt = (dt) ? Number(dt) ; 250; // Minimum time interval in milliseconds between subsequent function calls.
  this.queue = function(fn) {
    scheduled.push(fn);
    check();
  };
  var run = function() {
    var toRun = scheduled.shift();
    toRun();
  };
  var check = function() {
    var c = Number(new Date().getTime());
    // Last function call is long enough ago (or first time), execute given function immediately.
    if (c > t && scheduled.length > 0) {
      run();
      // Set timer for next possible function call.
      t = c + dt;
      window.setTimeout(check, dt);
    }
  };
};


/* An instance of the Scheduler */
var callRubyScheduler = new Scheduler(1);


/* Function to call a SketchUp Ruby action_callback. */
var callRuby = function(name, data) {
  if (!data) { data = ''; }
  var url = 'skp;' + name + '@' + encodeURIComponent(data);
  callRubyScheduler.queue(function(){ window.location.href = url; });
};

On Windows:
` %(#000000)[> first callback

second callback]On OSX: %(#000000)[> first callback
second callback]`

thomthom

Another way, that doesn't involve timing is to stack up messages in JS that call a receiving ruby method which takes care of forwarding to the correct ruby method and then send a ping back to JS which can then send the next message in the queue.

I made a version like that which also gives JS a return value from ruby.

Sent from my LT25i using Tapatalk 2

jolran

Ahh, missed this addition to this rather old topic. Interesting reading.

Might be relative to Didier's recent topic.
http://sketchucation.com/forums/viewtopic.php?f=180&t=51350

I wonder if I could get some clarification about this:
For ex, let say you have a dozen buttons that each is hooked up to it's own callback to Ruby with "window.location.href" for the callback.

Even if the Ruby script is permitted to "finish" it's doing before pushing the next buttons, will there be a sync problem ?

I'm having a hard time understanding how this issue behave since I don't have a Mac for testing it out myself.

It seams like Arielius has a clever solution, but what if for ex one has a slider performing realtime transformation or such ?