I have a console application that I didn't write. Is there some easy way to read from it?
I need to have the input still on the console window, but read what's being displayed.
I care not whether the output displays to the console or not, so long as the input still works.
Console Application Runner Classes are excellent to control the console application processes and to redirect input and output where required.
I had a project that is doing the same thing. I have a console application written in VB.Net and I run and capture it's output using my Delphi application. I have successfully achieved this by following this tutorial by Zarko Gajic.
Related
As the https://github.com/neo4j-examples/neo4j-procedure-template/blob/3.3/src/main/java/example/FullTextIndex.java shows, the example shows a public Log log; field but barely use it.
In my case, I use this field to print some log but find it in nowhere, so where is it? And what's more, can I just print the log on the junit console?
Use log.info("message") in your code and go to Neo4j/Logs is in Logs folder neo4j.log file.
Answer by myself:
According to the source code, the logs for harness is saved in /tmp/xxxx/neo4j.log
And the neo4j.log is hard code, I cannot find a way to redirect it to the standard system.out.
Or I can just use System.out.print() in my code, but since this part is not a test code, use System.out.print() only for harness test is a bad idea.
I'll come back if I found a way to redirect the neo4j to System.out
I'm modifying a Firefox extension that has been written by someone else, and I'm not very experienced with Javascript and Firefox, so my question is probably fairly simple.
I have a lot of code in a Javascript Module (.jsm file), and I want to produce some outputs form this module to help with debugging. I can't seem to use javascript alerts (alert("blah");) or log to the javascript console (console.log("blah");) as both of these give errors saying that console or alert cannot be found.
Is there any way to produce this sort of debugging output from code running in a Javascript Module? All I want is simple text output to help with my development/debugging process.
There are two common options:
Use dump(), the output will be printed to OS console (on Windows you need to run Firefox with -console command line option to see it).
Use Component.utils.reportError, the output will be printed to Error Console - use Ctrl-Shift-J to open it.
How to run a console application from a standard Delphi form application, but to run it hidden? Also i want to write commands in that console application from my form application.
How can i do those things?
And a personal request for the people who have the newest version of indy10. I have trouble to compile the console application and if is possible some of you to compile it for me and give me link to download. Please, that will be nice if you do me that favor. :)
To run a console app and hide the console window, call CreateProcess passing CREATE_NO_WINDOW in the creation flags parameter.
I'm currently developing a BlackBerry application using JDE 4.6.1 on Windows XP. Since I'm running the application directly from the console using fledge.exe I would like to know if there is a parameter for redirecting my application output, namely a simple system.out.println call, to the windows prompt console. Right now I'm able to view that output only on the Eclipse console window in Debug mode.
The simulator only outputs through its JDWP interface. If you don't want to use Eclipse, but are ok with a lighter-weight non-command-line tool, you can run the standalone debug server - you'll find a jdwp.bat file under your eclipse\plugins\net.rim.ejde.componentpackX.X.X.X\bin directory.
There may also be command line tools that let you print JDWP info, not sure as I haven't ever used one.
I don't know of a way to redirect the output, but you might consider using the BB event logger. You can use a simple script to extract the logger output
This question already has answers here:
Can one executable be both a console and GUI application?
(9 answers)
Closed 6 years ago.
Is it possible to (and if so, how do I) make a single program work both as a console application and a GUI version using Delphi 2007?
What I am after is that if the program is run with the appropriate command-line options, it should function as a console program, printing output to the console using WRITELN, but if no command line arguments are given it should run as a normal Delphi GUI application?
The catch is that when running as a console application, the command line interpreter waits for the application to terminate before allowing you to enter a new command, whereas a GUI application started from the command line immediately returns you to the command line and the GUI application is started in a detached process. I want this behaviour retained.
I don't mind something like this:
IF GUI THEN StartApplicationAsGUI(ParamStr(0))
ie. I don't mind that I'll have to restart the application using some form of EXECUTE call to start it in GUI mode if needed, as long as the command line interface returns to the command line input when the GUI version is started.
I'd prefer a solution/suggestion that is along the lines of:
<Parse Comnand Line>
IF ConsoleMode THEN
RunConsole(Parameters)
ELSE BEGIN
Application.Initialize;
Application.CreateForm(...)
Application.Run;
END
(or vice-versa, ie. doing things a special way if GUI mode)
so that I can still use Delphi's IDE and VCL when making the GUI interface...
On Windows this is a little bit tricky. Actually the distinction between a console application and a GUI one is a single flag in the PE header. You can easily write console applications that create windows but that way you always have the console window around (you could hide it, though, but that wouldn't be nice when people run your program from cmd).
You can, however write a GUI application that creates a console if it needs to, using the AllocConsole function:
A process can be associated with only one console, so the AllocConsole function fails if the calling process already has a console. A process can use the FreeConsole function to detach itself from its current console, then it can call AllocConsole to create a new console or AttachConsole to attach to another console.
If the calling process creates a child process, the child inherits the new console.
AllocConsole initializes standard input, standard output, and standard error handles for the new console. The standard input handle is a handle to the console's input buffer, and the standard output and standard error handles are handles to the console's screen buffer. To retrieve these handles, use the GetStdHandle function.
This function is primarily used by graphical user interface (GUI) application to create a console window. GUI applications are initialized without a console. Console applications are initialized with a console, unless they are created as detached processes (by calling the CreateProcess function with the DETACHED_PROCESS flag).
However, when run from cmd this will likely cause another console window to appear instead of re-using the existing one. I don't know whether a good solution exists there.
IMO, the best approach here is to have non-visual classes that actually do the work of the program. Then you can call that from a GUI program, and you can also call it from a separate command line program. Both programs are just wrappers around the functionality of your class(es).
This forces the design to be clean too - your classes necessarily are separated from the GUI layer of your application.
http://blogs.msdn.com/oldnewthing/archive/2009/01/01/9259142.aspx
Windows has different values in executable's header for console and UI application (see more details here). So it seems to be impossible to make the same executable to work in both modes.
As an alternative, you can open a console in you UI app, but it will be new console, not the one you've started app from.
AttachConsole() may be used to get a hold of the parents console.
E.g. if the application is started from a cmdline shell, AllocConsole() can be avoided:
if not AttachConsole(ATTACH_PARENT_PROCESS)
then AllocConsole;
More info here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681952(v=vs.85).aspx