Output window

Okey this is about having a console input/ouput window.

I've noticed that you can't close the output window that you get when writing to stdout/stderr. I would like to be able to close the output window and the get it reopened when something new is written to stdout/stderr.

Does anyone know how to make that possible?

@orgin

I think you have to Close(stdout/stderr) and then Open() a console window with /AUTO/CLOSE switches.

Chris

@Chris

Okey, but what if you're not the one opening the console window. (talking about the standard one that is created when you start a program from an icon with start from shell)

@Chris

Trying to follow the SDK. The following doesn't work very well:



A window is opened. (which I don't want, it shoudl only open if tehre's actually any output to it). And there's no close gadget and no output is actually sent to it.


okey changed to:



Which opens the window correctly (when no using /AUTO), but no output actually ends up in the window.

@orgin

Hmm it's weird. SelectOutput() etc seems to only affect processes that is created by the process that called SelectOutput(), not the process itself.

Bug?

Edit: Found the problem:

The stderr/stdout streams are not changed by SelectOutput/SelectErrorOutput.

fprintf(stdout, "blah"); Sends text to old output.
printf("blah"; Sends text to old output
IDOS->Printf("blah"); Sends text to new output.

Ohh well, silly me for mixing up clib streams and ados stream for a quick test.

@orgin

Quote:Strange, it's still working here.

If you just want to use a different CON: for C library stdio when the program is started from Workbench, i.e. you don't need to change it dynamically, add a global __stdiowin variable in your program with the file name, for example
const char *__stdiowin = "CON:64/48/800/200/foobar output/AUTO/CLOSE/WAIT";

If you need to change it dynamically you have to freopen() stdout and/or stderr.

@orgin

Quote:

The converse is also true, The Output() and Error() streams are not affected by freopneing stdout ot stderr.

This has consequences if you want any program you launch to obey your console redirection.

@orgin

Getting a bit upset by this functionality.

If you open a new con:, change something in the file system, and then close the con: then any file system notification event that the changes would have created are lost. Even if the con: have absolutely nothing to do with the notification and file system changes. Is this a bug in the OS?

If I add a 1 second delay before closing the con: then the notification events are not lost and are propagated properly. I just don't see why creating/closing console window would have anything at all to do with filesystem notifications.

(Using DOS notifications above, if I don't use DOS notification the ram-handler throws a really hard crash if I close the console before the notification has propagated even though they have absolutely nothing to do with each other)

Small example schedule not using an asynch sub process:

Add notification on ram:
Create con:
Use systemtags to run 'touch ram:myfile' (without using the con for in/out)
Close con
-> No notification is received

Add notification on ram:
Create con:
Use systemtags to run touch "ram:myfile" (without using the con for in/out)
IDOS->Delay(50);
Close con
notification is received

Asynch mode is not used above.

And also,

It doesn't seem possible to create a console that you can close (hide) while it still not IDOS->Close()'d. Any console that I open (/WAIT/AUTO/CLOSE in any combination) just refuses to close while the creating process haven't done IDOS->Close() one it. Extremely annoying. This means that I can't use the originating process console, input/output streams, when spawning new processes (systemtags) since if the new process writes some output the I'm stuck with a visible output window that can't be close until the original process is closed.

HEEEELP ! :)

@orgin

I've no idea about the notification stuff but interms closable consoles the followinf seems to work...

Using clib stdio
Quote:

using pure dos.library (for output)

Quote:

In both cases the user can close the console, and it will reopen, on the next line of output.

@broadblues

I have a RA_HandleInputLoop().

From your example(s) it just looks like it opens a console and quits when it receives "QUIT". There's no actual 'reopening'.

So is the following what you're saying that I should to? (isn't Gets() blocking btw?)

assign new console



If gets is blocking then the above won't work since the event loop will be stalled until there's some actual input to read. By "gets" do you mean IDOS->FGets() ?

@orgin

Well you wouldn't use gets() in your real loop

I used gets() above to get something to write to the console and to stop the example from falling stringht through with the bother of setting up a Wait loop of some kind for testing purposes only.

The point was that the console opened automatically when output was sent to it. It can be closed inbetween time BY THE USER.

It seems from your example what you wish to close it yourself, that's aslightly different kettle of fish. I miss inetrpreted what you were trying to acheive.

So in answer to point about a hideable console, with auto set it can be hidden by the user but not the program (without closing the filehandle).


Reading what you said again. Do you want to prevent a console from ever opening in the firstplace? In that case set

do something like

out = IDOS->Open("NIL:")

IDOS->CreateNewProcTags(
NPA_Output,out,
NPA_CloseOutput,TRUE,
...
...
)

when launching your sub process.


(best check those tags names not near my autodocs..)

For a better answer you'll need ColinW's input

@broadblues

Nope neither is what I want to do.


I need the console to open when there's some output being written, and the user must be able close it (not dispose, just close/hide it). Next time some output is written the window opens again.

Think of diropus. You create a button for creating a lha archive. When it runs you get a console window with the lha output, that the user can close at will. Clicking the lha button again and it opens again and so forth.

The console that is either automatically assigned or if I assign my own console (via open(con:)) to my process, cannot be closed by the user until the application calls IDOS->Close() on it. Ie, it stays open until the program terminates.

An alternative is to create a console and send it to SystemTags() when spawning the lha sub process, however that requires that you IDOS->Close() the window yourself once the subprocess is finished, or let it do it itself by calling it asynchronously. However, if you IDOS->Close() the console too quickly all filesystem notifications that teh sub process initiated are also killed (even if the new console is not assigned to the new process) unless I wait a second after the process returns before closing the console (means that the program is stalled for 1sec). And for asynchronous processes there no way to wait since it IDOS->Close()'s it by itself, which means automatic file system notification killing.

Another problem with the second solution is that if you want several sub processes to write to the same console (either synchronously or serialized) then you're basically forced to use the mother process console, but then you're back to the sticky-won't -die-whatever-the-user-does-damnit window.

@orgin

Quote:Please post a small example which has such a problem. At least with simple tests like the following I can't reproduce such a problem here, when starting the program from Workbench closing the console window works and it's reopend when there is new output:

@orgin

Quote:

That's is what I thought you wanted and what my example does. (ignore gets() bit that was just a quick and dirty looping trick).

There must be something different about how you open your console. Or how you pass the filehandle onto your subtask.

@broadblues&joerg

Got it to work now. Don't know why it didn't work this morning.

However the file system notification problem still persists.

- start listening to file system notification on ram:
- create new console
- lauch new process and attach new console to it
- new process simply does "touch newfile"
- new process terminates
- close console

The file system notification fails every time for that one.

if I add an IDOS->Delay() before "close console" that is long enough then the notification is propagated properly.

No delay means total notification absence.
delays between 1-24 ticks gradually improves the situation, with lots of missed notifications at one and basically none at 24.

Running the new process with SYS_Asynch->TRUE leads to 100% absence of notification.


Edit: Note that it doesn't matter if the new process has the new console attached to it or not, as long as a console is closed directly after the new process terminates the notification is killed.

@orgin

Final workaround. Extract from my code:



For asynch processes I add \nsleep 1 to the command string so that they do not quit too fast (and thus close the console too early).

And for non asynch processes I wait 24 ticks before closing the console.

output is a console, FreeConsole() simply does a IDOS->Close()

@orgin

Sorry I'm missing something here... why do you need to close the console at all?

Surely that's down to the user to do once they read the output from the program?

Like by analogy if I set up an external player for AWeb (say mplayer to play movies) I'm either interested in th output, in which case I read it from the AWeb program output console, then close it, or I'm not in which case I set the function arguments to >NIL:

It's not quite the same as your launching arbitrary programs from the filer ( I assume this is filer related) but do you see what I mean?

@broadblues

IDOS->Close() does not close the window. It just makes sure that there isn't an open file pointer left in the system. (don't mix up the user closing the window and doing IDOS->Close() they do different things). The window doesn't disappear from the screen until the user closes it.

@orgin

Oh, okay. . Of course, that's what the WAIT option does... don't mind me ....