As described here:
http://forums.codeblocks.org/index.php/topic,18580.msg128907.html#msg128907
and here:
http://forums.codeblocks.org/index.php/topic,19652.msg134219.html#msg134219
The IDE seems to have a problem with the file itself and not the path, because if I copy the file to another path and add it to the project, it also cannot open the copy. A zipped copy of the file is available here:
http://www.mediafire.com/download/sdnbmgggd9m7duc/alogg.zip
Diff:
I tried it out in the latest nightly (Jan 17, 2015) and it still occurs. Is there any more information I can provide to help?
Works here on Linux and English locale.
Do you have to add the file to the project to reproduce the problem?
Does this file open correctly in notepad++ and scite?
CodeBlocks exhibits this problem regardless of whether that source file is in the active project. The file displays correctly in EditPad Lite, Windows notepad and Notepad++.
Even if I add a new, blank file into the project and copy the content of that file from an external text editor into CodeBlocks, save and close that new file, the file is displayed blank if I try to open it again. This happens even if I save it as a different file name to the root of the source directory. It doesn't seem to be any problem with the file's encoding or the file path, but a problem with how Codeblocks handles the file's content?
What happens if you start binary searching which part of the file breaks it?
I'm sorry, I don't understand your question. Can you clarify what you want me to try? Did you want me to try copying parts of the source file in to find the particular part of the text content that causes CodeBlocks to no longer display it?
Yes, this is what I mean.
1. Delete the second half of the file
2. Open it in cb, if it fails goto step 1
3. Restore the file and delete first half
4. Open it in cb, if it fails goto step 1
I tracked the problem down to line 5, which credits Javier Gonzáles as the author of Allegro OGG. A hex editor shows the accented a using extended ASCII value 160, which is what I expected should work, but that character does not display correctly in any text editor, or even a web browser on another computer running Windows in a standard EN-US locale. Maybe it's one of those Windows issues where it uses the extended ASCII range for other things. That character just shows up as a space.
If I change just that one character, the file will then display in CodeBlocks. If I copy that accented character (á) off of a web page and paste that into the file, CodeBlocks will still re-open it.
I guess at this point it would be worth checking why CodeBlocks has problems displaying the file at all even if it's just one ASCII character it doesn't like. All other programs I've tried will at least display the rest of the file.
Well it works for me on Windows, in the logs I see:
Mozilla universal detection engine detected 'Pure ASCII'.
Final encoding detected: Windows Western European (CP 1252) (ID: 33)
Conversion succeeded using wxEncodingConverter (buffer size = 39904, converted size = 39908.
Is this platform related???
I don't know if it's platform related or not. Opening the file in Firefox 35.0 on Windows caused the accented character in question to display as a space (or otherwise a non printable, blank character). It displays the same in WordPad, and it won't display the accented character in Word 2010 unless I tell the file conversion wizard to treat it as MS-DOS encoding.
Can you show us a screenshot of your regional settings?
Here are some screenshots:
http://i15.photobucket.com/albums/a354/raynebc/region%20settings_zpsevf75zo0.jpg~original
Photobucket's a pain, so I'm attaching the picture here as well.
What is written in your log when you open the file? Run C::B with the --debug-log command line option.
I'm attaching the debug logs. It looks like if a non English language locale is used, C::B has trouble figuring out how to handle that one extended ASCII character and aborts loading the entire file.
In SVN 12814 the file with the accented (a with a ', hex 0xA1) loads and displays correctly on Windows 10 and Ubuntu 22.04. Screen capture on Win10 attached.
So looks like it's been fixed at some stage.
Therefore this can be closed.
Yet another ticket that can IMHO be closed based on previous posts above.
If someone comes back to say the issue still exists then this ticket can be re-opened or a new ticket can be created.
Yet another ticket that can IMHO be closed based on previous posts above.
If someone comes back to say the issue still exists then this ticket can be re-opened or a new ticket can be created.
Try #2!