"Detached" console_runner?

[MortenMacFly]

Dear devs,
I'm currently developing a console application with time measurements being plotted to the console. If I run the application from within C::B the console_runner is started, which shows me the results but I cannot run another instance before I close the console runner.

Here is my feature request (unsless ist's already imeplemented): How about allowing the console_runner to be run detached -> thus allowing to compare the output of two applications? I think another checkbox in the "select target" window that pops up on "Run" with target "All" would do the trick.

The basic functionality is already proven and implemented within the external tool setup... Any objections?

With regards, Morten.

[Vampyre_Dark]

You can turn off the console runner altogether, it's called 'pause after execution' in your build options. You will have to insert your own code to keep the window from automatically closing.

[MortenMacFly]

You will have to insert your own code to keep the window from automatically closing.

...and that's what I actually don't want to do. But thanks for the hint anyway! ;-)
With regards, Morten.

[Vampyre_Dark]

You will have to insert your own code to keep the window from automatically closing.

...and that's what I actually don't want to do. But thanks for the hint anyway! ;-)
With regards, Morten.

No, but it allows you to run more than 1 window at once, which is what you want...

[MortenMacFly]

No, but it allows you to run more than 1 window at once, which is what you want...

I know, but I have only read access to the sources that I would have to change for this. That's why I asked if it isn't nice to have a detached console_runner in addition...?!
With regards, Morten.

[Pecan]

No, but it allows you to run more than 1 window at once, which is what you want...

I know, but I have only read access to the sources that I would have to change for this. That's why I asked if it isn't nice to have a detached console_runner in addition...?!
With regards, Morten.

You can always use menubar->tools as a console_runner.
Example:


Take out the "start" if you want the shell to wait, and choose the button options you like.

[MortenMacFly]

You can always use menubar->tools as a console_runner.

Thanks Pecan for the hint. But in fact I guess I didn't make myself very clear. Because I know a workaround for this issue. But my question was different:
I'd like to know if I'm the only one that would be glad if an application isn't "locking" C::B after being launched. This is a project related issue, just as command line parameters. I have quite some command line tools that all report it's calculations to the console. I often want to compare the output of these tools because e.g. they share classes in common. So for debugging purposes I want to check if all (15!) tools still calculate correctly.
For now I have to use e.g. several command shells that remain open after the tool is launched so that I can compare the outputs. This could be resolved easily eighther by e.g.:
1.) Allowing a flag to run the application detached (from the "Run menu")
2.) Adding another %PROJECT_OUTPUT_FILE% macro to the tools menu.
(The second one came to me after Pecans post BTW...)
This would allow what I want: Having the currently compiled application launched detached in a window that remains open. Meanwhile I like the second idea much more - so again my question: Any objections?
With best regards, Morten.

[tiwag]

... I have quite some command line tools that all report it's calculations to the console. I often want to compare the output of these tools because e.g. they share classes in common. So for debugging purposes I want to check if all (15!) tools still calculate correctly...

i had a similar project and redirected the output of each tool to a file, which i could then analyse with the editor.

[thomas]

I'd personally do it this way... needs no change at all and works fine (if I understand correctly what you want).

[attachment deleted by admin]

[MortenMacFly]

I'd personally do it this way... needs no change at all and works fine (if I understand correctly what you want).

Nice one, too. But:
What my tools print out are matrices of quite some size. I would have to scoll a lot up and down to compare the outputs of all the (15!) tools. In addition besides the tool's output I don't care about the other C::B messages (e.g. from the build).
I guess I'll just try to implement the macros and propose a patch... we'll see if it gets accepted or not... ;-)
With regards, Morten.

[MortenMacFly]

Dear all, while trying to implement what I proposed here I found out that C::B has it already implemented! It's simply not documented. What I did:

1.) Added a new tool (cb_console_runner) with the following settings:
  - Parameter: $(RELEASE_OUTPUT_FILE)
  - Working dir: $(RELEASE_OUTPUT_DIR)
  - Option: Launch tool visible (without output redirection)
2.) Switched to the console project(s) I have that I want to compare and simply run the tool.

Notice the macros "FOO_OUTPUT_FILE" and "BAR_OUTPUT_DIR" where "FOO" and "BAR" have to be replaced by the active project's target name to access this targets output file/dir. In my case all tools have the same targets: "Debug" and "Release". So I select "RELEASE" to access the current project's "Release" target.

Now I can do what I want: I compile the "ToolA" project, run the console_runner "detached" by calling the tool. An external console opens with "ToolA". Then I switch to the next project and do the same (compilation & run the tool). A second console opens with "ToolB".... and so on...

Zero code change and all works perfect - exactly as I had in mind. This rocks!

With regards, Morten.

Edit: Too fast with words - I missed that if I try to lauch the second tool I now get a C::B error: "Another tool is currently executing. Please allow for it to finish before launching another tool..." :-(

[MortenMacFly]

Dear all,
it's me again finally with a patch for your kind inspection. I've modified the tools menu and added an option that allows to run a(ny) tool detached. This would not only allow me to do what I want but also others to run a tool whose output and state isn't required to be monitored. This simplifies the possibility to run more that (only) one tool at a time. I am aware that this is already possible by using "&" or the Win "start" command. Anyway: I believe that this is an easier solution.
How do you think about that? I'm looking forward to a discussion.
With regards, Morten.
Ps.: My last post still applies - using the patch finally everything I want is possible.

[attachment deleted by admin]

[Ceniza]

I just checked your patch and it sounds good. I'll compile it, test it and if everything goes well (it should) I'll commit it