BlackDoc documentation plugin

[marked]

Hi! I'm new here, so, firstly, thanks to the C::B team for the great IDE!

I want announce the plugin I am creating. This is the documentation generator, but it generates the documentation not from the source code comments, but from text files, which are separated from sources. These files can be written using the wiki-style markup language. Currently, the plugin supports only the output to HTML. This plugin may also be used not only for documentation purposes, but it was the main goal of creating it.

The very first usable version of BlackDoc is available.

I uploaded this project to Google Code, here is the link to the project page: http://code.google.com/p/blackdoc/
Source code versions are managed using Mercurial (hg): http://code.google.com/p/blackdoc/source/checkout

Also, here is the large description of this plugin, the page was generated by the plugin itself, without any additional changes: http://blackdoc.googlecode.com/hg/documentation/html/help/description-en.html

Plugin was written using C::B svn7899 version, C::B SDK 1.11.18, Linux Mint Debian Edition. It is also necessary to use the c++0x compiler flag.

Currently I need some feedback/testing/bugreports etc. And it would be pleasant, if someone could test the plugin on windows, and, maybe, on Mac.

Sorry for errors, my English is still not good enough.

edit: some misleading info was corrected

[MortenMacFly]

Sounds interesting, but I don't get it compiled at all. The compiler freaks out completely. I am using TDM's GCC 4.6.1 but even with or without the C++11 compiler flag - no way. If you provide a working Windows version I guess you'll reach a broader audience - it should really be cross-platform. (I've made myself windows project files btw.)

Why do you need C++11? Is is only due to random numbers, or any more constraints? You put hard requirements here that might not be needed I think...

[oBFusCATed]

Random numbers are present in TR1...

@marked:
1. You don't need the .depend file in the VCS, it is created automagically...
2. Can you add an autotools build system?
    You can use the plugins at svn://cmpt.benbmp.org/cb_gdb_mi/debbugger_gdbm and svn://cmpt.benbmp.org/cb_editor_navigation
    to see how can you do it, if you are not that familiar with autotools.

[marked]

@MortenMacFly
Sorry for the misleading, that was c++0x flag actually. But on Windows, as I know, it is necessary to use the gnu++0x flag.

I used the std::unique_ptr and some nice features like "delete" to disable copy-ctor and also the "auto" keyword instead of writing the full iterator type.

I don't have windows installation right now, and no free space on my hard-drive to install it actually, so providing the windows version by me is a little bit difficult. Ok, maybe, when ubuntu 12.04 will be released, I'll try to install them both instead of LMDE...

@oBFusCATed
1) Removed.
2) Yes, you are right, I'm not familiar with autotools. I'll give it a go, but... is it really necessary? Why just not to build C::B using C::B?

svn claimed the first link as non-existant, the second worked.

[ollydbg]

svn claimed the first link as non-existant, the second worked.

The first svn address is:

Code

svn://cmpt.benbmp.org/cb_gdb_mi/debbugger_gdbmi

[marked]

@ollydbg
Thank you, this worked.

[MortenMacFly]

@MortenMacFly
Sorry for the misleading, that was c++0x flag actually. But on Windows, as I know, it is necessary to use the gnu++0x flag.

I figured that out myself... ;-) However - it does simply not compile under Windows at all. I've attached by project file for those willing to try.

BTW: you don't necessarily need to install Windows - cross compilation from Unix to Windows using MinGW works just fine (unfortunately this is not true for cross compiling from Windows to Linux).

[oBFusCATed]

2) Yes, you are right, I'm not familiar with autotools. I'll give it a go, but... is it really necessary? Why just not to build C::B using C::B?

In order to have a way to manage your OS install in the long run?
Keep in mind that some people use nightlies, thus the API is not stable and when you upgrade your C::B you have to recompile all the plugins.
If autotools is working making packages for the main distros is pretty simple.

p.s. If you really want this plugin to be used by more people you'll have to remove all the c++11 parts and make the project compilable by gcc4.1.2
(the main compiler for centos/redhat <6 on centos/redhat>6 you have gcc-4.4).

[marked]

@oBFusCATed
I added the bootstrap, configure.ac and Makefile.am to the project. Suddenly, I can't test them, because I am missing AM_OPTIONS_WXCONFIG, AM_PATH_WXCONFIG, maybe something else too. So they are untested and may be wrong. I think, I will not be able to test them in the near future.

No, sorry, I think, I will never understand people, who prefer to build something from sources/via command-line instead of using the GUI. I'll better stop to discuss this.

As of removing c++11 code... I like C++11. Of course I want people to use this plugin, but if I need to support old compilers... Really, I don't know, I need a time to think about this.

@MortenMacFly
This is not a big problem for me to install Windows. Maybe, I will do this next weekend. But then I will need to build the C::B from sources...

[oBFusCATed]

marked: Do you have wxgtk-devel/dev packages?

Unfortunately c++11 is unusable in large open source projects at the moment.

See here how to link to a nightly build on windows: http://wiki.codeblocks.org/index.php?title=Linking_the_plugin_to_a_Nightly_Build

[Alpha]

As of removing c++11 code... I like C++11. Of course I want people to use this plugin, but if I need to support old compilers... Really, I don't know, I need a time to think about this.

I would think that it is not necessary to completely remove it; only supply a build-able (if somewhat less functional) version for those who cannot or do not want to enable C++11.

Code

#ifdef __GXX_EXPERIMENTAL_CXX0X__

#else

#endif

Attached is a cbp to build this plugin on Windows.

[oBFusCATed]

Alpha, I doubt he can make a buildable versions without std::unique_ptr and why bother maintaining two versions...

p.s. People should be shot when they use internal gcc definitions!

[Alpha]

Alpha, I doubt he can make a buildable versions without std::unique_ptr and why bother maintaining two versions...

Hmm, I probably should have actually looked at the source before suggesting that.

p.s. People should be shot when they use internal gcc definitions!

I guess that means I need to go into hiding now .  *Puts on black sunglasses.*

[marked]

@oBFusCATed
Ok, I got it. The wxgtk-devel isn't available by me from repos. But I have read somewhere, that I need only the wxwin.m4 file. So, I downloaded the wxgtk-devel rpm-package with the version near to the wxWidgets version I have installed, and then I just copied the wxwin.m4 from it to /usr/share/aclocal/ folder. And it worked. Now the plugin can be built and installed using autotools. The sources on googlecode are already updated.

The gnu++0x flag is now also added to the cbp too, instead of c++0x.

Thanks for the link, I will add it to my bookmarks.

@Alpha
Yes, I think that I need just to rewrite the unique_ptr class 'by hand'. As oBFusCATed pointed me, the random numbers are available in tr1. And as of other features I have used  - it is simple to replace them with the 'old' C++ code.

As I understand, the plugin is nevertheless buildable on WIndows?

[Alpha]

As I understand, the plugin is nevertheless buildable on WIndows?

Yes; compiled and tested on XP with the project file from my previous post.

[MortenMacFly]

Yes; compiled and tested on XP with the project file from my previous post.

But only, if hijacking the PCH chain.

To be correct: It would need some patches to work, but these are mainly missing includes. So nothing to worry about.

However, what I aalso noticed:

you are using wxString but then you are doing something like this:

Code

    // const wxString &data is defined
    size_t pos = data.find(m_pathsSeparator);
    if(wxNOT_FOUND == pos)

For a better style you should rather not use the STL version of find() but the wx one wxString provides. Especially if you compare with a wx constant (wxNOT_FOUND) afterwards. Either all wx or all STL...

[oBFusCATed]

The correct code (I think) is:

Code

wxString::size_type pos=str.find(...);
if (pos==wxString::npos) {
   ....
}

[MortenMacFly]

The correct code (I think) is:

Code

wxString::size_type pos=str.find(...);
if (pos==wxString::npos) {
   ....
}

True, if you insist on using the STL compatibility layer of wxString. But then again why using wxString at all? If wxString is not needed, STL string will surely perform better.

Edit: BTW: I though more in a direction of wxString::Contains(...) or alike.

[oBFusCATed]

http://docs.wxwidgets.org/stable/wx_wxstring.html#wxstringcontains

[marked]

Things turned even simpler: i just replaced the std::unique_ptr with the 'old bad' std::auto_ptr.

The use of gnu++0x flag is no more necessary. Sources are updated. Please, test them again. I hope, old GCC will be happy

MortenMacFly:
Yes, thank you for finding this mistake. I was changing the code to work the stl way and I've forgot some wxNOT_FOUND's. Now they are replaced in the way oBFusCATed suggested.

I deal with wxString the stl way wherever it is possible, because wxWidgets help is proposing this, for future compatibility etc. It is pointed exactly at the top of this doc
http://docs.wxwidgets.org/stable/wx_wxstring.html

Contains() returns the bool value, and in most cases I later need the start position of occurance to obtain substring.

[Jenna]

On wx-dev they recommend to use std::string wherever possible, and use wxString only to interact with the gui.

In general, my advice is very simple: do *not* use wxString for textual
manipulation. Use std::string or std::wstring for this and only use
wxString to get data to or from the GUI.

[MortenMacFly]

On wx-dev they recommend to use std::string wherever possible, and use wxString only to interact with the gui.

That's what I meant: either only STL or only wxString.

Mmmh... am I missing something here? Is there really a wx recommendation to use the STL methods of wxString instead of the wx ones? Can somebody enlighten me on this?

[marked]

The use of std::string instead of wxString will increase the time of development, because std::string is missing some nice methods, like StartsWith/EndsWith, Replace(char* old, char* new, bool all = true) etc. It then will be necessary to implement this operations in my code. C::B SDK also wants wxString, so I decided to use it.

Also it is not very clear, how to add the support for unicode and non-unicode builds of wxWidgets while using std::string and std::wstring. Dealing with locales and convertions between them is a little bit tricky.

@MortenMacFly
I know only what I mentioned above. Here is the quote from wxString help page: "You may notice that wxString sometimes has many functions which do the same thing like, for example, Length(), Len() and length() which all return the string length. In all cases of such duplication the std::string-compatible method (length() in this case, always the lowercase version) should be used as it will ensure smoother transition to std::string when wxWidgets starts using it instead of wxString."

[MortenMacFly]

In all cases of such duplication the std::string-compatible method (length() in this case, always the lowercase version) should be used as it will ensure smoother transition to std::string when wxWidgets starts using it instead of wxString."

This is really new to me. I really can't believe there will be a day without wxString. This would literally affect every wx application on earth!

An btw, Jens:

On wx-dev they recommend to use std::string wherever possible, and use wxString only to interact with the gui.

If you read further there is an answer of Julian Smart:

This is possibly the scariest thing I've heard in 2012 so far. I use
wxString *extensively* for data storage and manipulation. All the time,
for almost every class I ever write.
[...]
Am I mad to be using wxString? Well, it's a bit late now that's for sure...

I clearly share his thoughts.

Edit: Well, having said that I continued to read how VZ is arguing against that... interesting. I didn't expect such a "battle" on one of these core classes of wxWidgets to be honest.

So well, still: If you are with VZ you should only use std::string and not mixed. ;-)

But we shouln't continue on that an longer as IMHO everything has been said (and I learned something new). Back to the topic: lets talk about the plugin.

[Jenna]

So well, still: If you are with VZ you should only use std::string and not mixed. ;-)

The problem is, that many users find wxString in wx2.9 much slower as in 2.8.

That might be (and is most likely) the cause for the much slower cc with wx2.9.

[marked]

Ok, I am still waiting for some feedback about bugs and mistakes. Also feedback about autotools files I've added to the project will be very pleasant, just to be sure they work not only by me.

Now some ideas for the future to discuss.

The next large thing I want to implement in my plugin is the generation of help skeleton from C++ sources. This means, the plugin will parse project sources (maybe also doxygen comments) and then create BlackDoc files with appropriate names taken from classes/others names and fill this files with the info about class members etc. I need to do some research here: parsing the C++ code isn't simple because of preprocessor directives, and C++0x makes things even more scary. So this step may take time. This is only one more thing I really need from this plugin.

Several other ideas, I don't promise to create this all:
- BlackDoc project wizard to be able to create separate documentation project.
- 'Create BlackDoc file' item in the context menu, when you right-click over some name in the source code.
- Some text patterns which can be chosen while creating the BlackDoc file, for example 'class documentation file', 'namespace documentation file' etc.
- Export to other formats. At least *.chm is necessary, I think.
- Lists and tables with multiline items in the wiki-style lang.
- When the BlackDoc file is opened, some right-click or app menu features, like 'add current date', 'add table' etc.
- Maybe also the markup language highlighting, but is it possible without patching scintilla?
- Some other ideas?

[killerbot]

wxwidgets in relationship to stl is a strange to my personally.
A few distro versions ago (I am using Opensuse) I couldn't build CB anymore. Why, the default wx library and dev files were the stl variant; and no longer the wxcontainer version. Switching to the wxcontainer version solved it.
Confusing is the least we can say.

If the language provides it, I would always prefer the language instead of abstractions like boost, wxwidgets, poco, qt.
Wxwidgets and qt, and poco add more functionality to their string classes for example, things lacking in the stl variant.
But enhancing the stl variant with for example boost string algo library brings nearly the same thing.
Nice thing about this : it is extending the stl string not replacing or reinventing the wheel.
But this is offcourse a matter of taste.

With respect to the C++0x, I am 100% in favor for using it, I think the compilers mostly used for building CB are gcc, and to some extend MSVC. Gcc is really taking the C++0x lead, and MSVC is not that far behind. That's the good news, .... the bad news we want to support distros with older gcc versions.
As has been mentioned as an example CentOS.
Here again I express my personal feeling, I have been running into CentOS and have been wishing it not so pleasant things ;-) . I know people want it to be stable, but its packages are so darn old, that it makes me turn into a synical mood and I want to suggest windows 3.11 to those users ;-)
Just kidding, but personal taste.

Waiting another 3 - 5 years before really using C++0x, I am sorry, that's what the C++ community can do without, we want things to move on, and we all hope to have another standard in 5 years (file system ? sockets ? string algorithm ,....).

Today is surely to soon to switch and put some people out in the cold, but we need to think about it and after the next CB release (whenever that might be ;-) ) we should consider putting it on the roadmap). By theway, that would be good for Centos, they can stick with that release of CB for like 20 years , to bad for the developer that wants to build CB him/her self on Centos 

As for a new plug-in, I think the plug-in developer should be allowed to use C++0x, meaning his plug-in wil probably never been promoted to a contrib plugin in our repository, unless we have makefiles, projects files that might determine that there's no C++0x support and then disables that specific plug-in from the build being carried out at hand.

As another brain teaser :  keep waiting on wxwidgets to move on, no thanks. Their 3.0 is even getting ready at a slower pace then the C++0x standard took  .
And if you want to talk about a platform breaking code with every release , yes .. wxwidgets.

[oBFusCATed]

Unfortunately, if you want to use a linux to write plugins for other commercial software products as I do (Autodesk Maya and  Katana/Nuke by The Foundry in my case), you have to stick to the compilers they have been build with and the easiest option to do so is to use the distro and version they have being built on.
In my case Centos 5.6. I don't like Centos, nor do I like yum/rpm, but this is the easiest option and the most secure one in terms of compatibility.

[ollydbg]

So well, still: If you are with VZ you should only use std::string and not mixed. ;-)

The problem is, that many users find wxString in wx2.9 much slower as in 2.8.

That might be (and is most likely) the cause for the much slower cc with wx2.9.

Off thread question:
Do we need to fix the string type std::string<char> or std::string<wchar_t> in CodeCompletion plugin? A lot of the parsing work is text/buffer manipulation. Also when we need to do the GUI part, we can translate to wxString.

Another thing is: if the part buffer char type is fixed. I can use more extreme fast lexer like QUEX or FLEX. The Current Tokenizer is quite limited.

[Alpha]

Yes; compiled and tested on XP with the project file from my previous post.

But only, if hijacking the PCH chain.

Is this the proper way to do it?

Code

diff -r e8000aa19e1c BlackDoc-win.cbp
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/BlackDoc-win.cbp	Mon Apr 23 20:39:43 2012 -0400
@@ -0,0 +1,143 @@
+<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
+<CodeBlocks_project_file>
+	<FileVersion major="1" minor="6" />
+	<Project>
+		<Option title="BlackDoc" />
+		<Option pch_mode="2" />
+		<Option compiler="gcc" />
+		<Build>
+			<Target title="default">
+				<Option output="blackdoc" prefix_auto="1" extension_auto="1" />
+				<Option object_output="objs" />
+				<Option type="3" />
+				<Option compiler="gcc" />
+				<Option parameters="--debug-log --multiple-instance -na -ns -nd" />
+				<Option host_application="$(#cb)\devel\codeblocks.exe" />
+				<Option run_host_application_in_terminal="0" />
+				<Compiler>
+					<Add option="-g" />
+					<Add option="-pipe" />
+					<Add option="-mthreads" />
+					<Add option="-fmessage-length=0" />
+					<Add option="-fexceptions" />
+					<Add option="-Winvalid-pch" />
+					<Add option="-DBUILDING_PLUGIN" />
+					<Add option="-DHAVE_W32API_H" />
+					<Add option="-D__WXMSW__" />
+					<Add option="-DWXUSINGDLL" />
+					<Add option="-DcbDEBUG" />
+					<Add option="-DCB_PRECOMP" />
+					<Add option="-DWX_PRECOMP" />
+					<Add option="-DwxUSE_UNICODE" />
+					<Add directory="$(#cb)\include" />
+					<Add directory="$(#cb)\sdk\wxscintilla\include" />
+					<Add directory="$(#WX.include)" />
+					<Add directory="$(#WX.lib)\gcc_dll$(WX_CFG)\msw$(WX_SUFFIX)" />
+				</Compiler>
+				<Linker>
+					<Add option="-Wl,--enable-auto-import" />
+					<Add option="-mthreads" />
+					<Add library="wxmsw28$(WX_SUFFIX)" />
+					<Add library="codeblocks" />
+					<Add directory="$(#cb)\devel" />
+					<Add directory="$(#WX.lib)\gcc_dll$(WX_CFG)" />
+				</Linker>
+				<ExtraCommands>
+					<Add after="zip -j9 blackdoc.zip manifest.xml styles.css" />
+					<Add after="zip -j9 blackdoc.cbplugin blackdoc.dll blackdoc.zip" />
+					<Mode after="always" />
+				</ExtraCommands>
+			</Target>
+			<Environment>
+				<Variable name="WX_CFG" value="" />
+				<Variable name="WX_SUFFIX" value="u" />
+			</Environment>
+		</Build>
+		<VirtualTargets>
+			<Add alias="All" targets="default;" />
+		</VirtualTargets>
+		<Compiler>
+			<Add option="-Wall" />
+		</Compiler>
+		<Unit filename="Directory.cpp" />
+		<Unit filename="Directory.h" />
+		<Unit filename="ErrorMessage.cpp" />
+		<Unit filename="ErrorMessage.h" />
+		<Unit filename="FileCreationDialog.cpp" />
+		<Unit filename="FileCreationDialog.h" />
+		<Unit filename="FileSignature.cpp" />
+		<Unit filename="FileSignature.h" />
+		<Unit filename="FilesHandler.cpp" />
+		<Unit filename="FilesHandler.h" />
+		<Unit filename="HTMLActiveFileExporter.cpp" />
+		<Unit filename="HTMLActiveFileExporter.h" />
+		<Unit filename="HTMLActiveProjectExporter.cpp" />
+		<Unit filename="HTMLActiveProjectExporter.h" />
+		<Unit filename="HTMLBranchIndexBuilder.cpp" />
+		<Unit filename="HTMLBranchIndexBuilder.h" />
+		<Unit filename="HTMLContent.cpp" />
+		<Unit filename="HTMLContent.h" />
+		<Unit filename="HTMLDocument.cpp" />
+		<Unit filename="HTMLDocument.h" />
+		<Unit filename="HTMLExporter.cpp" />
+		<Unit filename="HTMLExporter.h" />
+		<Unit filename="HTMLFilesCreator.cpp" />
+		<Unit filename="HTMLFilesCreator.h" />
+		<Unit filename="HTMLFooter.h" />
+		<Unit filename="HTMLHeader.cpp" />
+		<Unit filename="HTMLHeader.h" />
+		<Unit filename="HTMLInnerParser.cpp" />
+		<Unit filename="HTMLInnerParser.h" />
+		<Unit filename="HTMLList.cpp" />
+		<Unit filename="HTMLList.h" />
+		<Unit filename="HTMLMainIndexBuilder.cpp" />
+		<Unit filename="HTMLMainIndexBuilder.h" />
+		<Unit filename="HTMLMenu.cpp" />
+		<Unit filename="HTMLMenu.h" />
+		<Unit filename="HTMLPageBuilder.cpp" />
+		<Unit filename="HTMLPageBuilder.h" />
+		<Unit filename="HTMLRemovePreviousFiles.cpp" />
+		<Unit filename="HTMLRemovePreviousFiles.h" />
+		<Unit filename="HTMLSourceCode.cpp" />
+		<Unit filename="HTMLSourceCode.h" />
+		<Unit filename="HTMLTable.cpp" />
+		<Unit filename="HTMLTable.h" />
+		<Unit filename="HTMLTags.cpp" />
+		<Unit filename="HTMLTags.h" />
+		<Unit filename="IFileData.h" />
+		<Unit filename="ProgressDialog.cpp" />
+		<Unit filename="ProgressDialog.h" />
+		<Unit filename="Project.cpp" />
+		<Unit filename="Project.h" />
+		<Unit filename="ProjectInfo.cpp" />
+		<Unit filename="ProjectInfo.h" />
+		<Unit filename="QuestionMessage.cpp" />
+		<Unit filename="QuestionMessage.h" />
+		<Unit filename="ReplacementDialog.cpp" />
+		<Unit filename="ReplacementDialog.h" />
+		<Unit filename="StringPreparator.cpp" />
+		<Unit filename="StringPreparator.h" />
+		<Unit filename="Text.cpp" />
+		<Unit filename="Text.h" />
+		<Unit filename="WarningMessage.cpp" />
+		<Unit filename="WarningMessage.h" />
+		<Unit filename="blackdoc.cpp" />
+		<Unit filename="blackdoc.h" />
+		<Unit filename="description-en.txt" />
+		<Unit filename="description-ru.txt" />
+		<Unit filename="documentation\html\help\description-en.html" />
+		<Unit filename="documentation\html\help\description-ru.html" />
+		<Unit filename="documentation\html\help\index.html" />
+		<Unit filename="documentation\html\help\styles.css" />
+		<Unit filename="documentation\html\index.html" />
+		<Unit filename="documentation\html\styles.css" />
+		<Unit filename="gpl-license.txt" />
+		<Unit filename="manifest.xml" />
+		<Unit filename="styles.css" />
+		<Extensions>
+			<code_completion />
+			<envvars />
+			<debugger />
+		</Extensions>
+	</Project>
+</CodeBlocks_project_file>
diff -r e8000aa19e1c HTMLExporter.cpp
--- a/HTMLExporter.cpp	Sun Apr 22 14:29:08 2012 +0400
+++ b/HTMLExporter.cpp	Mon Apr 23 20:39:43 2012 -0400
@@ -18,10 +18,15 @@
  * along with BlackDoc. If not, see <http://www.gnu.org/licenses/>.
  *
  */
+
+#include "sdk.h"
+
+#ifndef CB_PRECOMP
+    #include <projectmanager.h>
+    #include <editormanager.h>
+    #include <cbproject.h>
+#endif
 
-#include <projectmanager.h>
-#include <editormanager.h>
-#include <cbproject.h>
 #include "HTMLExporter.h"
 #include "QuestionMessage.h"
 #include "HTMLActiveFileExporter.h"

[oBFusCATed]

You should use #include <sdk.h>

[Alpha]

You should use #include <sdk.h>

Right you are.  (Teach me not to pay attention when utilizing copy/paste...)

@marked: I believe the following patch has been green-lighted as an acceptable Windows build file.

Code

diff -r e8000aa19e1c BlackDoc-win.cbp
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/BlackDoc-win.cbp	Mon Apr 23 20:39:43 2012 -0400
@@ -0,0 +1,143 @@
+<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
+<CodeBlocks_project_file>
+	<FileVersion major="1" minor="6" />
+	<Project>
+		<Option title="BlackDoc" />
+		<Option pch_mode="2" />
+		<Option compiler="gcc" />
+		<Build>
+			<Target title="default">
+				<Option output="blackdoc" prefix_auto="1" extension_auto="1" />
+				<Option object_output="objs" />
+				<Option type="3" />
+				<Option compiler="gcc" />
+				<Option parameters="--debug-log --multiple-instance -na -ns -nd" />
+				<Option host_application="$(#cb)\devel\codeblocks.exe" />
+				<Option run_host_application_in_terminal="0" />
+				<Compiler>
+					<Add option="-g" />
+					<Add option="-pipe" />
+					<Add option="-mthreads" />
+					<Add option="-fmessage-length=0" />
+					<Add option="-fexceptions" />
+					<Add option="-Winvalid-pch" />
+					<Add option="-DBUILDING_PLUGIN" />
+					<Add option="-DHAVE_W32API_H" />
+					<Add option="-D__WXMSW__" />
+					<Add option="-DWXUSINGDLL" />
+					<Add option="-DcbDEBUG" />
+					<Add option="-DCB_PRECOMP" />
+					<Add option="-DWX_PRECOMP" />
+					<Add option="-DwxUSE_UNICODE" />
+					<Add directory="$(#cb)\include" />
+					<Add directory="$(#cb)\sdk\wxscintilla\include" />
+					<Add directory="$(#WX.include)" />
+					<Add directory="$(#WX.lib)\gcc_dll$(WX_CFG)\msw$(WX_SUFFIX)" />
+				</Compiler>
+				<Linker>
+					<Add option="-Wl,--enable-auto-import" />
+					<Add option="-mthreads" />
+					<Add library="wxmsw28$(WX_SUFFIX)" />
+					<Add library="codeblocks" />
+					<Add directory="$(#cb)\devel" />
+					<Add directory="$(#WX.lib)\gcc_dll$(WX_CFG)" />
+				</Linker>
+				<ExtraCommands>
+					<Add after="zip -j9 blackdoc.zip manifest.xml styles.css" />
+					<Add after="zip -j9 blackdoc.cbplugin blackdoc.dll blackdoc.zip" />
+					<Mode after="always" />
+				</ExtraCommands>
+			</Target>
+			<Environment>
+				<Variable name="WX_CFG" value="" />
+				<Variable name="WX_SUFFIX" value="u" />
+			</Environment>
+		</Build>
+		<VirtualTargets>
+			<Add alias="All" targets="default;" />
+		</VirtualTargets>
+		<Compiler>
+			<Add option="-Wall" />
+		</Compiler>
+		<Unit filename="Directory.cpp" />
+		<Unit filename="Directory.h" />
+		<Unit filename="ErrorMessage.cpp" />
+		<Unit filename="ErrorMessage.h" />
+		<Unit filename="FileCreationDialog.cpp" />
+		<Unit filename="FileCreationDialog.h" />
+		<Unit filename="FileSignature.cpp" />
+		<Unit filename="FileSignature.h" />
+		<Unit filename="FilesHandler.cpp" />
+		<Unit filename="FilesHandler.h" />
+		<Unit filename="HTMLActiveFileExporter.cpp" />
+		<Unit filename="HTMLActiveFileExporter.h" />
+		<Unit filename="HTMLActiveProjectExporter.cpp" />
+		<Unit filename="HTMLActiveProjectExporter.h" />
+		<Unit filename="HTMLBranchIndexBuilder.cpp" />
+		<Unit filename="HTMLBranchIndexBuilder.h" />
+		<Unit filename="HTMLContent.cpp" />
+		<Unit filename="HTMLContent.h" />
+		<Unit filename="HTMLDocument.cpp" />
+		<Unit filename="HTMLDocument.h" />
+		<Unit filename="HTMLExporter.cpp" />
+		<Unit filename="HTMLExporter.h" />
+		<Unit filename="HTMLFilesCreator.cpp" />
+		<Unit filename="HTMLFilesCreator.h" />
+		<Unit filename="HTMLFooter.h" />
+		<Unit filename="HTMLHeader.cpp" />
+		<Unit filename="HTMLHeader.h" />
+		<Unit filename="HTMLInnerParser.cpp" />
+		<Unit filename="HTMLInnerParser.h" />
+		<Unit filename="HTMLList.cpp" />
+		<Unit filename="HTMLList.h" />
+		<Unit filename="HTMLMainIndexBuilder.cpp" />
+		<Unit filename="HTMLMainIndexBuilder.h" />
+		<Unit filename="HTMLMenu.cpp" />
+		<Unit filename="HTMLMenu.h" />
+		<Unit filename="HTMLPageBuilder.cpp" />
+		<Unit filename="HTMLPageBuilder.h" />
+		<Unit filename="HTMLRemovePreviousFiles.cpp" />
+		<Unit filename="HTMLRemovePreviousFiles.h" />
+		<Unit filename="HTMLSourceCode.cpp" />
+		<Unit filename="HTMLSourceCode.h" />
+		<Unit filename="HTMLTable.cpp" />
+		<Unit filename="HTMLTable.h" />
+		<Unit filename="HTMLTags.cpp" />
+		<Unit filename="HTMLTags.h" />
+		<Unit filename="IFileData.h" />
+		<Unit filename="ProgressDialog.cpp" />
+		<Unit filename="ProgressDialog.h" />
+		<Unit filename="Project.cpp" />
+		<Unit filename="Project.h" />
+		<Unit filename="ProjectInfo.cpp" />
+		<Unit filename="ProjectInfo.h" />
+		<Unit filename="QuestionMessage.cpp" />
+		<Unit filename="QuestionMessage.h" />
+		<Unit filename="ReplacementDialog.cpp" />
+		<Unit filename="ReplacementDialog.h" />
+		<Unit filename="StringPreparator.cpp" />
+		<Unit filename="StringPreparator.h" />
+		<Unit filename="Text.cpp" />
+		<Unit filename="Text.h" />
+		<Unit filename="WarningMessage.cpp" />
+		<Unit filename="WarningMessage.h" />
+		<Unit filename="blackdoc.cpp" />
+		<Unit filename="blackdoc.h" />
+		<Unit filename="description-en.txt" />
+		<Unit filename="description-ru.txt" />
+		<Unit filename="documentation\html\help\description-en.html" />
+		<Unit filename="documentation\html\help\description-ru.html" />
+		<Unit filename="documentation\html\help\index.html" />
+		<Unit filename="documentation\html\help\styles.css" />
+		<Unit filename="documentation\html\index.html" />
+		<Unit filename="documentation\html\styles.css" />
+		<Unit filename="gpl-license.txt" />
+		<Unit filename="manifest.xml" />
+		<Unit filename="styles.css" />
+		<Extensions>
+			<code_completion />
+			<envvars />
+			<debugger />
+		</Extensions>
+	</Project>
+</CodeBlocks_project_file>
diff -r e8000aa19e1c HTMLExporter.cpp
--- a/HTMLExporter.cpp	Sun Apr 22 14:29:08 2012 +0400
+++ b/HTMLExporter.cpp	Mon Apr 23 20:39:43 2012 -0400
@@ -18,10 +18,15 @@
  * along with BlackDoc. If not, see <http://www.gnu.org/licenses/>.
  *
  */
+
+#include <sdk.h>
+
+#ifndef CB_PRECOMP
+    #include <projectmanager.h>
+    #include <editormanager.h>
+    #include <cbproject.h>
+#endif
 
-#include <projectmanager.h>
-#include <editormanager.h>
-#include <cbproject.h>
 #include "HTMLExporter.h"
 #include "QuestionMessage.h"
 #include "HTMLActiveFileExporter.h"

[marked]

@Alpha
Ok, I've added your patch. Hope, I will be able to try the plugin on Windows this weekend.

@all
I have a question: is there a way to open a file inside C::B editor, but not to show it to the user?

[oBFusCATed]

marked: What do you want to achieve?

[ollydbg]

I have a question: is there a way to open a file inside C::B editor, but not to show it to the user?

You can see one of examples in:

Code

cb_trunk\src\plugins\codecompletion\coderefactoring.cpp

and the function:

Code

size_t CodeRefactoring::SearchInFiles(const wxArrayString& files, const wxString& targetText)