I have tried a lot of combinations of doctypes and meta tags to force WebDialogs to use IE8 instead of the default embedded IE7.
I thought this would work, but no:
<!DOCTYPE html>
<html style="overflow; auto">
<head>
<meta http-equiv="X-UA-Compatible" content="IE=8" />
Also talked about here: http://forums.sketchucation.com/viewtopic.php?f=180&t=27594, but nobody posted an actual solution.
Anyone done this with success?
I tried compiling a 1.8.5 version of Ruby on the Mac, which works if you follow the directions in the previous post about changing that compiler flag.
Unfortunately I can't find a 1.8.5 Ruby that includes the thread.bundle C extension. Several of the other C extensions depend on thread.bundle, so I haven't been able to get this working.
As a workaround I may resort to using shell commands instead of the Ruby libraries I need. This is painful since Mac comes with some programs that Windows does not (tar, gzip), so I'll have to do different things for each platform.
@chris fullmer said:
> $("select option;selected").each(function () {
> str += $(this).text() + ",";
> });
>
Be careful that your options don't contain commas.
So can you use C extensions to run asynchronous tasks?
@adamb said:
However, you can create as many real Processes / Threads / Fibres as you like using C - but you can't talk to the SketchUp API with them because its not designed for this (not thread-safe). You can only make calls into SketchUp from the execution thread that is called from Sketchup.
Spawning a subprocess is not the same thing as running a Ruby C extension.
A lightweight solution for plugin installers is to use self-extracting zips:
http://www.izarc.org/tutorials.html#sfx
izarc gives you a few basic options as well. You'll have to make separate installers for 32/64bit Windows (since 64-bit systems use C:\Program Files (x86)).
So how does this run in the background? I thought threading wasn't possible in SketchUp, even using an extension?
Just found this: http://forums.sketchucation.com/viewtopic.php?f=180&t=28673&start=0#p249370
Looks to be exactly my problem. I will try linking with a flat namespace tomorrow and see if that will compile a bundle that doesn't crash sketchup.
I was wondering if anyone had thought of a better way to get information out there for new plugin developers. There is a huge learning curve, in particular for working effectively with WebDialogs, and the info, while mostly available, is scattered across several websites (sketchucation, the google group, and the api doc comments).
Would it make sense to start a SketchUp plugin developers wiki? I personally have tons to contribute after writing a fairly large plugin (still unreleased except to a few beta customers), but haven't written a large guide on WebDialogs myself because I fear it will just get buried in the almost unsearchable Sketchucation forums.
In particular I think people need to learn how to package plugins in a reasonable way (wrapping webdialogs, dealing with action callbacks and, in general, the ruby<->javascript exchange, in a civilized fashion, and packaging plugins into correct directory structures with correct module wrapping).
@dan rathbun said:
I also suggest strongly that you organize your "filespace" by having all YOUR code within a "user/author" subfolder that identifies YOU. "TM" or whatever instead of a generic foldername like "Code".
Beneath your author folder you make a subdir for each plugin or project.
So the example above, would be in "Plugins/TM/MatlDlg" subdir or similar.
Globals are also dangerous, so $wd should not be used. I worked out a system for my plugin where I wrap all WebDialogs inside their own class and set the WebDialog as an instance variable. You should then wrap said class in your own module to be extra safe no other plugins will clash with it. Give your module a (hopefully) unique name.
Most scripters are not full-blown software engineers, so software architecture issues like this can be difficult. I could post a sample wrapped WebDialog class if you're interested.
Instead of sending delimited strings to Ruby from the address bar like this:
window.location.href = 'skp;some_action@' + var1 + "!@%!%!%$delimeter" + var2;
You can use:
WebDialog#get_element_value('element_id')
This gets the value attribute of the element with the given id. This is often the easiest way to get form data from a webdialog:
myWebDialog.add_action_callback('act_on_form_data') { |wd, params|
field1 = wd.get_element_value('my_form_field_1')
# Now do something with it...
}
And in JS:
$('#mySubmitButton').click(function() { window.location.href = 'skp;act_on_form_data@'; });
Also make sure to do this after DOM has loaded using $(document).ready(function() {});
Sorry, I thought people would recognize the issue, since there have been other posts about this:
http://forums.sketchucation.com/viewtopic.php?f=180&t=34219 (someone apparently trying to do the same thing as me, but there is little of use in this thread)
http://forums.sketchucation.com/viewtopic.php?t=29412 (Dan Rathbun's efforts to use an external ruby installation on PC. Apparently he doesn't own a Mac)
SketchUp comes with a Ruby interpreter and core libraries, which exists in a .dll in the sketchup directory on PC, and somewhere in the SketchUp package on Mac (/Applications/SketchUp/Contents/Frameworks/Ruby.framework/.....).
Unfortunately, SU's Ruby does NOT come with the standard libraries (basically, the /lib folder of a Ruby installation), which means it's missing the standard gems, StringIO, ZLib, and many many other useful extension libraries that I need for my plugin. The only way to get these libraries loaded into SketchUp is to append the $LOAD_PATH variable so that calls to Kernal.require will search in your own folders. However, the extension libraries are compiled C code, so I need separate versions for Mac and PC. I tried using libraries that come with the version of Ruby that my Leopard shipped with (1.8.7) (this can be tested by simply finding your native Mac's Ruby installation, in /usr/lib/ruby for me, and adding that path to $LOAD_PATH), but since SU is using a 1.8.5 interpreter on this Mac, I'm guessing this is what is crashing SU when I require these.
SO, I am trying to find versions of the extension libraries that won't crash sketchup.
I have been successful getting an installation of Ruby to work with my plugins on the PC, and am now trying on the Mac without success.
On PC, I copied the lib folder of a 1.8.6 p287 release into my plugin folder, and added this path to $LOAD_PATH, and it works fine. The problem is that I'm using stringio and zlib, which are compiled .so files on PC and appear to be .bundle files on the Mac. On Mac, I was able to find these libraries in:
/usr/lib/ruby/1.8/universal-darwin10.0/
Unfortunately, requiring the stringio.bundle or zlib.bundle from this location is causing a bugsplat in SU. I'm assuming this is because of a version difference (ruby -v in a terminal gives version 1.8.7, but SketchUp is running RUBY_VERSION=1.8.5).
I need to find a reasonable way to work with Ruby on a Mac. I am reading that Lion is shipping with 1.8.7 and Leopard with 1.8.6 (although I'm running Leopard and it's 1.8.7). If SU8 Mac only plays nice with 1.8.5, then I have two options:
I did #2 on PC by downloading 1.8.6 p287 and copying the libraries I needed into my plugin, but I don't know how to find these for the Mac (that is, 1.8.5 versions of zlib and stringio). #1 would be acceptable if it was only my machine, but I can't be replacing my users' SU Ruby interpreter when they install my plugin (that would be super selfish and could cause major conflicts with other plugins.)
Has anyone else solved this problem before? Anyone know where I can get 1.8.5 versions of zlib.bundle and stringio.bundle to try out with SU's Ruby?
I'm curious - Did this technique for designating zones ever get implemented in the OpenStudio plugin?
@thomthom said:
Do you have any sample code to demonstrate?
I will try to get sample code up here - just busy at the moment... Thanks guys.
@dan rathbun said:
Well we know the
show()method's block form is bugged on the Mac.Have you tried using
show_modal()instead? .... most Mac users prefer that, as it acts like it does on the PC. (always "on top".)
Tried show_modal(), didn't help.
As I google for a solution it seems that people use either ENV['HOME'] or File.expand_path('~').
Neither of these work on PC since it looks like the variable is HOMEPATH instead. So I was just hoping for a sanity check and wondering what others are doing here. Will this be reliable?
if (WIN)
userPath = ENV['HOMEDRIVE'] + ENV['HOMEPATH']
elsif (MAC)
userPath = File.expand_path('~')
end
I'm making my plugin compatible with Mac at the moment. I've run into the problem where my WebDialogs are not rendering (empty, white pages) when the dialogs are first shown. Instead I have to click on the main SU window, then suddenly the dialog HTML appears.
Any ideas about this? Thanks!
@unknownuser said:
And you also need to listen to the ToolsObsever to check if the user activates another tool - instead of actually placing the component.
That doesn't seem to be an issue. onComponentInstanceAdded gets fired when the component is placed, not when you activate the tool.
Thanks for the help fellas.
@tig said:
But he was talking about a 'tool'...
This way his tool can get a picked-point and then insert a component at that point, then repeat if desired...
Your way is much easier, but it will dump him out of the plugin code at the insertion, so no chance of repeat inserts in the same instance of the class [at least without incredible convolution??] ?
I can listen to DefinitionObserver# onComponentInstanceAdded to get back into Ruby after insertion.
This is a neat way to create a tool that's not a Tool. 