So given an array of edges 'elist' (imported from AutoCAD), I'm checking for intersections.

elist.each do |e1|
	# so given this line, we look for intersections, to amend [p1,p2] to [p1,px,pn,p2]
	p1 = e1.start.position
	p2 = e1.end.position
	plist = [p1,p2]
	line1 = e1.line # [point . vector]

	# for this line segment, compare to all other edges
	elist.each do |e2|
		if ( e1 != e2 ) # only if not the same edge of course
			line2 = e2.line # [point . vector]
			v1 = line1[1] # vector
			v2 = line2[1] # vector
					
			if ( v1 != v2 ) # if vectors are differnet, they aren't parallel
				int = Geom.intersect_line_line(line1,line2) # but assumes infinite!
				if ( int ) # make sure it's on both lines, and not an endpoint of line1
					z1 = e2.start.position
					z2 = e2.end.position

					if ( !plist.include?(int) ) # not end point or already found
						if ( pointonline(int,p1,p2) ) # and on line1
							if ( pointonline(int,z1,z2) ) # and on line2
								# so adding our intersection to line 1
								plist << int
							end # if co-linear2
						end # if co-linear1
					end # if not end point
				end # if intersection
			end # if not parallel

		end # if not same segment
	end # subloop

	# ... do stuff with amended plist ...
end # entity loop

Missing is a standard helper function 'pointonline' which checks if given point falls on the given line segment.
Given about 1,500 edges, it seems it can easily take 30 seconds, which just feels far too long for my taste.
Many thanks if you have any tips to optimize it!

--J

Thanks for clarifying a bit.
It's just difficult for the likes of me, coming from a strong background in the CAD realm (AutoCAD and Revit).
In AutoCAD, you have intersect(p1, p2, p3, p4, INF), where INF is the flag to treat the line segments as infinite.
Further, you can very quickly build a selection of all objects within certain bounds.
So coming from that experience, it just feels like I'm having to needlessly iterate through all entities in a model to perform some simple intersection checking.
I've got a routine that does exactly what you describe, but with 1,500 edges in a model (which seems like a ridiculously small set), checking them all against each other just seems to take too long.

--J

Here's my confusion with the Geom.intersect_line_line --
when I'm processing a large file, that seems to be a huge amount of additional processing, with it always assuming the two lines are infinite.
In particular,

Geom.intersect_line_line(edge1.line,edge2.line)

I can appreciate why it treats them as infinite, but what about this:

Geom.intersect_line_line(edge1.vertices,edge2.vertices)

If it's going to accept the vertices as parameters, why can't it treat them as fixed length?

Put that on my wishlist.

--J

Oh the hours I could have saved had I had this guide earlier!!!!
Thank you.

One other issue that is bedeviling me, is Security.
Specifically, loading remote Javascript, having local HTML fire a remote Ajax call, etc.
It seems that on the Windows side, with Domains, there can be all sorts of weirdness with cross-domain security policies, and I just never know where to start. And it seems allow_actions_from_host has no effect.
When I come across it again, I'll let you know the specifics.

--J

Both of those links that you sent merely say it is bad form to put javascript into the href, which is true.
The javascript:void(0) is the recommended practice, indicating that the onclick handler is to take precedence.
In fact, the whole point of it is so that it onclick handler doesn't have to return false.
(See here: http://stackoverflow.com/questions/134845/href-attribute-for-javascript-links-or-javascriptvoid0)

But good to know that was the issue!
Many thanks for your tireless attention to detail on every conceivable issue.

--J

Yes, there's plenty of ways around it.
But there's also nothing inherently wrong with having a link with 'javascript:void(0)' as the href, is there?
At least, in the sense of best programming practices.
In fact, it is, without fail, the best recommended practice.
So, my question remains -- why is it that every Sketchup developer in the world has to be careful to not accidentally follow best HTML practices, instead of one programmer in Boulder correcting what is ostensibly a single errant line of code?

--J

I got it to work, the issue is the "javascript:void(0)"

As for why I'm wrapping a dialog in a class, it's for Mac compatibility (and generally seems a good idea). But since they are modeless on the Mac, it's the only way I could come up with nicely handling the dialog box instances and communication between them. Also I generally try to Class everything, whether Ruby or PHP or Javascript.

As for the alert calls, ThomThom is right. Not only can you call "alert(0)" just about anywhere in any method, it's the fastest and easiest way I know of testing Javascript and Ruby->Javascript communication. Particularly as this is the issue at hand, thank god I don't even have to pass a string to Javascript alert, it's just totally my BFF in that manner.

But back to the issue at hand, if you have this in a WebDialog html:

<a href="javascript&#058;void(0)" onclick="window.location='skp;done'">Click Me!</a>

That works on a Mac, but on a PC, scope returns to Ruby, but Ruby is unable to access any dialog box elements, the DOM is completely gone. The only thing I've been able to do with the dialog is to close it. You can keep clicking the link, and Ruby will still get focus, but get_element_value and execute_script fail without any error.
So then this works:

<a href="#" onclick="window.location='skp;done'">Click Me!</a>

Which is bad programming form.
See, I don't know, this discussion.

I did originally find this topic:
http://sketchucation.com/forums/viewtopic.php?f=180&t=25252
But I had read it wrong, I thought it was the lack of javascript:void(0) that was killing his.

So to repeat my question -- why on Earth would "javascript:void(0)" kill Ruby's access to the DOM?
That just seems such an egregious bug.
I'm going to be in Boulder in 3 weeks, so I'd like to personally thank whichever programmer is responsible for this. In a friendly way of course.

--J

Ugh, I think I got it.
With javascript:void(0) in the web dialog, everything after that point kills the Ruby link to the DOM.
Any, uh, reason for this bug?
I'm going to be in Boulder in a couple weeks, who's desk shall I place a doggie turd on?
(kidding)
(sort of)

--J

I turned on the script debugging, still nothing.
But I've also narrowed down to the problem, this is so strange, now I know it's something simple, must be with the HTML or something.

But check this:

class Dialog1
   def outbound(selected)
        @dialog.execute_script("alert(0)") # fires the first time, that's it
        puts "firing" # fires every time
   end # outbound

   def initialize()
      @dialog = nil

      begin
         @dialog = UI;;WebDialog.new()
         @dialog.show {
            @dialog.add_action_callback("outbound") {|d,p| outbound(p)}
            @dialog.execute_script("requery()")
         } # show

      rescue SystemExit
         # clean exit
      end # begin
   end # initialize

end # Dialog1 Class

def goDialog1 ()
   $dialog1 = Dialog1.new()
end # goDialog1

When a user clicks on the button, window.location=skp fires, Ruby fires back that execute_script, I get the Javascript alert... but only once! I can keep clicking that button, and Ruby Console shows "firing", but nothing to the dialog.
So somehow my connection back to the DOM is lost, right?
I upgraded to IE10, thinking that might be it. Nope.
It has to be something simple, right?

--J

Thanks guys as always!
I'll get to replacing the global variable in a minute. But for the quick change, I switched it to Modeless, but still the same issue.
You can see that dialog2 is closing, and then calling back to dialog1.
Yet in Dialog1.callback, the execute_script calls just fail, without any error or anything (even a execute_script("alert(0)") produces nothing. I can do a @dialog.close oddly enough, but apparently nothing else! What could be going wrong?

$dialog1 = nil
class Dialog1
   def callback(data)
      @dialog.execute_script("document.forms.control.fieldx.value = '#{data}'") # doesn't fire second time
      @dialog.execute_script("requery()") # doesn't fire second time
      # @dialog.close # this will fire!
   end # callback

   def outbound(selected)
      goDialog2(selected,self)
   end # outbound

   def initialize()
      @dialog = nil

      begin
         @dialog = UI;;WebDialog.new()
         @dialog.show {
            @dialog.add_action_callback("outbound") {|d,p| outbound(p)}
            @dialog.execute_script("requery()")
         } # show

      rescue SystemExit
         # clean exit
      end # begin
   end # initialize

end # Dialog1 Class

def goDialog1 ()
   $dialog1 = Dialog1.new()
end # goDialog1


$dialog2 = nil
class Dialog2
   def returnto1 (data)
      @dialog.close()
      @callingmodule.callback(data)
   end # returnto1

   def initialize (selected,callingmodule)
      @callingmodule = callingmodule

      @dialog = UI;;WebDialog.new()
      @dialog.show_modal {
         @dialog.add_action_callback("done") {|d,p| returnto1(p)}
      } # show
   end # initialize

end # Dialog2 Class

def goDialog2 (selected,callingmodule)
   $dialog2 = Dialog2.new(selected,callingmodule)
end # goDialog2

I'm having an issue with WebDialogs, that is only misfiring on PC's, Mac is okay.
Any help would be greatly appreciated!

What I have is this:

$dialog1 = nil
class Dialog1
	def release ()
		if ( @dialog and @dialog.visible? )
			@dialog.close()
		end # if
	end # release

	def callback(data)
		@dialog.execute_script("document.forms.control.fieldx.value = '#{data}'")
		@dialog.execute_script("requery()")
	end # callback

	def outbound(selected)
		goDialog2(selected,self)
	end # outbound

	def initialize()
		@dialog = nil

		begin
			@dialog = UI;;WebDialog.new()
			@dialog.show_modal {
				@dialog.add_action_callback("outbound") {|d,p| outbound(p)}
				@dialog.execute_script("requery()")
			} # show

		rescue SystemExit
			# clean exit
		end # begin
	end # initialize

end # Dialog1 Class

def goDialog1 ()
	if ( $dialog1 )
		$dialog1.release
	end # if
	$dialog1 = Dialog1.new()
end # goDialog1


$dialog2 = nil
class Dialog2
	def release ()
		if ( @dialog and @dialog.visible? )
			@dialog.close()
		end # if
	end # release

	def returnto1 (data)
		@dialog.close()
		@callingmodule.callback(data)
	end # returnto1

	def initialize (selected,callingmodule)
		@callingmodule = callingmodule

		@dialog = UI;;WebDialog.new()
		@dialog.show_modal {
			@dialog.add_action_callback("done") {|d,p| returnto1(p)}
		} # show
	end # initialize

end # Dialog2 Class

def goDialog2 (selected,callingmodule)
	if ( $dialog2 )
		$dialog2.release
	end # if
	$dialog2 = Dialog2.new(selected,callingmodule)
end # goDialog2

Full disclosure: I freely admit I could be screwing something up, not following best practices!
But I've found this to work and be nicely stable on the Mac.
I use a global variable for each dialog class, so that if the user clicks the same button, there isn't a second instance of the same dialog (hence the .release method).
But the primarily dialog is dialog1, which then calls dialog2 (while dialog1 is still up and displayed).
User makes a selection in dialog2, which then closes, and dialog1 is updated with what they chose.
So I accomplish this by passing "self" to dialog2, which can then use that to pass back the selection.

So hopefully clearer still, the call path would be:
goDialog1, Dialog1::initialize, Dialog1::outbound,
goDialog2, Dialog2::initialize, Dialog2::returnto1, Dialog1::callback
right?
only, no. On the PC, it all works great, the first time.
After the first time, all the calls to @dialog for dialog1 just fail.
So if the user clicks again, outbound still fires, dialog2 still comes up, and user is still able to make a selection,
and Dialog1::callback still fires. But inside Dialog1::callback, anything involving @dialog just stops cold, no error message, no value returned, nothing.

Hopefully makes sense?
Thanks again for any help!

--J

That did it!
You're a genius!

It's probably a similar problem on the encoding side, but I'm okay with keeping the development station as a Mac.

Thanks as always.

--J

Well, snap, not working on the PC side.
Mac side is flawless.

Given my 106k RBZ file, and this line of code:

data = open(file) {|io|io.read}.unpack('H*').to_s

On the Mac, data.length is 207954
While on the PC, data.length is 18216

And then there's issue on the other end too.
I'll have to assume it's here:

datab = [data].pack('H*')

It's adding a bunch of 0D's in there, good ol' Chr(13), carriage returns.
At least it seems it is there, I suppose it could be in the actual file.write(datab) ?
But it's adding about 352 of them in that 106k file.

Soooooooooo close!
Any brilliant ideas?

(And in case you're wondering how it is on the Mac side where it works? Um, it's amazing, in a word.)

--J

@unknownuser said:

That doesn't produce visual flickering?

Nope, at least none that I notice on my Macbook Pro.
Even if there was a little, it would be acceptable for the rock solid performance.

--J

That was the route I was going, and then it hit me... what if I just toggle the Visible status of my object?!
Works perfectly, so it's a very simple Pick call and done.
Thanks as always!

--J

I have a Tool currently that uses the pick method, in order to place a Component that needs to be scaled.
The problem is, that seems to keep picking the component itself, so it keeps floating towards the camera.
I'm thinking PickHelper would, well, help with this? Am I understanding this right?
So conceivably, I would be replacing my @ip.pick with an @ph.do_pick, and then I could rifle through the objects to expressly avoid the component instance in question. Am I on the right track?

--J

Ah, I'm starting to get it.
I made the same mistake when I was a 19 year-old programmer.
If the arc crosses 0 degrees, it will get reversed.
So you're right, Sketchup is sort of normalizing the arc. Or put more accurately, it's a bug -- it assumes the start angle to be less than the end angle.
So easy enough fix -- if (start > end) start = start - 360.degrees
Thank you sir!

--J

I'm sorry, I'm just not following.
I'm Susan, I'm standing at the origin, and I'm pointing at at object down the negative Green axis, at 270 degrees relative to me. It is a car, and it is driving in counter-clockwise circle around me. As it drives counter-clockwise towards a point located at my 90 degrees, the resultant path it drew was a D shape, not a C shape.

I've dealt with arcs extensively with AutoCAD, and as I said, this is just taking the exact arc in AutoCAD and recreating here in SketchUp. But some of my arcs are getting reversed, and I can't figure out what I'm supposed to be accounting for.

--J

Those are the values from the Arc in AutoCAD.
If the Start is roughly 270 degrees, and the End is roughly 90 degrees, that is a D shape, not a C shape.
Angles accrue in counter-clockwise fashion, yes? So from Start angle, one begins slowly spinning in a counter-clockwise fashion until reaching the End angle.

--J

I'm having a devil of a time with add_arc, and this seemed the best place to ask.

I have, for instance,

entities.add_arc ORIGIN, X_AXIS, Z_AXIS, 100, 4.6998, 1.6823

Which should make an arc roughly resembling the curve of an upper-case D.
But instead it's making a C.
Start angle is 4.6998, end angle is 1.6823....
So, what am I missing???

--J