Problem is that MainFrm.cpp:m_wndStatusBar.PaneText(2) not get reset, if a windows get closed. The following code works for me, but I don't know if it is the correct/best way. Im still no C/C++ developer! ;)
Ok, but can you describe when and how the bug happens? By quick reading I understood that:
1) open folder compare of two folders
2) close the folder compare window, but not WinMerge, so that main window remains open
Expected:
Main window does not show folder compare item counts in statusbar
Actual:
Folder compare item count (and selected item) remains visible in main window statusbar
This is the bug reported? If so, I think this bug has been present as long as we've had multiple windows support. Seems nobody has reported it, and I've always forgot it myself...
The patch works, no doubt of that. But I think we'll want a bit different approach. I want one method/interface updating that statuspane, not that we set it from different places with different methods. Statusbar updating has some weird things in it in our current code and needs some refactoring.
So hmm.. I think this simple patch is good for 2.8 branch. It can't break anything. Can you just rename the mainframe method to "ClearStatusbarItemCount()". Yes, it is longer name, but tells what we are doing. And apply to 2.8 branch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I'm intending to do that refactoring + different fix once I have time. But it can take couple of weeks. So, ok, apply to trunk too so we have a fix there too. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=652377
Originator: NO
Problem is that MainFrm.cpp:m_wndStatusBar.PaneText(2) not get reset, if a windows get closed. The following code works for me, but I don't know if it is the correct/best way. Im still no C/C++ developer! ;)
Index: Src/ChildFrm.cpp
--- Src/ChildFrm.cpp (revision 5401)
+++ Src/ChildFrm.cpp (working copy)
@@ -540,6 +540,8 @@
{
// clean up pointers.
CMDIChildWnd::OnClose();
+
+ GetMainFrame()->ClearStatusNum();
}
void CChildFrame::OnSize(UINT nType, int cx, int cy)
Index: Src/DirView.cpp
===================================================================
--- Src/DirView.cpp (revision 5401)
+++ Src/DirView.cpp (working copy)
@@ -846,6 +846,8 @@
SaveColumnWidths();
+
+ GetMainFrame()->ClearStatusNum();
}
/**
Index: Src/MainFrm.cpp
===================================================================
--- Src/MainFrm.cpp (revision 5401)
+++ Src/MainFrm.cpp (working copy)
@@ -2025,6 +2025,12 @@
return old;
}
+// Clear the item count in the main status pane
+void CMainFrame::ClearStatusNum()
+{
+ m_wndStatusBar.SetPaneText(2, _T(""));
+}
+
/**
* @brief Generate patch from files selected.
*
Index: Src/MainFrm.h
===================================================================
--- Src/MainFrm.h (revision 5401)
+++ Src/MainFrm.h (working copy)
@@ -121,6 +121,7 @@
BOOL CreateBackup(BOOL bFolder, LPCTSTR pszPath);
int HandleReadonlySave(CString& strSavePath, BOOL bMultiFile, BOOL &bApplyToAll);
CString SetStatus(LPCTSTR status);
+ void ClearStatusNum();
void ApplyViewWhitespace();
void OpenFileToExternalEditor(LPCTSTR file);
void SetEOLMixed(BOOL bAllow);
Logged In: YES
user_id=631874
Originator: NO
Ok, but can you describe when and how the bug happens? By quick reading I understood that:
1) open folder compare of two folders
2) close the folder compare window, but not WinMerge, so that main window remains open
Expected:
Main window does not show folder compare item counts in statusbar
Actual:
Folder compare item count (and selected item) remains visible in main window statusbar
This is the bug reported? If so, I think this bug has been present as long as we've had multiple windows support. Seems nobody has reported it, and I've always forgot it myself...
The patch works, no doubt of that. But I think we'll want a bit different approach. I want one method/interface updating that statuspane, not that we set it from different places with different methods. Statusbar updating has some weird things in it in our current code and needs some refactoring.
So hmm.. I think this simple patch is good for 2.8 branch. It can't break anything. Can you just rename the mainframe method to "ClearStatusbarItemCount()". Yes, it is longer name, but tells what we are doing. And apply to 2.8 branch.
Logged In: YES
user_id=1749450
Originator: YES
You've understood the bug, I'll report even more specific the next time. I'll have a look at the patch when available through experimental build.
Logged In: YES
user_id=652377
Originator: NO
> And apply to 2.8 branch.
But Trunk too, or?
Index: Src/ChildFrm.cpp
--- Src/ChildFrm.cpp (revision 5405)
+++ Src/ChildFrm.cpp (working copy)
@@ -540,6 +540,8 @@
{
// clean up pointers.
CMDIChildWnd::OnClose();
+
+ GetMainFrame()->ClearStatusbarItemCount();
}
void CChildFrame::OnSize(UINT nType, int cx, int cy)
Index: Src/DirView.cpp
===================================================================
--- Src/DirView.cpp (revision 5405)
+++ Src/DirView.cpp (working copy)
@@ -846,6 +846,8 @@
SaveColumnWidths();
+
+ GetMainFrame()->ClearStatusbarItemCount();
}
/**
Index: Src/MainFrm.cpp
===================================================================
--- Src/MainFrm.cpp (revision 5405)
+++ Src/MainFrm.cpp (working copy)
@@ -2025,6 +2025,12 @@
return old;
}
+// Clear the item count in the main status pane
+void CMainFrame::ClearStatusbarItemCount()
+{
+ m_wndStatusBar.SetPaneText(2, _T(""));
+}
+
/**
* @brief Generate patch from files selected.
*
Index: Src/MainFrm.h
===================================================================
--- Src/MainFrm.h (revision 5405)
+++ Src/MainFrm.h (working copy)
@@ -121,6 +121,7 @@
BOOL CreateBackup(BOOL bFolder, LPCTSTR pszPath);
int HandleReadonlySave(CString& strSavePath, BOOL bMultiFile, BOOL &bApplyToAll);
CString SetStatus(LPCTSTR status);
+ void ClearStatusbarItemCount();
void ApplyViewWhitespace();
void OpenFileToExternalEditor(LPCTSTR file);
void SetEOLMixed(BOOL bAllow);
Logged In: YES
user_id=631874
Originator: NO
Well, I'm intending to do that refactoring + different fix once I have time. But it can take couple of weeks. So, ok, apply to trunk too so we have a fix there too. :)
Logged In: YES
user_id=652377
Originator: NO
Committed to SVN:
* In Revision 5419 (Trunk)
* In Revision 5420 (Branch R2_8)
Logged In: YES
user_id=631874
Originator: NO
Sorry, forgot to assign this item.
Anyway, closing as it is already fixed in SVN.