Console prompt (Windows)

[Michael Vogel]

I want to write to the actual console window and 'return' to the prompt again. In the example below (needs to be compiled for console) I have to press the return key again:

Code: Select all

#DebugMode=0

Procedure Console(s.s)

	OpenConsole("Run Tool")
	PrintN(s)
	;ConsoleError(s)
	CloseConsole()

EndProcedure
Procedure ConsoleEnd()

	CompilerIf #DebugMode
		Delay(2500)
	CompilerEndIf
	End 99

EndProcedure

Procedure Main()

	Console("Main")

	If CountProgramParameters()
		Console("Hurray!")
		ConsoleEnd()

	Else
		Console("Run")
		RunProgram(ProgramFilename(),".",".")
		ConsoleEnd()

	EndIf

EndProcedure
Main()

Output:

Code: Select all

E:\Xtras\Pure>test
Main
Run

E:\Xtras\Pure>Main
Hurray!

[PBJim]

I want to write to the actual console window and 'return' to the prompt again. In the example below (needs to be compiled for console) I have to press the return key again:

Hi Michael, you don't have to press Enter again — you're already back at the Windows command input, but you don't see the command prompt. It's due to the logic of your code, because you're calling your own programme again, if you don't run it with a parameter.

1. Example with a parameter :

C:\>cons1 Hello
Main
Hurray!

C:\>

It is doing what is expected of it.

2. Again, proof that it works without a parameter

C:\>Main
Hurray!
cd <---- Entered a Windows command and it responds as expected with C:\
C:\

C:\>

You also close the console every time you write a line to it. I would remove your complicated procedures, it was not easy to see what was going on because of the Main() and Console() and ConsoleEnd().

As a test which is all that is necessary to test the claim that you need to press Enter again, the whole thing can be replaced with two lines of code.

Code: Select all

OpenConsole("Run Tool")
PrintN("Yes, working")

[Michael Vogel]

The 'complicate structure' is part of the problem, that's the point. I do use a single program for two jobs:
- the main task is to stay in the background and wait for commands
- the second job will send commands to the tool which still runs

The whole thing works fine when using windows (and there is also no need for an additional RunProgram) but now I create a slimmer console only version.
Seems that I have to throw all messages back from the background program to the active instance to get rid of the problem.

[infratec]

Why not using udp on localhost for communication ?

[PBJim]

The whole thing works fine when using windows (and there is also no need for an additional RunProgram) but now I create a slimmer console only version.
Seems that I have to throw all messages back from the background program to the active instance to get rid of the problem.

How did you achieve what you needed in a window, Michael, without needing to call the application by itself? I just wondered, can't the console version work on roughly the same basis as your windowed version? Could you run your other commands inside threads and do it that way?

Apologies if I'm not on the right track with what you're trying to achieve, but just trying to get a better idea. I'm not quite sure of the intention that's all.

[Michael Vogel]

When starting a windows program (by mouse click or from command line) the program won't block the process where the program has been started from. Starting notepad.exe from cmd.exe does give back control to cmd.exe immediately. If you start a command line program you'd need to wait until it is terminated (without starting an additional command line instance by using start, cmd /k, etc.).

It's relative easy to create a single windows program abc.exe which will stay in background when started and can be easily controlled by restarting the program again with parameters (abc show message, abc quit, etc.). I was thinking to create a small (means console only) cronjob tool which stays in background but can be called by commands like (cron add 8:00 x:\y\task.exe, cron show tasks, etc.).