Delphi 5 WriteLn to Console AND Text File - console-application

I have made an console application (A) which runs independently every day to download files and uses WriteLn('text') to display progress in the console.
I then have another GUI application (B) which displays that data in tables, but can also call the first program (A) using ShellExecute.
I need (A) to write a log to a text file as well as display it's progress, so I have two questions:
Is there a faster / less tedious way of outputting to textfile AND console other than using AssignFile(F,log.txt) and then find/replacing every WriteLn with:
WriteLn('my output text');
WriteLn(F,'my output text');
Is there a way for my GUI application (B) to display the output from (A) in realtime from the text file, or at least know when (A) is complete. At present I display a message "Please wait for external import to complete and press OK" after which it refreshes the tables.
Thanks

You should be able to redirect the output from A to B and then display it in B and log it in B. Its been a long times since I used Delphi but if B is a .net app, there is a nice article here : how to redirect standard output

Related

Used System function to open an excel sheet

I'm using System function System(mypath/test.xls) to open and edit an excel sheet in C++ run time. It opens my excel sheet, allows me to edit ans close the same. After closing the excel sheet, the control goes to the code again. Everything works fine unless there is already some other excel sheet opened. If there is some other excel sheet already opened in the machine, I will not able to edit and close so that control goes to code. Can anyone suggest any solutions for this issue.
What is happening is your System(..) function call is asking the Windows shell to find the application associated with your file (test.xls) , which is Excel. Then if Excel is already running it is asked to open file. If the application is not running, then Windows starts the application for you.
So if the application is not already running and it is started for you it becomes associated with your program as a 'child' process. Therefore your System(..) call waits for it to end before continuing. If however Excel is already running then once Windows informs that instance of your desire to open the file test.xls, your call to System(..) returns immediately.
You can avoid this by explicitly running the Excel program by giving the full path to the Excel EXE file. And including the /x command line argument and full path to your file. The /x causes Excel to open a new process and then open your file. This new process is a child of your program's so the System(..) call will wait..
I'm not familiar with the System(..) call (is it like the system(..) one?) you may have to provide the switch /x, and path arguments as distinct arguments to this call rather than in one long string. Also there may be options on how your child process is launched, so waiting for it to return may be optional and so forth.

Displaying current output in wx.textctrl wigdet from python code entered in another wx.textctrl

I use two wx.TextCtrl widgets in my wxApp.
The first one is used to provide Python code by app user, e.g.:
from time import sleep
for i in range(4):
print i
sleep(4)
The second one is used to display the output.
To process user code I use EXEC.
But I have problems with displaying output dynamically.
Currently the output is displayed in second wx.TextCtrl widget but after whole code is processed (after 16 seconds).
I would like to display the user's code output every 4 seconds in above code.
How to do that?
I was trying to use threads but there are problems with using exec in case of threads.
time.sleep will block the GUI's main loop, which is why you don't see any output. You will have to put that into a separate thread if you want to go that route. Otherwise, you could use a wx.Timer.
Here's a tutorial: http://www.blog.pythonlibrary.org/2009/08/25/wxpython-using-wx-timers/
I don't think you should use Python's exec command though. That can lead to code injection issues. Instead, you should consider using the subprocess module.

how to handle different input/output in one console?

I am working on a windows sever program using c++, when the program started it stays for several days and output important logs to the default windows console.
now I want to add some control function to the console, like I cound enter something like query or stop, and the program ouput the variable number or stop accept requests. So there is the problem, I got two output stream(log and query response) and one input stream both mixed in one single console.
How do I seperate the three different stream in one single console? Maybe I cound write my own console to replace the default windows console?
I believe this is a very normal need and a lot of server application has implemented this but I could not find any source code...
I know I could use ncurses, but I think ncurses seems too low level for this. Any suggestion will be apprecitated.

Howto call external program and get it's output from another program

Howto do this in c++:
Suppose that program A is a command line tool with some inputs (for example file paths and a number), according to it's inputs, it may get some other parameters during runtime. (if(condithin) cin<<something) I'd like to call A from another program B and want to see complete output of A during it's running. A's inputs must be entered (if necessary). B is a gui tool written with Qt and A must be shown in a plain text area and it's inputs must be shown in same place (like a console client).
I just don't know where to start. Reading something about IPC didn't help. I know it's possible because I see Dolphin's console window and python interpreter in Eric IDE...
use QProcess::execute method to start running A. you can form the argument list from B to pass to A. Use QProcess::readAllStandardOutput () to read the output of the process and display in B.
Since you use Qt, using QProcess is probably the best way to do it.

Async Console Output

I have a problem with my application win32 console.
The console is used to give commands to my application. However, at the same time it is used to output log messages which mostly comes from asynchronous threads. This becomes a problem when the user tries to write some input and simultaneously an async log message is printed, thus thrashing the display of the users input.
I would like to have some advice in regards to how to handle such a situtation?
Is it possible for example to dedicate the last line in the console to input, similarly to how it looks in the in-game consoles for some games?
You can use SetConsoleMode to disable input echo and line editing mode. You can then echo back input whenever your program is ready to do so. Note that this means you will need to implement things like backspace manually. And don't forget to reset the mode back when you're done with the console!
This is possible using the Console API, but it involves quite a bit of work and all the threads that use the console will have to cooperate by calling your output method rather than directly calling the Console API functions or the runtime library output functions.
The basic idea is to have your common output function write to the console screen buffer, and scroll the buffer in code rather than letting the text flow onto the last line and scroll automatically. As I recall, you'll have to parse the output for newlines and other control characters, and handle them correctly.
You might be able to get away with using "cooked" console input on the last line, although in doing so you risk problems if the user enters more text than will fit on a single line. Also, the user hitting Enter at the end of the line might cause it to scroll up. Probably best in this situation to use raw console input.
You'll want to become very familiar with Windows consoles.
Any time you have asyncronous threads trying to update the same device at once, you are going to have issues like this unless something synchronizes them.
If you have access to everyone's source code, the thing to do would probably be to create some kind of sync object that every task must use to access the console (semaphore, etc).