TextEditor input going to console


#1

I've got an odd problem.  My application has a console component, just using stdio for the user to type text and see responses.

When I create a TextEditor on Linux or Windows, the editor behaves as expected, e.g. the text shows in the text box.

But on OSX, the when the editor has focus, all the text appears on the *console* and not in the control.

 

What am I doing wrong?  Is there something I need to tell OSX (or perhaps a compile or link flag)?


#2

If anyone has any suggestions as to what to try, I'm game.

I note that the JUCE Demo works fine on OSX, so clearly I'm doing something odd... but I also clearly have no idea what it may be,  particularly since Linux and Windows both work fine for me.


#3

There was nothing wrong with my code.  The problem is the OSX packaging.

When I remembered to put the exe inside an "app" wrapper, lo and behold!  it works now.

Is there no facility for starting a GUI application + console on OSX?


#4

Is there no facility for starting a GUI application + console on OSX?

From the terminal, you can type

open /path/to/your/app

...and anything the app outputs to console (such Logger::writeToLog(String)) will show up there.

I use this to debug plugins in Logic often.


#5

Thanks.

Yes, I discovered I could "open" the exe from within the app wrapper, and OSX would hook up the pipes correctly.  In my naivete I assumed I should be able to simply invoke the exe directly... doesn't work as well.


#6

I understand I can use 'open' on a bundle and it will hook up the input correctly.

However:

Is there a way to start my raw binary outside of an .app , and have the GUI (TextEditor for example) correctly get the input?

Surely there must be some programmatic  way to tell OSX that the console shouldn't get input, but rather the application?


#7

Any ideas on this?

Basically, the problem is: a GUI application if it is run outside of an .app container, does not get input events - they go to the console it was launched from.

I'm looking for a solution to this, since it is not convenient to always package utilities inside an .app , for my use cases. 

Thanks!


#8

Does anyone have ideas about this? It’s becoming a user issue.