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

Offline dje

  • Lives here!
  • ****
  • Posts: 683
External use of cbEditor
« on: December 06, 2006, 10:40:27 am »
Hi !!

I am working on a plug-in and I would like to use the cbEditor class outside the wxFlatNotebook using the EditorManager.

This plug-in adds a Find occrences of: contextual menu item just below Find declaration of: and Find implementation of:
items.
Look at the attachment for a better global understanding.

The search looks like a Search in files with options on the panel but has the advantage is of using its own thread not to block the IDE when searching.
Results are redirected in a Search results log and propose a preview window.

I felt that need when diving into very large projects and beeing forced to switch from current editor and to change caret in current one when searching for items.

For now, I use the cbStyledTextCtrl with EditorColourSet to colorise but I would like to use cbEditor to manage all other user options and not reinvent the wheel.

Is it possible to change the API, changing from private to public some method mike SetEditorStyleBeforeFileOpen ??

By the way, are you interested in such a plug-in ?

Thanks

Dje


[attachment deleted by admin]

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: External use of cbEditor
« Reply #1 on: December 06, 2006, 02:06:17 pm »
Quote
For now, I use the cbStyledTextCtrl with EditorColourSet to colorise but I would like to use cbEditor to manage all other user options and not reinvent the wheel.

Is it possible to change the API, changing from private to public some method mike SetEditorStyleBeforeFileOpen ??

cbEditor is tightly coupled because it has to be (for various reasons). What is it exactly that you would do with cbEditor that you can't do with cbStyledTextCtrl? I 'd be happy to help you and even provide API access to any internals you would like, but not without a good reason too. So please explain a bit more.
Be patient!
This bug will be fixed soon...

Offline dje

  • Lives here!
  • ****
  • Posts: 683
Re: External use of cbEditor
« Reply #2 on: December 06, 2006, 02:25:52 pm »
I'd like to use the same configuration for my preview window as for the editor.

I am interested in all "already implemented" services concerning control management :
  • colours
  • folding
  • indentation
  • font
  • bookmark
  • contextual menu
  • keyboard shortcuts (Ctrl+C)

For colours, I use :
Code
EditorColourSet EdColSet;
EdColSet.Apply(EdColSet.GetLanguageForFilename(m_sPreviewFilePath), m_pSearchPreview);

But that's too limited.

Basically, for now, I need API to:
  • create my control on my panel
  • styling methods (SetEditorStyle()),

The idea is to provide a read only cbEditor to the user to be able to browse code without losing his "main" editor/position.

Thanks,

Dje

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: External use of cbEditor
« Reply #3 on: December 06, 2006, 02:48:52 pm »
So you just want SetEditorStyleBeforeFileOpen() and SetEditorStyleAfterFileOpen() made public?
If that is so, then it is doable. Just say the word ;).

For more, don't even bother to ask. Not now that we 're heading into the API freeze.
Be patient!
This bug will be fixed soon...

Offline dje

  • Lives here!
  • ****
  • Posts: 683
Re: External use of cbEditor
« Reply #4 on: December 06, 2006, 03:06:50 pm »
Yes, please  :wink:

I think it is sufficient.

What about the constructor ??
In header, there is
Note: you should not create a cbEditor object directly. Instead use EditorManager's methods to do it...

For sure I won't use EditorManager for creation as I want to be independant from the wxFlatNotebook...
Anything particular to know about construction requirements ??

Thanks,

Dje

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: External use of cbEditor
« Reply #5 on: December 06, 2006, 03:38:42 pm »
What about the constructor ??
In header, there is
Note: you should not create a cbEditor object directly. Instead use EditorManager's methods to do it...

For sure I won't use EditorManager for creation as I want to be independant from the wxFlatNotebook...
Anything particular to know about construction requirements ??

Maybe you misunderstood something. You will not be able to create a new cbEditor, as a matter of fact I moved the constructors/destructor to protected scope.
But I have added a static function cbEditor::ApplyStyles(cbStyledTextCtrl*). Just feed this function with your cbStyledTextCtrl* and it will set it up like internal editors are setup.

Note: I haven't yet committed the above, but I will do so once I verify everything works as expected.
Be patient!
This bug will be fixed soon...

Offline dje

  • Lives here!
  • ****
  • Posts: 683
Re: External use of cbEditor
« Reply #6 on: December 06, 2006, 03:46:22 pm »
Ok, my SVN code from yesterday shew me public.

That's OK for me.

I can help you to test it in my case...

Thanks again,

Dje

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: External use of cbEditor
« Reply #7 on: December 06, 2006, 04:06:26 pm »
Just committed what I posted in my previous message. Feel free to test it.
Be patient!
This bug will be fixed soon...

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: External use of cbEditor
« Reply #8 on: December 06, 2006, 04:10:39 pm »
very interested in that plug-in :-)

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: External use of cbEditor
« Reply #9 on: December 06, 2006, 05:03:08 pm »
off topic a little, but...

Not now that we 're heading into the API freeze.

Does this mean you won't be doing anything with the debugger plugin API until v1.x?
(Since I'm the only one who seems to need changes to this part of API and the apparently the only person that uses my python debugger plugin, I'm not all that concerned, but it will help my planning to know what's in store.)

It would be nice if you could post a message sometime soon about this feature freeze.

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: External use of cbEditor
« Reply #10 on: December 06, 2006, 05:41:55 pm »
Not now that we 're heading into the API freeze.

Does this mean you won't be doing anything with the debugger plugin API until v1.x?
(Since I'm the only one who seems to need changes to this part of API and the apparently the only person that uses my python debugger plugin, I'm not all that concerned, but it will help my planning to know what's in store.)

I 'm talking about the SDK API (sdk/*.h). Any plugin's interface can change without causing any problems. But the main SDK interfaces won't change after that.

It would be nice if you could post a message sometime soon about this feature freeze.

There will be a public announcement a few days before we enter the freeze.
Be patient!
This bug will be fixed soon...

Offline dje

  • Lives here!
  • ****
  • Posts: 683
Re: External use of cbEditor
« Reply #11 on: December 06, 2006, 06:02:41 pm »
Quote
Just committed what I posted in my previous message. Feel free to test it.

Great !!!  :D
It works as expected !!

Thanks for the evolution.

A problem still remains; I'd like to handle margin click and added this code :
Code
index = m_pSearchPreview->GetId();
Connect(index, -1, wxEVT_SCI_MARGINCLICK,   (wxObjectEventFunction) (wxEventFunction) (wxScintillaEventFunction)   &cbEditor::OnMarginClick );

but cbEditor::OnMarginClick is private.
Is it possible to make it public too ?

Dje



Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: External use of cbEditor
« Reply #12 on: December 06, 2006, 06:39:31 pm »
I 'm talking about the SDK API (sdk/*.h). Any plugin's interface can change without causing any problems. But the main SDK interfaces won't change after that.

in our last exchange, you hinted at changing the way debuggers are handled:

Quote
What I plan to add soon is a language enum so that each compiler/debugger can report the languages it supports. Consequently, the editor will send breakpoint events to the debugger that should handle them.

would this not affect the SDK?

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: External use of cbEditor
« Reply #13 on: December 06, 2006, 07:11:12 pm »
would this not affect the SDK?

Have we entered the freeze yet and I 'm not aware? ;)
Be patient!
This bug will be fixed soon...

Offline dje

  • Lives here!
  • ****
  • Posts: 683
Re: External use of cbEditor
« Reply #14 on: December 07, 2006, 03:55:31 pm »
Hi !!

Quote
but cbEditor::OnMarginClick is private.
Is it possible to make it public too ?

Waiting for an answer, I adapted the cbEditor::OnMarginClick in my class to handle only folding events.

I would like to use the default contextual menu.
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);
}

Any idea ??

When I use the EVT_CONTEXT_MENU and EVT_RIGHT_UP macros, the right clicks on panel are correctly handled, but not on cbStyledTextCtrl (for sure, no id provided...).

Thanks for support,

Dje

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
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
// 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: 2750
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
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.

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
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
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: 2750
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: 2750
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