@tompendergrass said:

I attempted the set_on_close method, and it kept the dialog box open until the method within the set_on_close call had finished. it seems to run it's code block and then close the dialog box, instead of vice versa.

After a long drive I've decided to replace the type=file input with a button that calls UI.openpanel from ruby, and then returns the path that sketchup provides back into a text field in the webDialog. I just tested it and it solves the problem! Thank you all for your timely responses.

Thomas

You are correct. This behavior is consistent with the paradigm of "on close" events in many other frameworks, but is not mentioned in the SU API docs. The callback is really "about to close" rather than "was closed". I suppose this is so that the callback can access window attributes before they are destroyed, or maybe release other resources held by Ruby.

In the case of a SketchUp WebDialog, the anticipation isn't really needed because the WebDialog object actually persists until the last Ruby reference to it is cleared and the Ruby garbage collector runs (which can be some time later unless you explicitly invoke it). In other words, WebDialog#close really means "hide" not "destroy". John's example code illustrates this point: he is able to bring_to_front the dialog after it was previously closed! You can continue to access the WebDialog from Ruby after it is closed so long as you hold a reference to it.

In any case, as you found, this means that the set_on_close Ruby code block needs to finish its work quickly and return, else SU will stall with the WebDialog still visible. The most common use is as an abort/cancel for your tool that activates the selection tool in SU (which makes sense because the user might have closed the dialog by clicking on the frame close button!). Don't invoke #close from within the set_on_close block in an attempt to clear the screen - this will create an endless loop that will block SU until it exhausts the stack and BugSplats!

In particular, this isn't the way to return control to Ruby permanently when the WebDialog closes. Instead, invoke a javascript callback to an skp: handler in which you close the WebDialog and continue with Ruby. On a PC this will leave javascript waiting for return because it is synchronous, but if you are done with the WebDialog you really don't care.

Steve

@driven said:

@dan rathbun said:

The set_on_close block was not being run on the Mac. Not sure if this was ever fixed.

totally pointless, but not technically broken...

It has always run, but you rarely see it's actions as it fires when you close SU, not the dlg, which is possibly a little late...

To see it running you need to interrupt SU's closing with unsaved changes and have an set_on_close alert that will fire...

on a mac both dlg.execute_script('window.blur;') and dlg.execute_script('window.focus;') do work [from a script]...

If you are 'finished' with your dlg, just add a dlg.close to your callback, and dlg.bring_to_front to get it back later...

john

Are you guys certain about that? I used set_on_close successfully to detect a WebDialog closing under SU8 on Mac and Windows - the dialog, not the whole SU app. Haven't tested this under 2014 as the plugin that used it is no longer necessary, but...

Like this:

within the definition of the class that owns the WebDialog:

class Foo
  # code that creates WebDialog @dlg, populates it, and gives it other callbacks
  # and assigns something to @value
  def add_close_callback()
    @dlg.set_on_close() {
      begin
         yield(@value)
      rescue Exception => e
        puts "On close error;\n #{e.class} -> #{e.message}
      end
    }
  end
end

Then elsewhere in the code, something like

foo = Foo.new
foo.add_close_callback() {|val| puts val}

Steve

Yup, I get that the angle between red and green axes in your component is about 51 degrees. Could you provide more information about the steps you used to create this situation?

The Readme on Github says that Mac is not supported yet, but the repository contains project files for Xcode and build succeeded on my Mac. However, there is no discussion of where to put the dylib or how to invoke it. I tried putting it with the other dylibs in the Frameworks folder and activating with the command line args as suggested for Windows, but I can't see any evidence that it does anything (SU starts and seems to run as normal...). Has anybody gotten this to work on Mac yet?

Steve

On Mac OS X, even with XCode and command line developer tools installed, the SU installation of Ruby is not set up to enable compiling and installation of most C-library Gems. For example, one Gem I attempted assumed that there was an executable Ruby interpreter in the SU Ruby Framework where the Gem library lives (there is not - only the dynamic library loaded by SU). Fixing this requires loading a 32-bit Ruby compatible with SU, since the native installation is 64-bit. But even then the generated Makefile and other scripts fail due to problems with configuration. For example, Ruby was launched with an illegal command line option to one of the install scripts. In the end I hand-edited things and got the Gem to compile and install, only to discover as TT points out that SU's Ruby intentionally omits certain standard library components that were found to crash SU.

Bottom line: with enough determination you can build a compiled-C Gem, but don't be surprised if libraries it wants are missing or if it BugSplats SU!

Steve

@dan rathbun said:

@slbaumgartner said:

But in 2014, the original 5-byte UTF-8 string is somehow transmuted into the 8-byte string \xE2\x88\x9A\xC2\xA9lan. ... It's as if the callback processing code has an incorrect implementation of the transcoding.

YES, agree.

To me it looks like it IS UTF-8, but Ruby thinks it is some other encoding, and doubly transcodes* it into UTF-8 AGAIN.

• P.S. - isn't transmute a math term ?

I was thinking more of alchemy

@driven said:

@slbaumgartner said:

... Further, it believes this string and the one from get_element_value (that prints as Ãlan) are equal. This makes no sense to me...

I create this confusion... I don't check for equality it's a 'puts', it should be

    @dlg2.execute_script("translation3.textContent='#{param_val}' + ' == ' + '#{elm_val}' + ' is ' + '#{param_val == elm_val}'")
> 

which returns
√©lan == élan is false

sorry I'll get my coat...

john

Nah, I should know enough to check your code . With a real test, equality fails in all cases (as it should!).

@driven said:

@aerilius said:

...Then one can use get_element_value to fetch user input of any arbitrary character range.

except, get_element_value fails pre v2013 and get_element_value works.

I got a few old scripts I was trying to update, and was unable to figure out the issue...

I think this shows it was broken to begin and got broken 'differently' with a fix...

I'm more inclined, to look at using 'unicodeEscape' in the js... before retrieving by either method...

john

It's possible to get deeply confused trying to sort this out
Here's what I have observed:

The UTF-8 byte sequence for élan is \xC3\xA9lan (that is, UTF-8 encodes é as the two-byte sequence \xC3\xA9).

On Mac, get_element_value returns this byte sequence exactly in both SU8 and 2014. However, because Ruby 8 thinks it is a 5-character string in ASCII-8BIT, it treats \xC3 as à and \xA9 as , the extended ASCII interpretations of these bytes. Ruby 2.0 happily assumes it is UTF-8 and gets it correct.

The action callback parameters are handled differently and inconsistently between Windows and Mac.

On the Mac, in SU8 the action callback also returns the original UTF-8 5-byte sequence, but somehow when Ruby prints it as a string, it gets it right Further, it believes this string and the one from get_element_value (that prints as Ãlan) are equal. This makes no sense to me...

But in 2014, the original 5-byte UTF-8 string is somehow transmuted into the 8-byte string \xE2\x88\x9A\xC2\xA9lan. Note that \xE2\x88\x9A is the UTF-8 for the square-root sign √ and \xC2\xA9 is UTF-8 for . So it appears the translation of the copyright is an attempt to handle misreading of the UTF-8 as ASCII-8BIT, but I don't know where that square root sign byte-sequence came from since as I mentioned above, \xC3 is à in ASCII-8BIT, which is \xC3\x83 in UTF-8. It's as if the callback processing code has an incorrect implementation of the transcoding.

And then, as juantx0 reports, SU8 on Windows 7 returns the 5 UTF-8 bytes unconverted yet again somehow manages to make sense of it in both cases .

@driven said:

@juantxo said:

In Windows 7 p(params) returns non utf-8
"lid1,\xC3\xA9lan"..

ON mac p(params)
"lid1,\xE2\x88\x9A\xC2\xA9lan"

why?

We are seeing the raw 8-bit byte sequences of the string representations and the chaos that results when Ruby and SU try to convert character encodings without knowing for sure what they had.

to further the analysis, get_element_value does not do any conversion. Since you loaded the javascript side on the mac with UTF-8, that makes 2014 happy but messes up SU8!

I managed to fire up SU8 and I also confirm your results there (given the correction to which value displays where). What is happening is that the action callback converts its values to ASCII-8BIT when sending them from javascript to Ruby. In SU8 (Ruby 1.8) this works because that's what Ruby 1.8 expects. In SU 2014, it causes an issue because Ruby 2.0 expects UTF-8 and receives ASCII-8BIT. You can print out the encodings for the values in 2.0 to confirm that is what is happening.

Steve

John,

I haven't tested 1.8 yet, but I can reproduce your results in 2014. By the way, your code has param_val and elm_val swapped in the lines that put them into translation1 and translation2, which makes the display misleading. The bug in 2014 is that the action callback is returning the parameters ASCII-8BIT encoded even though everything else is UTF-8.

Your code contains an assumption that can cause errors: you assume that the iterator will traverse the edges of the base triangle in reverse order to how their start and end are oriented. Suppose you label the edges of the base A, B, C in the order the iterator finds them. Your code begins by drawing an edge from A.start to the apex, and remembers it as edge1. In the next iteration it draws an edge from B.start to the apex and sets it as edge2. It then tries to add a face bounded by B, edge2 (from B.start) and edge1 (from A.start). But unless the iterator is traversing the edges in reverse direction to their start->end orientation, A.start is not a vertex of B at all! The Face will fail because the edges do not form a closed shape! If you insert a pause such as a UI.messagebox in the iteration you can see this happen as the edges are drawn. Switch to using A.end instead of A.start and it the nature of the problem will change. Of course, that just builds in the reverse assumption.

I didn't get your error about a deleted edge, so I'm not certain, but this may be happening because sometimes when SU adds a face it redraws the edges - possibly to reorder their start->end orientations to form a continuous loop. When it does this, even though the new edge is in the identical location to the original, the original is marked as deleted. As a rule, it is not safe to hold references across an operation that adds faces to an entities collection.

You might want to try just adding all the edges and then iterating the final collection invoking find_faces on each edge.

Steve

@fredo6 said:

Doing some tests, I realized that entities.add_group <list_of_entities> will not really add a new group containing the list of entities.

Instead it will make put the entities into a new group, that is, create a new group and move the entities inside.

This is the behavior in SU8, SU13 and SU14.

So, it is in reality equivalent to a "Make Group" function.

Did I miss something?

Fredo

Your confusion confuses me

My read of the API is that if e is an Entities collection, g= e.add_group creates a new group g within e. When you provide entities as an argument to the method, it puts them into g.entities. What did you think would happen?

Steve

@driven said:

you should have a look at geodesic .rb, if you haven't already...

uses Geom::PolygonMesh.new to populate the point arrays...

it's very fast.
john

If you do that, be aware that a PolygonMesh triangulates each Face, which might not be what you wanted. The triangulating edges may be hidden, so be sure to view hidden geometry to know what you got.

This problem has been popping up all over and there are several other topics about it. Thom Thom in particular is trying to find a solid solution.

This issue may be Windows only or maybe only certain system configurations. The FILE I get on my Mac is already UTF-8.

Steve

@dave r said:

The precision of the angle is driven by the precision you have set in Model Info>Units. For angular units you have up to 3 places right of the decimal.

Dave, you are absolutely correct. I used SketchUp's built-in formatting for the angle, which obeys whatever the user has set in the model info.

Steve

I don't have a solution, but a few observations:

• the lack of the BugSplat window on Mac has been reported by several people. So far as I know, nobody has figured out why, though I believe Trimble has contacted the BugSplat developers to see if they can diagnose it.
• the popup to report to Apple rather than BugSplat means the error appeared to be in an OS X library rather than in SU code per-se. That could still be SU's fault for provoking the error, but it was detected in the library.
• Inability to quit means the app is not responding to events. As someone else noted, sometimes this means there is a modal dialog hidden behind some other window. It could also mean that a plugin is hung up. Observers are notorious for problems of this sort. Have you tried with all plugins disabled?

Steve

Here are the folders and contents after importing the dae. As John reported, the textures folder exists but is empty, as is the output folder.

steves-macbook:su_render steve$ ls -lR ./*
-rw-r--r-- 1 steve admin 6673 Mar 17 21:23 ./Mitsuba_geometries.xml
-rw-r--r-- 1 steve admin 1365 Mar 17 21:23 ./Mitsuba_scene.xml
-rw-r--r-- 1 steve admin 5867 Mar 17 21:23 ./mitsuba_geom.txt
-rw-r--r-- 1 steve admin 30488 Mar 17 21:23 ./mitsuba_main.dae
-rw-r--r-- 1 steve admin 903109 Mar 18 09:04 ./mitsuba_main.exr
-rw-r--r-- 1 steve admin 3582 Mar 18 08:55 ./mitsuba_main.serialized
-rw-r--r-- 1 steve admin 1620 Mar 18 08:55 ./mitsuba_main.xml

./output:

./preview_cash:
total 80
-rw-r--r-- 1 steve admin 39202 Mar 17 17:31 su2objmtl_default_material.png

./textures:

./tx_default:
total 8
-rw-r--r-- 1 steve admin 3645 Mar 17 21:23 dark_mahogany.jpg