As the title says I'm struggling with web requests taking way longer to throw a timeout and move on than they should, 21 seconds. Here's what I'm working with currently:

t=1
puts Time.new
begin
response=Net;;HTTP.start(full_address.host,full_address.port,
;read_timeout=>t,;open_timeout=>t,;ssl_timeout=>t,;continue_timeout=>t,
;write_timeout=>t){|http|http.request(request)}
rescue Exception => e
puts "Rescue block end"
puts e.message
end
puts Time.new

Normally I would think I'd have to only set the open_timeout, as I expect that users might set incorrect variables for full_address. The two time outputs should be no more than a few seconds maximum apart, instead it's this:

2019-02-05 02:32:10 +0100
Rescue block end
execution expired
2019-02-05 02:32:31 +0100

21 seconds, much, much to long for proper user experience.
Now it's not like the t value is completely ignored, just kinda. Setting t to some really high value, something above 21 (or setting no timeout at all) changes the error message, but nothing else, it still takes the exact same amount of time.

2019-02-05 02:41:12 +0100
Rescue block end
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. - connect(2) for "[IP]" port X
2019-02-05 02:41:33 +0100

I've tried multiple ways of rewriting the http request too, all giving me the same dreaded 21 seconds. Anyone have an idea what's going on?

Totally. I'm not the most experienced developer out there but I did develop an entire toolbar for my previous company. I've made tools like immediate batch recoloring and renaming, tools to immediately create functional dynamic components from geometry and some other stuff like that.

Another 2 years later I'd ask the same, does this still need to be here? If yes it'd be cool if that could be confirmed, if no I guess the sticky could be taken down.

@pixero said:

Not sure why I'm having such a hard time getting this right but following TIGs guide, the Components BoundingBox/selection box remains unrotated until I open the component to edit. After exiting out of the edit component mode, the selection box is properly rotated, even though I still have some work left to get the component axis where I want it... Coding can be sooo frustrating...

That's what I thought during my first month or so, but eventually it gets a lot easier as you learn how Sketchup and Ruby work.

I don't know that phenomenon personally but I think it might be related to the component not being refreshed properly. You could try to redraw it:

   dcs = $dc_observers.get_latest_class
   dcs.redraw(entity,progress_bar_visible=false,is_recursive_call=false)

Indeed, it was a bug with the old version of ABP. Not sure why the update passed me though...
Thanks for the help!

I just realized what seems to cause the issue, though I'm not sure why. There are those specific ads on the top, above threads and under the board index. When I choose to unblock sketchucation they however are still blocked. Might be either an issue with weird linking, or ABP does something wrong.
I can't seem to add a working exception for them either.

You seem to be right about it working properly in Chrome, I just tried it out since I have many browsers for webdesign testing at hand anyway.

So it probably is a Firefox specific issue. The filter lists don't seem to be at fault though, I've tried changing them.

ABP offers me 3 options in Firefox:

1. Deavtivate on domain
2. Deactivate on current site only
3. Deactivate everywhere

The blocking check of SketchUcation doesn't notice the first 2 settings though, it only works with #3.
When I use #1 or #2 the ads are displayed properly, but the images and links are still being removed.

That's odd. This system uses Adblock Plus 2.6.3, and the normal Firefox [34.0.5], and I have not really modified anything either. I wouldn't know of anything that could be at fault on my end, any ideas?

Yes, Make is the free version of SketchUp. However every installation starts off with a pro trial period. After the pro period has run out, the next time you start SketchUp it will start as SketchUp make, and not pro.

This is just a rather minor issue but it is somewhat annoying.
This board doesn't display links and images when an Adblocker is installed and active, which is reasonable, I don't have any problem with that either as the ads here are both relevant and unobtrusive.

The faulty behaviour here however is the way it checks whether ads are blocked or not. For example I use Adblock Plus, but whether I turn off the blocker for http://sketchucation.com or not doesn't make a difference. Instead I have to either turn it off for all sites or deactivate it completely which doesn't make any sense, unless the intent behind that is specifically to support ads on other totally unrelated websites as well.

Would be cool if you could fix it so it only cares whether the ads on this site are blocked or not.

   comp = group.to_component

↑ Here you take an existing group and turn it into a component,
mind you, it still is in the drawing

   entities.add_instance(compdef,trans)

↑ Here you add a second component based on the definition of the first one
If you only want one component you'll either have to delete the first one,
or don't create the second one and move the first one to the point where you want it

instance = (compdef.name = "MyComponent")

↑ Here you set instance to the string "MyComponent"
However you can't fetch a component like that by it's name, you need the link to the instance. You don't need this line.

The moment you create the instance you get the link to the created instance, just catch it like that:

   instance = entities.add_instance(compdef,trans)

Tip: You can try reading out what you got by putting "puts instance" afterwards, the result should look like this: #Sketchup::ComponentInstance:0xXXXXXXXX

I would assume typos can still be posted here? If so, here's one:
http://www.sketchup.com/intl/en/developer/docs/ourdoc/tool#onKeyDown

Tool.onKeyDown SketchUp 6.0+

The onKeyDown method is called by SketchUp when the user presses a key on the keyboard. If you want to get input from the VCB, you should implement onUserText rather than this method.

This method is can be used for special keys such as the Shift key

Well, that's too bad, thanks for your help though. I guess I will instead use observers to toggle the style according to which layers are visible, it'll ultimately achieve the same while saving me the trouble of writing huge chunks of code to meddle with the undo stack.

@thomthom said:

@xorunison said:

Considering though that the undo stack shouldn't be meddled with through these observers I'd prefer to somehow go with solution #1 and just prevent these tools from adding their layer changes to the undo stack.

That's not possible. You can make things transparent - but that doesn't make the event avoid the undo stack it's still there.

Since the Style changes doesn't record on the undo stack, then I'd try to use observers to toggle the styles instead. It's only model changes (stuff that is recorded by the undo system) one should avoid doing in observer events.

I feared that might be the case. What about accessing the names of the things on the undo/redo stack then, would that be possible?

This is a smaller but somewhat annoying problem. The situation is this:

I have a few Plug-Ins which allow the user to switch between different working modes. To do so each Plug-In with its own button does 2 things:
1: Change the current style (between my predefined styles Construction and Display)
2: Turn on/off certain layers

The problem is that only the change of layers lands in the undo stack, which means that if I use one of the buttons to change the working mode, and then do a undo, I land right in between the modes where I don't want to be, the layers will be switched back like they were before, the style won't. Certain layers are only meant to be seen with certain styles though.
(The tools do use start/commit_operation to only add one step to the undo stack.)

Possible solutions I could imagine would be:

1. Completely prevent the tools from putting anything onto the undo stack. That way the current layout could be handled entirely by those plug-ins. I didn't encounter any way to do this though. This would be easy and elegant, and considering the only missing changes from the undo stack are layer visibility values there couldn't be any jumbled geometry either.
2. Use observers to modify the undo stack, or rather make sure that when the last step was one of my tools the change of style will also be reverted. As far as I'd know this would require me to keep a separate stack parallel to the undo stack, which in turn would require almost twice as much code as the plug-ins themselves require, which seems rather unnecessary and inefficient to me.
   If I could somehow access the name of the current undo/redo operations I could read and compare that value as I can freely name the operation with start_operation, which would make the separate stack unnecessary.

Considering though that the undo stack shouldn't be meddled with through these observers I'd prefer to somehow go with solution #1 and just prevent these tools from adding their layer changes to the undo stack.

I was wondering if there was a way to do it without going through all parent origins as I feared that might become very complicated, I didn't think about doing it like that (recurse) though. Your solution is right on the spot! Also I didn't knew about the grep method yet, so thanks for that as well.

As the title says, I want to read out the origins of components, nested within other components. And as far as I can tell that task is not as trivial as it sounds. While searching and googling for something to answer my questions I only stumbled upon this:
https://groups.google.com/forum/#!topic/sketchupruby/nM4hRA2ioDI

Here an exact description of what I want to do:
I have a bunch of components, which I can put together with guides. Per request I need a plugin that can check whether those guides are properly aligned. So ideally to do this I need a list of all origins of all according guides, then I can check all the distances and if everything is okay I will end up with a neat array full of pairs of (nearly) matching coordinates. Given I'd find a guide that has no other guide close, I'd have found some stray components. Working with that list once I'd get it is easy and I already have a solution for that.

In short, I need the origins of nested and replicated guide components. There are 2 problems:

1. The nested components have only 1 ComponentInstance name, regardless of how often I copy the parent component. This makes sense when reading the topic I linked above, however it also makes it exceedingly hard to even get a grip on those things I need the origin from.
2. If I get a grip on them, I can't just go and read out the origin because the results will always be completely wrong, that is the given origin will be in relation to the parent, not to the global origin. The results would be right if I could read out the origins while in the context of the parent, which however is not possible because the Ruby API only offers the possibility to close active groups/components, not to open them.

I do have some ideas how I could still get to where I want to be, the only problem being that those ideas all would end in a plugin which would eat a lot of resources and time for a task that is actually rather simple.

Ideas:

1. Copy the whole model, break down all components except for the guides, and read out the origins, afterwards delete all geometry that has been created in the process.
   Very well possible and I also tried it. It should be obvious though that this takes rather long thanks to exploding almost every component in the model.
2. Fetch all guides that are present in the model, take a look at the parents and find out in which geometrical relation the guides are. Then extrapolate all needed origins by calculating them with the relation we got and the origins of all parents.
   This should be more resource efficent, would need a rather excessive amount of code to work with scalable components though. And I have scalable components.
3. By making a copy of the model and making all components unique I could get a grip on the locations of all needed guides. This would be much more resource efficient and I wouldn't need to calculate the origins, however I'd still have the problem that the given origin would be wrong as it would be in relation to the parent.

So, anything I've overseen which would make this task easier? Any good ideas?

PS: Why do I get the origin in relation to the parent when I directly fetch the ComponentInstance.transformation.origin while not being in any edit mode, while I get the origin in relation to the global origin while I'm in the edit mode of the parent? Shouldn't it be right the other way around? Doesn't seem to make any sense to me, so if anyone could satisfy my curiousity as to why it is that way I'd be grateful as well.

The OpenGL settings unfortunately didn't really help. Just as I figured, a style change might be the best thing available currently. I whipped up some styles for my main template and a few plugins that switch between a normal display mode and some construction modes, that's gonna have to do I guess.

The components origin alone is unfortunately not really enough to assure easy placement all the time. On top of that the origin is crucial for some of the plugins I use so there are certain requirement as to how I place that origin.
A gluing plane also wouldn't suffice for the necessities of the placement, I had considered that some time ago already.
Hitting Edit>Delete Guides is something that should simply be avoided with my setup, due to that any and all guide points go on a separate layer where they can be simply turned off.

With Crosshair component I assume you mean putting in some lines that cross at the point where I currently have the guide point. I considered that briefly once but discarded the idea because it wasn't that visually pleasing either. Due to my recent meddling with all the style settings I think you might've just given me an idea. I could have a style like a construction mode that displays lines according to material and make those thick. I could then color the guide lines separately, making them stick out while all the other lines have the same colors as their surrounding geometry... Could be worth a shot.

I'd still be interested to hear about your OpenGL Hardware Acceleration idea. Where and how could I try that?

Hi people, I have a very specific question, as stated in the title. How do I make guide points appear larger so they are easier to hit? I'm currently building up a library of components which are attached to each other in a certain way, but in some situations the geometry makes it a little hard to see and hit the guide points I'm using. Properly attaching the components requires a lot of zooming in and out and using the X-Ray function, simply because those points always have the same size and screen, and that size is a little too small. If they'd be just 3 or 4 times as big that'd make working A LOT easier.
I didn't find anything too useful in the settings either (except for the possibility to change the color of the points, it's a start but that's not helping enough).

Is there a setting like that I missed somewhere? Maybe some kind of advanced configuration could achieve this?
If you have ideas that involve Ruby feel free to share them, I got some experience with that during the past months and wrote a bunch of tools for my own application already.