Carbide Create 637 - Now With Arrays!

We just uploaded CC 637 to . The changes are:

  • (NEW) Undo now works current the Trim command.
  • (NEW) Undo behavior of Corner Tool command matches Trim command.
  • (NEW) Linear Array command.
  • (INTERNAL) Optimizations for toolpath calculation with lots of little islands.

Give it a shot and let us know what you think.

EDIT: 638 includes some bug fixes and improvements:


  • (NEW) Linear Array allows dragging, selection changes, and undo within the command.
  • (FIX) Tab order in Linear Array command (and a few others as well).
  • (FIX) Cancel in Linear Array command discards changes to parameters.
  • (FIX) Some open curves didn’t trim properly in Trim Command.
  • (FIX) Crash in duplicate (CTRL-D) command.

Care to shed any light on the new linear array cmd? Is this similar to what we see in Fusion where you can create a gridwork of holes or other repeating features?

It allows one to do a grid or other repeating arrangement of objects:

Draw something:

Click on the “Linear Array” command:

Adjust settings as desired:


Wonderful news! It’s great seeing CC get so many useful features.

This is a great feature! Got a chance to give 637 a little workout…found a couple of things:

  1. Undo in Arrays:
  • Does not seem to work within the dialog. For example, if you move one of the objects while in the Array dialog (I did that by accident trying to move all of the copies to a new location and only the one object I originally copied moved…so I tried to undo the move) Undo doesn’t work.
  • Additionally, if you change a value in one of the edit boxes and tab out, undo does not put the old value back. I found that one by accidentally typing a large number in the “Row Offset” and tried to get back…since I didn’t notice what the original value was, I tried to undo…couldn’t. So I CANCELED the dialog and came back in - and the value was still changed.
  1. I think this is a bug with the TRIM tool:
    I created a somewhat complex set of objects and started the TRIM command::

    I “Trimmed” the right side of the circle away…all worked

    Then I tried to trim the circle between the next two points:
    and it DOES NOT delete.
    So I undid the operation and tried to delete that segment:
    That worked. So then I tried to delete the right side of the circle…but it WILL NOT TRIM.

EDIT: Interestingly, you CAN trim the other line between those same two points:

EDITED AGAIN: It gets even more interesting…you’ll notice in the image above, the dot that used to be at the top of the circle is now gone…but if I click on the top right of the circle again, THIS time, it trims - from the non-existent point!

Why would that be??? Is this a bug or a feature? :slight_smile:

  • Gary

Bug. There are probably a bunch of these because this is a really complicated chunk of code. Can you add a second layer to make the locations of the clicks to cause the failure and then upload it here?

Dragging should have been disabled, I think.

Not sure if the global undo is interfering with the entry boxes or not.

So you think the values should persist only if the user clicks OK?

1 Like

Noticed that when I use the ctrl/d option to duplicate, the program will shutdown and close. Is it a bug or am I doing something wrong? It worked great before.

1 Like

Bug, I’ve logged it — hopefully it’ll get fixed in the next version.

OK…Here you go, @robgrz:
Bug in Trim - 2 Examples.c2d (1.2 MB)

OK…but why? I think it’s OK, as long as anything you do in the dialog is reversable with Cancel.

Yes…if the user chooses “Cancel”, I would anticipate things being as if I never went into the dialog in the first place. I think of modal dialogs as units of work…so it’s all or nothing - it rolls back as a single set of changes.

I noticed that this is NOT the way the modals work, in general. I noticed that if you press OK in a modal, and then click “Undo”, you end up undoing the sub-tasks that you did in the dialog, one by one. That’s not what I would anticipate. I would anticipate that the entire unit of work done by the modal would undo. Once I commit a modal, I’m basically saying I’m done and I don’t expect to do the sub-tasks I did when I was in the modal. I can undo everything, but not the things done within the dialog independent of each other. Does that make sense?

Whoops, we used that code for the array command and broke it. That will be fixed in the next release.

Good argument. Should be no problem to implement.


Way cool! Circular array next? (No rest for the weary :smiley: )


Yes! But why stop there? How about arrays that are evenly distributed along any curve?

1 Like

It’s on the To-Do list but…

this would be the goal.


Give 638 a try, :


  • (NEW) Linear Array allows dragging, selection changes, and undo within the command.
  • (FIX) Tab order in Linear Array command (and a few others as well).
  • (FIX) Cancel in Linear Array command discards changes to parameters.
  • (FIX) Some open curves didn’t trim properly in Trim Command.
  • (FIX) Crash in duplicate (CTRL-D) command.

Looks pretty good…
Found one SMALL snafu (so small you might not need to repair it):
Go into Array…move the item (nice: All the items move together)
Everything reverts (EXCELLENT)

The REDO queue, however, still has the moves stored in them.

As I said, tiny defect…really depends on how anal you want to be!

@robgrz You can hate me now, if you want:

There is an issue with Redo/Undo/Cancel in the Trim command as well:
Starting with this drawing:

Enter Trim and Trim any two intersections (I played with the circle and square

Click UNDO; then click REDO
Click Cancel

One of the two removed curves does not reappear on Cancel…it is saved in the UNDO buffer, though.

NOTE: it’s always the first vector trimmed that does not revert on Cancel after UNDO and REDO. Perhaps it’s a counter that’s not getting decremented on REDO???

Yes…that’s most definitely it - for every REDO, you get more and more vectors not reverting (plus odd things happen even within the dialog - the first redone trimmed item comes back when you hit redo the second time!)

I’m of the opinion (maybe I WAS of the opinion) that adding them to the redo queue is the right call. If you redo them, you can undo them without consequence. The second you execute another command that uses the undo queue, they’d be flushed. It’s one function call to preflush them, so it’s not a big deal, but I’d be curious on what the general opinion is. (Now that I’m typing this, maybe I’ve changed my mind. It’s always possible to preflush the queue but it might not be possible to always allow redo)

I’ll have to take a look at your trim problem. Can you upload the file?

It really works with any file…adding it to the redo queue is fine…but when you Redo, it looks like you’re not updating a counter (or pointer), because you lose one item per Redo

I’ll put together an example

OK…Here’s an example of multiple Redos creating multiple problems. (The example I did in thread shows one Redo causing trouble)
Undo Redo Cancel defect.c2d (1.4 MB)

Sorry @robgrz That file will not demonstrate the issue (wrong instructions)…this one will:
Undo Redo Cancel defect version 2.c2d (1.6 MB)