Access to standard output


#1

I want my juce application to be able to automate its behaviour by mean of command line parameters.
When the command line is not empy, the application should parse it and work as a console application displaying messages related to the work in progress on the standard output.
I’ve already added the code for discriminating the emptiness of command line into my main application’s “initialise” method, but I’m unable to display any message either via “printf” or “puts”.
Is there a way to do so, avoiding the messages to be treated as debug messages?


#2

You can use the normal printf stuff in the same way you would in any other app - juce doesn’t interfere with it at all. “fprintf (stdout” should probably work ok?


#3

similar problem here…

http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?t=1850&highlight=

would love to run an app and see text streaming to command window!

is it normal windows app behavior for it to return immediatly when run from command line?


#4

Yes it is, for a Windows app that is. This type of application has the /SUBSYSTEM:WINDOWS linker option set. In this mode, you cannot stream to stdout. Change the option to /SUBSYSTEM:CONSOLE . Then you can use stdout/stderr to your hearts content.


#5

No, the “fprintf(stdout” statement is ignored under windows. I thought it was a buffering problem, so called fflush(stdout) immediately after the output, but nothing is printed anyway.

@Karbon: yes, I did already read the mentioned discussion as well


#6

yeah. found this…

http://blogs.adobe.com/simplicity/2007/04/window_and_consolefriendly_win_1.html

bloody windows!


#7

lol! tried that. heres what happened…

F:\DEVELOPMENT\KARMA_SVN\app>Karma_Release.exe
tone <frequency_Hz>,[<amplitude>] [<frequency_Hz>,[<amplitude>]...]

F:\DEVELOPMENT\KARMA_SVN\app>

no GUI, nothing! whats all that tone crap?! lol.


#8

[quote=“Karbon L. Forms”]
lol! tried that. heres what happened…

F:\DEVELOPMENT\KARMA_SVN\app>Karma_Release.exe
tone <frequency_Hz>,[<amplitude>] [<frequency_Hz>,[<amplitude>]...]

F:\DEVELOPMENT\KARMA_SVN\app>

no GUI, nothing! whats all that tone crap?! lol.[/quote]

Cool… or NOT… :slight_smile: No idea really… you can’t find that text in your app you say? :?


#9

[quote=“robiwan”][quote=“Karbon L. Forms”]
lol! tried that. heres what happened…

F:\DEVELOPMENT\KARMA_SVN\app>Karma_Release.exe
tone <frequency_Hz>,[<amplitude>] [<frequency_Hz>,[<amplitude>]...]

F:\DEVELOPMENT\KARMA_SVN\app>

no GUI, nothing! whats all that tone crap?! lol.[/quote]

Cool… or NOT… :slight_smile: No idea really… you can’t find that text in your app you say? :?[/quote]

no such text in app no. wierd eh? i’ll google it.

so… used the “AttachConsole()” / “start /wait app.exe” technique and now have an attached CMD! yay. so now at same stage as yfede and wondering still where my text is going?!


#10

the “tone” crap is coming from this…

void usage(){ fprintf(stderr,"tone <frequency_Hz>,[<amplitude>] [<frequency_Hz>,[<amplitude>]...]\n"); exit(1); }

in tone.c in the Juce vorbis stuff.

?


#11

The “/SUBSYSTEM:CONSOLE” trick does not seem to work out-of-the-box for me, I get the following linker error

LIBCMTD.lib(crt0.obj) : error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup

I’m not linking against any other project or library other than juce, downloaded from the current SVN snapshot.


#12

tone.c shouldn’t be there - I removed it from the build recently…


#13

very nearly!

got a new console to pop up that has all my stdouts! good enough for me.

did it with this…

#define MAX_CONSOLE_LINES 500

#include <io.h>
#include <fcntl.h>
static void RedirectIOToConsole(void)
{
	int hConHandle;
	long lStdHandle;

	CONSOLE_SCREEN_BUFFER_INFO coninfo;
	FILE *fp;

	// allocate a console for this app
	AllocConsole();

	// set the screen buffer to be big enough to let us scroll text
	GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE),	&coninfo);
	coninfo.dwSize.Y = MAX_CONSOLE_LINES;
	SetConsoleScreenBufferSize(GetStdHandle(STD_OUTPUT_HANDLE), coninfo.dwSize);

	// redirect unbuffered STDOUT to the console
	lStdHandle = (long)GetStdHandle(STD_OUTPUT_HANDLE);
	hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
	fp = _fdopen( hConHandle, "w" );
	*stdout = *fp;
	setvbuf( stdout, NULL, _IONBF, 0 );

	// redirect unbuffered STDIN to the console
	lStdHandle = (long)GetStdHandle(STD_INPUT_HANDLE);
	hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
	fp = _fdopen( hConHandle, "r" );
	*stdin = *fp;
	setvbuf( stdin, NULL, _IONBF, 0 );

	// redirect unbuffered STDERR to the console
	lStdHandle = (long)GetStdHandle(STD_ERROR_HANDLE);
	hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
	fp = _fdopen( hConHandle, "w" );
	*stderr = *fp;
	setvbuf( stderr, NULL, _IONBF, 0 );
}

from here…

http://episteme.arstechnica.com/eve/forums/a/tpc/f/6330927813/m/387004985831

so you could call this depending on a command line switch or _DEBUG or whatever. creates a new dosbox but what the hell.


#14