Ctrl+V taking pictures? Really?!
1 Like
Maybe the picture was stored in the clipboard from other program prior that?
This is the picture
This is what Rhino says in the command bar:
Name of the bitmap file to open ( Browse ): "C:\Users\Username\AppData\Local\Temp\Clipboard-b8f30f64-5720-4f3d-a8e3-f9a347924962.png"
that ain’t other software taking this picture
Steps to reproduce:
- Activate filter for sub-objects
- Select a few subd faces and Ctrl+C
- Then Ctrl+V
1 Like
Wow, what a bug… I also can confirm that this happened on my Rhino 7, no matter if I tryed to copy a single SubD face or multiple ones. The result is Rhino asking me to place the coordinates of a picture frame consisting a screen-shot of the viewport.
1 Like
Nice one…
Regards
Rodolfo Santos.
Actually it’s Ctrl+C that is taking pictures. The command in Rhino is set up to copy certain elements of Rhino files - if it recognizes them - “to the clipboard” and then paste them back in with Ctrl+V.
In fact, IIRC, it doesn’t actually copy them directly to the clipboard, because the Windows/Mac clipboards do not understand Rhino geometry - so Rhino makes a temp file somewhere and puts that on the clipboard for pasting.
If nothing is selected, pressing Ctrl+C copies a screenshot of the active Rhino window to the clipboard.
Which brings us back to the first paragraph above, the important part being if it recognizes them. Obviously what is happening here is that Rhino does not (yet) recognize individual sub-d faces as elements that are copy-able to the temp file. For that matter Rhino doesn’t recognize ANY selected sub-objects, sub-d or otherwise - try it with the face or edge of a simple cube, same thing will happen. So, it acts as though nothing is selected, and takes a screenshot instead.
QED. It’s not a bug per se, it’s a “limitation”… 
Also, one of the differences V6>V7 is that in V6, if there was an image on the clipboard, and you tried to paste into Rhino, it would just say “Unable to paste, no Rhino elements on the clipboard”. In V7, if there is an image on the clipboard, it assumes you want to insert that image into Rhino and automatically launches the Picture command.
2 Likes
I’ve logged the irritation as RH-64052 Screenshot is taken even if a selection exists.
1 Like
Maybe qualify that as “…even if a subobject selection exists”. It works fine with normal selected objects.
Personally I see this as an enhancement request.
1 Like
To me subobject selection is also a selection.
Usability problem often needs an enhancement 
Agree, and yes, enhancement will be welcome as it makes sense in terms of use.
Regards
Rodolfo Santos
Well, there are a number of things that are not hooked up with sub-objects, which is why I consider this to be a general (current) limitation and not specific to this one issue. Most (but not all) of the things are hooked up for internal use within the same file, but not when one needs to externalize objects.
For example, in the same vein as Copy/Paste, you cannot ExportSelected selected subobjects. This is because subobjects lack IDs. In order to make this happen Rhino would need to create IDs for the objects to export as it does for internal use when one makes copies of them via the Copy command or with the Gumball. I’m sure this is planned for the future at some point.
Some examples of internal stuff that is not hooked up yet are making a mesh from selected sub-surfaces or a block from selected subobjects.
Hm, I want the v6 behavior
To me as well. In fact what I expected as a result was an “extraction” of the subd faces as a separate subd containing only these faces.
As I said, this is not currently possible with any kind of selected sub-objects - curves, surfaces, mesh faces, sub-d’s etc. I’m sure it will be made possible at some point. There are already at least two youtrack items on this:
1 Like