Ruby is not a strongly typed language. That means information is missing that tells what something is (except when you create this something).
Usually the API documentation gives the exact types (but it is incomplete here):
Since “View” is written uppercase, it could be a class name, so you just paste it into the search box and go to:
So the correct type is Sketchup::View.
By the way, the method deactivate(view) is called by SketchUp (not by you), so SketchUp provides the “view” argument. You could also find out the argument’s type with the following and then run your tool (and deactivate it):
def deactivate(view)
puts("Tool#deactivate(#{view.class})")
end
You have missed the closing ) after view
But even if you include it it only works when you define your Class as a Tool.
Many of the Tool methods automatically receive arguments like view and so on…
So if the user chooses to ‘deactivate’ your tool - e.g. by selecting a different tool, your tool then automatically gets a warning direct from SketchUp, and in the example you gave it ‘invalidates the view’ - that is to say that any inferences or Tool’s ‘draw’ graphics etc are cleared, so as not to affect the newly selected tool unexpectedly…
You can’t run that code in the console on its own.
It’s a Method which runs as part of a Tool Class.
It can’t run on its own at all.
The ‘view’ is a reference to the current view, at the time your Tool is deactivated.
The ‘view’ can have graphics drawn in it etc, so the example code you gave is to remove those using the ‘invalidate’ method for the ‘view’…
Also note that the @drawn reference is an instance-variable, which used in your Tool Class and set elsewhere, so that you only invalidate the view if there are already graphics etc created in an earlier use of the draw() method within your Tool…
Have a look at the Ruby API documentation for Sketchup::View as linked by Aerilius previously. You get access to the current View object via
current_view = Sketchup.active_model.active_view
which you can type in the Ruby Console if you wish to experiment. The View class has a variety of methods dealing with the Camera generating the view (see also the Ruby API for that class) and a variety of methods to probe what is showing in the view, e.g. to find the screen coordinates of some part of the model in the View or to test whether something is visible. These are meant for use by a Tool object, but can be accessed via the Ruby Console to see what they do.
There are also some methods to draw various non-model things to the screen. By non-model, I mean that these are screen drawings that don’t depend on the actual contents of the model. They are intended for use in a Tool’s draw method where they can add information to a screen for feedback on what the user is doing - for example a “rubber band line” that stretches from an initial point to the current cursor position. Because of this intended use, they will have no effect anywhere except in a Tool’s #draw callback method (which as noted, is called by SketchUp when the view is redrawn, not by your code).
In your example of the #deactivate method, the view is passed so that a Tool can clean up whatever it has drawn on the screen before control is passed to another Tool. Without doing this, things may persist on the view until the next redraw. Presumably the @drawn instance variable was set by the Tool to remember that it drew something that needs to be cleaned up - it is nothing set or defined by the Ruby API itself.
so what I do not understand why I do not see a drawing when I run the code on the ruby console, on the contrary, I get “draw” as result, but no drawing on sketchup, nor red color,
thanks for everyone
You pasted a method definition into the Ruby Console and it returned a reference to the defined method (that’s why you saw :draw). To run a method, it needs to be called (usually with round parenthesis around the arguments, like draw(view)).
As sWilliams wrote, what you do must also make sense, it must be correct usage before you see correct results. The draw method is not to be called by you, but it will be called by SketchUp, and SketchUp will provide the view object so you can use it to draw on it.
class MyTool
def draw(view)
view.draw2d(GL_POLYGON, [200, 500, 0], [600, 500, 0], [400, 200 ,0]
end
end
my_tool = MyTool.new
Sketchup.active_model.select_tool(my_tool)
hi Aerilius,
by the way, what I’m looking for is to understand each line what to match and what is its effect, that is what I have to see on the screen for each step, by the way all that allows me to understand pronfodement the API and allows me to know how to use it and especially its usefulness, for example for me I do not see its effect on the screen so in my head I can delete, except that I know that it is not , it’s not true that’s why I try to understand concretely or physically the methods View, draw, drawn … to understand the utility and the need to use them in the program
thank you TIG
, for 3 days I read and I reread your comment to understand the meaning of the behavior of the method view, I understand a little but not quite.
Some of your posts suggest a poor grasp of Ruby programming basics. Until you have a good understanding of Ruby basics, it is of little value for us to provide code samples because you are misunderstanding what they do. For example, you were puzzled why your snippet involving def draw…end did not draw anything on the screen when you pasted it into the Ruby Console window. That’s because a def…end block defines a method, it does not execute the code in the method. You can search this forum or online for suggested reading to better learn Ruby.
Second, you haven’t grasped the SketchUp Ruby API concept of “Tool”. Help with that was, no doubt, the reason for starting this topic. There are two crucial aspects to the Tool concept:
A Ruby API Tool is an object that extends the SketchUp GUI by receiving mouse and keyboard input from the user and commands from the SketchUp engine. It responds to these inputs by doing something to the model and/or the display on your screen. Built-in Tools include ones that draw things, such as Line, Rectangle, Circle, etc., ones that modify the model in other ways, such as Rotate, Scale, etc., ones that change the way you are displaying the model, such as Orbit, Zoom, Pan, etc., and others. The Tool interface is what lets you write code to do similar things.
Sketchup::Tool is not a Ruby Class (this is potentially very confusing to newbies). It is a collection of methods (a protocol) that let SketchUp pass user mouse and keyboard input to a Ruby object, let SketchUp tell the object that certain actions are needed or that certain UI events are happening, and let an object manipulate the screen display of the model. Any object that implements some or all of these methods is a candidate to be activated as the current Tool, that is, to take control of the GUI until told to release control (is suspended or deactivated). The Tool methods are not meant to be invoked by your code, rather they are callbacks to be invoked by the SketchUp engine.
So, for example, Tool#draw is called by the SketchUp engine when it is redrawing the screen contents. It gives the Tool a chance to modify what is shown.
The View class is the Ruby API representation of the screen shown to the user. Although some of its methods can be called by any Ruby code at any time (e.g. zoom), most of what it provides is meant to be used by a Tool object while that object is processing a callback from the SketchUp engine. The engine passes the current View object to many of the callback methods so that the Tool object can modify the display using View methods. It is stated in the Ruby API documentation, but not always clear to newbies, that some of the methods provided by View will only have any effect if they are called from within a Ruby Tool’s draw method. That is, the SketchUp engine looks at when and by what these methods are invoked, and ignores them unless called from within a Tool’s draw callback. Examples include #draw2d, #draw_line, #draw_lines, #draw_points, #draw_polyline, #draw_text. So, it is fruitless to test out these methods by invoking them from the Ruby Console - they will do nothing because that is not the allowed context.
Thank you for all of you, finally I find my happiness, I found a course that speaks fully on “view” and I understand the logic and its usefulness, I’m over for an hour and I’m seeing the examples, the course it’s for Matt Scarpino