Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

Semantic highlight

<< < (12/16) > >>

MortenMacFly:

--- Quote from: mistar on June 16, 2012, 06:19:27 pm ---And how about function returning true when C::B is starting and false otherwise? You have Manager::IsAppShuttingDown but no counterpart on startup.

--- End quote ---
You can do it yourself easily: Have a global var "startupdone" that is false initially, connect to the "cbEVT_APP_STARTUP_DONE" event and set it to true if this fires. Combined with IsAppShuttingDown you get a method that "bools" if it is safe to operate or not.


--- Quote from: mistar on June 16, 2012, 06:19:27 pm ---Also, did you consider adding a mutex for each wxScintilla control that would be publicly available?

--- End quote ---
Well - that is not so easy. But what is wrong if you operate inside an event and call Skip() only if you have finished. This way you have the control exclusively during that time.

mistar:

--- Quote from: MortenMacFly on June 17, 2012, 12:20:40 pm ---
--- Quote from: mistar on June 16, 2012, 06:19:27 pm ---And how about function returning true when C::B is starting and false otherwise? You have Manager::IsAppShuttingDown but no counterpart on startup.

--- End quote ---
You can do it yourself easily: Have a global var "startupdone" that is false initially, connect to the "cbEVT_APP_STARTUP_DONE" event and set it to true if this fires. Combined with IsAppShuttingDown you get a method that "bools" if it is safe to operate or not.

--- End quote ---
I cannot do it in the plugin, it has to be provided from outside, that is from the main application. The reason is that attaching a plugin may occur after EVT_APP_STARTUP_DONE is fired (loading plugin via Plugins->Manage plugins).


--- Quote from: MortenMacFly on June 17, 2012, 12:20:40 pm ---
--- Quote from: mistar on June 16, 2012, 06:19:27 pm ---Also, did you consider adding a mutex for each wxScintilla control that would be publicly available?

--- End quote ---
Well - that is not so easy. But what is wrong if you operate inside an event and call Skip() only if you have finished. This way you have the control exclusively during that time.

--- End quote ---
The problem is that I do not want to block application until reparse-highlight process is completed, which may happen long time after OnTextChanged handler returns (I have threads, one for each editor for parsing/highlighting). Second, reparsing is much longer than highlighting and I need to lock the editor's control only for highlighting.
IMHO, Scintilla should take care of synchronizing access to the control, so I'll try to use one function (wxScintilla::SetStyleBytes) to do highlighting and maybe this helps.

mistar:
There are tools that should help in locking a mutex for an editor while updating the editor's control, but they do not work properly...
The solution would be to handle wxEVT_SCI_MODIFIED in the following way:
* if GetModificationType() is SC_MOD_BEFOREINSERT/SC_MOD_BEFOREDELETE (-> http://www.scintilla.org/ScintillaDoc.html#Notifications) then Lock the editor's mutex;
* if GetModificationType() is SC_MOD_INSERTTEXT/SC_MOD_DELETETEXT (which, according to the documentation, should occur after the control's modification) then Unlock the editor's mutex and do reparsing-highlighting;

However, I observed that updating control occurs after SC_MOD_INSERTTEXT/SC_MOD_DELETETEXT is handled (except for the first modification after startup...). Maybe I'm wrong and this is only delay in GUI redrawing...

I'm attaching sources. Note the lines 388-390 and 401-402 with wxSleep time-margins. To reproduce the behavior, just open C::B from command line so that you see the stderr output, place C::B with the terminal visible behind. The sequence in the terminal should be:

--- Code: ---*** before
(500 millisecond pause)
**** update
(control update)
(2000 millisecond pause)
*** after
--- End code ---
but is

--- Code: ---*** before
(500 millisecond pause)
**** update
(2000 millisecond pause)
*** after and control update simultaneously
--- End code ---

As for 'bool IsAppStartingUp()' function, shall I provide a patch?
If so, please guide me where to define the global variable 'bool isAppStarted' or so.
I understand that it should be set to true at the end of C::B's OnInit().
But it would be easier and faster if someone of C::B team could do it for me ;)

MortenMacFly:

--- Quote from: mistar on June 18, 2012, 12:42:38 pm ---As for 'bool IsAppStartingUp()' function, shall I provide a patch?

--- End quote ---
Yes, just do it similar to the IsShuttingDown method. I'm off the next few days - so you have enough time for a patch... Otherwise I can do if I'm back ;-)

mistar:

--- Quote from: MortenMacFly on June 18, 2012, 08:03:12 pm ---
--- Quote from: mistar on June 18, 2012, 12:42:38 pm ---As for 'bool IsAppStartingUp()' function, shall I provide a patch?

--- End quote ---
Yes, just do it similar to the IsShuttingDown method. I'm off the next few days - so you have enough time for a patch... Otherwise I can do if I'm back ;-)

--- End quote ---
Ok, I'll try to do it myself.

I also checked the exact order of scintilla's events and UI update and it is

--- Code: ---wxEVT_SCI_MODIFIED(BEFORE_INSERT/DELETE)
UI (control) update
wxEVT_SCI_MODIFIED(TEXTINSERT/DELETE)
--- End code ---
the first time editor is activated and

--- Code: ---wxEVT_SCI_MODIFIED(BEFORE_INSERT/DELETE)
wxEVT_SCI_MODIFIED(TEXTINSERT/DELETE)
UI (control) update
--- End code ---
each subsequent time. Really weird...
Is this scintilla's bug, or C::B? Or maybe scintilla buffers graphical updates on several inserts/deletes?

Nevertheless the plugin hasn't crashed since yesterday after adding some synchronization :)

Now I'm going to do the most stupid part, that is, to write configuration panel... ::)

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version