Here is a fix for bug #2615, which only occured on unix. Basically, I just
fixed it by copying and pasting some code from the windows version of the
same, which was correct. I give the same caveat as last time: someone more
familiar with this code than I may want to review it before committing.
Some thoughts:
I noticed that there is a lot of code duplication going on in the platform
specific frame stuff (there's like 2 lines worth of gtk! everything else is
substantially the same). We should probably figure out a way of refactoring
this post-1.0..
Also, shouldn't this Document->close thing leaving a "blank document" rather
than "exiting" be turned off by default? I thought that was Dom's verdict
after the whole August kerfuffle. [ not that I'm trying to bring it up again
but fwiw I find this behaviour really silly ]
Regards,
Will Lachance
[EMAIL PROTECTED]
--- ap_UnixFrame.cpp Sun Mar 24 16:36:37 2002
+++ ap_UnixFrame.cpp.new Sun Mar 24 16:36:30 2002
@@ -110,12 +110,7 @@
pG->setZoomPercentage(iZoom);
pDocLayout = new FL_DocLayout(static_cast<PD_Document *>(m_pDoc), pG);
- ENSUREP(pDocLayout);
- if (m_pView != NULL)
- {
- point = ((FV_View *) m_pView)->getPoint();
- }
-
+ ENSUREP(pDocLayout);
pView = new FV_View(getApp(), this, pDocLayout);
ENSUREP(pView);
@@ -236,27 +231,30 @@
setYScrollRange();
updateTitle();
-#if 1
- /*
- UPDATE: this code is back, but I'm leaving these comments as
- an audit trail. See bug 99. This only happens when loading
- a document into an empty window -- the case where a frame gets
- reused. TODO consider putting an expose into ap_EditMethods.cpp
- instead of a draw() here.
- */
-
- /*
- I've removed this once again. (Eric) I replaced it with a call
- to draw() which is now in the configure event handler in the GTK
- section of the code. See me if this causes problems.
- */
- pDocLayout->fillLayouts();
- if (point != 0)
- ((FV_View *) m_pView)->moveInsPtTo(point);
- m_pView->draw();
+ pDocLayout->fillLayouts();
+
+ if (m_pView != NULL)
+ {
+ // WL: adding this method into the UnixFrame from the win32 code to fix 2615
+ // we cannot just set the insertion position to that of the previous
+ // view, since the new document could be shorter or completely
+ // different from the previous one (see bug 2615)
+ // Instead we have to test that the original position is within
+ // the editable bounds, and if not, we will set the point
+ // to the end of the document (i.e., if reloading an earlier
+ // version of the same document we try to get the point as near
+ // the users editing position as possible
+ point = ((FV_View *) m_pView)->getPoint();
+ PT_DocPosition posEOD;
+ static_cast<FV_View *>(pView)->getEditableBounds(true, posEOD, false);
+ if(point > posEOD)
+ point = posEOD;
+ }
-#endif
-
+ if (point != 0)
+ ((FV_View *) m_pView)->moveInsPtTo(point);
+ m_pView->draw();
+
if ( ((AP_FrameData*)m_pData)->m_bShowRuler )
{
if ( ((AP_FrameData*)m_pData)->m_pTopRuler )
