Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
ThreadSearch 0.7 release
dje:
Hi !
@dmoore, I'll have a look this WE, I find your idea very interesting (ThreadSearch external calls).
For now, Search in dir is possible, not search in file.
For the near future:
* Morten's bug fix (crash on plugin disable). It does not look too difficult.
* windows project rework to put threadSearch plugin under SVN contrib plugins.
* pictures management
@Pecan
--- Quote ---I'll use ThreadSearch a the guinea pig if that's ok with dje
--- End quote ---
Shame on my English :oops:
I don't understand what you mean
Dje
MortenMacFly:
--- Quote from: dje on June 29, 2007, 05:00:24 pm ---
--- Quote ---I'll use ThreadSearch a the guinea pig if that's ok with dje
--- End quote ---
I don't understand what you mean
--- End quote ---
Me not, too. WiKiPedia has a lot of different meanings for that but I'd say none of them really matches... Hehe...:
http://en.wikipedia.org/wiki/Guinea_pig_%28disambiguation%29
Edit: Ah:
# (idiomatic) A person who volunteers for an experiment or to try anything new; an experimental subject (from the use of the rodent in laboratory experiments).
e.g. "Would you like to be the guinea pig for our new product concept?"
dmoore:
--- Quote from: dje on June 29, 2007, 05:00:24 pm ---@dmoore, I'll have a look this WE, I find your idea very interesting (ThreadSearch external calls).
For now, Search in dir is possible, not search in file.
--- End quote ---
thanks for taking the time. the nice thing is that I don't need to do anything on my end that's specific to ThreadSearch (i.e. the fileexplorer will add whatever items that any plugin wants to put into the fileexplorer context menu). the plugin architecture takes care of the communication between the two plugins, so you don't have to worry about messy #includes.
I realize that search in file isn't possible, but just left it in to show the possibilities (I did take out the more complex multiple file/directory targets, which sends a list of a space separated files and directories that the user selected before right clicking)
btw, it could have been something I did wrong, but I was getting a crash on exit (even without starting up a threadsearch)
Pecan:
--- Quote from: dmoore on June 29, 2007, 04:49:17 pm ---
--- Quote from: Pecan on June 29, 2007, 04:32:37 pm ---To my knowledge, there is currently no way that .cbplugin images get copied to the necessary CB share directories.
So leaving the images in the zip file will not work.
--- End quote ---
Pecan: can you explain this in more detail? I have an xrc toolbar in my Python plugin that loads a bunch of images. those images are all stored in the PyPlugin.zip along with the xrc file and the manifest and it *appears* to work fine.... So you must be talking about a different case?
--- End quote ---
You have an .xrc that gets loaded with LoadResources(), I guess, which in turn loads the .png from the resource .zip.
However, ThreadSearch has no .xrc, but a bunch of .png's .
So they're being loaded via cbLoadBitmap() or new() etc.
That's ok when they're already extracted in .../images/16x16 etc, but if they're in the .zip with no xrc, some routine has to go extract them.
I was thinking that the easiest solution is simply to glom onto the CB plugin .zip extraction routine, modify it, & use it locally to grab the needed .png when needed.
dmoore:
hmm... it would be possible to specify a sequence of wxBitMaps in an XRC file as follows:
--- Code: ---<resource>
<object class="wxBitmap" name="img1">images/image1.png</object>
<object class="wxBitmap" name="img2">images/image2.png</object>
etc...
</resource>
--- End code ---
zip the XRC in with the images and manifest (using the relative paths for the images as in the xrc). Then after you call
--- Code: ---Manager::LoadResource(_T("myplugin.zip");
--- End code ---
you can access your images with
--- Code: --- wxBitmap bmp;
// typedef
bmp = wxXmlResource::Get()->LoadBitmap(_T("img1"));
--- End code ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version