This is patch 703069 + same fix for redo. Hopefully
this prevents crashes on redo code.
Logged In: YES
I'm still blowing up on Redo, even with this patch (which
I just applied to my working source, because I saw a
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:
then ctrl-Z (undo) and it comes back
then ctrl-Y (redo) and ASSERT failure.
Verified this ASSERT occurs with current CVS code and this
ASSERT is the middle of the three in
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
Files for ASSERT I hit with this patch today are attached to
Bug#691423: Undo ASSERT failure (Rescan wrecks Undo info I
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
(I guess we have that defined, at least in debug)
ASSERT (lstrcmp (text, ur.GetText ()) == 0);
My "text" variable contains two bytes (a CR-LF), but
ur contains the actual line I deleted.
Logged In: YES
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.
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
- clear undo at rescan
and if you check the upper one, it automatically checks the
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 :)
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.
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.