Thanks for the 2 really cool new features:
-read only icon
-pane layout saving
While I have no problem with the readonly icon (works perfectly), the pane layout does not get saved. Is there any extra thing to do before closing cb or anything I could report to help debugging ?
I have 2 vertical panes of equal size. When I close then reopen codeblocks, only one pane appear covering the whole window (I mean similar to the legacy behavior).
Here is the (shortened) layout file in question;
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_layout_file>
<FileVersion major="1" minor="0" />
<ActiveTarget name="Release" />
<File name="src/antenna/model/angles.cc" open="0" top="0" tabpos="0" split="0" active="1" splitpos="0" zoom_1="0" zoom_2="0">
<Cursor>
<Cursor1 position="862" topLine="1" />
</Cursor>
</File>
<File name="src/aodv/test/aodv-regression.cc" open="0" top="0" tabpos="0" split="0" active="1" splitpos="0" zoom_1="0" zoom_2="0">
<Cursor>
<Cursor1 position="2305" topLine="36" />
</Cursor>
</File>
<File name="src/internet/model/tcp-option-ts.cc" open="0" top="0" tabpos="0" split="0" active="1" splitpos="0" zoom_1="0" zoom_2="0">
<Cursor>
<Cursor1 position="1450" topLine="50" />
</Cursor>
</File>
<File name="src/network/utils/ipv4-address.h" open="0" top="0" tabpos="0" split="0" active="1" splitpos="0" zoom_1="0" zoom_2="0">
<Cursor>
<Cursor1 position="2824" topLine="44" />
</Cursor>
</File>
<File name="src/internet/model/tcp-option.h" open="0" top="0" tabpos="10" split="0" active="1" splitpos="0" zoom_1="0" zoom_2="0">
<Cursor>
<Cursor1 position="1070" topLine="18" />
</Cursor>
</File>
<File name="src/internet/model/tcp-option-mptcp.cc" open="0" top="0" tabpos="13" split="0" active="1" splitpos="0" zoom_1="0" zoom_2="0">
<Cursor>
<Cursor1 position="16273" topLine="823" />
</Cursor>
</File>
<File name="src/internet/test/mptcp-options-test.cc" open="0" top="0" tabpos="4" split="0" active="1" splitpos="0" zoom_1="0" zoom_2="0">
<Cursor>
<Cursor1 position="11176" topLine="354" />
</Cursor>
</File>
<File name="src/internet/model/tcp-westwood.cc" open="0" top="0" tabpos="19" split="0" active="1" splitpos="0" zoom_1="0" zoom_2="0">
<Cursor>
<Cursor1 position="2056" topLine="93" />
</Cursor>
</File>
<File name="src/internet/model/mp-tcp-olia.h" open="0" top="0" tabpos="11" split="0" active="1" splitpos="0" zoom_1="0" zoom_2="0">
<Cursor>
<Cursor1 position="631" topLine="21" />
</Cursor>
</File>
<EditorTabsLayout layout="0603b9e0543be510003ca91a00000002=+1;mptcp:src/network/model/socket.cc,2;mptcp:src/internet/model/mp-tcp-typedefs.cc,3;mptcp:src/internet/model/mp-tcp-socket-base.cc,4;mptcp:src/internet/test/mptcp-tcp-test.cc,5;mptcp:src/internet/model/tcp-socket-base.cc,6;mptcp:src/internet/model/mp-tcp-subflow.cc,7;mptcp:src/internet/model/tcp-socket-base.h,8;mptcp:src/internet/model/mp-tcp-socket-base.h,9;mptcp:src/internet/model/mp-tcp-subflow.h|014abe00543be54900c5426400000003=*0;mptcp:src/internet/model/mp-tcp-typedefs.h@layout2|name=dummy;caption=;state=2098174;dir=3;layer=0;row=0;pos=0;prop=100000;bestw=180;besth=180;minw=180;minh=180;maxw=-1;maxh=-1;floatx=-1;floaty=-1;floatw=-1;floath=-1|name=0603b9e0543be510003ca91a00000002;caption=;state=2098172;dir=5;layer=0;row=0;pos=0;prop=100000;bestw=200;besth=200;minw=-1;minh=-1;maxw=-1;maxh=-1;floatx=-1;floaty=-1;floatw=-1;floath=-1|name=014abe00543be54900c5426400000003;caption=;state=2098172;dir=2;layer=0;row=1;pos=0;prop=100000;bestw=839;besth=385;minw=-1;minh=-1;maxw=-1;maxh=-1;floatx=-1;floaty=-1;floatw=-1;floath=-1|dock_size(5,0,0)=20|dock_size(2,0,1)=841|" />
</CodeBlocks_layout_file>
EDIT: I use the packages from jens on ubuntu.
Hello Everybody.
Since the nightly from October the 11th 2014 (SVN 9936) I see the same effect again as described in my comment on June the 16th 2013
http://forums.codeblocks.org/index.php/topic,18044.msg123571.html#msg123571 (http://forums.codeblocks.org/index.php/topic,18044.msg123571.html#msg123571)( Re: The 16 June 2013 build (9158) is out. « Reply #31 on: June 20, 2013, 03:15:01 pm » please scroll up since the link does not show the first post) .
...
...
I looked at the post: Re: The 16 June 2013 build (9158) is out. (http://forums.codeblocks.org/index.php/topic,18044.msg123525.html#msg123525)
I have debugged a little, but I think it is the expect behavior.
If we have this sample code:
namespace a {
namespace b {
};
};
using namespace b;
There are two tokens named "b" in the TokenTree.
One is the sub namespace under a. (the first b)
One is in global namespace. (the second b)
Furthermore I'm not able to use the Button Preview of this forum anymore, what I normally use to check how my post looks like. I think I have to look for some plug-in updates and to check the security adjustments. If somebody has tip for me, it will be great.
The preview button is broken, see:Code::Blocks forum 'Preview' not working (http://forums.codeblocks.org/index.php/topic,19740.msg134776.html#msg134776)
As attachment I added the combination of 2 screen shots that contains for one project the symbol browsers of the nightlies from September the 16th and October the 12th. As you can see in the older nightly I have to open the nesting namespace to see the nested namespace ( as I like), while in the newer nightly the nested namespaces are visible on the directly under the root node together with the nesting namespaces also (as I don't like).
I have debugged a little and I have the same symbol tree results in the two version of nightlies, and see that you have such code:
MuLanPa\process\h\transform.h
#ifndef DOXYGEN
namespace CL_PROCESS {
namespace CL_TRANSFORM {
#endif //DOXYGEN
...
...
#ifndef DOXYGEN
#define USING_NAMESPACE using namespace
};}; USING_NAMESPACE CL_TRANSFORM;
#endif //DOXYGEN
#undef USING_NAMESPACE
Question:
Why do you use:
using namespace CL_TRANSFORM
I recommend you should use
using namespace CL_PROCESS::CL_TRANSFORM
Since CL_TRANSFORM is a child of CL_PROCESS.
Anyway, the CC parser's behaviour is correct in this case as I can see.
Furthermore if I click on a nested namespace shown on the same level as the nesting namespaces, C::B is not showing the location where the namespace is defined. C::B just opens the file and shows its first source lines. This was the case last year also.
This is the same issue as I said before.
See here: Re: The 12 October 2014 build (9958) is out. (http://forums.codeblocks.org/index.php/topic,19727.msg134788.html#msg134788)
When you click on the second "b" (the namespace "b" under global namespace), because the second "b" is created as a dummy token.
I assume that one reason you have to get my point, is that my use of namespaces is more or less a misuse of them to establish a workaround. I use them to reduce the number of source elements shown in the symbol browser. Without doing this for me it is very difficult, to use the symbol browser for navigating through the code, since this means always a lot of scrolling.
...
...
Please don't use the "misuse" any more, since our parser works correctly now.
...
...
That's why I asked so often if it would be possible to offer a possibility to define virtual folders like in the project browser.
Note that symbol browser just build a hierarchy tree from the TokenTree, so if we get the correct parsing result, the symbol browser issue will be fixed, I don't think a "virtual folder" is possible, because the symbol tree are always created dynamically.
I already mentioned the limited possibility of reducing the since of top level lists in the symbol browser in the past. But until now nobody reacted. OK, I can understand, that this may mean a bigger change, what may be currently not possible for the C::B developers. You may also ask me why I would not do it by my self. To be honest I already thought about and did some investigations in your sources. But doing it by myself means to stop my own projects. Furthermore it means I have to learn how C::B intently works. I don't think, that you would accept a change to improve one part of C::B, if it influences other parts negatively, since the one who implemented the change was not aware of it. As a newbie in C::B development I would assume, that it would take at least one year to provide a solution that harmonise with the rest of the project and while this time I need frequently support from you also. But perhaps this is a thing we should discuss not in the nightly forum.
The source code of C::B is not that hard to understand, so if you have any problems reading the source code, just ask here, I think you can get help from other ones(including me).
OS: Debian testing (32-bit) [but it's the same on 64-bit at home PC]
GCC: gcc (Debian 4.9.1-16) 4.9.1
SVN: 10001
Bug detected in AStyle formatting.
Copy the following code in your C / C++ project.
#include <stdio.h>
#include <stdlib.h>
int valid(void *p) {
extern char _etext;
return (p != NULL) && ((char*) p > &_etext);
}
int global;
int main(void) {
int local;
printf("pointer to local var valid? %d\n", valid(&local));
printf("pointer to static var valid? %d\n", valid(&global));
printf("pointer to function valid? %d\n", valid((void *)main));
int *p = (int *) malloc(sizeof(int));
printf("pointer to heap valid? %d\n", valid(p));
printf("pointer to end of allocated heap valid? %d\n", valid(++p));
free(--p);
printf("pointer to freed heap valid? %d\n", valid(p));
printf("null pointer valid? %d\n", valid(NULL));
return 0;
}
DO NOT compile it just yet; right-click inside editor and choose "Format use AStyle"
The code becomes
#include <stdio.h>
#include <stdlib.h>
int valid(void *p)
{
extern char _etext;
return (p != NULL) && ((char*) p > &_etext);
}
int global;
int main(void)
{
int local;
}
printf("pointer to local var valid? %d\n", valid(&local));
printf("pointer to static var valid? %d\n", valid(&global));
printf("pointer to function valid? %d\n", valid((void *)main));
int *p = (int *) malloc(sizeof(int));
printf("pointer to heap valid? %d\n", valid(p));
printf("pointer to end of allocated heap valid? %d\n", valid(++p));
free(--p);
printf("pointer to freed heap valid? %d\n", valid(p));
printf("null pointer valid? %d\n", valid(NULL));
return 0;
}
Can you see the unnecessary } right after int local? Of course it won't compile as it closes main() prematurely, before reaching return 0.
Now, the mystery lies in the following order; paste the code in editor, compile it, and run it.
Close the run application and format the code. No curly brace added.
This will make AStyle play nice again..
diff --git a/src/plugins/astyle/astyleplugin.cpp b/src/plugins/astyle/astyleplugin.cpp
index 80c002c..123fa65 100644
--- a/src/plugins/astyle/astyleplugin.cpp
+++ b/src/plugins/astyle/astyleplugin.cpp
@@ -419,6 +419,10 @@ bool AStylePlugin::FormatEditor( cbEditor *ed )
void AStylePlugin::ApplyTextDelta(cbStyledTextCtrl* stc, wxString text, int rangeStart, int rangeEnd)
{
+ stc->SetTargetStart(rangeStart);
+ stc->SetTargetEnd(rangeEnd);
+ stc->ReplaceTarget(text);
+#if 0
rangeStart = stc->LineFromPosition(rangeStart);
rangeEnd = stc->LineFromPosition(rangeEnd) + 1;
const wxString& eolChars = GetEOLStr(stc->GetEOLMode());
@@ -483,4 +487,5 @@ void AStylePlugin::ApplyTextDelta(cbStyledTextCtrl* stc, wxString text, int rang
}
stc->SetTargetEnd(stc->GetLineEndPosition(rangeEnd - 1));
stc->ReplaceTarget(buffer);
+#endif // 0
}
ApplyTextDelta() attempted to make only the lines in the editor that actually changed be marked as updated. Unfortunately, it appears my logic had been flawed, and it is in a bad need of a rewrite.
ApplyTextDelta() attempted to make only the lines in the editor that actually changed be marked as updated. Unfortunately, it appears my logic had been flawed, and it is in a bad need of a rewrite.
On second thought, magic numbers fix everything, right?
diff --git a/src/plugins/astyle/astyleplugin.cpp b/src/plugins/astyle/astyleplugin.cpp
index 80c002c..afc645a 100644
--- a/src/plugins/astyle/astyleplugin.cpp
+++ b/src/plugins/astyle/astyleplugin.cpp
@@ -450,7 +450,10 @@ void AStylePlugin::ApplyTextDelta(cbStyledTextCtrl* stc, wxString text, int rang
int i = rangeStart + 1;
for (; i < rangeEnd; ++i)
{
- StrVecItr searchItr = std::find(lnItr + 1, (StrVecItr)textLines.end(), stc->GetLine(i).BeforeLast(eolChars[0]));
+ wxString edLine = stc->GetLine(i).BeforeLast(eolChars[0]);
+ if (edLine.Strip(wxString::both).Length() < 7) // magic number
+ continue;
+ StrVecItr searchItr = std::find(lnItr + 1, (StrVecItr)textLines.end(), edLine);
if (searchItr != textLines.end())
{
stc->SetTargetStart(stc->PositionFromLine(rangeStart));
Hello Ollydbg.
Thanks for your detailed post and please excuse my late reply.
First of all, after doing the change you and Morten proposed the shown namespaces in the symbol browser main-level are only the top-level ones. Thus you are right, if you say that the reason of my initial problem was my code even I still wonder why MinGW was still able to compile it. But this may be an other problem between my ears you don't have to care about. While implementing the namespace-using in the way of
#ifndef DOXYGEN
namespace A {
namespace B {
namespace C {
#endif //DOXYGEN
...
...
#ifndef DOXYGEN
#define USING_NAMESPACE using namespace
};};}; USING_NAMESPACE A::B::C;
#endif //DOXYGEN
#undef USING_NAMESPACE
I recognized that the symbol browser showed an empty and unnamed namespace symbol as child node of A. This occurred not if namespace A contains child namespaces which contain no own child namespaces I face no empty braces. But if the child namespaces of A contain other child namespaces like C by them self than the effect occurred.
Thus I changed the implementation:
#ifndef DOXYGEN
namespace A {
namespace B {
namespace C {
#endif //DOXYGEN
...
...
#ifndef DOXYGEN
#define USING_NAMESPACE using namespace
}; USING_NAMESPACE C;
}; USING_NAMESPACE B;
}; USING_NAMESPACE A;
#endif //DOXYGEN
#undef USING_NAMESPACE
Now it looks like in the old nightlies. It may be, that I failed again while implementing your solution. Thus from my point of view there is no need for further investigations. But I thought you may be interested in.
I assume that one reason you have to get my point, is that my use of namespaces is more or less a misuse of them to establish a workaround. I use them to reduce the number of source elements shown in the symbol browser. Without doing this for me it is very difficult, to use the symbol browser for navigating through the code, since this means always a lot of scrolling.
...
...
Please don't use the "misuse" any more, since our parser works correctly now.
No, sorry misuse is still the right word to use here. But I don't write about a wrong display inside the symbol browser. What I mean is that I use hammer where normally a screwdriver should be used. If you take a look to my sources you will see that my namespace structure redefines the structure of the classes. In an object-orientated design you are modeling your structure by derivation of a child-class from a parent-class. But this deviation is not used by the symbol browser to filter out the child to show them only as child-nodes of their parents. Thus I decided to choose namespaces to redefine this derivation structure, since the nesting structure of namespaces is used to show the structure in the symbol browser as I like. But as we learned, this works only if it will be done in the right way. Furthermore maintaining nested namespaces is a tough task and I would nobody recommend to do so without a really good reason.
However my current issue caused by my self is solved now, so thank you very much for you support.
The source code of C::B is not that hard to understand, so if you have any problems reading the source code, just ask here, I think you can get help from other ones(including me).
I hope that I will find some time in the next days, to note down some details what I'm thinking about if I'm writing about having a package model in the symbol browser (or in an own browser?). And I will post it here. If you agree that the idea may have some potential, I would propose to have further discussions in the development forum. I agree, that the code of the symbol browser itself looks understandable. But there are some other sources which are hard to understand. Some time ago I posted a problem I have with the folding-feature. Furthermore I took a look into the C::B sources but I failed to get an idea how to solve this issue by my self. But I think in the case of my browser solution I already have an idea how to do it and need more somebody who reviews my thoughts to ensure that my solution does not create new issues.
Best regards,
Eckard.
Hi,
I just need some help using the nightly on linux ubuntu 14.10. I use Jens packages flawlessly with a similar software configuration (Ubuntu 14.10 etc...) on one of my computers but it does not start on this one. I am pretty sure it has to deal with wxWidget (both jens and I use 2.8 I believe but the ubuntu version must differ from Debian's). Apparently it is caused when a software uses a static wxWidget timer in his code cf https://forums.wxwidgets.org/viewtopic.php?p=113193 (from this thread, it looks like a bad idea).
Here is the output of "codeblocks -v" (I could not find how to display the version number but this should be the latest nightly).
Initialize EditColourSet .....
Initialize EditColourSet: done.
Loading menubar...
ToolsPlus: loaded
ProjectsImporter: loaded
../src/common/timercmn.cpp(62): assert "Assert failure" failed in Init(): No timer implementation for this platform
../src/common/timercmn.cpp(73): assert "m_impl" failed in SetOwner(): uninitialized timer
../src/common/timercmn.cpp(73): assert "m_impl" failed in SetOwner(): uninitialized timer
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Here is my wxwidget version:
$ wx-config --list
Default config is base-unicode-release-2.8
Default config will be used for output