Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
[Minor visual bug] Syntax and comments
oBFusCATed:
--- Quote from: jens on March 21, 2013, 09:44:49 am ---Why is it a bug ?
--- End quote ---
Because it triggers for non-wxsmith comments. And when it triggers for non-wxsmith comment, most of the times there is no //*)
(or whatever is the proper closing comment), so the whole file ends up being marked as one big wxsmith block.
Alpha:
For reference purposes, here are the comments that list out the names of all blocks (to my knowledge) that wxSmith generates. If we want to make the wxSmith code highlighting more restrictive, we could explicitly enumerate the allowed block names.
src/plugins/contrib/wxSmith/wxscoder.h 163
--- Code: ---/** \page Auto-Code Code automatically generated by wxSmith
*
* Here's list of automatically generated code:
*
* \li \c //(*EventTable($CLASSNAME) - generated in class source file, contains
* entries for event table
* \li \c //(*Initialize($CLASSNAME) - generated in class source file, this code
* does all resource initialization (loading
* XRC, adding widgets etc.)
* \li \c //(*Headers($CLASSNAME) - generated in class header file, this block
* contains set of #includes including required
* header files for this resource
* \li \c //(*Identifiers($CLASSNAME) - generated in class header file, this
* code generates identifiers for window
* items (usually enum), in case of XRC
* resource (with it's own identifier
* handling system), it will be empty
* \li \c //(*Handlers($CLASSNAME) - generated in class header. It contains
* declarations of event handler functions,
* inside this code, user may put it's own
* event handler declarations but they must
* be in form:
* void HandlerName(eventType& event).
* This block is parsed when generating list
* of event handlers which may be used with
* given event type.
* \li \c //(*Declarations($CLASSNAME) - declarations of window items. This
* block will contain declarations of all
* window items which have "Is Member"
* property set to true.
*
* Blocks which will be added in future:
*
* \li \c //(*AppHeaders - declared in main application's source file.
* This block will contain set of #includes
* required by application.
* \li \c //(*AppInitialize - declared in main application's source file.
* This block will automatically load resources
* and show main application's window
*/
--- End code ---
src/plugins/contrib/wxSmith/wxsversionconverter.cpp 198
--- Code: --- // Need to add two new sections: //(*InternalHeaders and //(*IdInit
// to do this //(*InternalHeaders will be added before any source code
// but after all #xxx directives
// //(*IdInit will be added just before //(*EventTable nearrest line
// before that section containing BEGIN_EVENT_TABLE
//
// This may not be tricky enough but I hope that not much people mess
// with code generated by wxSmith from templates ;)
//
// BTW we do not use wxsCodeMarks::Beg and wxsCodeMarks::End because that could
// cause some problems with future conversion of these marks
// (upgrade of old-wxSmith project will be done in two steps then,
// first - convertion to version 1 of new wxsmith and then upgrading to
// higher version so if convention of code marks will change, it will
// break the conversion chain)
--- End code ---
Alpha:
For example:
--- Code: ---Index: src/sdk/wxscintilla/src/scintilla/lexers/LexCPP.cxx
===================================================================
--- src/sdk/wxscintilla/src/scintilla/lexers/LexCPP.cxx (revision 8909)
+++ src/sdk/wxscintilla/src/scintilla/lexers/LexCPP.cxx (working copy)
@@ -854,12 +854,33 @@
/* C::B begin */
else if (sc.Match("//(*") && options.highlightWxSmith) {
// Support for wxSmith auto-generated code
- sc.SetState(SCE_C_WXSMITH|activitySet);
- sc.Forward(4);
- sc.SetState(SCE_C_COMMENTLINE|activitySet);
- while (!sc.atLineEnd)
- sc.Forward();
- sc.SetState(SCE_C_WXSMITH|activitySet);
+ char* blockIds[] = {"//(*AppHeaders",
+ "//(*AppInitialize",
+ "//(*Declarations",
+ "//(*Destroy",
+ "//(*EventTable",
+ "//(*Handlers",
+ "//(*Headers",
+ "//(*IdInit",
+ "//(*Identifiers",
+ "//(*Initialize",
+ "//(*InternalHeaders",
+ 0};
+ int i = 0;
+ for (; blockIds[i]; ++i) {
+ if (sc.Match(blockIds[i]))
+ break;
+ }
+ if (blockIds[i]) {
+ sc.SetState(SCE_C_WXSMITH|activitySet);
+ sc.Forward(4);
+ sc.SetState(SCE_C_COMMENTLINE|activitySet);
+ while (!sc.atLineEnd)
+ sc.Forward();
+ sc.SetState(SCE_C_WXSMITH|activitySet);
+ }
+ else
+ sc.SetState(SCE_C_COMMENTLINE|activitySet);
}
/* C::B end */
else
--- End code ---
(Disclaimer: this code was quickly written, and is suboptimal.)
MortenMacFly:
--- Quote from: Alpha on March 21, 2013, 10:11:07 pm ---we want to make the wxSmith code highlighting more restrictive,
--- End quote ---
Thats an option. But honestly I think most user will be happy to know that another space will "fix" the highlighting issue. I think the proposed solution with having the option disabled by default might be the easiest thing to do and we will never forget to change the wxScintilla portion if we change wxSmith.
Although I personally would do exactly nothing about it.
oBFusCATed:
--- Quote from: MortenMacFly on March 22, 2013, 11:24:29 am ---I think most user will be happy to know that another space will "fix" the highlighting issue.
--- End quote ---
No they won't, at least the ones using it for work projects and where the source is stored in a VCS.
Committing such thing will look ridiculous :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version