Attaching process to use in Non GUI mode

Hi,

I have GUI application and want use in both GUI n Non GUI mode (command line).
GUI mode is working fine and same thing i want to use in Non GUI mode that is using command line.

How it can be done?

Thanks.

…by not creating any windows!?

Yes without launching the UI.

In windows we have the API called Attachconsole which will do similar functionality. But not able to find it in MAC.

I don’t understand the question… Like I said, if you want a non-UI app, then don’t create any UI. End of story. I do the same thing in the introjucer. What’s the problem?

In windows i am handeling both GUI mode and non gui mode, if its GUI mode in staeway it will launch UI, and in Non gui mode it wont lanuch UI.
In non GUI i am using like this

[code]#if JUCE_WINDOWS
CONSOLE_SCREEN_BUFFER_INFO coninfo;

FILE *fp;
AttachConsole(ATTACH_PARENT_PROCESS);
GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &coninfo);
coninfo.dwSize.Y = 200;
SetConsoleScreenBufferSize(GetStdHandle(STD_OUTPUT_HANDLE), coninfo.dwSize);

// redirect unbuffered STDOUT to the console
lStdHandle = (long)GetStdHandle(STD_OUTPUT_HANDLE);
if(NULL != lStdHandle )
{
	hStdOutHandle = _open_osfhandle(lStdHandle, _O_TEXT);
	fp = _fdopen( hStdOutHandle, "w" );
	*stdout = *fp;
	setvbuf( stdout, NULL, _IONBF, 0 );
	// redirect unbuffered STDIN to the console
	lStdHandle = (long)GetStdHandle(STD_INPUT_HANDLE);
	hStdInHandle = _open_osfhandle(lStdHandle, _O_TEXT);
	fp = _fdopen( hStdInHandle, "r" );
	*stdin = *fp;
	setvbuf( stdin, NULL, _IONBF, 0 );

	// redirect unbuffered STDERR to the console
	lStdHandle = (long)GetStdHandle(STD_ERROR_HANDLE);
	hStdErrHandle = _open_osfhandle(lStdHandle, _O_TEXT);
	fp = _fdopen( hStdErrHandle, "w" );
	*stderr = *fp;
	setvbuf( stderr, NULL, _IONBF, 0 );
	// make cout, wcout, cin, wcin, wcerr, cerr, wclog and clog 
	// point to console as well
	ios::sync_with_stdio();
}

#endif[/code]

so similar way i need to handle in MAC.

(No idea what all of that lot is supposed to do)

On the mac there’s no distinction between UI/non-UI apps - just run the damned thing without creating any windows, and do whatever you need to do in your app startup code!

Have a look at the newest introjucer for an example.

Thanks, let me try on this. If any problem i will come back.

Thanks again.

Hi,

My requirement is, single exe should contain both commandline and GUI functionality.

So I have created project as win32 -> win32 Project.

is it possible to hide the window(GUI) for the commandline ?

Implementing Non GUI mode and GUI mode in single application is it best approach?

Thanks.

It’s your code that creates the window! If you want to hide it, then just don’t show the damned thing!

yeah, i am hiding it in non GUI mode, the problem here is stderr and stdout are navigating to console by using attachconsole.
so when executing the commands in console its

ex:
[Windows]
d:\Application\Output>App.exe -nogui --help
d:\Application\Output> //This line is not required
App starting…

Executed successfully.

App exiting.

d:\Application\Output>

[MAC]

when command line is executed its crashing while quiting the application.

2011-11-03 12:37:35.416 App[4398:903] *** Assertion failure in +[NSEvent startPeriodicEventsAfterDelay:withPeriod:], /SourceCache/AppKit/AppKit-1038.36/AppKit.subproj/NSEvent.m:2373
2011-11-03 12:37:35.422 App[4398:903] An uncaught exception was raised
2011-11-03 12:37:35.422 App4398:903] Periodic events are already being generated
2011-11-03 12:37:35.513 App[4398:903] *** Terminating app due to uncaught exception ‘NSInternalInconsistencyException’, reason: ‘Periodic events are already being generated’
*** Call stack at first throw:
(
0 CoreFoundation 0x912a86ca __raiseError + 410
1 libobjc.A.dylib 0x907055a9 objc_exception_throw + 56
2 CoreFoundation 0x912a83f8 +[NSException raise:format:arguments:] + 136
3 Foundation 0x967cc75b -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 116
4 AppKit 0x972878e0 +[NSEvent startPeriodicEventsAfterDelay:withPeriod:] + 160
5 App 0x003dbba6 _ZN4juce14MessageManager16stopDispatchLoopEv + 164
6 App 0x00253b87 _ZN4juce15JUCEApplication4quitEv + 25
7 App 0x000e144f _ZN27Application8shutdownEv + 111
8 App 0x00252abc _ZN4juce15JUCEApplication21shutdownAppAndClearUpEv + 300
9 App 0x00253924 ZN4juce15JUCEApplication4mainERNS_6StringEPS0 + 406
10 App 0x002539bb ZN4juce15JUCEApplication4mainEiPPKcPS0 + 137
11 App 0x000e0d85 main + 64
12 App 0x000e07fd start + 53
)

but where as in MAC if i create the project as commandline, command line working fine and GUI is not working.
So now doubt is what i am approaching is this correct design?

should make it is 2 separate exe for GUI and Non GUI mode?

Thanks.

At least on Macintosh, it would be a good idea to have separate applications. In Macintosh command line application cannot be used to display any GUI. You might face issues with mouse click and there won’t be any menu bar.

You could design a GUI application which could use some of the functionality of the command line application.

[quote=“vishvesh”]At least on Macintosh, it would be a good idea to have separate applications. In Macintosh command line application cannot be used to display any GUI. You might face issues with mouse click and there won’t be any menu bar.

You could design a GUI application which could use some of the functionality of the command line application.[/quote]

Sorry, but that’s a terrible piece of advice. In OSX there’s no difference between a command-line binary and a GUI one. The only difference is that for it to run as a GUI app, the binary needs to be inside an app bundle. But the binary is the same.

And like I’ve said about ten times on this thread, have a look at the introjucer where I’ve done exactly this!