Sorry
Maybe this is a trivial question.
I went back to code: blocks after four years.
And this is perhaps the main reason for my questions
I am trying to debug the program.
In the editor, is highlighted in the program code, depending on Conditional.
But not the one who should.
The example given shows where debugging.
The code in the editor should be highlighted, and it is not.
I can not control it.
Please help (links) explaining what I need to do to properly
were sublight space depending on the conditional
(http://codeblock.png)
Please search the forum before you ask, this has been answered many times.
Here the quick answer: This is a feature of the (3rd party) editor control we use (scintilla) which is far from being perfect. In fact, it works for simple cases, but mostly it fails. If you don't like it, please disable it in the editor options.
Thanks for the answer,
Believe me that before I was looking for answers.
It was of course a lot but not to the point.
Only when you have entered a scintilla, I found a hint.
Search Google for example, will adjust to what before you scan for. That's why I could not get through the amount of information.
But I really thank you for the tip because I thought it was my fault or you need to set some parameters.
Is it possible to improve this tool because it is very useful for large projects
SmallTed
Quote from: SmallTed on December 11, 2015, 09:29:34 PM
Is it possible to improve this tool because it is very useful for large projects
Sure it is, but this is probably a question you should ask the scintilla maintainer or find out yourself (depending on your programming skills).
There are several ideas to implement this feature(but that need some code changes in Scintilla's code base)
1, I see Huki try to implement this: see his commits: Scintilla: [huki] CB - support "grey out inactive" using CC plugin. (https://github.com/gk7huki/codeblocks_sf/commit/a8202025effa4ba041d8d991ad7d35bf7ce86bc7) and the following two commits. This is quite similar like the one Alpha try to make the variable highlight, see: CC based semantic highlight (http://forums.next.codeblocks.org/index.php/topic,17526.msg120138.html#msg120138), I see that Alpha's code is not landed in our C::B's code base.
This kinds of methods is try to let scintilla call some function of our CC.
My idea is slightly different with Huki's, that is: CC can record all the #if xxx lines , and record all the calculated value of xxx in a database, either it is "true" or "false", and the scintilla just need to read the value, and see whether the next code need to be grayed out.
2, The method Alpha's added to our C::B's code base is try to set the keywords of the the member variables, such as the function in our C::B:
void CodeCompletion::UpdateEditorSyntax(cbEditor* ed)
{
if (!Manager::Get()->GetConfigManager(wxT("code_completion"))->ReadBool(wxT("/semantic_keywords"), false))
return;
if (!ed)
ed = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
if (!ed || ed->GetControl()->GetLexer() != wxSCI_LEX_CPP)
return;
TokenIdxSet result;
int flags = tkAnyContainer | tkAnyFunction;
if (ed->GetFilename().EndsWith(wxT(".c")))
flags |= tkVariable;
m_NativeParser.GetParser().FindTokensInFile(ed->GetFilename(), result, flags);
TokenTree* tree = m_NativeParser.GetParser().GetTokenTree();
std::set<wxString> varList;
TokenIdxSet parsedTokens;
CC_LOCKER_TRACK_TT_MTX_LOCK(s_TokenTreeMutex)
for (TokenIdxSet::const_iterator it = result.begin(); it != result.end(); ++it)
{
Token* token = tree->at(*it);
if (!token)
continue;
if (token->m_TokenKind == tkVariable) // global var - only added in C
{
varList.insert(token->m_Name);
continue;
}
else if (token->m_TokenKind & tkAnyFunction) // find parent class
{
if (token->m_ParentIndex == wxNOT_FOUND)
continue;
else
token = tree->at(token->m_ParentIndex);
}
if (!token || parsedTokens.find(token->m_Index) != parsedTokens.end())
continue; // no need to check the same token multiple times
parsedTokens.insert(token->m_Index);
for (TokenIdxSet::const_iterator chIt = token->m_Children.begin();
chIt != token->m_Children.end(); ++chIt)
{
const Token* chToken = tree->at(*chIt);
if (chToken && chToken->m_TokenKind == tkVariable)
{
varList.insert(chToken->m_Name);
}
}
// inherited members
if (token->m_Ancestors.empty())
tree->RecalcInheritanceChain(token);
for (TokenIdxSet::const_iterator ancIt = token->m_Ancestors.begin();
ancIt != token->m_Ancestors.end(); ++ancIt)
{
const Token* ancToken = tree->at(*ancIt);
if (!ancToken || parsedTokens.find(ancToken->m_Index) != parsedTokens.end())
continue;
for (TokenIdxSet::const_iterator chIt = ancToken->m_Children.begin();
chIt != ancToken->m_Children.end(); ++chIt)
{
const Token* chToken = tree->at(*chIt);
if ( chToken && chToken->m_TokenKind == tkVariable
&& chToken->m_Scope != tsPrivate) // cannot inherit these...
{
varList.insert(chToken->m_Name);
}
}
}
}
CC_LOCKER_TRACK_TT_MTX_UNLOCK(s_TokenTreeMutex)
EditorColourSet* colour_set = Manager::Get()->GetEditorManager()->GetColourSet();
if (!colour_set)
return;
wxString keywords = colour_set->GetKeywords(ed->GetLanguage(), 3);
for (std::set<wxString>::const_iterator keyIt = varList.begin();
keyIt != varList.end(); ++keyIt)
{
keywords += wxT(" ") + *keyIt;
}
ed->GetControl()->SetKeyWords(3, keywords);
ed->GetControl()->Colourise(0, -1);
}
I see it just feed the "keywords" of the scintilla, and the scintilla will automatically highlight those words.
So, similar, we can feed the scintilla with another keywords(which is all the macro definitions). I see there is a page describe here: - http://www.scintilla.org/nulex.html
lexer.cpp.track.preprocessor=1
lexer.cpp.update.preprocessor=1
keywords5.$(file.patterns.cpp)=\
PLAT_GTK=1 \
_MSC_VER \
PLAT_GTK_WIN32=1
...
So, maybe, we need to feed the "keywords5" to scintilla with all the macros we get from the TokenTree.
As I see scintilla's some document: Upcoming 3.4.2 - Google Groups (https://groups.google.com/forum/#!searchin/scintilla-interest/preprocessor$20highlight/scintilla-interest/bR11THNxYXs/QLArJ793D2EJ) years ago, it said:
Quote
C++ lexer understands more preprocessor statements. #if defined SYMBOL is understood. Some macros with arguments can be understood and these may be predefined in keyword set 4 (keywords5 for SciTE) with syntax similar to CHECKVERSION(x)=(x<3). Feature #1051.
So, we can let its C++ lexer to handle all the #if like preprocessor statements.
Any good ideas?
EDIT: it looks like the method 2 I said above do not need to change the scintilla's code base, right?
OK, I see the method 2 is partially implemented, as I see we already have a function named:
void EditorManager::CollectDefines(CodeBlocksEvent& event)
{
cbProject* prj = Manager::Get()->GetProjectManager()->GetActiveProject();
if ( !prj
|| !Manager::Get()->GetConfigManager(wxT("editor"))->ReadBool(wxT("/track_preprocessor"), true)
|| !Manager::Get()->GetConfigManager(wxT("editor"))->ReadBool(wxT("/collect_prj_defines"), true) )
{
event.Skip();
return;
}
wxArrayString compilerFlags = prj->GetCompilerOptions();
ProjectBuildTarget* tgt = prj->GetBuildTarget(prj->GetActiveBuildTarget());
FilesList* lst;
wxString id;
if (tgt)
{
AppendArray(tgt->GetCompilerOptions(), compilerFlags);
lst = &tgt->GetFilesList();
id = tgt->GetCompilerID();
}
else
{
lst = &prj->GetFilesList();
id = prj->GetCompilerID();
}
Compiler* comp = CompilerFactory::GetCompiler(id); // get global flags
if (comp)
AppendArray(comp->GetCompilerOptions(), compilerFlags);
wxArrayString defines;
for (size_t i = 0; i < compilerFlags.GetCount(); ++i)
{
if ( compilerFlags[i].StartsWith(wxT("-D"))
|| compilerFlags[i].StartsWith(wxT("/D")) )
{
defines.Add(compilerFlags[i].Mid(2));
}
else if (compilerFlags[i].Find(wxT("`")) != wxNOT_FOUND)
{
wxString str = compilerFlags[i];
ExpandBackticks(str);
str.Replace(wxT("`"), wxT(" ")); // remove any leftover backticks to prevent an infinite loop
AppendArray(GetArrayFromString(str, wxT(" ")), compilerFlags);
}
else if ( compilerFlags[i] == wxT("-ansi")
|| compilerFlags[i] == wxT("-std=c90")
|| compilerFlags[i] == wxT("-std=c++98"))
{
defines.Add(wxT("__STRICT_ANSI__"));
}
}
defines.Add(wxT("__cplusplus"));
for (FilesList::iterator it = lst->begin(); it != lst->end(); ++it)
{
if ((*it)->relativeFilename.EndsWith(wxT(".c")))
{
defines.RemoveAt(defines.GetCount() - 1); // do not define '__cplusplus' if even a single C file is found
break;
}
}
if (id.Find(wxT("gcc")) != wxNOT_FOUND)
{
defines.Add(wxT("__GNUC__"));
defines.Add(wxT("__GNUG__"));
}
else if (id.Find(wxT("msvc")) != wxNOT_FOUND)
{
defines.Add(wxT("_MSC_VER"));
defines.Add(wxT("__VISUALC__"));
}
if (Manager::Get()->GetConfigManager(wxT("editor"))->ReadBool(wxT("/platform_defines"), false))
{
if (platform::windows)
{
defines.Add(wxT("_WIN32"));
defines.Add(wxT("__WIN32"));
defines.Add(wxT("__WIN32__"));
defines.Add(wxT("WIN32"));
defines.Add(wxT("__WINNT"));
defines.Add(wxT("__WINNT__"));
defines.Add(wxT("WINNT"));
defines.Add(wxT("__WXMSW__"));
defines.Add(wxT("__WINDOWS__"));
if (platform::bits == 64)
{
defines.Add(wxT("_WIN64"));
defines.Add(wxT("__WIN64__"));
}
}
else if (platform::macosx)
{
defines.Add(wxT("__WXMAC__"));
defines.Add(wxT("__WXOSX__"));
defines.Add(wxT("__WXCOCOA__"));
defines.Add(wxT("__WXOSX_MAC__"));
defines.Add(wxT("__APPLE__"));
}
else if (platform::linux)
{
defines.Add(wxT("LINUX"));
defines.Add(wxT("linux"));
defines.Add(wxT("__linux"));
defines.Add(wxT("__linux__"));
}
else if (platform::freebsd)
{
defines.Add(wxT("FREEBSD"));
defines.Add(wxT("__FREEBSD__"));
}
else if (platform::netbsd)
{
defines.Add(wxT("NETBSD"));
defines.Add(wxT("__NETBSD__"));
}
else if (platform::openbsd)
{
defines.Add(wxT("OPENBSD"));
defines.Add(wxT("__OPENBSD__"));
}
else if (platform::darwin)
{
defines.Add(wxT("DARWIN"));
defines.Add(wxT("__APPLE__"));
}
else if (platform::solaris)
{
defines.Add(wxT("sun"));
defines.Add(wxT("__sun"));
defines.Add(wxT("__SUN__"));
defines.Add(wxT("__SUNOS__"));
defines.Add(wxT("__SOLARIS__"));
}
if (platform::unix)
{
defines.Add(wxT("unix"));
defines.Add(wxT("__unix"));
defines.Add(wxT("__unix__"));
defines.Add(wxT("__UNIX__"));
}
if (platform::gtk)
defines.Add(wxT("__WXGTK__"));
if (platform::bits == 32)
{
defines.Add(wxT("i386"));
defines.Add(wxT("__i386"));
defines.Add(wxT("__i386__"));
defines.Add(wxT("__i386__"));
defines.Add(wxT("_X86_"));
defines.Add(wxT("__INTEL__"));
}
else if (platform::bits == 64)
{
defines.Add(wxT("__amd64"));
defines.Add(wxT("__amd64__"));
defines.Add(wxT("__x86_64"));
defines.Add(wxT("__x86_64__"));
defines.Add(wxT("__IA64__"));
}
}
const wxString keywords = GetStringFromArray(MakeUniqueArray(defines, true), wxT(" "), false);
const HighlightLanguage hlCpp = m_Theme->GetHighlightLanguage(wxT("C/C++"));
if (m_Theme->GetKeywords(hlCpp, 4) == keywords)
return; // no change
m_Theme->SetKeywords(hlCpp, 4, keywords);
const wxString key = wxT("/colour_sets/") + m_Theme->GetName() + wxT("/cc/");
Manager::Get()->GetConfigManager(wxT("editor"))->Write(key + wxT("editor/keywords/set4"), keywords);
Manager::Get()->GetConfigManager(wxT("editor"))->Write(key + wxT("name"), wxT("C/C++"));
// update open editors
for (int index = 0; index < GetEditorsCount(); ++index)
{
cbEditor* ed = GetBuiltinEditor(index);
if ( ed && (ed->GetLanguage() == hlCpp) )
{
cbStyledTextCtrl* stc = ed->GetControl();
stc->SetKeyWords(4, keywords);
}
}
event.Skip();
}
So, we can do quite similar thing inside the function void CodeCompletion::UpdateEditorSyntax(cbEditor* ed).
And we can set the "keywords 4", right?
This is the code to read the macro definition string:
int SCI_METHOD LexerCPP::WordListSet(int n, const char *wl) {
WordList *wordListN = 0;
switch (n) {
case 0:
wordListN = &keywords;
break;
case 1:
wordListN = &keywords2;
break;
case 2:
wordListN = &keywords3;
break;
case 3:
wordListN = &keywords4;
break;
case 4:
wordListN = &ppDefinitions;
break;
case 5:
wordListN = &markerList;
break;
/* C::B begin */
case 6:
wordListN = &wxSmithIds;
break;
/* C::B end */
}
int firstModification = -1;
if (wordListN) {
WordList wlNew;
wlNew.Set(wl);
if (*wordListN != wlNew) {
wordListN->Set(wl);
firstModification = 0;
if (n == 4) {
// Rebuild preprocessorDefinitions
preprocessorDefinitionsStart.clear();
for (int nDefinition = 0; nDefinition < ppDefinitions.Length(); nDefinition++) {
const char *cpDefinition = ppDefinitions.WordAt(nDefinition);
const char *cpEquals = strchr(cpDefinition, '=');
if (cpEquals) {
std::string name(cpDefinition, cpEquals - cpDefinition);
std::string val(cpEquals+1);
size_t bracket = name.find('(');
size_t bracketEnd = name.find(')');
if ((bracket != std::string::npos) && (bracketEnd != std::string::npos)) {
// Macro
std::string args = name.substr(bracket + 1, bracketEnd - bracket - 1);
name = name.substr(0, bracket);
preprocessorDefinitionsStart[name] = SymbolValue(val, args);
} else {
preprocessorDefinitionsStart[name] = val;
}
} else {
std::string name(cpDefinition);
std::string val("1");
preprocessorDefinitionsStart[name] = val;
}
}
}
}
}
return firstModification;
}
The bad thing is:
Currently, the WordList variable is construct with default arguments, that is:
class WordList {
// Each word contains at least one character - a empty word acts as sentinel at the end.
char **words;
char *list;
int len;
bool onlyLineEnds; ///< Delimited by any white space or only line ends
int starts[256];
public:
explicit WordList(bool onlyLineEnds_ = false);
~WordList();
operator bool() const;
bool operator!=(const WordList &other) const;
int Length() const;
void Clear();
void Set(const char *s);
bool InList(const char *s) const;
bool InListAbbreviated(const char *s, const char marker) const;
const char *WordAt(int n) const;
};
See the bool onlyLineEnds_ = false, that is, if our macro definition have spaces inside its definition, such as if we pass the string:
_WIN32_
mydef(x,y)=x + y
Then, it will read a single macro as "mydef(x,y)=x".
OllyDbg after what you wrote, I can probably off because I have no such knowledge about these tools.
Will the new version of CodeBlocks improve this problem?
Now this statement do not want to cause war, but to present my conclusions from the last week. As I wrote in the first post. I'll be back after a few years to Code :: Blocks then seemed to me better than Eclipse, more intuitive. I used CodeBlocks for 5 years. Yesterday after problems with debugging under CodeBlocks tried to debug the same program in Eclipse and was held without a problem.
Eclipse took on the appearance of a serious tool. Maybe it's just a first impression. Unfortunately I can not say that about CodeBlocks, in general has not changed and it's not about looks, because it is sometimes an advantage. But this kind of trouble such as the debugging should not happen.
Regards
SmallTed
Guys, I have implement this feature. It works quite well(but as you know, it does not work 100% correctly) as I tested.
src/plugins/codecompletion/codecompletion.cpp | 22 ++++++++++++++++++++++
src/sdk/editormanager.cpp | 4 ++--
.../wxscintilla/src/scintilla/lexers/LexCPP.cxx | 2 +-
3 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/src/plugins/codecompletion/codecompletion.cpp b/src/plugins/codecompletion/codecompletion.cpp
index 0cf8427..f590dd4 100644
--- a/src/plugins/codecompletion/codecompletion.cpp
+++ b/src/plugins/codecompletion/codecompletion.cpp
@@ -3419,6 +3419,24 @@ void CodeCompletion::UpdateEditorSyntax(cbEditor* ed)
}
}
}
+
+ wxString macroText;
+ // the the current file index
+ size_t fileIdx = tree->GetFileIndex(ed->GetFilename());
+ // get all the tokens under global namespace
+ const
+ TokenIdxSet* globalTokens = tree->GetGlobalNameSpaces();
+ // loop those tokens, and add all the global macro definitions to a single
+ for (TokenIdxSet::const_iterator it = globalTokens->begin(); it != globalTokens->end(); ++it)
+ {
+ Token* token = tree->at(*it);
+ if (!token)
+ continue;
+ // exclude the macros defined in the current file
+ if (token->m_TokenKind == tkMacroDef && token->m_FileIdx != fileIdx)
+ macroText << token->m_Name << token->m_Args << wxT("=") << token->m_FullType << wxT("\n");
+ }
+
CC_LOCKER_TRACK_TT_MTX_UNLOCK(s_TokenTreeMutex)
EditorColourSet* colour_set = Manager::Get()->GetEditorManager()->GetColourSet();
@@ -3432,6 +3450,10 @@ void CodeCompletion::UpdateEditorSyntax(cbEditor* ed)
keywords += wxT(" ") + *keyIt;
}
ed->GetControl()->SetKeyWords(3, keywords);
+
+ // set the macro definition string
+ ed->GetControl()->SetKeyWords(4, macroText);
+
ed->GetControl()->Colourise(0, -1);
}
diff --git a/src/sdk/editormanager.cpp b/src/sdk/editormanager.cpp
index 3197755..db50655 100644
--- a/src/sdk/editormanager.cpp
+++ b/src/sdk/editormanager.cpp
@@ -1907,8 +1907,8 @@ void EditorManager::CollectDefines(CodeBlocksEvent& event)
defines.Add(wxT("__IA64__"));
}
}
-
- const wxString keywords = GetStringFromArray(MakeUniqueArray(defines, true), wxT(" "), false);
+ // \n is the delimiter
+ const wxString keywords = GetStringFromArray(MakeUniqueArray(defines, true), wxT("\n"), false);
const HighlightLanguage hlCpp = m_Theme->GetHighlightLanguage(wxT("C/C++"));
if (m_Theme->GetKeywords(hlCpp, 4) == keywords)
return; // no change
diff --git a/src/sdk/wxscintilla/src/scintilla/lexers/LexCPP.cxx b/src/sdk/wxscintilla/src/scintilla/lexers/LexCPP.cxx
index 3d37611..5aa46ac 100644
--- a/src/sdk/wxscintilla/src/scintilla/lexers/LexCPP.cxx
+++ b/src/sdk/wxscintilla/src/scintilla/lexers/LexCPP.cxx
@@ -606,7 +606,7 @@ int SCI_METHOD LexerCPP::WordListSet(int n, const char *wl) {
}
int firstModification = -1;
if (wordListN) {
- WordList wlNew;
+ WordList wlNew(true);// onlyLineEnds = true
wlNew.Set(wl);
if (*wordListN != wlNew) {
wordListN->Set(wl);
I just exclude the macro definition in the current opened editor, so that it can handle the macros correctly by the scintilla's C++ lexer.
Mmh, I guess I'll have to do the same thing in Clang CC ;-)
It will get to be weird once we start using compiler-specific macro's as it should actually use the ones from the compiler and not Clang unless Clang is also the compiler...
Yves
Quote from: yvesdm3000 on December 12, 2015, 02:32:33 PM
Mmh, I guess I'll have to do the same thing in Clang CC ;-)
It will get to be weird once we start using compiler-specific macro's as it should actually use the ones from the compiler and not Clang unless Clang is also the compiler...
Yves
I think clang can do better than the one I have made in my previous post.
If I remember correctly, there is a plugin called semantic highlight, which uses libclang, see here: Semantic highlight (http://forums.next.codeblocks.org/index.php/topic,16249.msg109954.html#msg109954). I think it does not feed the macro definitions to scintilla, instead, it use its own c++ lexer to highlight the editor.
Quote from: SmallTed on December 12, 2015, 10:07:01 AM
OllyDbg after what you wrote, I can probably off because I have no such knowledge about these tools.
Will the new version of CodeBlocks improve this problem?
I think we don't have enough time to make such feature in the new release.
As you know, we will release a 15.12 release.
ollydbg
Quote
I think we don't have enough time to make such feature in the new release.
As you know, we will release a 15.12 release.
It will be add to new release 15.22.
It would be a summary of your job.
Maybe one or two days later but this function is useful,
especially when the project is large and you're tired.
SmallTed
Quote from: SmallTed on December 12, 2015, 04:40:53 PM
ollydbg
Quote
I think we don't have enough time to make such feature in the new release.
As you know, we will release a 15.12 release.
It will be add to new release 15.22.
It would be a summary of your job.
Maybe one or two days later but this function is useful,
especially when the project is large and you're tired.
SmallTed
15.12 means 2015, December. So, there is no 15.22.
You may try a nightly build version of you need such feature(after the feature is committed to trunk)
Quote from: ollydbg on December 12, 2015, 01:23:12 PM
Guys, I have implement this feature. It works quite well(but as you know, it does not work 100% correctly) as I tested.
As usual, changes in scintilla should either be reported upstream to scintilla or (worst solution) be highlighted as C::B changes.
Is the change really needed? (Why?) Can't this be set from outside?
Quote from: MortenMacFly on December 13, 2015, 07:11:39 AM
Quote from: ollydbg on December 12, 2015, 01:23:12 PM
Guys, I have implement this feature. It works quite well(but as you know, it does not work 100% correctly) as I tested.
As usual, changes in scintilla should either be reported upstream to scintilla or (worst solution) be highlighted as C::B changes.
OK, I know this, and I won't commit the changes soon, because it need more testing.
Quote
Is the change really needed? (Why?) Can't this be set from outside?
I see that scintilla use either space or "\n" or "\r" as the default delimiter. So, unless we pass all the macro definition without any space in its replacement, we should use "\n" only delimiter. I don't see there is an option outside, you can look at the code snippet I posted in previous posts.
I downloaded but probably not of this repository.
After compilation code blocks I see svn 10621. you're working on git.
You do not have time now, so I will not bother you.
Quote
15.12 means 2015, December. So, there is no 15.22.
So I was concerned about 15.12, my mistake.
But I see that this is not the version 15.12, maybe later.
SmallTed
FYI: I have post a feature request Lexcpp: allow white space when reading hte macro definition - Google Groups (https://groups.google.com/forum/#!topic/scintilla-interest/eaAeNR6UTts).