Text block is a curve?

I am trying to project a random selection of objects onto a surface, using the PullCurve function. Since projection is only possible for curves, and will generate an error message when a non-curve object is selected, I am filtering out the curves with IsCurve. Here is the code part:
pulllist= rs.SelectedObjects()

	for pully in pulllist:
		if rs.IsCurve(pully):
			if resultcurve:

Trying it, it was a hit-and-miss. Sometimes it worked, sometimes it came up with a message regarding the SelectObject function: "argument requires a guid or a string representing a guid"
I found out that this happened when the selection included a Text Block, and after more research that a Text Block is actually a tuple of two guides. Changing the argument to resultcurve[0] solved the problem, although there is no visible evidence of the projected Text Block (which is fine).
What puzzles me is how the Text Block got past the IsCurve filter. Anybody an explanation?


Edit: I reversed the change in the script, and it still works without error messages, go figure!

That doesn’t make any sense to me - a text block in Rhino is just like any other object, it is referenced by just one GUID… Something else must be going on.

I created a bunch of random object types including curves, surfaces, text blocks etc. and ran the following, only the curves selected…

for obj in objs:
    if rs.IsCurve(obj): rs.SelectObject(obj)


Hi Max,

Be aware, that rs.PullCurve will return a list of pull results.
So the lines below should read:

			if pull_result:

The reason why you did not run into errors was because SelectObject accepts single items in a list as valid input. Yet the moment PullCurve returned a list of multiple resulting objects you got an error.

@stevebaer I like to adress this to you as well:
After some tests to find out why it did work at all, I found that rhinoscriptsyntax.SelectObject() will not raise an error when passed a list or tuple with a single valid item. It will run as if a single Item is passed.

In utility.py line 491 the reason for this unexpected behaviour can be found.

Might this be in need of some revision? maybe for V6 at least. The behavior of coerceguid use in SelectObject is error prone and might overshoot the purpose by making coercing so lenient.


I’m not sure what the appropriate thing to do here would be. The coerce functions try to handle any case that makes sense.

What do you think should be done to improve things?

Maybe let SelectObject check and raise an error when a list or tuple is passed.
I can see however that it might break existing scripts.
I have no overview what implications this might have so maybe it needs to leave be…

My guess is not as good as yours in this.


Willem, that was just my point, Pulllist is a list of randomly selected items, regardless whether these are singles or tuples. Then I went through the list and selected on curves with IsCurve. After that each curve was projected onto a surface, producing a resulting resultcurve. That should have been represented by a single guid, so SelectObject should not result in an error.
Yet it did, and by inserting a print statement I found out that the culprit was a tuple guid. With more research I found that this happened with Text Blocks, but not consistently. According to @Helvetosaur that could not have been the reason, since Text Blocks are also represented by singles (and should not have passed the IsCurve function in the first place, @stevebaer could this happen?) Seems I have to do more testing if I want to get to the bottom of this, in the mean time the solution I described above works adequately.


No, not necessarily. Projecting a single curve onto a surface can result in more than one projected curve being created.


Thanks Mitch, you put me on the right track. Testing it with a single curve passing over a surface twice gave exactly the error I saw before, combined with indeed a tuple of GUID’s. So SelectObjects it will be, @stevebaer you can forget about my earlier question.
Now I have to adapt my scaling routine, it does not like tuples :unamused: . It is like solving traffic bottlenecks, you solve one only to get another one further down the road…