Making "delete hole" command autocomplete..?

Rhino Rhino for Windows
1

This command annoys the hell out of me, because it just stays live for ever until specifically closed, and It always trips me up; I either accidentally delete more holes than i intend because its still running and I haven’t clocked it, or the next command I am trying to run wont, because “delete hole” is still hanging in there…

move hole autocompletes
mirror hole autocompletes
make hole autocompletes
The actual delete command autocompletes
Wirecut autocompletes

lets make things consistent here…!

cheers
rabbit

2

In Rhino 6, DeleteHole has been replaced by UntrimHoles… And it is one of those commands that stays active until you tell it you’re finished with an Enter, as you can pick multiple holes to delete in the same operation.

3

Well yeah, but what i’m saying is I don’t think it should stay active - it much too dangerous like that.
A long time ago I used a 2D program where every command ran automatically without pressing enter. So you’d just type a command, eg dl for “draw line” and it was waiting for your start point.
I hated that autocad convention where to get to the same place you had to go “dl enter”.
Anyway, that fight is long lost, and rhino sadly adopted that methodology.
So, now that pressing enter to get the program to do anything is the convention, to my mind all commands should behave like that.
And likewise all commands should terminate in the same consistent fashion ie they should all terminate automatically once they have completed their action.
Why? Because this makes the program flow easy to learn, and when new commands are added as the program develops, the core methodology works as we expect.
And as a experienced user, which we all become over time to various degrees of proficiency, we are not suddenly tripped up in the workflow by an un-expected rouge command that breaks the chain.
However, rhino has too many added, hacked and one-off commands that insist on following various different logic flows, which while they may make sense in their own seperate context, don’t fit into the overall program convention.

Delete hole (or untrim hole) is one of them.
Wirecut is another.
There are others.
I think it is long past time that this group of stragglers to be rounded up and brought into line, and further that as commands are added as the program develops, all new commands behave according to the overall accepted conventions of the program.

Just sayin…

Cheers
rabbit

4

Well, no.

There are also lots of commands in Rhino that have variable sequences where the number of picks/clicks/placements is arbitrary and thus need some way (Enter) to signal that the user is done with the current set. Let’s see - that might be

Copy (and any transform command with the copy option like Rotate)
Points
Polyline
Curve, InterpCrv
Trim
Split
DupEdge
Extract…
Etc.

Note also that the V6 command is UntrimHoles (plural)…

However, if you absolutely need to have the command do only one hole at a time and stop, a macro such as this will work:

! _DeleteHole _All=No _Pause _Enter (V5)
or
! _UntrimHoles _All=_No _Pause _Enter (V6)

It will then stop automatically after just one pick without Enter.

Just sayin…

–Mitch

5

Well yeah – you are right…

So why then do I feel there is a problem with “delete hole”?

Lets take the “make hole” command:

Firstly you are asked to select planar closed curves (press enter when done)

So as you do this, the curves are highlighted as you pick.

Once you have selected all the curves you want, you press enter and are then asked to select a surface or polysurface.

Once done, you press enter to complete the task (or optionally select further options). The command ends.

Now “delete hole”:

You are asked to select a hole edge, the edge is highlighted, and once you have selected an edge, either via the mouse, or pressing enter, the command deletes the hole without further confirmation, AND STAYS ACTIVE, with no visual information as to this being the case except the command line.

The difference here is that the Make Hole command gives feedback of what is about to happen, to possibly multiple holes, and then waits for confirmation before it carries out the command on enter, and ends.

The Delete Hole command gives feedback of what is about to happen to one hole, and then deletes it on enter without waiting for confirmation, and further stays active.

This is not consistent behavior.

Delete Hole should:

Ask you to select a hole edge. Once this is done via a pick with the mouse or enter, it should ask you to select the polysurface, and then complete the task via enter, and end.

Now, just because the command already “knows” which polysurface you mean because you have already selected an edge, doesn’t mean it should rush ahead and do it without confirmation.

Why?

Because other commands don’t do that….and they don’t stay active once the task is carried out.

For example:

Split: Asks for objects to split, press enter when done. Then asks for cutting objects. You select these, press enter to carry out the command, and it completes.

Copy: Asks for objects to copy, press enter when done. Asks for from point, all the while giving feedback as to what is about to happen, and once you are done with copying, terminates.

The difference is Delete Hole is “overly smart” compared to the general command set of the program, where the convention is Enter is used during the command to confirm options and to complete a command, with the command terminating when done.

Further, another example of this “overly smart” command is WireCut, which doesn’t wait for an enter after selecting the cutting curve, but goes directly to asking for the object to be cut.

To be consistent, it should require an “enter” once the cutting curve is selected. I use this command often and I still screw it up more often than not by pressing enter after selecting the cutting curve, whereupon the command unhelpfully terminates.

It can be argued this is nonsense, and endlessly having to pressing enter when the software can be coded so it isn’t necessary is stupid!

I would so agree; however unfortunately that is the convention that Rhino has adopted, and I would argue that it is counterproductive to allow rogue commands to operate outside it.

I suppose I should note that I almost always use the command line and shortcut macros; perhaps if I used the menu or the icons this kind of thing wouldn’t be such a problem…

Anyway, enough.

Mitch, thank you for the marcos, which I will certainly adopt.

Cheers

rabbit

6

Hi Rabbit - I don’t see this at all - the command knows what polysurface you picked on… I can see a case for one and done, but it should not take more than one pick per, just because some other commands do…?

-Pascal

7

Nah, same issue exists when using menus and icons since you still need to answer the option questions. All the menu or icon pick does is initiate the command, which then goes through the same command line gymnastics as if you typed it in the command line to start it.

I certainly agree with your basic premise - that it’s too easy to get caught in the loop of having the command ask to do it again when you actually think you’re done. Thank goodness for the UNDO button and the ESC key. Unless, of course all you do every day all day is Rhino. Then I suspect it’s all muscle memory anyway, even the muscle inside your skull.

Could it be improved? Heck yes. Will it be? Don’t hold your breath.

8

Hello Pascal

I can see a case for one and done, but it should not take more than one pick per, just because some other commands do…?<

I would argue that it should!

I agree it appears stupid, but what I think is really “stupid” is that rhino adopted this autocad thing of pressing “enter” to tell a command to operate.

Back in the day before rhino, and when most CAD was still 2D, Generic Cadd operated all its commands with just a two letter command set, and didn’t require “enter”.

Autodesk bought generic, and trashed it, so that was the end of that, and since then enter has been king!

Rhino chose to lie in that bed, and, to be consistent, that’s how it should operate.

Your brain gets wired to “Enter”, and it becomes a habit- then you get tripped up by smarty-pants commands that think they know better…well, they do, but they should be ruthlessly culled / bought into line!!

It’s all a shame, but it’s just like Amiga vs IBM computers, or VHS vs Betamax etc: just because something is smarter or technologically better, doesn’t mean it will be the most successful…

Cheers

rabbit

—Sent from mobile device & email—

9

Man, all that from a phone - hats off! I wouldn’t even try. What I meant was just that I understand the wish to finish the command after one pick and be done, it just does not make sense to me to add an extra and functionally unnecessary input pick, which is what I understand from

“Ask you to select a hole edge. Once this is done via a pick with the mouse or enter, it should ask you to select the polysurface, and then complete the task via enter, and end.”

One pick on the hole edge and end the command does make sense. Untrim and Extend are the same, I am occaasionally, even after decades, caught out by these not ending.

-Pascal

10

One pick on the hole edge and end the command does make sense. Untrim and Extend are the same, I am occaasionally, even after decades, caught out by these not ending.<

So, why Pascal, why not clean these things up…I mean why not???
Why?

cheers
rabbit

—Sent from mobile device & email—

11

Hi Rabbit - a couple of reasons come to mind - - ‘cause there are other points of view, for one - there are at least as many times when it’s good that the command keeps going as not, and there is some weight or inertia of years of being this way, where messing with peoples’ known and habitual workflows will cause havoc that we are not able to predict - we see that from time to time when we think we’re making things more sensible and it backfires. And, there is not that much pressure, to be honest, given the pile of stuff and the resources available.

However, that does not mean it’s a bad idea, just that it needs to be done, if at all, carefully.

-Pascal

12

Yes there is, the shape of the mouse pointer is also different when being inside a command and are asked to select something. Once you got out of the command the mouse pointer changes to it’s normal shape.

I’m also not sure I see the problem here, but maybe I’m one of those that remember things from “Muscle memory”.

13

HI Rabbit
How about making yourself a custom button that does end?

14

Yep, that what I’ve done…

Cheers

rabbit

—Sent from mobile device & email—