By "simple lines" I assume you mean smoothly curving, unsegmented ones, something like you would get by drawing a circle on paper with a compass, right? If so, I don't know of any way to convert SU files to ones that define circles & arcs that way; IOW strictly in terms of a center point & radius. Sorry.

You can change the number of segments in arcs in the same ways you do for circles; for instance by typing "20s" (or just 20) in the VCB & pressing return before drawing it. Or you can select an already drawn arc that has not been modified & change its number of segments in the "Segments:" field of the Entity Info window & pressing return (or selecting something else) to finish the change.

In SketchUp, there is no such thing as a perfectly smooth circle or arc. They are always constructed from straight line segments.

@driven said:

not so much a quick, but how Su specifies the Nib files for all the sub-windows
the majority are NSPanels that have been left as 'click thru' so that they 'don't' take 'focus' when clicked.

To be honest, I understand almost none of that but the 'quirk' as best as I can explain it is under the circumstances I described, the focus doesn't 'click thru' to anything.

It is as if the programmers are relying on a click in some window to set the focus explicitly when the app becomes frontmost, but did not consider that there is no click involved when a tool is selected via a keyboard shortcut. So in this case nothing 'takes' the focus, & the toolbar & pointer in the drawing window aren't updated properly.

Does that make any sense?

@driven said:

Can you test this in 'Ruby Console', it's an old 'what works here' script that I automated with Applescript...

Draw a cube the paste in console and return, should generate a list of all SU names for tools used...

if it baulks at anything, comment that line out with a #...

When I run this, I get a very long succession of dialog boxes with various messages & just an OK button. Sometimes the message is just "#," sometimes "##," & sometimes something more descriptive. Sometimes the dialog boxes auto-dismiss themselves, sometimes I have to click "OK" to get things moving again.

After letting it run ~ 10 minutes, I started clicking furiously on the "OK" button as soon as it appeared & it finally finished. Only then could I could scroll through the RC window's hundreds of lines of output. A few of them ended with "#* does work on mac" or "#! dosn't work on mac" EDIT: which I see now are just part of your script.

I haven't looked at it too closely but it seems to repeat everything several times, almost as if it was stuck in an infinite loop.

I'll PM you the RC output as a Textedit file -- it's too long to post here.

EDIT: aside from the output in the RC window, nothing else happened. What should have?

@driven said:

I only tested 17 of the 19 I had open, guess which I missed...

It's easy to miss: from what I can tell, the Entity Info window is the only window besides any open drawing windows that will retain the focus of SU when it is made frontmost by the "Activate" action, & only if the cursor was in one of its regular editable text fields when it was last frontmost. (It won't even retain the focus if the cursor was in the layer field.)

However, if any window besides a drawing window or the Entity Info window with a text field selected last had the focus, both our scripts show that no window has the focus when the script makes SU frontmost again. At first I thought this was some quirk of GUI Scripting or the "Activate" action or something like that, but now I think it is a quirk of SU itself.

I haven't worked out all the details yet but it appears that if SU is made frontmost by any other method besides clicking on one of its windows (like via a script's "Activate" action or clicking on its icon in the Dock when it is already open), it can go into a weird, 'indefinite focus' state.

For instance, if I click on a group in the drawing window & then click on the "name" field in the Entity Info window, the focus shifts to the Entity Info window, as expected. But if I then click on some other open app in the Dock & then click on the SU icon in the Dock, the focus isn't on either the Entity Info window or any drawing window. It actually seems to be on the "Large Tool Set" palette (if it is present), because for instance if I type "a" for the arc tool, the arc icon highlights in that palette … but not in the toolbar of the drawing window. At this point, the drawing window isn't frontmost or the focus: Moreover, the mouse pointer has not been updated with the arc icon, & even after clicking in the drawing window to get it & even after drawing an arc, the toolbar icon in the drawing window remains "stuck" on the select tool's arrow icon.

@driven said:

hi,
the problem with using 'focused' is that I can only ever get main window to return true, regardless of what's actully focused

Odd. That doesn't happen for me. For instance, if I select an arc in a new, unsaved draw window named "Untitled - SketchUp" & then click on the Entity Info "Segments:" box, in part the events/replies for your script shows the following :

get focused of window "Entity Info" of application process "SketchUp"
		--> true
get focused of window "Untitled - SketchUp" of application process "SketchUp"
		--> false

In this case my script results shows

{"Entity Info", 2}

Interestingly, the Outliner window gives different results. If I select a group in the Outliner list or click in its search/filter box, it is clearly the focus, but both scripts indicate that 'focused' is true for no window. It is this kind of behavior that prompted me to write my script in the first place.

@unknownuser said:

another problem is using 'name' v 'title', if an item has neither, 'name' returns nothing and 'title' returns an empty string, which you can at lease use to dig deeper...

True, but my script was intended to only to look for application windows that might have the focus. AFAIK only named windows in SU can do that.

@unknownuser said:

a question- if using 'set winProps to (get properties of thisWindow)' how can you filter out missing value?

I have never found a very elegant general method for dealing with 'missing value' properties, mostly because I don't know how to do that without explicitly using the property's name (like "whose size is not missing value"), which leads to a separate line for each property of interest.

Along those lines, something like this might work for you:

tell application "SketchUp"
	activate
	tell application "System Events" to tell process "SketchUp"
		set HasSize to {}
		set HasName to {}
		-- etc.
		repeat with n from 1 to count of windows
			set WinProps to properties of window n
			if size of WinProps is not missing value then set end of HasSize to n
			if name of WinProps is not missing value then set end of HasName to n
			-- etc.
		end repeat
	end tell
end tell
activate me
{HasSize, HasName}

That will give you lists of window numbers that exclude those with missing values for one specific property each. You can use each of them in a 'repeat with loopVariable in list' type loop (like "repeat with i in HasSize") to process just the windows that have values.

Just an idea.

FWIW, here is yet another AppleScript idea for getting the frontmost window, or more accurately the one that has the app's focus:

tell application "SketchUp"
	activate
	tell application "System Events" to tell process "SketchUp"
		set Focus_Is to "nothing"
		repeat with i from (count of windows) to 1 by -1
			if focused of window i then
				set Focus_Is to name of window i
				exit repeat
			end if
		end repeat
	end tell
end tell
activate me
{Focus_Is, i}

Unlike Jeff's method using the "AXmain" attribute, this script will return whatever window currently has the focus, even if it isn't a drawing document window. It handles multiple drawing windows & even no drawing windows without problems. As is, I assume it will not handle the unusual case in which absolutely no SU windows are open (counting from zero to 1 by -1 isn't going to work!) but except for that I think it is pretty bulletproof (as long as SU is running when it is called, of course.)

Aside from that, if anyone can get it to stop on an error, please let me know.

I wrote it mostly to explore the conditions in which System Events doesn't get the right focus (like when the page setup sheet is open & users change something in it, as I noted earlier) but maybe it will be useful for something else as well….

@unknownuser said:

i found i was doing this for dealing with multiple drawing windows...

Very interesting! Long ago I tried to work out a good general way to get the frontmost document window when using GUI scripting but I never thought of using the attribute class & never got anywhere without it. Thanks very much for that!

Another problem with GUI scripting I've never been able to solve is how to reliably detect if the frontmost app window has changed during the execution of the script, like when the script is in a loop waiting for some user action in the app to trigger exiting the loop. That can cause problems even with a foolproof way to get an unambiguous reference to what is frontmost before the script enters the loop.

Oh well. One step at a time, I guess.

@driven said:

not Jeff, but gave it a whirl anyway... it didn't work here... and took a little while to see why.

basically I had 2 drawings open, without realising it and it was screwing with the count of windows...

I knew that using 'count of windows' as a reference to the frontmost document window could cause problems if the app had more than one of them open. I was really just trying to call attention to the fact that System Events apparently 'sees' the focused property of the app change to the sheet of a document window only when one of the sheet's buttons is clicked & not (for example) when one of its text fields or some other UI element is changed. That seems strange since the app's focus has to be on a UI element to enable users to change it … right?

Jeff:

I don't know if you still have any interest in this project, but if you do please check out the script below (based on one of your earlier ones) & see if it works for you like it does for me.

tell application "SketchUp"
	-- more robust to error trap for SketchUp not running before telling it anything!
	activate
	tell application "System Events" to tell process "SketchUp"
		set drawwin to count of windows
		click menu item "page setup..." of menu "file" of menu bar 1
		
		repeat while focused of window drawwin = false
			try
				set psz to name of static text 2 of sheet 1 of window drawwin
				(* To dismiss the page setup sheet as soon as it appears,
				uncomment the 'click button' line below.
				May be useful if allowing user changes is not needed &
				the script just needs to get current values & continue?*)
				-- click button "OK" of sheet 1 of window drawwin
			end try
		end repeat
		
	end tell
end tell
(* Bring the AppleScript Editor to the front;
manually check its Result pane for the expected psz text.
Demonstrates that it can be processed outside the
'tell SketchUp' loop
*)
activate me
psz

From what I understand, one of the things you wanted to do was drop down the page setup sheet & let users change its settings before continuing. It seems a little weird, but in my testing the inverted logic "repeat while focused of window drawwin = false" line accomplishes that. Here is (I think) how it works:

The 'Events' pane of the AppleScript Editor shows the script looping through the repeat over & over, grabbing the current 'psz' value on each pass, just as one might expect. But the unexpected part is that SU doesn't seem to return 'focused = true' to the script even if a user changes something in the sheet. That only happens when a button in the sheet is clicked. That causes an error in the repeat loop (because sheet 1 is no longer there) so the script exits the loop & continues with the 'psz' value from the last "good" repeat.

To keep things simple & make testing easier, I didn't do any processing of the 'psz' text in the script. If you run it from Script Editor, it should bring the script window back to the front as soon as you click "OK" in the SU sheet & the text should be the only thing in the 'Result' pane.

That also avoids the distraction of a 'Display Dialog' window & messing with AppleScript's Text Item Delimiters (which really should be saved before a change & restored to the saved value ASAP afterwards so the change won't screw up some other script that expects the default or its own changed value).

@mac1 said:

If you want to trace over each and every face that is your call.

The trace method works when I trace over any one edge of each missing face. The 'make face' plugin method requires that I first select every edge of a missing face (& of course no edges of anything else) before it will form the face.

So for me it is an easy call to make because there are far fewer steps involved. Better yet, there is no need to find & select all the edges. Depending on the complexity of the model, that can require a lot of tedious orbiting & zooming to make sure just the right edges are selected.

@mac1 said:

It has been pointed many times the problems with import from CAD programs and to make sure clean up is done before import to SU.

I am aware of that but it doesn't help with my problem. The dxf files I'm working with came from a commercial CD from a company no longer in existence, & the only other format on the CD is readable only by an app from that company that won't run on OS X. I no longer have a working Mac that could support an OS that runs that app, & even if I did I'm not sure it could export its 'native' format files to any format any contemporary 3D app could understand.

I don't own any other 3D app that does a better job of importing the dxf version of the files than SU 7, so I'm stuck with doing all the cleanup work with that or SU 8.

All things considered, the 'trace edge' trick is the best solution for this issue I have seen. So far at least, it only fails when the edges are far enough from coplanar that I can zoom in & see that without having to clutter up the model with a bunch of text entities at max display resolution. It often works even when the 'make face' plugin fails, suggesting that the tolerance for creating faces from nearly coplanar edges may be different depending on the tool or method used.

I'm sure you are right about much of this being the result of inadequate numeric precision in the algorithms SU uses for its calculations. That certainly isn't a user created error, except possibly in the broad sense that users need to be aware of the limitations that imposes, but personally I think that is a bit of a stretch.

@driven said:

Hard links are different on a mac, they are modified (from the unix version) for use with TimeMachine.
They work on files or folders….

I'm familiar with how Time Machine uses hard links in the backup folders. Shortly after it was released, I spent some time on Apple's user support forums trying to explain to curious users how it worked & why they should not tamper with those folders outside of the Time Machine interface.

A surprising number of Mac users noticed the backup folder sizes added up to more than the total backup space used on the drive & tried to "fix" that.

@unknownuser said:

nah.. there's no way our screens can show the real precision.. sketchup can calculate down to a millionth of a millimeter.. our screen can't come anywhere close to that type of precision.. and even it it could, our eyes could never ever see it without using some high powered microscopes..

I must respectfully disagree with you about that. If SU treated objects as bitmaps, your argument would be true. But objects in SU are vector based -- they are just sets of coordinates in a mathematical 3 space that are mapped onto the two dimensional pixel grid of the screen. That means they are resolution independent, so at least in theory you should be able to zoom in far enough that a 0.000001 mm long entity maps to hundreds of pixels on the screen … or zoom out far enough that a 1000 m one maps to a single pixel.

Plus, since the 3D space must of necessity be mapped onto a 2D screen, any one point on the screen maps to arbitrarily many points along the dimension the screen cannot display. That means there will always be some uncertainty about where along that dimension a point lies. The inference engine tries to resolve that uncertainty for the user by looking for nearby entities to use as inference points, but since many different entities at greatly different distances along the undisplayed dimension may map to the same few or even just one screen pixel, it may be impossible for a user to tell which point the inference engine has chosen, even with all the visual aids the app provides.

Worse, when many different inference points are sufficiently proximate, either in the 2D view or in 3D space, the inference engine may "jitter" among them so quickly that it becomes almost impossible to choose the desired one. If the proximity is just in the 2D view, users can relatively easily change the view angle or zoom level to get around that but if it is in 3D space -- & you can't zoom in far enough to get adequate separation among those points -- there is no easy workaround.

I think the Finder treats symbolic links the same as aliases. Hard links would work but like you say, using them probably isn't a good idea, at least for folders.

@wind-borne said:

My quirk, i find that arrow stuck into an alias unacceptable
Can you show a way around that?

The only way I know around that is very extreme & not recommended: dig down into the OS & edit the system level icon files (there are a couple of them) that contain the curved arrow overlays to replace the arrow image with something else.

@unknownuser said:

another popular sketchup rant / bug report is "intersecting faces sux! sketchup doesn't work right!" (or whatever).. but the reality is the user has a bad model but they're trying to blame sketchup..

I think there is some justification for blaming SU. For one thing, it's a bit silly that the tolerance for creating faces from nearly aligned edges is below what the app can display -- I've tried zooming in on models like my example to extreme levels & never reached a point that shows that the lines don't intersect. Scaling the model up by extreme factors helps, but there is always still some minimum distance below which this becomes a problem.

At the least, the display should always be zoomable in to resolve the minimum distance the app supports. Anything below that should be considered the same point & all points in that neighborhood should be merged into one vertex without users having to do anything to cause it.

As it is, it seems that at least sometimes the maximum available display precision is greater than the precision of the underlying calculations, & that is more than a little silly.

@mac1 said:

Change your model units precision to .xxxxxx and use the text tool and you will note a very slight ~.00003 difference in the x dimensions between right and left even thought the edge display " color by axis" shows all at least parallel to the green axis.
I used the move tool so difference is .0000, used the make faces plugin and all faces formed as I would expect. Of course I had removed the extraneous lines as noted above.

Very clever! I always suspected that some kind of precision issue was at the heart of this problem, but I never thought about using the text tool at max display precision to explore it. Thanks very much for that tip -- it will come in handy for exploring other issues as well.

Once you called my attention to it, I noticed there was also a similar x axis difference top to bottom everywhere except on the vertical edges creating the leftmost outside face, so some of the endpoints were offset as much as .000006" along the x axis from those reference points (2.250000" for the front edge & 0.750000" for the back one). So I guess the moral here is to pick one reference point & use it for all the endpoint moves one wants to be aligned perfectly along an axis, right?

What I find most interesting about this is that the trace line technique works even though the edges are not in perfect alignment. It somehow causes all the connected edges to "snap" into alignment, at least if they are close enough to aligned to begin with. I have no idea what tolerances are involved for this to work reliably, but judging from my model I'm guessing it must be greater than .000006". Any thoughts on that?

@pbacot said:

But for this model I found a faster way. After cleanup, I traced one outside edge to get the overall face. Then I selected all and copied. Then I pasted in place. The interior faces all came in separated.

Oddly, that only partially worked for me. It only created two new interior faces:Maybe that was because I removed the extra lines by hand instead of with a plugin?

I had not tried tracing over edges, thinking that might somehow lead to problems because of multiple lines overlaid on a single edge, but at least with the example I uploaded, it works perfectly if I am careful to trace from one vertex to another -- the traced line & the original merge into a single line.

It also works if I just trace from a vertex to a point on the edge somewhere short of the next vertex, like to a midpoint, but that leaves the edge segmented with two end-connected parallel lines.

I'll have to see what happens with other models, especially those that already have edges made up of more than one end-connected parallel lines after import, but I think you have solved my problem.

Thanks!