Ruby to WebDialog Communication
-
@unknownuser said:
Windows folk: directory separators are forward slashes in Ruby.
SketchUp-Ruby on Windows is perfectly happy about using back slashes.
-
It's recommended though to use / or File::SEPARATOR for compatibility reasons.
Related discussion: http://www.ruby-forum.com/topic/50137 -
Martin,
You've been recommending putting the JavaScript at the bottom of the html. I am still clinging to keeping it in a separate file. Can you just include the script:
<script src="myjs.js"></script>
at the bottom of the html intead of in the head section?
-
@unknownuser said:
If the script comes at the very end of the body, where it should be, you will be fine.
Can't say I agree with this. I go by what I do when developing websites - linking to the JS in the HEAD section and using a onLoad or DOMContentLoaded. (DOMContentLoaded is more relevant for websites as it triggers when the HTML is loaded and onLoad triggers when all other related media such as images are loaded.)
This is where it should be in a HTML document following normal web best practice - and since webdialogs are the same - I hold on to that this is best practice here as well. -
Hello all!
-
I've always used '/' for my directory delimiter in Windows, and it works fine.
-
onLoad or DOMContentLoaded - I'm sure you know, but DOMContentLoaded is not implemented in IE at present. Also, I think Safari doesn't handle onLoad like Firefox or IE...
-
Re 'backslashing' text, I think this issue is tied to strings that are passed between Ruby and javascript in a WebDialog. I'll try the '%' syntax sometime. Of course, my Ruby reference book is not where I am...
Greg
-
-
@msp_greg said:
- onLoad or DOMContentLoaded - I'm sure you know, but DOMContentLoaded is not implemented in IE at present. Also, I think Safari doesn't handle onLoad like Firefox or IE...
I've been using jQuery to make things easier. That takes care of most cross-browser issues.
http://www.kryogenix.org/days/2007/09/26/shortloaded -
@jim said:
Can you just include the script:
<script src="myjs.js"></script>
at the bottom of the html intead of in the head section?
Yes.
-
@jim said:
I find more readable like this:
reply = %(Hi, JavsScript. Thanks for saying "#{message}"!)
I'm working on the Rubies for Everyone section of my tutorial. I use a very small subset of Ruby as a suitable language for beginners (very like Chris Pine's tutorial). No #{message} in my subset.
-
@unknownuser said:
Martin wrote(in tutorial
"You get scrollbars on a PC whether you want them or not."Not actually true. It depends on whether you need to specify a HTML version and standards-compliant mode in the webpage. This is done with a <!DOCTYPE> tag on the first line. You can leave it out, but then you would need to know what the 2 browsers (MSIE & Safari) will default to.
Note the following from MSDN (on the body tag.)
@unknownuser said:
As of Microsoft Internet Explorer 6, when you use the !DOCTYPE declaration to specify standards-compliant mode, the body object can obtain its size from its content, or you can set its size explicitly—like a div object, for example. In standards-compliant mode, the html element represents the entire surface onto which a document's contents can be rendered. When the !DOCTYPE declaration does not specify standards-compliant mode, and with earler versions of Internet Explorer, the body object represents the entire surface onto which a document's contents can be rendered. The size of the body object cannot be changed and is equal to the size of the window. Margins you set on this object are rendered inside the border and scrollbars of the object.
So... IF you do NOT want scroll bars, and want the WebDialog to look like a real dialogbox, you need to decide where (which tag, ie: HTML or BODY,) to place a SCROLL="no" attribute.
@unknownuser said:
With Microsoft Internet Explorer 6 and later, when you use the <!DOCTYPE> declaration to specify standards-compliant mode, this attribute (scroll=) applies to the HTML element. When standards-compliant mode is not specified, as with earlier versions of Windows Internet Explorer, this attribute applies to the BODY element, not the HTML element.
I've pulled my hair out in the past, trying to find a perfect combination of compliant modes (just take a look at the table on the <!DOCTYPE> page and you will want to slap whomever it was that designed such a crazy 'switch'.)
Anyway we are talking about simple dialogs, the best system may be to leave off the <!DOCTYPE> tag and put SCROLL="no" in both the HTML and BODY tags, letting the browser(s) ignore the one in the wrong place. I will tell you that in STRICT mode, an attribute in the wrong tag causes problems.
I'd rather just go with wxRuby dialogs after all the problems I've had with html / hta dialog applets.
(btw, HTA dialogs won't work with SUruby, MSIE takes over and opens the file in a second window disconnected from the window that SU opens. Nothing appears in the SU dialog, and the HTA window can't recognize the "skp:" callback. It opens yet a third window with the 'Unable to locate skp:callbackname@ website' message, or such like.) Really wish HTAs would work because I can trap ESC and ENTER keys in HTA but not in HTML (security for preventing browser hijacking.)
. -
@unknownuser said:
The Mac requires a complete <body> section before it will do anything. If your actual body depends on getting data from Ruby, this is a problem. The trick is to have bogus HTML that displays a "Start" button. Call the Ruby when the button is pressed. (And wait for it to call back, as above.){tutorial}
This may well be true but the reason I used a start button solution was that cgScenes immediately examines the model for the current scene and list of all, and as I understand there is no **Sketchup.active_model when the Ruby scripts are first loaded.
BTW I would question whether the notice " 2009, Martin Rinehart" in "SketchUp Ruby Interface to JavaScript" is appropriate given the contributions of SCF members.
** edited 1400 gmt for clarity
Advertisement