Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
External use of cbEditor
Pecan:
--- Quote from: dje on December 07, 2006, 03:55:31 pm ---I don't understand why the follwing code doesn't work:
--- Code: ---// Panel constructor
id = m_pSearchPreview->GetId();
Connect(id, wxEVT_SCI_MARGINCLICK,
(wxObjectEventFunction) (wxEventFunction) (wxScintillaEventFunction)
&FindOccurrencesView::OnMarginClick); // OK
Connect(id, wxEVT_CONTEXT_MENU,
(wxObjectEventFunction) (wxEventFunction) (wxContextMenuEventFunction)
&FindOccurrencesView::OnContextMenu); // KO
Connect(id, wxEVT_RIGHT_UP,
(wxObjectEventFunction) (wxEventFunction) (wxMouseEventFunction)
&FindOccurrencesView::OnMouseRightUp); // KO
// End of panel constructor
// m_pSearchPreview is a cbStyledTextCtrl*
void FindOccurrencesView::OnContextMenu(wxContextMenuEvent& event)
{
m_pSearchPreview->ProcessEvent(event);
}
void FindOccurrencesView::OnMouseRightUp(wxMouseEvent& event)
{
m_pSearchPreview->ProcessEvent(event);
}
--- End code ---
--- End quote ---
It occurs to me that "id" had better be the same value as the scintilla object you wish to intercept if you want those objects' events. Yet you've assigned a new one instead. Are you sure the id is the correct object?
Be aware of which events propagate (regardless/upward) of id, and those which dont.
scintilla is a textCtrl, so you have to connect to a textCtrl's id. It doesn't propagate events outside it's own id.
Also, scintilla has a nasty habit of not event.Skip()'ing. I've had to delve into the code to see which events it eats instead of passing off to other users.
Someone else (another event handler) may be doing a return instead of a Skip() on this event.
Try obtaining,verifying and Connect()'ing to the scintilla (not an intervening object) id first, if that doesn't work, read the code (eventHandler chain) 8-(. I'll bet you'll find a non Skip()'ing event handler(cbEditor?,cbStyledTextCtrl?), or that scintilla has a condition that causes it to not issue the event.
As an aside, you might look at stEdit. You can invoke it with a copy of the cbEditor settings, but have full control of all scintilla events(devoid of others failing to Skip() ). You can use the CB scintilla DLL directly without having to create another dll. StEdit has a nice example of a one line instantiation after having set all the settings you like.
Nice!
StEdit invoked (not instantiated) from a plugin with customized CB settings.
dje:
- Navigating the classes, id is only defined in wxControl, which is the one I use
- the only object that could have another id is the ScintillaWX named m_swx declared in wxScintilla
- ScintillaWX is a ScintillaBase, which is an Editor, which is a DocWatcher.
I didn't find the wxTextCtrl...
Moreover, all creations do not provide any id and there is no accessor to get them...
I'd have preferred using directly a cbEditor but Mandrav told it was not possible...
I'm not keen on using another control like stEdit because I would like to keep the same direction as C::B on managing editors.
Maybe I'll have a look at this fabulous event chain... or I may forget the contextual menu, Ctrl+C works !! :)
Do you think it would be very valuable for the plug-in (desc at the top of the post) ?
Thanks,
Dje
Pecan:
I truely like your idea of a "find in files" in another thread.
I find three problems with the implementation.
1) Your talking about using gui controls in a separate thread. This causes major problems with wxWidgets. Or, if executed properly, most likely needs critical sections that will cause present and future headachs to both CB and your plugin.
2) If going to all this trouble, the "find in files" idea should be expanded to other utility features, such as maybe actually editing in the editor.
3) Tightly tieing a complex plugin to cbEditor (or any core/sdk interface) is asking to chase the a mandrav rabbit. This is impossible. No one, not even my terrier, could keep up with such a beast.
I think it's best that you use what's necessary from the sdk, but uncouple from it. You'll progress faster and won't have to constantly keep up with mods in CB.
My 2cents worth.
Game_Ender:
--- Quote from: Pecan on December 07, 2006, 05:49:02 pm ---1) Your talking about using gui controls in a separate thread. This causes major problems with wxWidgets. Or, if executed properly, most likely needs critical sections that will cause present and future headachs to both CB and your plugin.
--- End quote ---
Let me second this. Do not touch wxWidgets gui classes in a worker thread. I believe the CodeCompletion plugin used to/does this and its error prone and not supported by wxWidgets. It should be pretty simple to run the search in another thread and post events to the main thread when you get each result back. wxWidgets has function to posting messages from a worker thread back the main thread.
--- Quote from: Pecan on December 07, 2006, 05:49:02 pm ---3) Tightly tieing a complex plugin to cbEditor (or any core/sdk interface) is asking to chase the a mandrav rabbit. This is impossible. No one, not even my terrier, could keep up with such a beast.
--- End quote ---
That shouldn't matter once the SDK api is frozen for the first release. The whole point of the SDK is to use, if there are parts that can't be used reliably it wouldn't make sense to have them public.
dje:
--- Quote from: Pecan on December 07, 2006, 05:49:02 pm ---1) Your talking about using gui controls in a separate thread. This causes major problems with wxWidgets. Or, if executed properly, most likely needs critical sections that will cause present and future headachs to both CB and your plugin.
--- End quote ---
The list control si the only shared resource so it is not too difficult to avoid headachs.
--- Quote from: Pecan on December 07, 2006, 05:49:02 pm ---2) If going to all this trouble, the "find in files" idea should be expanded to other utility features, such as maybe actually editing in the editor.
--- End quote ---
I already thought about it but, at the beginning, I prefer a first read only version and propose edition (if I succeed in implementation) later.
Pekan, I found one of your modification in cbEditor.cpp :
--- Code: ---reinterpret_cast<cbEditor*>(m_pParent)->DisplayContextMenu(mp,mtEditorManager); //pecan 2006/03/22
--- End code ---
What do you think about replacing it by :
--- Code: ---cbEditor* pParent = dynamic_cast<cbEditor*>(m_pParent);
if ( pParent != NULL )
{
pParent->DisplayContextMenu(mp,mtEditorManager);
}
else
{
event.Skip();
}
--- End code ---
Did you intentionnaly ommit the event.Skip ?
I think wxScintilla will be able to manage ctx menu with this evol.
Game_Ender, when you say :
--- Quote ---It should be pretty simple to run the search in another thread and post events to the main thread when you get each result back. wxWidgets has function to posting messages from a worker thread back the main thread.
--- End quote ---
Do you mean creating a custom event in my panel class and using AddPendingEvent/ProcessEvent from my worker thread (called Search method in included in panel class for now) ?
Finally, I thought that wxWidgets was the quasi-unique multi-threaded ui framework.
When I read this post remarks, I doubt. Does any one have a sure answer on this point ??
Thanks to all,
Dje
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version