#74 Redo fix (incl. undo fix)

closed-rejected
None
5
2003-04-28
2003-03-17
Kimmo Varis
No

This is patch 703069 + same fix for redo. Hopefully
this prevents crashes on redo code.

Discussion

  • Kimmo Varis

    Kimmo Varis - 2003-03-17

    Changed file

     
  • Anonymous

    Anonymous - 2003-03-23

    Logged In: YES
    user_id=60964

    Darn.

    I'm still blowing up on Redo, even with this patch (which
    I just applied to my working source, because I saw a
    Redo fail).

    Diff the two versions of readme.txt (which I will attach).
    On the RHS (which is missing lines at the top),
    highlight the top line and delete it -- this line:
    2003-03-22 Kimmo

    then ctrl-Z (undo) and it comes back
    then ctrl-Y (redo) and ASSERT failure.

     
  • Anonymous

    Anonymous - 2003-03-23

    Logged In: YES
    user_id=60964

    Verified this ASSERT occurs with current CVS code and this
    patch.

    ASSERT is the middle of the three in
    CCrystalTextView::AssertValidTextPos

    Oops, I can't attach files because it isn't my bug.
    I'll go look to see if there is a convenient bug they could
    go on.

     
  • Anonymous

    Anonymous - 2003-03-23

    Logged In: YES
    user_id=60964

    Files for ASSERT I hit with this patch today are attached to

    Bug#691423: Undo ASSERT failure (Rescan wrecks Undo info I
    think)

     
  • Anonymous

    Anonymous - 2003-03-31

    Logged In: YES
    user_id=60964

    Gee.

    I was just testing to see if this is fixed now, and now the
    first Undo (after deleting the top line with content on RHS)
    doesn't work right -- I get a blank line back. Or it looks
    blank at least.

    Then the Redo causes an ASSERT
    inside of

    CCrystalTextBuffer::Redo

    inside of
    #ifdef _ADVANCED_BUGCHECK
    (I guess we have that defined, at least in debug)

    on

    ASSERT (lstrcmp (text, ur.GetText ()) == 0);

    My "text" variable contains two bytes (a CR-LF), but
    ur contains the actual line I deleted.

     
  • Kimmo Varis

    Kimmo Varis - 2003-03-31

    Logged In: YES
    user_id=631874

    Uups. I didn't add a note here when applying. Only wrote
    mail to devel-list.

    Anyway, undo part of patch were applied, redo part were not
    applied. So yes, redo can crash.

    Undo failure is decision, I wanted to prevent crash,
    although it corrupts undo data. There is again problem of
    not able to empty all the buffers...

    I really do not know what to do with undo/redo. They are
    very nice when they work. Mistakes happen when merging and
    I personally prefer even half-working undo feature.

     
  • Anonymous

    Anonymous - 2003-03-31

    Logged In: YES
    user_id=60964

    Ok, right, you have said that before, I just have trouble
    following undo/redo stuff.

    What if -- and this involves significant UI changes :( -- we
    set it up so there are checkboxes for
    - auto-rescan
    - clear undo at rescan

    and if you check the upper one, it automatically checks the
    lower one.

    So, you can go clear the lower one, if you (like Kimmo) want
    auto-rescan but also want undo, but it is not easy or
    default to have this arrangement -- my idea being to make it
    harder to get this setup, so we get less bug reports about
    it... b/c, I don't know how much we need more bug reports
    about Undo & Redo really, we haven't fixed the ones we have :)

     
  • Anonymous

    Anonymous - 2003-03-31

    Logged In: YES
    user_id=60964

    Well, I guess I just have lost interest in how many ways
    there are to break Undo & Redo (which is why I don't look
    forward to bug reports about them; I like a short bug list,
    and dread a long one full of undo/redo stuff).

    I'd be a lot more interested in ways to fix them :)

    I think the problem is complex enough to manifest in a lot
    of ways that are not particularly interesting individually;
    I guess that is why I'm less interested than usual in
    knowing how to produce ASSERTs.

    Maybe if we release it with the problem, some developer/user
    will hit it and get interested and figure out the answer.

     
  • Kimmo Varis

    Kimmo Varis - 2003-04-28
    • assigned_to: nobody --> kimmov
    • status: open --> closed-rejected
     
  • Kimmo Varis

    Kimmo Varis - 2003-04-28

    Logged In: YES
    user_id=631874

    Closing and marking rejected.

    This has couple of bad problems. And Perry has a lot better
    solution than this one.

     

Log in to post a comment.