Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Undo behavior

Is there any way to stop BricsCAD from storing view changes as part of the undo stack?

I'd like to undo only actual changes to a drawing, not changes to a view that has no effect on a drawing.

Comments

  • Gd question

  • edited January 7

    Mixing Undos with View Changes is extremely irritating.
    My other CAD has that misbehavior too.

    • You realize you did something wrong
    • you zoom out for better overview for a planned series of Undos
    • you will finally jump back between previous View changes and
      Zoom Levels, can't remember where you were nor see if you "undo"
      the correct objects, ....

    And if you allow yourself to do View Changes in between Undos,
    you will even destroy your Redo Stack !

    (Can't remember that anything in an OS or Finder/Explorer would
    ever jump back to a parent folder, if you undo a file copy ore delete
    and such)

    I worked with a lot of CAD's in the past and have a lot of 3D Apps
    that do that as expected.
    But Undo/Redo View is a command that I need so extremely seldom
    that I even don't know or care about the Shortcut. The 3 times a year
    I need it, I even prefer to use a tedious Menu or Arrow Icons,
    if available, for that.

    It would be so great if that would be changed and real Undos
    separated from "View Undos" by CTRL+SHIFT+Z or similar.

  • I would of course not mind if BricsCAD chose to offer users coming from other applications the undo they have grown accustomed to - as long as the current system remains unchanged for those who prefer it.

    I cannot follow Michael's arguments of BricsCAD's undo system being confusing ("...can't remember where you were nor see if you "undo"
    the correct objects..."): BricsCAD will take you exactly back the road you came - assumed you saw what you did, you will also see what you undo. To me, this feels much more logical and safer than what (almost all) other apps do, where multiple undo operations will usually change parts of the drawing that are not actually visible on screen. When I use undo in ArchiCAD, I often fear that I might have accidentally gone too far without noticing it. Zooming out before undoing changes does not look like a real solution to me, since some edits might be too minute to spot then.

  • @Knut Hohenberg

    In my case, I'm such a CAD neophyte that I make numerous mistakes and use various views to corroborate when I've done something correctly. Take, for example, working in 3D but trying to move things in Ortho views instead of Iso views. The move or copy looks good until you change perspective and realize that the destination point the software chose was the back end of the object and the intent was the front end. I've chased objects all over the place simply because I was using top, left, right, back and front views when working with a 3D object. I have learned not to do that any longer, but periodically I slip up.

    Chasing through all the view changes doesn't help me with the undo of the drawing change I want to get rid of. Eliminating all the view changes would allow me to typically undo once as opposed to numerous undo operations flipping through views. That's why I started this thread. I was hoping for a switch to throw to eliminate the views on the stack, but I got the impression that switch doesn't exist.

  • To help with your navigation issue have you considered using VIEWPORTS ?

    I found then a big help and quick and easy to set up
    and they can be saved and restored which is handy.

    Personally I wouldn't like to see UNDO recording changed :)

    2019-01-08_14-41-37.png
    203 x 274 - 7K
    2019-01-08_14-36-15.png
    1920 x 1040 - 236K
  • @Kerry Brown

    While I'm evaluating BricsCAD on a trial, I'm operating on a 20" monitor. Screen real estate is at a premium.

    I have a 32" high res monitor on the way along with a Quadro board to run it. Once I experience how it feels to work on a larger monitor, I might give VIEWPORTS a try. Thanks for the suggestion.

  • To all:

    I'm not suggesting removing the current behavior. I am suggesting that a setting could alter the behavior for those that want it.

  • edited January 8

    as long as the current system remains unchanged for those who prefer it.

    Of course - an option.
    And I think there is nothing to fear that any ACAD legacy would ever get lost
    in Bricscad. Looks like ACAD compatibility, functional and for user experience,
    is carved in stone and has highest priority over everything else.
    To not break any Bricscad compatible vertical ACAD 3rd party Software or
    scare any current or potential ACAD switchers.
    As it is the common ground of Bricscad's existence.

    The View changes in Undos is just one single of many other oddities and non
    standard behavior. (1-time only commands and selections, ADDSELECT, .....)

    So I hope for a future "global" option to switch everything from ACAD to
    back to Standard behavior at a time.

    But for me it is not so much about ACAD legacy just being different from the
    rest of the world, like imperial vs metric. I am always wide open for any
    alternative behavior - as long as it is better than the standard.

    I cannot follow Michael's arguments of BricsCAD's undo system being confusing ("...can't remember where you were nor see if you "undo" the correct objects..."): BricsCAD will take you exactly back the road you came - assumed you saw what you did, you will also see what you undo. To me, this feels much more logical and safer than what (almost all) other apps do, where multiple undo operations will usually change parts of the drawing that are not actually visible on screen.

    That may be very valid for simpler models.
    For a complex Building it may be nearly impossible to estimate your real location
    in the building from a view zoomed-in to detail or room level.
    There may be 100s of other possible very similar looking zoom positions.
    And you may have done pretty similar edits to pretty similar objects.
    But may have noticed that one of it had been wrong.
    (And and a bunch of Undos may be a better solution a destructive Modeling
    workflow than rebuilding something)
    In such a case I would intuitively zoom into the problematic area and hit Undo
    until I see that the objects reaches its previous state again and I'm fine.
    Or I also may prefer to better zoom out.

    If the view jumps around while Undos instead I can't be sure if I really reached
    the faulty object or just something similar looking.
    Maybe I did not go far in enough in undo history or even already too far.
    That is very error prone.
    I am the one who is in charge of moving Views around to observe my model.
    If I zoomed out for that purpose - it may have a valid reason.

    Combining real Undos and View Undos "may" be useful in certain situations.
    But I worked nearly 2 decades without a CAD counteracting my View Area
    Selection and never even felt I would be missing something,
    but since my first View+Undo combining App in 2014, I immediately felt
    this is wrong, error prone, hindering and annoying to me and
    that state didn't change so far after over 4 years

  • Hello Michael,

    I forgot to mention that I completely agree with one of your points: View changes should not break redo functionality. With this corrected, you could always zoom out when you lost orientation, and continue undo operations at will. Also, undo grouping could IMO get further enhancements - right now BricsCAD groups some consecutive view changes, but I see no reason not to skip over all commands that did not change the database in one go. Maybe the undo system would then feel less odd for new users.

  • I do think that AutoCAD behavior compatibility is very important. In an age when CAD systems are getting "smarter", knowing what it is thinking and doing becomes even more important. And even the behavior of the Undo feature is part of that needed predictability.

    However, adding new features, such as adding an option to bypass pan/zoom history (perhaps except for the last one) is a good one. An experienced BricsCAD user may find that going to AutoCAD may result in some frustrations, but usually the issue is someone going from AutoCAD to BricsCAD.

    -Joe

  • Hello Knut,

    I want to point out again, that for me,
    it is not at all about feeling odd or being different from what I was used to,
    I am deeply convinced it is wrong and crap that way :)
    I really notice that and get annoyed each single time I need a multiple Undo.
    I could write a list of what all could go wrong vs the advantages of View
    following the status of history.

    I think an "option" to completely(!) exclude any View history from Undo
    history would help me and some other users a lot.
    (
    Yes, the unwanted Redo history destruction may be the most obvious
    and dangerous risk. But I think it is the whole System)

    I totally respect that others are different and the majority of other Bricscad
    users really want to keep the current Undo, or even any strict ACAD behavior
    anywhere - for valid reasons.
    Of course an option - if possible.

    (For me it seems like in Vectorworks(?) it is so deeply hardcoded into the
    whole system that such an option would break everything)

  • Michael Mayer said:
    "In such a case I would intuitively zoom into the problematic area and hit Undo until I see that the objects reaches its previous state again and I'm fine."
    Very nicely put - I completely agree that's exactly what's required - sometimes - at will, easily switched maybe by holding Shift etc.

  • Yes, and there are so many other reasons ...
    like I may prefer a completely different View zoom and rotation
    to "repair" things, from what I used in the past while screwing things up
    .... and other things.

  • What if every change you make just created a new branch in a very big change tree, and you could jump around to any branch on the tree at will, going forward, backward, over branches, over certain branches (like view changes). etc. Just something to think about.

  • edited January 8

    Would that be significantly more useful than simply stepping backward, which is actually the only naturally-generated 'tree'. Not sure how or why I would want to deliberately create branches of a tree of errors!

    Another kind of View-change-independent Undo-viewing -
    While fairly zoomed out, each step of Undo would be highlighted in some way, until I could see an Undo is happening in approx the place I'm interested in.
    AI/ML could help anticipate what level of zoom/rotation would be most helpful as the process went along.

    My biggest use of Undo is when I've accidentally created a tangle amongst Refedits of multiple Blocks. I have each Plan as a Block (multiple copies of, in at least 4 different orientations, so I can construct N,E,W and S elevations and sections by projecting Xlines from them).
    Having been happily working away, copying geometry from one Plan Block to another, I zoom out and see a terrible mess of fragments scattered all over the place, repeated in four different orientations. I've messed up the +, -, open, save rigour in Refedit.
    It's really hard to correct, easier to just waste a chunk of work and Undo back to the pre-mistake stage - I can usually guess where I went wrong.

    Both of the above suggested Undo modes would help enormously in this.

    How about a Feature Request SR?

  • @Owen Wengerd
    You're taking this way past what's reasonable via simple programming.

    I'm a retired professional software developer. I know how programmers think and how they implement things. My query, and that's what it is, was to find out IF a mechanism existed that I didn't know about.

    To implement a change to provide the undo mechanism without view changes amounts to providing a setting to indicate the choice, and then to query the setting BEFORE dropping things on a software "stack" to see if they should be put there. That's a single stack.

    Every programmer is familiar with a stack. A change to not put view changes on the stack is trivial compared with what you're suggesting. Yours would take an unlimited number of stacks. That's a huge difference.

  • edited January 8

    How about a Feature Request SR?

    I thought SR'd that long ago ... but don't find it anymore.
    Maybe I mixed it with other wishes or it was just a forum post....

    Yes, if people are interested,
    lots of similar SRs from different unique users may have more weight
    than a single user complaining again and again.

  • RoatanBill said:
    "to provide the undo mechanism without view changes amounts to providing a setting to indicate the choice, and then to query the setting BEFORE dropping things on a software "stack" to see if they should be put there"

    I'd say the view changes should be saved in the stack, but then, during a particular Undo/Re-do session, have a choice of whether or not (e.g. hold Shift or not) it should ignore the saved view changes, while allowing view changes ad lib during the Undo/Re-do session.

  • So far I knew only 2 separate stacks, Undos and View Undos.

    But an option to keep both histories in sync, if needed,
    sounds interesting too.

  • @Tom Foster
    Great idea!
    That leaves the code pushing things onto the stack completely alone and requires a modification to the code that pops things off the stack to just check if it's a view, ignore it and pop the next item. Wash, rinse, repeat. Shift key as the indicator for ignore views is perfect and requires no new settings variable to be invented, initialized and then checked.

  • I, too, have been routinely annoyed by undo affecting every action, and madly frustrated if I happen to scroll or zoom a bit during undoing, attempt to reverse, and get scolded: "There is nothing to redo."

    For me, what I'd prefer to be inconsequential history is not even limited to view changes. Sometimes I have to make desired changes to settings over again that got lost while undoing other actions.

    Maybe what @Owen Wengerd suggests is impractical, but perhaps the Drawing Explorer could provide the means to access various types of history. Such as, undo view changes under the Views panel, undo layer changes under the Layers panel, etc. And the rest of the time, while working in model space, only undo changes to the actual model.

  • edited January 8

    @Owen Wengerd said:
    What if every change you make just created a new branch in a very big change tree, .......................

    Hi Owen,
    If it's good enough for GIT, then ,,,,

    Excellent bit of lateral thinking :)

  • So if we already discuss the whole Undo System ....

    In Modo I can expand a complete Undo History with all (Sub)Commands
    and move the Time Slider back to where I need.
    Maybe you could even delete actions in between without loosing later
    actions - but am not sure.
    Probably the best solution I have seen so far.

    I think Microstation and C4D showed at least which current Command for
    UnDo and Redo in Menu, which also helps.

    I think Vectorworks (and Bricscad ?) only shows what you have Undone - after
    you did the Undo. Better than nothing

  • @Owen Wengerd said:
    What if every change you make just created a new branch in a very big change tree, and you could jump around to any branch on the tree at will, going forward, backward, over branches, over certain branches (like view changes). etc. Just something to think about.

    Sounds interesting.

    As already suggested, I think the ability to view the undo stack, and being able to move forwards and backwards would be a good start. Inkscape is another example with this feature. You could build from this to allow for versioning. Select a point in the history and create a branch.

    In the early days AutoCAD didn't include zoom calls in the undo stack. I assume that this was due to machine capability of the time. Back then you did everything you could to avoid a REGEN as they could take many minutes to complete.

    Regards,
    Jason Bourhill
    CAD Concepts


    Come to the Australasia BricsCAD Conference


  • Back then you did everything you could to avoid a REGEN as they could take many minutes to complete.

    Probably the reason why they invented the redundant System of
    Visibility + Freezing Layers.

  • @Michael Mayer said:

    Back then you did everything you could to avoid a REGEN as they could take many minutes to complete.

    Probably the reason why they invented the redundant System of
    Visibility + Freezing Layers.

    Precisely. But, even though for most drawings, the Regen time is negligible. large data sets, such as point clouds or dense triangulated scans, need the freeze/thaw capability.

    -Joe

Sign In or Register to comment.
Origami
Origami is the Japanese word for paper folding. ORI means to fold and KAMI means paper and involves the creation of paper forms usually entirely by folding.

Powered by VanillaForums, Designed by Steam