User forums > General (but related to Code::Blocks)

"file updated" dialogue bug

<< < (3/5) > >>

thomas:

--- Quote from: jens on November 07, 2007, 09:58:04 am ---Yes, I'm sure !
The "cbMessageBox" is used when a file is deleted or moved
--- End quote ---
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.

Jenna:

--- Quote from: thomas on November 07, 2007, 10:20:27 am ---
--- Quote from: jens on November 07, 2007, 09:58:04 am ---Yes, I'm sure !
The "cbMessageBox" is used when a file is deleted or moved
--- End quote ---
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.

--- End quote ---

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

--- Quote from: jens on November 07, 2007, 09:58:04 am ---If a file gets modified outside the editor, this code is used :

editormanager.cpp (lines 1036 to 1038)

--- Code: ---                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);

--- End code ---

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.

--- End quote ---

MortenMacFly:

--- Quote from: jens on November 07, 2007, 10:34:23 am ---It can be fixed, because the "file updated"-dialog does not use "cbMessageBox", but "ConfirmReplaceDlg" !

--- End quote ---
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.

Jenna:

--- Quote from: MortenMacFly on November 07, 2007, 10:51:57 am ---
--- Quote from: jens on November 07, 2007, 10:34:23 am ---It can be fixed, because the "file updated"-dialog does not use "cbMessageBox", but "ConfirmReplaceDlg" !

--- End quote ---
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.

--- End quote ---

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:

--- Quote from: jens on November 07, 2007, 11:18:38 am ---I still think it is a good solution as long as "ConfirmReplaceDlg" is used.

--- End quote ---
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version