"file updated" dialogue bug

[jarro_2783]

When a file is updated outside of codeblocks and the dialog box which asks if I want to reload the file comes up, I can hardly click the yes button because the dialog isn't tall enough.
I'm using wxGTK 2.8.4 and svn revision 4596.

[thomas]

Hmm... unless I am very, very, very mistaken, this is using a plain vanilla standard dialog box.

Thus, if the dialog is too small, there must be a problem with your GTK thingie..? We don't do anything really, only call the wxWidgets function which calls the respective OS function.

[jarro_2783]

I'm using gtk 2.10.14 which is the latest that the fedora 7 repository has, and wxGTK 2.8.4 which I compiled myself.
The height of the box seems fixed, when my file names are long enough, the text takes up more room and it pushes the buttons even further out of the dialog box. I also can't resize it.

[JGM]

I'm using gtk 2.10.14 which is the latest that the fedora 7 repository has, and wxGTK 2.8.4 which I compiled myself.
The height of the box seems fixed, when my file names are long enough, the text takes up more room and it pushes the buttons even further out of the dialog box. I also can't resize it.

Try putting your project files into a less deep path, For example: /home/ProjectFiles or testing with shorter file names

[jarro_2783]

Some of the time I can see about half of the buttons. Other times when the path is longer I can see the top three pixels of the buttons.

My paths are kind of long too (/home/jarryd/programming/programs/prjfreedom/src/engine/engine.cpp for example), but the dialog should be able to resize itself shouldn't it.

[thomas]

Just looked what we do there. It's using a wxMessageDialog which should "know" the correct size. Additionally, the dialog may be centered on the main window (if you have enabled the smart placing feature), which again only calls the standard wxWidgets CentreOnWindow function under all non-Windows platforms.

The only time the dialog's size can modified at all is if you have enabled the smart placement functionality in constraint mode, and if your screen is so small that the dialog would not fit. However, you cannot even do that any more, since someone removed this option from the settings panel 

So... clueless as to what happens there with you.

[dmoore]

I have also had this problem on ubuntu feisty

[jens]

The following patch fixes the bug.

Code: [Select]

--- codeblocks-1.0svn.orig/src/sdk/resources/confirm_replace.xrc        2007-09-28 13:55:10.000000000 +0000
+++ codeblocks-1.0svn.work/src/sdk/resources/confirm_replace.xrc        2007-11-06 13:28:21.000000000 +0000
@@ -12,6 +12,7 @@
         </object>
         <flag>wxALL|wxGROW</flag>
         <border>8</border>
+        <option>1</option>
       </object>
       <object class="sizeritem">
         <object class="wxBoxSizer">
--- codeblocks-1.0svn.orig/src/sdk/resources/confirm_replace_multiple.xrc       2007-09-28 13:55:10.000000000 +0000
+++ codeblocks-1.0svn.work/src/sdk/resources/confirm_replace_multiple.xrc       2007-11-06 13:31:14.000000000 +0000
@@ -11,6 +11,7 @@
         </object>
         <flag>wxALL|wxGROW</flag>
         <border>8</border>
+        <option>1</option>
       </object>
       <object class="sizeritem">
         <object class="wxBoxSizer">

I added the line "<option>1</option>" to "confirm_replace_multiple.xrc" also, eve if it is not used by the fileupdate-Dlg, to make both behave identical.

If you confirm the patch, I can post it at berlios.

On windows the problem with extremly long file-name (-paths) is different, because the line is not wrapped there, and a part of it get cut by the Dialog-Border.

[thomas]

The following patch fixes the bug.

Are you sure? The "reload file?" box uses no xrc at all.
Your patch seems to address something different (search/replace). Apparently those dialogs are too small on our system too?

[jens]

The following patch fixes the bug.

Are you sure? The "reload file?" box uses no xrc at all.
Your patch seems to address something different (search/replace). Apparently those dialogs are too small on our system too?

Yes, I'm sure !
The "cbMessageBox" is used when a file is deleted or moved :

editormanager.cpp (line 988s to 992)

Code: [Select]

            msg.Printf(_("%s has been deleted, or is no longer available.\n"
                         "Do you wish to keep the file open?\n"
                         "Yes to keep the file, No to close it."), ed->GetFilename().c_str());
            if (cbMessageBox(msg, _("File changed!"), wxICON_QUESTION | wxYES_NO) == wxID_YES)
                ed->SetModified(true);

If a file gets modified outside the editor, this code is used :

editormanager.cpp (lines 1036 to 1038)

Code: [Select]

                msg.Printf(_("File %s is modified outside the IDE...\nDo you want to reload it (you will lose any unsaved work)?"),
                           ed->GetFilename().c_str());
                ConfirmReplaceDlg dlg(Manager::Get()->GetAppWindow(), false, msg);

The bug (I think it is a bug) only happens for me if I use very long file-/pathnames. I tested it.
The code with the "cbMessageBox" works for me, even with really deep nested paths.

[thomas]

Yes, I'm sure !
The "cbMessageBox" is used when a file is deleted or moved

Yes, that is what I'm saying... it does not use XRC at all. cbMessageBox calls wxMessageDialog (which, again, does not use XRC). So I am confused how this can be fixed by a patch to an XRC file.

[jens]

Yes, I'm sure !
The "cbMessageBox" is used when a file is deleted or moved

Yes, that is what I'm saying... it does not use XRC at all. cbMessageBox calls wxMessageDialog (which, again, does not use XRC). So I am confused how this can be fixed by a patch to an XRC file.

It can be fixed, because the "file updated"-dialog does not use "cbMessageBox", but "ConfirmReplaceDlg" !
That's what I posted :

If a file gets modified outside the editor, this code is used :

editormanager.cpp (lines 1036 to 1038)

Code: [Select]

                msg.Printf(_("File %s is modified outside the IDE...\nDo you want to reload it (you will lose any unsaved work)?"),
                           ed->GetFilename().c_str());
                ConfirmReplaceDlg dlg(Manager::Get()->GetAppWindow(), false, msg);

The bug (I think it is a bug) only happens for me if I use very long file-/pathnames. I tested it.
The code with the "cbMessageBox" works for me, even with really deep nested paths.

[MortenMacFly]

It can be fixed, because the "file updated"-dialog does not use "cbMessageBox", but "ConfirmReplaceDlg" !

This is not a good solution at all. This dialog has nothing to do with the content you want to use it with. The issue here is that the filename is in the title bar of the dialog (cbMessageBox). This is very bad as the dialog cannot wrap a single-line label. The solution I'd propose is plain simple:
Put the filename in the message box content and (maybe) remove or at least shorten the path. That's it.
With regards, Morten.

[jens]

It can be fixed, because the "file updated"-dialog does not use "cbMessageBox", but "ConfirmReplaceDlg" !

This is not a good solution at all. This dialog has nothing to do with the content you want to use it with. The issue here is that the filename is in the title bar of the dialog (cbMessageBox). This is very bad as the dialog cannot wrap a single-line label. The solution I'd propose is plain simple:
Put the filename in the message box content and (maybe) remove or at least shorten the path. That's it.
With regards, Morten.

First: I don't have any problems with long file-/pathnames.
But the OP has.

Second: the dialog is not used by me, it is original C::B-code. I think it might be because of the "All"-button.

Third: on linux the filepaths are wrapped at the "/", on W2K (I did not try on XP) the paths are not wrapped (maybe because  of the "\").

Fourth: where is the problem? The "<option>1</option>" makes the wxStaticText-control vertical stretchable. This only happens if the content does not fit in it and this is what I would suggest.

I still think it is a good solution as long as "ConfirmReplaceDlg" is used.

[MortenMacFly]

I still think it is a good solution as long as "ConfirmReplaceDlg" is used.

I'm sorry, but within the content we are talking about this is not an option.

Edit: For clarification: Hijacking foreign dialogs and mis-using them within a foreign content is no good.