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
With regards, Morten.
Please 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())
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).
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
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)
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.
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.
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.
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 ! :)
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 ?
Even 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));
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.
This has been corrected with patch 1704 integration.
I think your nightly may be too old.
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.
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.
wxSystemSettings::GetColour(wxSYS_COLOUR_BTNFACE)
This works with
wxSystemSettings::GetColour(wxSYS_COLOUR_WINDOW)
I'll test it (not today) on my Linux environment.
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.
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.
The 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
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...
Yes, 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!).
wxSystemSettings::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.
it 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.
The 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]
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! :)
It 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.
I 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..
I 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...' :)