Author Topic: External use of cbEditor  (Read 13439 times)

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2165
Re: External use of cbEditor
« Reply #15 on: December 07, 2006, 04:42:05 pm »
I don't understand why the follwing code doesn't work:
Code: [Select]
// 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);
}

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.
« Last Edit: December 07, 2006, 05:32:44 pm by Pecan »

Offline dje

  • Lives here!
  • ****
  • Posts: 683
Re: External use of cbEditor
« Reply #16 on: December 07, 2006, 05:25:05 pm »
- 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

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2165
Re: External use of cbEditor
« Reply #17 on: December 07, 2006, 05:49:02 pm »
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.

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: External use of cbEditor
« Reply #18 on: December 07, 2006, 09:07:33 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.
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.

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.

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.
« Last Edit: December 07, 2006, 09:11:19 pm by Game_Ender »

Offline dje

  • Lives here!
  • ****
  • Posts: 683
Re: External use of cbEditor
« Reply #19 on: December 08, 2006, 10:59:37 am »
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.
The list control si the only shared resource so it is not too difficult to avoid headachs.

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.
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: [Select]
reinterpret_cast<cbEditor*>(m_pParent)->DisplayContextMenu(mp,mtEditorManager); //pecan 2006/03/22What do you think about replacing it by :
Code: [Select]
cbEditor* pParent = dynamic_cast<cbEditor*>(m_pParent);
if ( pParent != NULL )
{
pParent->DisplayContextMenu(mp,mtEditorManager);
}
else
{
event.Skip();
}
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.
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

Offline dje

  • Lives here!
  • ****
  • Posts: 683
Re: External use of cbEditor
« Reply #20 on: December 08, 2006, 11:39:00 am »
Hi !!

Tested my cbEditor evolution from :
Code: [Select]
void cbStyledTextCtrl::OnContextMenu(wxContextMenuEvent& event)
{
    if (m_pParent)
    {
        /*  or use noeditor to handle "contect menu" key?
         */
        const bool is_right_click = event.GetPosition()!=wxDefaultPosition;
        const wxPoint mp(is_right_click ? event.GetPosition() : wxDefaultPosition);
        reinterpret_cast<cbEditor*>(m_pParent)->DisplayContextMenu(mp,mtEditorManager); //pecan 2006/03/22
    }
}

To :
Code: [Select]
void cbStyledTextCtrl::OnContextMenu(wxContextMenuEvent& event)
{
    if ( m_pParent != NULL )
    {
        cbEditor* pParent = dynamic_cast<cbEditor*>(m_pParent);
        if ( pParent != NULL )
        {
            const bool is_right_click = event.GetPosition()!=wxDefaultPosition;
            const wxPoint mp(is_right_click ? event.GetPosition() : wxDefaultPosition);
            pParent->DisplayContextMenu(mp,mtEditorManager);
        }
        else
        {
            event.Skip();
        }
    }
}

I don't see any side effects or undesired behaviour.
Unless any remaks, I'll SVN this change.

Dje

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2165
Re: External use of cbEditor
« Reply #21 on: December 08, 2006, 01:33:26 pm »
Quote
Pekan, I found one of your modification in cbEditor.cpp :
Code:

reinterpret_cast<cbEditor*>(m_pParent)->DisplayContextMenu(mp,mtEditorManager); //pecan 2006/03/22

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();
}

Did you intentionnaly ommit the event.Skip ?
I think wxScintilla will be able to manage ctx menu with this evol.

Not intentional. Forgetting Skip()s is a common error.
I see you are going to submit a patch.
The core devs will have to approve and apply it.


Offline dje

  • Lives here!
  • ****
  • Posts: 683
Re: External use of cbEditor
« Reply #22 on: December 08, 2006, 01:52:55 pm »
Patch submitted, Id : 001704

BTW, are patches a mean to filter code modifs (instead of commit file directly) ?

Dje

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2165
Re: External use of cbEditor
« Reply #23 on: December 08, 2006, 02:00:59 pm »
Patch submitted, Id : 001704

BTW, are patches a mean to filter code modifs (instead of commit file directly) ?

Dje
Google: No definition found for modif.
If that means modifications? then yes. Only a few of the developers are allowed to modify the code directly.

Offline dje

  • Lives here!
  • ****
  • Posts: 683
Re: External use of cbEditor
« Reply #24 on: December 08, 2006, 03:31:49 pm »
Quote
If that means modifications?
Yes, probably to hungry :)

Dje

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: External use of cbEditor
« Reply #25 on: December 08, 2006, 10:37:47 pm »
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 ??

Yes, but always read the documentation.  When ever a user searches just spawn off a work thread.  Then use wxEvtHandler::AddPendingEvent/wxPostEvent to post an event to the main thread that another result is ready.  Do not use ProcessEvent it is not thread safe.

Offline dje

  • Lives here!
  • ****
  • Posts: 683
Re: External use of cbEditor
« Reply #26 on: December 08, 2006, 11:11:56 pm »
Quote
Yes, but always read the documentation.
Sorry; I read the doc after posting the message and found my answer. :?
The thread sample was useful too.

Dje