View.pickhelper

TIG

It's not the PickHelper object itself I'm wondering about.
It's the arguments for view.pickhelper.
They seem to indicate that you shouldn't need to call do_pick, if you specify x and y when calling view.pickhelper.

So to cast it another way, view.pickhelper [which returns a 'pick_helper'] seems to have optional arguments that don't work.
Those options don't do the pick, they merely limit the acceptable picking possibilities to the given point's x/y and an 'aperture' radius about it - note the x/y need NOT be the x/y returned by the mouse-button-event BUT could instead be say set to limit you to pick a valid point anywhere within 1m of the ORIGIN, or simply use a bigger aperture so user need not pick so carefully. Without these arguments the user is free to pick anywhere on screen using the default pick-aperture etc. The pick_helper's do_pick and its other methods work on what the pick_helper returns.
It is a pick_helper not a pick itself - the do_pick does the pick...

thomthom

@tig said:

So to cast it another way, view.pickhelper [which returns a 'pick_helper'] seems to have optional arguments that don't work.

Read - bugged?

@tig said:

Those options don't do the pick, they merely limit the acceptable picking possibilities to the given point's x/y and an 'aperture' radius about it

Limit the x and y?
I don't understand this. The manual says:

@unknownuser said:

An x value to create the pick from.
Don't see anything about limiting. ?

@tig said:

note the x/y need NOT be the x/y returned by the mouse-button-event BUT could instead be say set to limit you to pick a valid point anywhere within 1m of the ORIGIN

1m from the ORIGIN? I've seen nothing in the manual about that. And how would x and y - 2D point be related to ORIGIN - 3D point?

@tig said:

It is a pick_helper not a pick itself - the do_pick does the pick...

That's the thing - I thought providing the extra arguments would make it return a PickHelper and doa pick in one go - without having to do the extra pick at the end.

I'm very confused now.

TIG

You can't use the ' ORIGIN' directly. BUT you can translate its 3D point into a screen xy [ view.screen_coords(ORIGIN)].
The '1m aperture' isn't going to be easy either, BUT you could work out [0,0,1.m] as a screen xy too, and then find the relative pixel distance from one to the other, then do it for [0,1.m,0] and [1.m,0,0] to get the maximum aperture pixel size from these three [it's a 'globe' centered on the ORIGIN]...
Remember that the screen_coords are still a 3D point BUT the Z is ignored.
You can then dynamically set the pick_helper x y aperture using these values as the user pans, zooms... The user is then restricted to pick things centered on the ORIGIN and within a 1m of it...

To be honest I never use anything but a 'bare' pick_helper with no arguments and then a ph.do_pick etc....

thomthom

I'm confused to where ORIGIN comes into this..?

@tig said:

To be honest I never use anything but a 'bare' pick_helper with no arguments and then a ph.do_pick etc....

That's what I've do so far as well. Just looked like I could skip that last step - combine the two statements. But I'm not sure if it's a SU bug - or if the arguments for view.pick_helper works differently from what I'd expect.

AdamB

I think your looking at this a bit wrong..

When you create a pick_helper, you create a Query Object for that x,y. You can then extract a variety of information from it and then dispose of it.

thomthom

"Query Object"?

AdamB

@thomthom said:

"Query Object"?

As in an object that encapsulates the query and all associated state into 1 handy 'thing'. It's a common pattern for picking / raytesting because you often want to make decisions about what your looking for as you walk through the results and don't necessarily want all answers/info - which can be large.

The point being its not a simple procedural call. Its returning a result which is a first class object on which you can operate to get the answer you want.

Adam

thomthom

Sorry for being so dense, but I don't understand this at all.

What's the difference between:

ip = view.pickhelper ip.pick(x, y)

and

ip = view.pickhelper(x, y)

Why are they not the same, and what would the use of ip = view.pickhelper(x, y) be?

thomthom

Think there is some confusion to what people think I'm asking about.

I'm not asking what the purpose of the PickHelper class is. But the difference in the examples in my previous post. The arguments of the method view.pick_helper that returns a PickHelper.

AdamB

@thomthom said:

Sorry for being so dense, but I don't understand this at all.

What's the difference between:

ip = view.pickhelper ip.pick(x, y)

and

ip = view.pickhelper(x, y)

Why are they not the same, and what would the use of ip = view.pickhelper(x, y) be?

pickhelper(x,y) is a convenience. But you may want to create a pickhelper (which holds all the state) and then do a series of .pick(x,y) calls.

thomthom

Surely you can still do this?

` ip = view.pickhelper(x, y)

...

ip.pick(n,m)

...

ip.pick(i,j)`

ip = view.pickhelper
This returns a PickHelper object. Which you then later uses .pick with.

ip = view.pickhelper(x, y)
This also returns a PickHelper object - which you also can use to later call .pick with. But specifying x and y doesn't seem to make it pick - which I wonder if it is a bug?

TIG

@thomthom said:

I'm confused to where ORIGIN comes into this..?

@tig said:

To be honest I never use anything but a 'bare' pick_helper with no arguments and then a ph.do_pick etc....

That's what I've do so far as well. Just looked like I could skip that last step - combine the two statements. But I'm not sure if it's a SU bug - or if the arguments for view.pick_helper works differently from what I'd expect.

ORIGIN is a built-in global-variable like X_AXIS, Y_AXIS and Z_AXIS...........

Chris Fullmer

I understand Thom, I always assumed it was a bug, or designed for something I did not understand. To make it easy on myself I've always used pickhelper without and parameters, and then use pick or dopick or whatever with parameters. You're not crazy.

Chris

thomthom

I couldn't find any bug reports on it - wanted to check. will submit a new ticket.

thomthom

Reported as a bug. example script attached.

tt_picktest.rb

Dan Rathbun

@thomthom said:

View.pick_helper
http://code.google.com/apis/sketchup/docs/ourdoc/view.html#pick_helper

@unknownuser said:

If you supply x and y, they are screen coordinates of the point at which you want to do a pick. Typically, there will be points that were passed to a method on a tool class.

From that I'm given the impression that I can do:
ip = view.pick_helper(x, y)
And it'd then return a PickHelper that's picked a point.
But that does not seem to work.

The API should probably say "If you supply x and y, they are screen coordinates of the point at which you will want to do a pick." (refering to the pick as a future event, yet to occur.)

@thomthom said:

If I do this:
ip = view.pick_helper ip.do_pick(x, y)
Then it works.

Because the description of PickHelper.do_pick states: "The do_pickmethod is used to perform the initial pick."
So, prior to this method getting called, the picklist should always be empty; and PickHelper.count should return 0.

@thomthom said:

Bug?

YES bug.

I think it either may have once worked and because of changes it no longer does, OR it was intended to work, but when the code for PickHelper class was written it wasn't possible, or someone forget the intention, etc. (perhaps more than one person was working on it and things got lost in the shuffle.)

What is supposed to happen when you call:
ph = view.pick_helper(x,y,apt) ?
I think something like this:


class Sketchup;;View
  def pick_helper(*args)
    case args.size
    when 0
      Sketchup;;PickHelper.new()
    when 1
      raise ArgumentError,"x and y required", caller
    else
      Sketchup;;PickHelper.new().init(args)
    end
  end#def
end#class

@thomthom said:

then what's the point of the arguments in the view_pickhelper method?

So the arguments for View.pick_helper were really 'intended' to be passed to PickHelper.init, so that you could then use either PickHelper.test_point or PickHelper.do_pick without having to again specify the x,y. Any method that takes an apeture would also use either the one set by .init or (as we are told in the API,) the "standard Sketchup aperture size".

However, PickHelper.do_pick always requires the two x,y arguments (regardless of whether .init was first called.)

And PickHelper.test_point, I cannot get to return true (regardless of whether .init was first called, or all arguments are specified.) Even when the point argument is exactly the same as the x,y .. still .test_point returns false.

p3.test_point [200,200],200,200,20
>> false

_