I think the limit here is that, while in the command, you will not be able to undo past the state at the start of the command, or you’re creating alternates history states to wind forward and backward (and if we know anything from Back to the Future II, that’s confusing).
This seems reasonable to me, but I’m not always a good judge.
It’s 100% reasonable that you can’t undo past the start of a modal from within the modal…however, I don’t think I did undo past the start of the modal. I trimmed 3 vectors and undid 2 of them…then redid the 2…and then cancelled…and you see the wrong info. It seems the problem is with the REDO logic - it’s not doing some housekeeping that UNDO is doing correctly…and you’re getting out of synch in your history states.
Just to be clear, redo wasn’t handled well in the last release (definitely a bug). We just uploaded 640 which should be correct for both the Trim and Array commands.
Didn’t know there was a new release…let me look there…
Confirming that Redo is now working correctly in 640 for both Trim and Arrays! I suppose you think that sub-hour fixes are “good enough”? 
Thank you.
You’ve got to act while the code is fresh.
I’m very eager to get these two commands “perfect” so they can be the model for all future work.
They’re the result of all of the new internals and rework we did to get V6 ready, and then months of learning the right way to apply everything.
We’ve got another command or two to knock out and then we’ll freeze and move onto V7, where we can break with some UI history to redo existing commands and change the file format to add new ones.
That all sounds VERY exciting. Anything I can do to help, let me know.
I like the array feature.
I tried to back into an array and edit it. When clicking the array, it added another set of images off the end of the workspace?
I tried to add another row and it closed?
An array is only an array while the command is active — once the command is applied then you get either a bunch of objects, or a group of the objects.
Makes sense. It’s a data entry aid…saves you time
Just wanted to say, kudos to the carbide create team for fixing the bugs. That was fast! What else could a guy ask for? Thanks guys!
We appreciate the help we’ve gotten up to this point.
And for the final update of the day, probably the week, we just uploaded 641 with Circular Arrays since it was largely a cut-and-paste from the Linear Array command.
We’re glad to know that it’s getting used.
I’m afraid there is some major stuff going on when you drag within the circular array dialog. If you drag the object, the others kind of scatter far away!
When you drag, the center doesn’t move, so the pattern will expand or contract depending on the direction. Is that what you’re seeing?
Ah…most likely. Is that really what’s expected? I could see that being the behavior if you’re holding the shift key, or something like that while dragging - but I would think the array commands would operate the same way. In a square array, you’re moving the entire collection - in a circle, you’re increasing the spacing…
Knowing that, I understand what’s going on - but it is inconsistent with the other Array command.
If I were designing it, drag would always move the entire array…Shift-Drag would expand (or contract) the spacing…in both array commands.
The center of the array is defined in the dialog — the only thing being moved is the beginning point of the rotation — think in terms of polar coordinates and it makes sense.
But the purpose of dragging is different for the two dialogs…in one, you’re dragging to move the array (which moves it’s center, btw), in the other, you’re changing the starting point relative to a fixed center (which you can’t move). Personally, I find that confusing.
I’ll take a look at other programs that do this and see how they handle it. Not that changes anything - I just want to be as close to “common sense” for the users as possible.
I guess I could make an argument either way. That said, my general thinking is that you “always” know the center of the array in your design so you can anchor the center point there. You’d then be moving the objects (if necessary) to set the effective radius or alignment of the objects in the pattern.
I was playing with the idea of drawing a reference circle through the center of the bounds of the objects being arranged to make the whole thing more clear. The more I think about it, this might help a lot.
Now, in a more practical world, the way we implemented it is the only thing the framework supports right now.
Lightburn (which supports all of these array things) does not allow you to drag while you’re building the array. It puts up a modal dialog with the parms of the array and you can’t do anything until you either accept or dismiss the dialog.
EDIT: I like what you’re doing better, frankly. I’d just like the array tools to be consistent in behavior
Looks to me like the behavior is consistent. When you drag the base object, it updates the array / pattern based on it’s position. In the linear array, there is no center, positions are relative to the base object. In the circular array, you can move both the base object, and change the center.
BTW, Linear array - “Gap Between” spacing doesn’t behave as expected with negative spacing. Although I suppose this could be an “undocumented feature” if I wanted the spacing measured to the outside of the objects, rather than the space between them??