I am just trying out Lazarus IDE out of curiosity, with the simplest Pascal program possible:
program project1;
begin
WriteLn('Hi there');
end.
When I run it with F9 in the IDE, I thought I would see the standard output in some window, but I cannot find it.
Does Lazarus provide a standard out view?
Yes, it does and console apps work fine in Lazarus. Probably all you need to do is to add a Readln() statement at the very end of your program so that the console window stays open long enough to be visible, otherwise the console window will close automatically as soon as the program completes execution.
program project1;
begin
WriteLn('Hi there');
ReadLn();
end.
However, it seems that Lazarus behaves somewhat differently: in Windows, the terminal window (aka console) displays automatically when the app starts execution, but may require a final ReadLn as above for it to stay on-screen long enough to be visible. On Ubuntu v.1704, to display the console window, I need to go to View | Debug windows | Terminal Output to get it to display (this is what Ctrl-Alt-O does, of course); once I've done that, the console window stays on-screen even after I close and re-open Lazarus. I imagine that somewhere in Lazarus there is a setting that makes the console window visible by default in new projects.
ISTR that somewhere in Lazarus there is an option to not display the console window, but I can't find at at the moment, so try what I have suggested and see if that works for you.
Of course, if you put a debugger breakpoint somewhere before the end of your program code, you should find that the console window is on-screen when the breakpoint trips.
Related
I'm writing an application for Windows 10 to display and update text at specific locations in a Windows console window. The program is launched by a command in the console window. Upon launch, it erases the window's previous contents, then displays its output, updating as it goes, until completion. Upon exit, it should leave the displayed output in place, and a new command prompt should appear below. Launch, display, and subsequent command prompt all occur in the same console window. (Old school, I know, but that's the requirement.) The program is written in C and uses calls to the PDcurses library to control cursor placement and to output display text to the screen. The application is built with GCC/MinGW on a Windows 10 platform.
Everything works until the application exits, but then the display output disappears and the previous window contents (from before the app was launched) reappear. From what I can tell, this seems to be the default behavior for curses, possibly due to the way it handles screen buffering.
I'm looking for ways to override this behavior, but I'm not sure how to approach it. Can I direct PDcurses to write to the standard screen buffer rather than the alternate screen buffer (if that's what's going on)? If so, how? Should I copy the contents of the screen buffer before I call endwin(), then copy those contents back to the screen buffer afterward? Again, how? I'm sure this problem has already been solved, probably many times, but I haven't found any solutions that seem to apply to a C executable running in a Windows console, and I have only limited experience with PDcurses and the Windows API library. Any help would be appreciated.
The official way to do it is to set an environment variable: set PDC_RESTORE_SCREEN=0. You can combine this with set PDC_PRESERVE_SCREEN=Y to prevent PDCurses from clearing the screen at startup.
Any way to keep debugged program window open while stepping the code in ollydbg? The program displays buttons in a loop in a dialog box. But its window stays minimized so I can't observe what effect each command has on visual display.
source: https://legend.octopuslabs.io/sample-page.html (tutorial 16A)
Since you are debugging this program, the program will be "stuck" before GUI components initialized and enter the main loop of GUI thread. You can just keep all window away of "hovering" the program's window, for example don't maximize your OllyDbg window.
I am trying to write a program what will manage few console windows, my program will be able to CreateProcess() for new console windows, get a window main handle and the use that handle to resize, close, hide, change title etc. But I cannot find a reliable way to get a main window handle. The purpose is to have a tab bar and switch between created console windows with the click on the tab.
I have tried few ways:
1) use windows "cmd.exe" ability to set window title, and then FindWindow("tmp_title"...)
This has a problem, I do not need cmd.exe running, and also I need a processID for the target program not the cmd.exe. Maybe I should use this way but check for children subprocesses?
2) EnumWindows() then CreateProcess() then wait 40 ms, then EnumWindows() again and find the new window.
This is unreliable! I got two new windows sometimes for weird reasons.
3) use GetWindowThreadProcessId() + EnumWindows(). This worked the best on XP, but on win7 the found window seems to be the wrong one, it's GetWindowText() returns "DefaultIME" and hide/show of this window does nothing. So it is obviously a wrong one.
So any idea how to do it reliably and if possible cross-platform (Cross-windows, XP,Vista,7)
When my program is paused in Visual Studios 2010 during debugging, like from reaching a break point and me doing a manual step through, the program window becomes impossible to view.
It is a GUI window not a console window, which I run simultaneously with my program and am still able to view. The window seems to be open it's just that when I click its icon on the taskbar it doesn't come to the front of all the other windows. When I minimize all the windows in front of it, I see the outline of the window but it is either blacked out or showing the remnants of previously expanded windows.
I've noticed this with using Visual Studio's before (various versions of it), and after trying other IDE's that didn't have this behavior I notice it more. It would be really helpful to view the program's change's as I step through the program. Anyone know how I can do this?
I searched a long while and couldn't find a single reference to this matter.
The reason the window doesn't display is that the window paint message won't be processed if the main thread has been paused. Which other IDEs let you do this? I haven't come across any native code debuggers that do this on Windows.
If you are stepping through code that is run by the main thread, then the main thread can't simultaniously poll the message pump, which is needed for the GUI to work.
If you debug a different thread, the GUI will work while you are debugging.
How do I make a process go the background programatically?
What I want is for the user to double-click the process executable, and it just goes into the background ... and does not open a window while executing.
Any code snippet in visual c++ would be very helpful
Have you considered creating a Windows Service instead? They're specifically designed to run in the background without showing a UI.
Otherwise, just create an application without a window.
I know this is old, but I thought I would post something for when people find this through search.
While I like Cody Gray's answer for design correctness, sometimes you don't have a choice.
If you want to launch a program without jumping to the new window (it appears in the background or minimized) or not create a window at all try looking at the ShellExecute and ShellExecuteEx functions. The argument nShowCmd (or nShow) gives you (among others) the options:
SW_HIDE
Hides the window and activates another window.
SW_SHOWMINNOACTIVE
Displays the window as a minimized window. The active window remains active.
As the documentation says, SW_HIDE creates a process running the executable you give it, but if this program would normally create a window, none appears.
This might help: http://ss64.com/nt/start.html
I tried this way and it worked fine:
Create a console application and write your codes in the sub main as any other console application.
Now change the application type in the project properties to windows Forms application from Console application
thats it