Code::Blocks Forums

Hi all !!

The "ThreadSearch" plugin offers the following features:

• multi-threaded "Search in files"
• preview of the results (left single click on log window)
• file open (left double click on log window)
• check boxes instead of radio boxes to allow searches with both project and directories for example.
• contextual menu "Find occurrences" to start a search in files with the word under cursor (can be activated or not)

Why ?

• I am working on very big projects (700 Mo of cpp, h files) and text searches take up to 5 minutes. It is very frustrating being blocked because of the search. It is now possible to continue editing code during searches.
• I do not like leaving the editor position to browse 'Search in files' resuts. There is now the 'Code preview' to do this with possibility to open the file at the right position.

Please note :

• The provided dll is release unicode (windows only for now).
• Even if beta version, it is stable (I've been using it for 2 months).
• Tested only on 3 XP SP2 PCs, personal and professional editions.

Installation :

• Download the following files: ThreadSearch-0.3.cbplugin (http://www.esnips.com/doc/c4f56131-80e6-4ebf-8230-28e66c5ed3cc/ThreadSearch-0.3), ThreadSearch.png (http://www.esnips.com/doc/13896624-7adf-4fa3-85ad-2fdedba4a0aa/ThreadSearch) and ThreadSearch-off.png (http://www.esnips.com/doc/247113d7-82bf-4c20-bfe7-72367ef883fd/ThreadSearch-off)
• Copy and paste the downloaded pngs in the <...>\CodeBlocks\share\CodeBlocks\images\settings directory
• Click on Plugins/Manage plugins
• Click on Install new and select the downloaded ThreadSearch-0.3.cbplugin

Now a few questions :
I would like to release the source code in the contrib plugins. Do I make a SVN patch?
How do I get rights to modify my code without SVN patching ?

Remarks :

• I duplicated the cbFindReplaceData in my project because it is declared in cbeditor.cpp. Any problem moving it to cbeditor.h ?? Can send the patch ?
• My search strategy is inspired from the find in files one (use of an hidden cbEditor) but is not a raw copy. What do I need to do to comply with GPL licence ?
• You may have noticed there is only Windows XP version. I need help to translate Windows codeblocks project to other platforms and to build the dedicated binaries.

For sure, I am interesting in your opinions concerning this plugin !

Dje

Sorry, no success here:

[22:04:01.828]: ERROR: E:\Devel\CodeBlocks_Devel/share/codeblocks/plugins/ThreadSearch.dll: not loaded (missing symbols?)
[22:04:01.843]: Failed

Seems it's build against a non up-to-date SDK. But: Sounds interesting anyway. ;-)
With regards, Morten.

Sorry again, forgotton to answer the second part (which I kind of overlooked):
I'd suggest first posting the plugin sources here for testing and maybe announcing it in the WiKi under plugins section. Once you believe that you have received enough feedback it *could* be added to contrib at C::B SVN (by mandrav). But: You could also create your own SVN repository as it is done with quite some other plugins. You could even use BerliOS as platform if you like. The advantage: You have full control over the sources and the repository itself yourself.
With regards, Morten.

I updated my environment to SVN 3672 and rebuilt my plugin.

I had problems with install and uninstall. All worked in my development environment but install/uninstall systematically failed when installing in the nightly build the exported plugin.

To solve this, I replaced the static libs (wxScintilla, wxWidgets and CodeBlocks) from my development environment by the corresponding nightly dlls (suggested by Mandrav).

I am using GCC 3.4.5.

I compiled the plugin with several different nightlies and tried it with several ones without rebuilding it. I had no problem.

Did you try with a nightly build or your SVN environment (I saw devel in your log) ?

Could you try with a recent nightly if you tested it on SVN environment ?

Dje

Quote from: dje on March 13, 2007, 09:52:46 PM
You may have noticed there is only Windows XP version. I need help to translate Windows codeblocks project to other platforms and to build the dedicated binaries.

You have a good idea going here.

Suggestion:

Support Linux.

(http://)Download andLinux. Install it. Install CodeBlocks under andLinux, recompile CB and test your plugin.

When you support Linux,as all the other contribs do, you'll have a better chance of getting it added to the Contribs.

andLinux is a Linux distrubution using coLinux and ubuntu that runs under windows XP. You don't have to reboot or reserve a partition.

http://wiki.gp2x.org/wiki/AndLinux (http://wiki.gp2x.org/wiki/AndLinux)
http://forums.next.codeblocks.org/index.php/topic,4549.0.html (http://forums.next.codeblocks.org/index.php/topic,4549.0.html)

XP running CB under Linux under Windows with wxWidgets help file and WinExplorer. Linux is running from the E:\andLinux directory.

(http://img163.imageshack.us/img163/4688/154np8.png)

Quote from: dje on March 13, 2007, 10:23:56 PM
Did you try with a nightly build or your SVN environment (I saw devel in your log) ?
Could you try with a recent nightly if you tested it on SVN environment ?

Yes - I only use my own development version, usually. I'll try to install a nightly but have to save my config first that I can switch back afterwards. Will do that tomorrow... time to go for me for today... :mrgreen:
With regards, Morten.

Wiki annoucenments page (http://wiki.codeblocks.org/index.php?title=Announcement_for_plugins/patches#Plugin_announcements) has been updated.

I prefer join ThreadSearch plugin to the contrib plugins once the current problem is solved unless Mandrav doesn't want to.

My source code is in the ThreadSearch.zip (http://www.esnips.com/doc/49b431c1-cd8f-4d91-bae8-032a2ebc9161/ThreadSearchSourceCode) zip.
Just extract it to the <...>\codeblocks\src\plugins\contrib directory.

Don't forget to change the linker settings, I use the nihtly dlls and paths are relative to my install.
I think I'll create a variable to make it portable for integration.

I created my panels with wxGlade (http://wxglade.sourceforge.net) and my pngs with PortableGIMP (http://www.framakey.org/Portables/PortableGIMP)

Dje

QuoteSuggestion:

Support Linux.

I installed Ubuntu 6.10, wxGTK, C::B nightly, SVN and updated a development environment.

As I am the perfect newbee and don't have a lot of time, I progress  :) but slowly  :?
I thought to the poor Linux users who can not use this wonderful plugin... That's why I asked for help.

Dje

QuoteI prefer join ThreadSearch plugin to the contrib plugins once the current problem is solved unless Mandrav doesn't want to.

Why wouldn't I want to? If it delivers what it promises ;).
Besides, as I told you in a PM, we were already considering of making it a core plugin but unfortunately we didn't have the time to test it. So putting it in as a contrib plugin would be the way to go for now.

I will build it in linux tomorrow and if all goes well (and after the mandatory testing ;)), we will consider adding it as a contrib plugin.

cool, gonna start (finally  :oops:) using it. Too bad all day meeting today :-( .
For me : if it is stable --> contrib fo sure.

@Yiannis : when somebody creates a plugin --> .cbplugin, it would be nice that we could somehow also put the png's in that package so they also get installed automatically. What do you think ?

Sorry for being dumb, but where do I actually access the plugin? It did compile/load fine now, but I can't see any menu for this feature...?! What am I missing?!
With regards, Morten.

Hi !

Quotewhere do I actually access the plugin?

In the view menu, there is a 'Thread search' entry that makes a 'Thread search' panel appears in the Messages notebook.

Another solution is to open a file and right-click on it; by default, a 'Find occurrences of' entry is added below the 'Find implementation of' entry. This allows running a search of the word under cursor.

Searches history is stored in the combo box; it can also be used to run searches.

To configure it, you can go to the 'Settings/Environment' panel and go at the bottom or click on the 'Options' button of the panel.

Quotewould be nice that we could somehow also put the png's in that package so they also get installed automatically

I asked for this in another thread; the manifest file is should be used for this but it is not implemented for now.

Dje

Quote from: dje on March 14, 2007, 08:20:00 AM
In the view menu, there is a 'Thread search' entry that makes a 'Thread search' panel appears in the Messages notebook.

Ah sorry - I have been blind. So I've tested it a little and I'm  quite impressed! Nicely done! :D
Hence there are a few points I'd like to state:
1.) The GUI looks pretty broken (as you can see on the first screenshot attached) if C::B isn't maximised
2.) (For the future) a menu entry in the "Search" menu would be nice - that's where I would have expected the functionality. I guess it's enough activating and switching to the panel when clicking on that menu entry.
3.) Displaying the found item in another editor next to the search results is nice in principle, but I believe with most layouts of C::B this won't be of much help as the editor window is just too small. Why not opening a "big" (usual) editor instead (I guess you have reasons for that)?
4.) If you enable the "dir items" things get worse for me. I usually keep the message panel quite small and then it looks like the other screenshot attached. I'm not sure how to handle this any better... But: If this goes to core all worries are gone because then it would replace the current find dialog.

In the end that's all I have to say. I think it's great... no, wait a second: it's GREAT! ;-) Very fast search, nicely presented / configurable... well done! My worries above maybe a point for discussion but I believe they are minor in the end.

With regards, Morten.

[attachment deleted by admin]

First, thanks for congratulations !

QuoteThe GUI looks pretty broken

It's true I systematically use C::B in maximised mode; I'll try to find how to add scroll bars (does not seem too difficult) but more space will be wasted whereas they appear because of the few available space...
There no miracle but 50'' screen  :)

QuoteI guess it's enough activating and switching to the panel when clicking on that menu entry.

Yes, I'll add another menu entry in the Search menu with the same event ID as in the view menu.
Is this what you mean ?

QuoteWhy not opening a "big" (usual) editor instead (I guess you have reasons for that)?

Yes, I have  :D
In fact, when I read code, I often search for items but leaving my current position to switch to another place in the same file bores me a lot : where was I in this wonderful 20000 lines file I got back :evil:
Another thing, I often need to browse method calls to see how it works and the use context. But I want to keep the editor I am working on in the same state. In this case, I either change Messages notebook size or I play (a lot) with F2 to switch Messages notebook visibility : far more efficient !
Note that single click on a result line previews the code whereas double click opens a "big" (usual) editor

QuoteIf you enable the "dir items" things get worse for me. I usually keep the message panel quite small and then it looks like the other screenshot attached. I'm not sure how to handle this any better...

I was aware of this problem, that's why there is the 'Hid dir items' button. Data are managed but you spare one line of controls space. You do not need to display dirs items to perform search in directories.

Dje

Quote from: dje on March 14, 2007, 10:35:07 AM
Yes, I'll add another menu entry in the Search menu with the same event ID as in the view menu.
Is this what you mean ?

Yes, exactly. ;-)

Quote from: dje on March 14, 2007, 10:35:07 AM
In fact, when I read code, I often search for items but leaving my current position to switch to another place in the same file bores me a lot : where was I in this wonderful 20000 lines file I got back :evil:

I understand - BTW: I'm using the bookmark feature for that purposes. But I agree this can be annoying.

Quote from: dje on March 14, 2007, 10:35:07 AM
with F2 to switch Messages notebook visibility : far more efficient !

Ok then. The only thing that worries me (haven't tried yet) are those "mini" editors writable? Because that would be evil! You would have to take care about syncing with any other open editor of the same file. If this is not already done: Please make the mini editors at least read-only.

Quote from: dje on March 14, 2007, 10:35:07 AM
Note that single click on a result line previews the code whereas double click opens a "big" (usual) editor

Oh great! I didn't try - and yes, it works! 8)

Quote from: dje on March 14, 2007, 10:35:07 AM
You do not need to display dirs items to perform search in directories.

That's right... maybe what you had said above with the scrollbars would be another option. But in the end I think when it comes down to replacing the "old" find dialog with this one you might not need all that control functionality in the panel and/or enable toggling visibility of certain settings even more options.

With regards, Morten.

Quote from: dje on March 13, 2007, 09:52:46 PM
The "ThreadSearch" plugin offers the following features:

• multi-threaded "Search in files"
• preview of the results (left single click on log window)
• file open (left double click on log window)
• check boxes instead of radio boxes to allow searches with both project and directories for example.
• contextual menu "Find occurrences" to start a search in files with the word under cursor (can be activated or not)

Looks fine! There is only one feature missed... :D

• group search results by file

Best regards,
jomeggs

QuotePlease make the mini editors at least read-only

That's the case.
For know I use a cbStyledTextCtrl that allows what I use.
To be writable, it would be better to use a cbEditor, what is impossible today due to the several interactions between cbEditor/ProjectManager/wxFlatNotebook.
Make the Code preview writable is not planned for today.

Quotegroup search results by file

I'm not sure to understand clearly what you mean, make column header clickable to sort the log items ?

Dje

Quote from: dje on March 14, 2007, 01:16:33 PM

QuotePlease make the mini editors at least read-only

That's the case. [...] Make the Code preview writable is not planned for today.

Again: Great... keep it that way. ;-)

Quote from: dje on March 14, 2007, 01:16:33 PM

QuotePlease make the mini editors at least read-only

That's the case.
For know I use a cbStyledTextCtrl that allows what I use.
To be writable, it would be better to use a cbEditor, what is impossible today due to the several interactions between cbEditor/ProjectManager/wxFlatNotebook.
Make the Code preview writable is not planned for today.

Although I agree that it should be read-only, still you could make it writable if you insisted, with minimal fuss.
The key is to use scintilla's document pointers. It's just one line of code for you to add:

your_control->SetDocPointer(open_cbeditor->GetDocPointer())

These are refcounted and should pose no problem. The only issue I see is that if a cbEditor is not open when previewing your search results you should then watch for EDITOR_OPEN events and if you see that an internal editor opens with the same file, then "attach" the docpointer again so that you use the one and same internal buffer.

Once again: I don't think that making it writable is a good idea. I 'm just writing this so you learn something new (if you didn't know already).

I must be overlooking something. I was going to compile ThreadSearch under Linux but cannot find the source.

Could you give us a link to the source, and I'll run it through andLinux.

Quote from: dje on March 13, 2007, 10:49:34 PM
My source code is in the ThreadSearch.zip (http://www.esnips.com/doc/49b431c1-cd8f-4d91-bae8-032a2ebc9161/ThreadSearchSourceCode) zip.
Just extract it to the <...>\codeblocks\src\plugins\contrib directory.

You will notice there is no LINUX/UNIX project.
Have a look at the linker settings.
To use it in my SVN environment, I use the generated static libs.
To use it with a nightly, I link directly with the corresponding dlls.
If I do not respect these rules, plugin install fails; I suspect the link because I didn't apply C::B team wxWidgets patch for menu alignement in my development environment.

QuoteI don't think that making it writable is a good idea.

I agree. In my opinion, it is just a previewer, not an editor. The code preview is not there to fill the need of editors splitting/cascading.

Dje

Quote from: dje on March 14, 2007, 01:16:33 PM
I'm not sure to understand clearly what you mean, make column header clickable to sort the log items ?

No, i am referring to gather the search results in a treeview. Each file is a root node, the single search results are subitems of these root nodes.

QuoteNo, i am referring to gather the search results in a treeview.

I see now...
I keep it in mind but I have already planned changes before.

Thanks for the idea !

Under Linux, the following statements get error:
Does anyone know how to fix this?

(http://img81.imageshack.us/img81/2855/157uy0.png)


-------------- Build: default in ThreadSearch-Lunix ---------------
g++-4.0 -Wall `pkg-config --cflags codeblocks` `wx-config --cflags` -g  -I/home/pecan/devel/trunk/src/include -I/usr/include -I/home/pecan/devel/trunk/src/include/wxFlatNotebook/include -I/home/pecan/devel/trunk/src/include/wxscintilla/include -I/usr/include  -c /mnt/e/linux/proj/ThreadSearch/ThreadSearch.cpp -o .objs/ThreadSearch.o
Package codeblocks was not found in the pkg-config search path.
Perhaps you should add the directory containing `codeblocks.pc'
to the PKG_CONFIG_PATH environment variable
No package 'codeblocks' found
/mnt/e/linux/proj/ThreadSearch/ThreadSearchEvent.h:48: error: ISO C++ forbids declaration of '__declspec' with no type
/mnt/e/linux/proj/ThreadSearch/ThreadSearchEvent.h:48: warning: '__declspec' initialized and declared 'extern'
/mnt/e/linux/proj/ThreadSearch/ThreadSearchEvent.h:48: error: 'dllexport' was not declared in this scope



Hi !

I found info on the net.
You need to use __declspec(dllimport/dllexport) on windows to import/export symbol from/to a dll.
On Linux, it seems that nothing is required.

I'll define or use a set of macro to differentiate the OSs.

I'll update it today.

Dje

Here's what I came up with to get it to compile under Linux.


diff -u C:\Usr\Proj\ThreadSearch/ThreadSearch.cpp e:\linux\proj\ThreadSearch/ThreadSearch.cpp
--- C:\Usr\Proj\ThreadSearch/ThreadSearch.cpp 2007-02-20 22:54:02.000000000 -0500
+++ e:\linux\proj\ThreadSearch/ThreadSearch.cpp 2007-03-14 13:04:36.000000000 -0500
@@ -17,6 +17,11 @@
#include "ThreadSearchConfPanel.h"
#include "ThreadSearchControlIds.h"

+//Missing headers //(pecan 2007/3/14)
+#include "messagemanager.h"
+#include "configmanager.h"
+#include "sdk_events.h"
+
class wxFlatNotebook;

// Register the plugin with Code::Blocks.
Files C:\Usr\Proj\ThreadSearch/ThreadSearch.zip and e:\linux\proj\ThreadSearch/ThreadSearch.zip differ
diff -u C:\Usr\Proj\ThreadSearch/ThreadSearchEvent.h e:\linux\proj\ThreadSearch/ThreadSearchEvent.h
--- C:\Usr\Proj\ThreadSearch/ThreadSearchEvent.h 2007-03-11 10:17:34.000000000 -0500
+++ e:\linux\proj\ThreadSearch/ThreadSearchEvent.h 2007-03-14 12:49:58.000000000 -0500
@@ -19,6 +19,26 @@
#include <wx/event.h>
#include <wx/arrstr.h>

+//(pecan 2007/3/14)
+#if defined(__WXGTK__)
+    #ifdef _MSC_VER
+      #ifdef BUILDING_DLL
+        #define DLLEXPORT __declspec(dllexport)
+      #else
+        #define DLLEXPORT __declspec(dllimport)
+      #endif
+      #define DLLLOCAL
+    #else
+      #ifdef HAVE_GCCVISIBILITYPATCH
+        #define DLLEXPORT __attribute__ ((visibility("default")))
+        #define DLLLOCAL __attribute__ ((visibility("hidden")))
+      #else
+        #define DLLEXPORT
+        #define DLLLOCAL
+      #endif
+    #endif
+#endif
+
class ThreadSearchEvent : public wxCommandEvent
{
public:
@@ -45,7 +65,9 @@
typedef void (wxEvtHandler::*ThreadSearchEventFunction)(ThreadSearchEvent&);

BEGIN_DECLARE_EVENT_TYPES()
- DECLARE_EXPORTED_EVENT_TYPE(__declspec(dllexport), wxEVT_THREAD_SEARCH, wxID_ANY)
+    //(pecan 2007/3/14)
+ //DECLARE_EXPORTED_EVENT_TYPE(__declspec(dllexport), wxEVT_THREAD_SEARCH, wxID_ANY)
+ DECLARE_EXPORTED_EVENT_TYPE(DLLEXPORT, wxEVT_THREAD_SEARCH, wxID_ANY)
END_DECLARE_EVENT_TYPES()

#define EVT_THREAD_SEARCH(id, fn) \


However, it must not be right, because the layout gets screwed up when I resize CB. Sometimes the menu completely disappears. I think it's not getting its events.

When I enter a search string into the search textCtrl, it doesn't do anything.

(http://img410.imageshack.us/img410/94/158ct6.png)

Pecan,
I found the magical macro in wxWidgets dlimpexp.h :
WXEXPORT
All OSs are managed.

Why do you speak of missing includes, on LINUX:
sdk.h -> sdk_precomp.h -> sdk_common.h -> configmanager.h, messagemanager.h and sdk_events.h

To have this behaviour, the CB_PRECOMP macro must be defined in project settings and __WXMSW__ must not be defined.
Can you check and tell me more about this ?

ThreadSearch 0.4 is available :

• plugin (http://www.esnips.com/doc/0e1369be-23e3-41f2-9f31-0525a4743038/ThreadSearch-0.4)
• source code (http://www.esnips.com/doc/8554da55-65fc-47d4-9e2d-521e67fc7bfb/ThreadSearchSourceCode0.4)

What's new :

• QuoteI'll add another menu entry in the Search menu with the same event ID as in the view menu.

• Use of the WXEXPORT instead of __declspec(dllexport) to compile under LINUX (correction has to be checked)

Dje

not all compilers support precompiled headers, and the CB_PRECOMP is for pch's.
To be honest, I hate them. Today I once again fixed a bug due to those darn pch's.
Pch's can be a help , a speed up, but still people first need to write correct headers and includes, and only then pch should be applied. Now too many people write incorrect headers and includes but things work because of those pch's (this is not a good side effect, it is a bad one, because it create unportable code). I once prepared a post on correct header inclusion, next week I will spend a lot of time in hotels. I will finish it and post it (finally), it will explain al ot of things.

Basically you do something like this :

#include "sdk.h"
#indef CB_PRECOMP
// include here all headers which are actually needed and are otherwise delivered through include of sdk.h
#endif
// include here all remaining headers needed and which are not provided by sdk.h

when there's no CB_PRECOMP then sdk.h should bring no headers at all, that's the correct way.

I promise to post my article next week to clarify a lot of things.


Cheers,
Lieven

I'll apply this in O.5, but not today, it's time to stop !

Quote from: dje on March 14, 2007, 10:49:17 PM
What's new :

• QuoteI'll add another menu entry in the Search menu with the same event ID as in the view menu.

• Use of the WXEXPORT instead of __declspec(dllexport) to compile under LINUX (correction has to be checked)

Nice one. Will try tomorrow. So far I have attached something you might want to consider, too: The zip file contains fixes to the project file (there were e.g. references to non-existing folders) and an update to the post-build process using a batch file on windows. Thus ensuring that the images are being copied to all locations required.
The same file can be converted to a unix bash script appropriate next to another project file for unix.

With regards, Morten.

[attachment deleted by admin]

Thanks for the improvement.

What about this point :

QuoteTo use it in my SVN environment, I use the generated static libs.
To use it with a nightly, I link directly with the corresponding dlls.

I need to link with *.a to work with my development environment.
I need to link with nightly *.dll to work with the nightly.

As I said :

QuoteI suspect the link because I didn't apply C::B team wxWidgets patch for menu alignement in my development environment.

It seems to be the development project version, which may not be appropriate for nightly builds production.
Do you think the use of virtual targets is recommended in this case ?

Dje

Quote from: dje on March 14, 2007, 11:48:27 PM
I need to link with *.a to work with my development environment.
I need to link with nightly *.dll to work with the nightly.
[...]
Do you think the use of virtual targets is recommended in this case ?

I wouldn't make things too complicated. I'd say just provide the sources (which will ensure enough tester I believe) and (maybe) ask killerbot to include this plugin in the nightlys if you want a wider spectrum of testers. Everything else is simply too error-prone.
Once the next C::B version comes out there will also be a SDK released. At that point one can think about shipping *.cbplugin files build against this "static" SDK. For now this isn't much useful... IMHO.
with regards, Morten.

Hi dje,

I have tried the new Plugin (under windows) and it is really nice. I am using UTF-8 character encoding for my files and if I search with ThreadSearch plugin the preview of special characters (e.g. ü in german) is not correct. What default character encoding is used for this Plugin (CP1252)?

Thanks.

Bye

Mario

I ran the .04 source on Linux this morning after adding to ThreadSearch.cpp :

#include "messagemanager.h"
#include "configmanager.h"
#include "sdk_events.h"

It compiles just fine. But the search doesn't work. It takes the search string, starts a thread, then goes zombie. So I'm guessing the thread ends, but no attention is paid to it. It's hung.

Also, after the thread starts, any resize of any window in CB causes refreshes to freeze. The main menu or task bars even disappear. This might be evidence that an event is stuck in the event queue, not allowing other events to get through.

(http://img402.imageshack.us/img402/5302/160sv5.png)

QuoteWhat default character encoding is used for this Plugin (CP1252)?

I don't know... :oops:
In fact, I use the same search strategy as in 'Search in files', ie using a hidden cbStyledTextControl to search in file for me.
I keep the point and I'll have a look on how it is managed in C::B.
Do you have the same problem with Code::Blocks editors ?

Pecan, I am working on setting up a working environment on Ubuntu 6.10.
I am blocked for now with the problem discussed in another thread (http://forums.next.codeblocks.org/index.php/topic,5400.msg42134/topicseen.html#msg42134)
I read your remarks with big interest.

Dje

If you're going to compile on ubuntu, you're going to need this:

ThreadSearch-Lunix.cbp


<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_project_file>
<FileVersion major="1" minor="6" />
<Project>
<Option title="ThreadSearch-Lunix" />
<Option pch_mode="2" />
<Option compiler="gcc" />
<Build>
<Target title="debug">
<Option output="bin/debug/ThreadSearch.so" prefix_auto="1" extension_auto="1" />
<Option type="3" />
<Option compiler="gcc" />
<Option host_application="codeblocks" />
<Compiler>
<Add option="`pkg-config --cflags codeblocks`" />
<Add option="`wx-config --cflags`" />
<Add option="-g" />
</Compiler>
<Linker>
<Add option="`pkg-config --libs codeblocks`" />
<Add option="`wx-config --libs`" />
</Linker>
<ExtraCommands>
<Add after="zip -j9 ThreadSearch.zip manifest.xml" />
<Add after="zip -j9 ThreadSearch.cbplugin ThreadSearch.so ThreadSearch.zip" />
</ExtraCommands>
</Target>
</Build>
<Compiler>
<Add option="-Wall" />
<Add directory="$(#cb)/include" />
<Add directory="$(#cb)/include/wxFlatNotebook/include" />
<Add directory="$(#cb)/include/wxscintilla/include" />
<Add directory="$(#wx)/include" />
</Compiler>
<Unit filename="DirectoryParamsPanel.cpp" />
<Unit filename="DirectoryParamsPanel.h" />
<Unit filename="FindDataUtils.cpp" />
<Unit filename="FindDataUtils.h" />
<Unit filename="SearchInPanel.cpp" />
<Unit filename="SearchInPanel.h" />
<Unit filename="ThreadSearch.cbp" />
<Unit filename="ThreadSearch.cpp" />
<Unit filename="ThreadSearch.h" />
<Unit filename="ThreadSearchConfPanel.cpp" />
<Unit filename="ThreadSearchConfPanel.h" />
<Unit filename="ThreadSearchControlIds.h" />
<Unit filename="ThreadSearchEvent.cpp" />
<Unit filename="ThreadSearchEvent.h" />
<Unit filename="ThreadSearchThread.cpp" />
<Unit filename="ThreadSearchThread.h" />
<Unit filename="ThreadSearchView.cpp" />
<Unit filename="ThreadSearchView.h" />
<Unit filename="manifest.xml" />
<Extensions>
<code_completion />
</Extensions>
</Project>
</CodeBlocks_project_file>



I call it "-Lunix" because the .so file is output only to the local directory. I install and test the .so after the code compiles cleanly.

You can make a production ThreadSearch-unix.cbp later.

I'll do some debugging soon, to see why the thread hangs/or never notifies the plugin.

Hi dje,

you are right the same problem occurs with find in files within the Code::Blocks editor?
Under linux utf-8 is the default encoding, so I will try the same with Code::Blocks under linux to see what happens.

Bye

Mario

Mario, did you try to play with the "Edit\File encoding" sub menu (at least for editors) ?
You may have a look at the "Settings\Editor" then "General settings" to set default encoding for file open.

Dje

Merging Pecan's and Killerbot's remarks I added the magical lines
#include <sdk.h> // Code::Blocks SDK
#ifndef CB_PRECOMP
#include "messagemanager.h"
#include "configmanager.h"
#include "sdk_events.h"
#endif

And I have finally a complete running environment on Linux.

QuoteBut the search doesn't work. It takes the search string, starts a thread, then goes zombie. So I'm guessing the thread ends, but no attention is paid to it. It's hung.

Also, after the thread starts, any resize of any window in CB causes refreshes to freeze. The main menu or task bars even disappear. This might be evidence that an event is stuck in the event queue, not allowing other events to get through.

I had the problem but it is strange... Some widgets are no more refreshed whereas other still continue to behave correctly.

Let's test C::B debugger ! :)

Hi dje,

I tried the same file with UTF-8 under linux. The Search in files show the correct character encoding. Code:Blocks does not use the character encoding of the file or the settings of the editor, but the system default encoding.
Under linux it is UTF-8 so the find in files or threadsearch plugin will show the correct content (also for special characters like ü), but windows has a different system default encoding.


Bye,

Mario

Hi Mario, did you try this on Windows ?

QuoteMario, did you try to play with the "Edit\File encoding" sub menu (at least for editors) ?
You may have a look at the "Settings\Editor" then "General settings" to set default encoding for file open.

Dje

Hi dje,

I use the same settings in Code::Blocks under windows and linux. I have selected Edit\File encoding UTF-8 for the file and UTF-8 for file open in Settings\Editor.
The find in files show the correct content under linux, but not under windows, because the system default encoding under linux is UTF-8 and under windows ISO-8859-1.

Just try to wirte a text under windows with the content like:
Dies ist ein üä Test.
and save it with UTF-8 character encoding. Now open the file with codeblocks and search for "ist" with find in files.

Bye

Mario

For me it works.
Did you apply UTF-8 as default encoding as suggested in

QuoteYou may have a look at the "Settings\Editor" then "General settings" to set default encoding for file open.

or as on the picture Encoding.gif ?

Dje

[attachment deleted by admin]

It took me two hours to figure out that as long as Jerome is spelled with the little backward quote and the little "house top", the ususal CB Find-in-files will not work under linux.

I tried utf-8 and a bunch of 8859 setting and nothing worked until I change "J`er^ome"  to "Jerome" under windows, then copied the files back to Linux.

Anybody got any idea why this happens?

I have a fundamental, maybe stupid, question.

ThreadSearch does the searches using a hidden cbStyledTextCtrl.

Threads are not allowed to do GUI calls without carefull critical sections.

Even though the cbSTC is hidden, aren't GUI calls being made from this background thread?

Nice plugin!  The preview idea is very cool (minimal tab clutter), thanks for sharing.  :)

I have some suggestions I hope you'll find useful, although it's possible they are already on your todo list...

Background colour
The hard coded XP background colour looks a bit out of place on Vista - no doubt the same is true on other platforms and themes.  This is an easy fix for win32 using 'GetSysColor' but I'm unsure if there is an equivalent function for other platforms (if one is even needed)... I found the following wxWidgets implementation, if colours are normally correct on other platforms then perhaps it's good enough?

ThreadSearchView.cpp
..
..
void ThreadSearchView::set_properties()
{
// Set correct background colour on win32 systems
SetBackgroundColour(wxSystemSettings::GetColour(wxSYS_COLOUR_BTNFACE));
..


Search Results
The filename is not visible in the thread search results listview as the preceding path takes up what little space there is, an option to show only the filename along with saving column widths would be a huge improvement.

The preview normally shows the highlighted line at the bottom (depending on what was previously shown) - would it be possible for the line to be initially set in the middle each time?  ie, if 5 lines are visible, the 3rd line is the one highlighted with the search term.  A program I use called Search & Replace does this and it's good for quickly getting the context of the result.  It might be tricky knowing how many lines are visible but perhaps you could have an option which sets the amount of lines above the highlight - in this case you would set it to 2.

An improvement of lower priority would be to maximise the vertical space usable for search results as it is at such a premium in the messages window.  A good idea for this would be to (optionally?) relocate the controls to an advanced search dialogue and instead provide a search toolbar similar to visual studio etc.  The toolbar could be as simple as a combobox (pressing enter performs search with existing options) and a button which opens the new dialogue.

Bug report
Keyboard shortcuts (Ctrl+V/X/C/Z etc.) are sent to the active editor when caret is in the thread search combobox.  This is unexpected and awkward for pasting search terms etc.

Not really a bug but on my system a search which produces a lot of hits (eg. 'if') occupies the CPU such that codeblocks and (more annoyingly) the cancel search button is unresponsive until the search is complete.  I think it should be possible to correct this without incurring a significant performance hit.

Thanks again for sharing your work, I hope you appreciate my suggestions and I look forward to your views as well as any future releases.

Jamie

Hi all !

Sorry... I didn't know I was a bug  :) !

I'll replace all the Jérôme by Jerome !
Pecan, could you explain what this correction change ?

QuoteEven though the cbSTC is hidden, aren't GUI calls being made from this background thread?

Well, I do not have the answer to this interesting question.
As I use the view as parent during hidden cbSTC creation whereas it is not useful, I'll replace it by NULL to limit gui interactions:
cbStyledTextCtrl* control = new cbStyledTextCtrl(m_pThreadSearchView, -1, wxDefaultPosition, wxSize(0, 0));
=>
cbStyledTextCtrl* control = new cbStyledTextCtrl(NULL, -1, wxDefaultPosition, wxSize(0, 0));

QuoteKeyboard shortcuts (Ctrl+V/X/C/Z etc.) are sent to the active editor when caret is in the thread search combobox.  This is unexpected and awkward for pasting search terms etc.

This has been corrected with patch 1704 integration.
I think your nightly may be too old.

QuoteNot really a bug but on my system a search which produces a lot of hits (eg. 'if') occupies the CPU such that codeblocks and (more annoyingly) the cancel search button is unresponsive until the search is complete.  I think it should be possible to correct this without incurring a significant performance hit.

Yes, that's a limitation.
The worker thread sends events to the view to add found lines.
One event per file is sent.
As click or other events are enqueued after worker thread events, the application hangs if you search after an expression present in lots of files.
I would like to be able to specify a lower priority to the thread events but I think events handlers do not manage events priority.

QuotewxSystemSettings::GetColour(wxSYS_COLOUR_BTNFACE)

This works with
wxSystemSettings::GetColour(wxSYS_COLOUR_WINDOW)
on my XP environment.
I'll test it (not today) on my Linux environment.

QuoteThe filename is not visible in the thread search results listview as the preceding path takes up what little space there is, an option to show only the filename along with saving column widths would be a huge improvement.

Yes, I'll think about it. At first glance, it may be configurable so that user can choose between the two solutions (I think directory is often useful).
On XP, I just put the cursor on the file path so that the tool tip gives me the full path.

QuoteThe preview normally shows the highlighted line at the bottom

I already saw that point. I'll try to improve it but I think that it's lower priority than many other points.


I really like the toolbar idea but my first priority is to make this plugin run on "other than Windows" platforms.


Finally, thanks for your positive feedback and your constructive remarks/propositions.

Dje

Quote from: Pecan on March 17, 2007, 06:20:10 PM
I have a fundamental, maybe stupid, question.

ThreadSearch does the searches using a hidden cbStyledTextCtrl.

Threads are not allowed to do GUI calls without carefull critical sections.

Even though the cbSTC is hidden, aren't GUI calls being made from this background thread?

The reason I ask the question is this from the wxWidgets manual:

Quote
::wxMutexGuiEnter
void wxMutexGuiEnter()

This function must be called when any thread other than the main GUI thread wants to get access to the GUI library. This function will block the execution of the calling thread until the main thread (or any other thread holding the main GUI lock) leaves the GUI library and no other thread will enter the GUI library until the calling thread calls ::wxMutexGuiLeave().

Typically, these functions are used like this:


void MyThread::Foo(void)
{
    // before doing any GUI calls we must ensure that this thread is the only
    // one doing it!

    wxMutexGuiEnter();

    // Call GUI here:
    my_window->DrawSomething();

    wxMutexGuiLeave();
}

Note that under GTK, no creation of top-level windows is allowed in any thread but the main one.
This function is only defined on platforms which support preemptive threads

When I attempt to run ThreadSearch under Linux, I get all sorts of freezes and segment violations as it tries to update/paint the cbStyledTextCtrl.

My thought is: that you cannot allocate a GUI control in a secondary thread. Nor can you cause it to update itself or paint. That's a gui call.

IE, you should not use a GUI editor in the secondary thread.

That may be why it crashes/hangs Linux CB.

I had this problem trying to write a wxTextCtrl log in KeyMacs. I had to completely remove the writes because they caused GUI calls to the wxTextCtrl.

I finally solved the problem with wxMutexGuiEnter/Leave, but I had to take the allocation of the text control out of the secondary thread.

Quote from: dje on March 18, 2007, 10:57:07 PM
This has been corrected with patch 1704 integration.
I think your nightly may be too old.

Weird, my nightly (svn 3720) is from yesterday!   :shock:  I will download today's and try a clean install...

Update:   Downloaded CB_20070318_rev3721_win32, extracted it to it's own folder and added mingwm10.dll, wxmsw26u_gcc_cb.dll and your unmodified plugin.  Moved my profile folder elsewhere, started codeblocks, loaded a project, copied some text from the editor, clicked inside the threadsearch combobox, hit ctrl+v, text is pasted to my last position in the editor!  I'm on Vista so could somebody else please try ctrl+v in the combobox?

PS. I had a quick look at patch 1704 and it's for 'OnContextMenu' while my problem involves the keyboard shortcuts...

QuoteYes, that's a limitation.
The worker thread sends events to the view to add found lines.
One event per file is sent.<snip>

I guessed that was the case, on win32 I have used 'WaitForSingleObject' with 1ms time-out to work around this.  The PSDK recommends 'WaitForMultipleObjects' if the wait is for any length of time but it is unnecessary when used with a short time-out.  In very fast loops I have set this up to execute on every nth iteration.  With a little tuning it should give the gui enough cycles to run smoothly with little impact on performance if any (although I have no numbers to prove it!).

QuotewxSystemSettings::GetColour(wxSYS_COLOUR_WINDOW)

Hmm.. are you saying COLOUR_BTNFACE is incorrect on your system for the beige xp coloured background as featured in your plugin and the screenshots previously in this thread?  I think COLOUR_WINDOW is an older pre-win95 constant - eg. the background of 'Program Manager' in Windows 3.11?!  On my system at least it results in a pure white background that looks a bit ugly and washed out (see attached png).  I don't have XP installed to check but looking at some software I've written in the past I've always used 'COLOR_BTNFACE' or it's alias 'COLOR_3DFACE' to match the same themed background you had hard coded.  Also, a drawback of using a colour that doesn't match the themed background is that themed buttons will have a 'halo' of colour around the button that won't match (please see magnified examples in the png).

Here's what the PSDK says about these constants.
COLOR_3DFACE = 15
Face color for three-dimensional display elements and for dialog box backgrounds.
COLOR_BTNFACE = 15
Face color for three-dimensional display elements and for dialog box backgrounds.
COLOR_WINDOW = 5
Window background.

Quoteit may be configurable so that user can choose between the two solutions (I think directory is often useful).

Yes, an option for either would be great.

Quote

QuoteThe preview normally shows the highlighted line at the bottom

I already saw that point. I'll try to improve it but I think that it's lower priority than many other points.

I really like the toolbar idea but my first priority is to make this plugin run on "other than Windows" platforms.

Finally, thanks for your positive feedback and your constructive remarks/propositions.

As I said, the toolbar idea would be a low priority suggestion as it is purely a gui thing and would be more than just a small mod.  I'm glad you appreciate my feedback, perhaps I'll look into some of the low priority ideas (eg. highlighted line) to see if I can contribute a patch or two, if you agree.  Although, I have not done any wxWidgets so don't count on anything great, anytime soon!   :lol:

Jamie

[attachment deleted by admin]

Here's a suggestion for achieving a consistent line position in the search preview and having it offset an optional number of lines.

You do have to have another 'GotoLine' but as I believe they both occur before a repaint there should be no impact on update speed.  Certainly on my machine (1.7Ghz Centrino Laptop) it was just as quick as before - which is instant!  Optimally, you would use an 'if' condition to check the initial 'GotoLine' as it's only required if you previously viewed the same file from a position later in the file - but as there was no noticeable performance hit I kept is simple for the sake of clarity.

The attached png shows the result of previewing a line.  So far while using the up/down arrows to traverse (quickly) up and down the results the line is always bang in the middle.  :)

ThreadSearchView.cpp

In ThreadSearchView::UpdatePreview replace:

// Display the selected line
m_pSearchPreview->GotoLine(line);

with:

// Display the selected line // Preview sets position inconsistently depending on the previous
m_pSearchPreview->GotoLine(0); // position so first, set line to a position before the destination,
m_pSearchPreview->GotoLine(line+2); // then set it to the destination postion + any desired offset.


Jamie

[attachment deleted by admin]

Hi all !

The 0.5 version of the ThreadSearch plugin is available.
What's new ??

• All Jérôme replaced by Jerome
• Added code to center line in preview editor on list single click.
• Added wxMutexGuiEnter() and wxMutexGuiLeave()
• Hard coded background color replaced by wxSystemSettings::GetColour(wxSYS_COLOUR_BTNFACE)

Files:

• source code (http://www.esnips.com/doc/14018345-27c6-442a-a772-030ac5aa748b/ThreadSearchSourceCode0.5)
• plugin (http://www.esnips.com/doc/b5ac83fc-7390-446c-bca0-7aaa3e482a5a/ThreadSearch-0.5)

Remarks:

• BIG THANKS TO PECAN FOR MAKING ME KNOW ABOUT wxMutexGui... CALLS. That way, the plugin became far more stable on my Ubuntu. No crashes appended since I used those mutexes. Next Linux problem : it seems that wxGlade generated code does not behave the same way : the height of the editor/list is not managed correctly (scrollbars scale).
• line centering code is taken from cbEditor::GotoLine. Jamie, I thank you for the solution you proposed but I think this one is better.
• Thanks to Jamie, I use wxSYS_COLOUR_BTNFACE instead of wxSYS_COLOUR_WINDOW. I found that wxSYS_COLOUR_WINDOW was more appropriate in wxWidgets 2.6.3 documentation but it is nicer with wxSYS_COLOUR_BTNFACE

Quotetext is pasted to my last position in the editor

Well... On XP, I have no problem but different problems appended on Ubuntu.
I'll have to dive into keyboard shortcuts management and event skipping...

QuoteI guessed that was the case, on win32 I have used 'WaitForSingleObject' with 1ms time-out to work around this

I had thought about this solution. I'll implement it but I give it a low priority, as I think people do not often search for 'if' or 'wxString'.

Dje

Good work dje, I agree that your solution is better for the preview as it automatically centres regardless of control height (plus mine was a bit of a hack just to show an idea ;)).

I hope you don't mind but I have attached a patch which implements some ideas wrt maximising the use of space available, the results of which can be seen in the attached png.  It would be nice if you'd consider adding these ideas - possibly as a few optional settings tucked away in the config dialog?

Also, I've noted a couple of minor issues below - if I get time I'll look into them if you like?

• Searching a file that has been modified (and saved) since previously previewed produces correct search results but the preview is not re-loaded to show the changes.  To recreate search a file and preview the result so the file is loaded.  Then, type some text into the same file, save, and then search for that text.  The result for the new text will be listed but when clicked upon it will be missing from the preview.   I've over complicated the explanation a bit but basically the preview needs to be reloaded if the file has been saved since last previewed.
  
  
• Some items are not sorted as expected.  For an example, please see the attached png - it seems the the results are mostly sorted except for the odd result from another file that interrupts the series.

QuoteI think people do not often search for 'if' or 'wxString'.

I think so too but it's damn annoying when you do and you can't cancel!!   :lol:

Jamie

[attachment deleted by admin]

Hi !

Quotepossibly as a few optional settings tucked away in the config dialog?

OK, that's what I'll do. I'll keep current settings as default because they match the 'Search results' panel ones.

QuoteSome items are not sorted as expected.

I had already noticed that point.
It happens only if you checked both 'Open files' and 'Project files' (as it seems to be on your picture).
For now, a wxSortedArrayString gathers all files from the different search scopes then the search is performed on each file.
All found items are appended to list control. I don't see for now why it behaves that why (but I didn't have time to debug it).
It could help me if you could have a look !

QuoteI think so too but it's damn annoying when you do and you can't cancel!!

I'll improve it !

QuoteSearching a file that has been modified (and saved) since previously previewed produces correct search results but the preview is not re-loaded to show the changes.

I noticed the 'not reloading' problem.
It can be a little tricky to look for file change, reload file and perform a list and preview refresh. How can you be sure to get the good line, I mean suppose you get current selected list item, you are not sure the same text won't be inserted, the text preview may not be focused on the selected item. In fact, I think it is a very hard thing to synchronize preview with file change and to be sure to do it well !
I chose this strategy because of the previous difficulty and because this strategy is the same as C::B 'Search in files'.

I know I often say 'I already saw that point', but it is true I developped this on a long time and tested it so that I thought and found lots of things (either minor problems or evolutions) I didn't write to avoid beginning the post with 200 pages  :D

Dje

Quote from: dje on March 20, 2007, 08:39:56 AM
OK, that's what I'll do. I'll keep current settings as default because they match the 'Search results' panel ones.

Cool, I look forward to your next build!  :)

QuoteIt happens only if you checked both 'Open files' and 'Project files'.

Ah...  I had not investigated it but can confirm unticking 'Open files' does the trick for now, cheers...  I will try to look into it.

QuoteI think it is a very hard thing to synchronize preview with file change and to be sure to do it well !

I didn't explain it very well so I think we misunderstand each other.  I'm not referring to unsaved changes made to a file, I mean if a change is made and then saved but the older version is already in the preview it won't get updated until you first preview a different file because of the following code which is there for good reason.

// Loads file if different from current loaded
if ( m_PreviewFilePath != sFile )


I have two suggestions to improve this (neither I know how to do in wxWidgets  - I'll look into it, but you may be able to do it more easily)...

Either save the file modified time with the file name and then compare them as well, ex:

// Loads file if different from current loaded
if ( (m_PreviewFilePath != sFile) || ( newFiletime != oldFiletime ) )


Or, hook into codeblocks somewhere so whenever a file is saved you reload your preview if it's the same file.  I'm sure there are other ways..

QuoteI know I often say 'I already saw that point', but it is true.

Hey, I don't mind - the points I've raised are of the more obvious, usability type so that's why I started my first post saying 'it's possible they are already on your todo list...'   :)

Here's a patch that'll hopefully explain the file preview thing better (and fix it too!) ;)

To test:

• Perform a search so the preview is loaded with a file
• In the same file that is currently previewed, type some obscure text
• Save the file!
• Right click the new text and 'find occurrences...'

The new text should be listed as a search result but won't be previewed as the file isn't reloaded, the purpose of this patch is to fix that.  :)

Jamie

[attachment deleted by admin]

BUG ALERT !!!

When a long search is performed (big directory), the application hangs on ui events until the thread is finished.

Sorry, probably due to the wxMutexGui... added.
I investigate...

Concerns only v 0.5.

Dje

Quote from: dje on March 21, 2007, 11:19:34 PM
BUG ALERT !!!

When a long search is performed (big directory), the application hangs on ui events until the thread is finished.

Sorry, probably due to the wxMutexGui... added.
I investigate...

Concerns only v 0.5.

Dje

I could be wrong about this, but....

I believe the fact that a GUI control (styledTextCtrl) is being instantiated and used in a secondary thread is the real problem.

Even though the control is "hidden" it still calls Update, Paint, SetFont, etc. It may not actually do the paint or setfont, but they're still called.

It makes cursor calls to bink the cursor, it makes paint and setfont calls when a file is loaded into its control, it makes update calls from OnIdle etc etc.

I found that I could get away with a lot of GUI calls in MSwindows in a secondary thread without a hang, but when I moved to Linux, it crashed and burned constantly.

I hope you can solve your problem, but I just want to mention this to keep you aware of the downside.

Hi,

it is a possible to mark text within the editor and then use the contextual menu: find occurance of: <selected text>.
I think it would be easier to use a short cut like Ctrl+Alt+F (like Search->Ffind) to put the selection directly to the Thread Search and then pressing return to get the search results.

Would this be much effort?

Bye,

Mario

Hi all !

I'm not dead !
I am working on the hanging bug !

Quoteit is a possible to mark text within the editor and then use the contextual menu: find occurance of: <selected text>.

I can change the default behaviour (find the word under cursor) to 'if selection, find selection else find the word under cursor'.
Is this what you would like ?

QuoteI think it would be easier to use a short cut like Ctrl+Alt+F (like Search->Ffind) to put the selection directly to the Thread Search and then pressing return to get the search results.

The Search->Thread search menu item will be modified.
I hesitate between running tne contextual 'Find occurrences' or your suggestion.

Dje