Code::Blocks Forums
User forums => Using Code::Blocks => Topic started by: daniloz on November 25, 2010, 10:44:36 am
-
Does CB provides a COM server at all? OR just a DDE server?
-
C::B is portable, COM is not :)
Why would you need C::B as a COM object?
-
Partly
http://www.codeblocks.org/docs/main_codeblocks_en3.html#x3-230001.11.2 (http://www.codeblocks.org/docs/main_codeblocks_en3.html#x3-230001.11.2)
-
Because I use C::B to edit and navigate through my code, but use VisualDSP++ to do the compiling and debug (DSP embedded C++ code).
So, I'd like to have a easy way to jump from one editor to the other. I already have a VBscript that I can call from C::B that sends me to he same file and line on the VisualDSP++ IDE.
Now I want to do the inverse, from the VisualDSP++ IDE have a script to jump to the same line and file on C::B...
Any ideas?
-
Because I use C::B to edit and navigate through my code, but use VisualDSP++ to do the compiling and debug (DSP embedded C++ code).
So, I'd like to have a easy way to jump from one editor to the other. I already have a VBscript that I can call from C::B that sends me to he same file and line on the VisualDSP++ IDE.
Now I want to do the inverse, from the VisualDSP++ IDE have a script to jump to the same line and file on C::B...
Any ideas?
You can do it with DDE or more easy with calling C::B directly.
If you uncheck "Settings -> General settings -> Allow only one running ..." and check "Settings -> General settings -> Use an already running ..." and "Settings -> General settings -> Bring it on ...", you just have to call C::B with the appropriate parameters (e.g. --file=name[:line] to open a file in a running instance of C::B).
In this case all the DDE-stuff is done by C::B itself and you don't have to care about it.
The same also works on linux (but IPC via unix-socket is used in this case).
-
If you uncheck "Settings -> General settings -> Allow only one running ..." and check "Settings -> General settings -> Use an already running ..." and "Settings -> General settings -> Bring it on ...", you just have to call C::B with the appropriate parameters (e.g. --file=name[:line] to open a file in a running instance of C::B).
In this case all the DDE-stuff is done by C::B itself and you don't have to care about it.
Shouldn't it be CHECK "Settings -> General settings -> Allow only one running ..." ?? I don't want another one to be opened...
-
Actually, I don't see any difference here whether "Settings -> General settings -> Allow only one running ..." is checked or unchecked... I'm puzzled :shock:
What should be the difference??
Another point, if C::B is minimized, it's not automatically maximized, it only gains the focus... Don't you think it should be automatically maximized in this case?
Btw, thank you very much for your reply, I really like this solution...
-
If you do not run another instance of C::B, that does not allow DDE-/IPC (started with -nd/-ni), it does not matter.
But if you have a running instance of C::B, that does not run a DDE-/IPC-Server, it will fail, if "Allow only one running instance" is checked, because the signal can be send, but "nobody" will answer and no new instance can be started.
That's the normal situation for me, if I work in C::B on C::B.
-
Actually, I don't see any difference here whether "Settings -> General settings -> Allow only one running ..." is checked or unchecked... I'm puzzled :shock:
What should be the difference??
Another point, if C::B is minimized, it's not automatically maximized, it only gains the focus... Don't you think it should be automatically maximized in this case?
Btw, thank you very much for your reply, I really like this solution...
If "Bring it on top..." is checked the MainFrame of C::B is raised via the (wxWidgets) Raise()-function, but it seems not always work as expected:
wxWindow::Raise
void Raise()
Raises the window to the top of the window hierarchy (z-order).
In current version of wxWidgets this works both for managed and child windows.