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?
This is a great feature! Got a chance to give 637 a little workout…found a couple of things:
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.
I think this is a bug with the TRIM tool:
I created a somewhat complex set of objects and started the TRIM command::
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!
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?
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.
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?
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)
CANCEL
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!
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
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)
)
