Index: src/sdk/filemanager.cpp
===================================================================
--- src/sdk/filemanager.cpp (revision 5986)
+++ src/sdk/filemanager.cpp (working copy)
@@ -341,14 +341,16 @@
default:
break;
}
+
+ if(f.Write(mark, mark_length) != mark_length)
+ return false;
}
- if(f.Write(mark, mark_length) != mark_length)
- return false;
-
- if(data.length() == 0)
+ if (data.length() == 0)
return true;
+#if defined(UNICODE) || defined(_UNICODE)
+
size_t inlen = data.Len(), outlen = 0;
wxCharBuffer mbBuff;
if ( encoding == wxFONTENCODING_UTF7 )
@@ -443,4 +445,11 @@
}
return f.Write(buf, size);
+
+#else
+
+ // For ANSI builds, dump the char* to file.
+ return f.Write(data.c_str(), data.Length()) == data.Length();
+
+#endif
}
History
Well, I must say I quite dislike the "project management" part of codeblocks - bug reports are ignored, not much feedback and no releases...
(Not telling this to make people angry - these are just the main problems of codeblocks I see right now - unfortunately I can't post a patch to fix this...)
Anyway, here is a fix for the bug - since ansi is default when compiling wxGTK, the first experience one gets with codeblocks is that it doesn't compile...
> bug reports are ignored
...which one in particular?
Well, in the bug tracker I just see many bug reports with no response and for instance this bug (16076) was reported by me 4 months ago, clearly indicating the commit where the compilation regressed + I have also suggested what's wrong -- and still no fix (and no feedback). I think that the more people are involved in a project, the better the project becomes (more bug reports, more contributors). Seeing no response might be a bit discouraging the users as well as not seeing any regular releases (ordinary users just see the last release 8.02 and think the project is kind of dead).
I can understand what you mean and agree. Hence the team is very busy atm as we all have families and jobs to be done, too. Help from the community is taken and a lot contributions are incorporated (have a look at the log). Probably it sounds weired, but the bug tracker may not be the best place for a rerport. As we (the admins) need to read the forums anyways (for legal reasons in our countries) a report in the forums has a higher priority. I for myself hardly find the time to follow the bug tracker. Only every 10th report is relevant / correct anyways (my personal experience). So - next times start with the forums first. In addition as you see: Patches have higher priotitiy, too. That's the BEST (!!!) way people / the community can help.
Sure, I completely understand that you are busy and can't spend so much time with codeblocks (something I'm fighting with myself as well - even though I have several ideas how to fix some annoyances I'm experiencing with codeblocks, right now I don't have time to do it). But at the same time, this is _exactly_ the thing where I don't understand the way codeblocks is developed - you should use the tools that make your work as efficient as possible. Please take the following points as ideas for improving the process codeblocks is developed rather than a criticism from a guy who believes he knows best how to do things:
1. Bugtracker serves for tracking bugs. Sure, most of the "bugs" will be just garbage coming from users who don't know how to use the software (I've seen the "bugs" in the bugtracker of codeblocks and agree with you). However, these bugs can be immediately marked as invalid so the developers will see real bugs only and concentrate on them. I think there are much less than 365 bugs a year for codeblocks and if all of them are garbage, closing one bug report a day isn't much work I think. And I really doubt that you are able to keep track of every bug reported on the forum - you just forget about some if you don't have time to fix them immediately (for instance, I haven't received any answer about the performance problem when loading boost library sources in codeblocks).
On the other hand, the bug tracker offered by berlios is really poor. I would recommend using trac (or similar tool) - I have very good experience with it and it can server as a wiki + revision tracker at the same time so users can see that the project isn't dead.
2. Forums are great for users, but not very good for developers because of their non-linear nature so you can't be sure that the other developers read the same posts as you and you can easily overlook some posts as well. This, however, doesn't happen with mailing lists (something that codeblocks lacks badly IMO) which are much superior for developers IMO. I would also say that 90pct of posts on the forum is just a garbage - lots of LOLs, OMGs, ROFLs without much contents + stupid questions of newbies. But if you have a forum, where advanced users help to the newbies and a mailing list, where the development questions are being discussed, you save a lot of time by not having to read the stupid posts because they get answered by other users. And if they don't know or think that there is a bug, they'll make a report in bugtracker so you'll be informed about the problem or feature request. (I don't mean that you should completely lose the contact with the users, but your presence in the forum should be the "bonus part" while reading the bug tracker and mailing list the "mandatory part" of developer's work and not vice versa.)
3. Usage of distributed version control system (mercurial, git) could save a lot of time as well. Myself I have experience with git only, but mercurial might be a better choice for codeblocks as it supports Windows better than git. For git, there is a great web service at http://gitorious.org where you can easily branch the mainline, make your changes and request re-merge with the trunk again (I expect there is something similar for mercurial as well). This is really MUCH superior (both for project admins and contributors) to the patches you have to keep track of manually (this feature of berlios really doesn't belong among the best technological achievements). And merges with distributed VCSs are a piece of cake. Having an easy way to submit patches attracts more developers so there will be more people fixing the software.
And finally, when you know what bugs there are, when it is easy for developers to submit their patches and when you have more time because most things will work just automatically, all the effort can result in
REGULAR RELEASES
(watch how beautiful it sounds and repeat these two magical words before you fall asleep :-)