I have a ruby script that displays it's progress via the cmd and completes in about 10 minutes. In the last few weeks the cmd seems to freeze and after 10 minutes when I click on the cmd window it then completes the script.
I have searched on forums and suggestions include: disable QuickEdit Mode & Insert Mode which I have done but this has not fixed the problem.
The platform is an azure windows server 2016 VM.
Could this problem be due to a recent windows update?
Thanks
If you are using the usual Windows Command Window, Ruby has no way of knowing that you have clicked into the Window, so it is unlikely that it is related to the code. However, Windows does block a command to write to the command window on certain circumstances, and if this happens, Ruby waits on, say, STDOUT.puts, until it is allowed to continue. Of course this applies not only to Ruby, but to any application writing to the command console.
The most typical situation, in which this occurs, is, if you (maybe accidentally) select with the mouse something in the console Window. The script running in the console is blocked. By clicking with the mouse inside the window, the selection is cancelled, and the program continues to run.
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.
The scroll bar in WSL is not usable while running a process. My attempts to scroll up are futile because the system automatically sets the scroll bar to the bottom of the window since there's a process running.
In my case, I invoked ./gradlew bootRun, which starts an application on 8080 and keeps printing logs. I tried to read the logs by scrolling up but any manual upward movement of scroll bar was being overridden.
Just wondering if some other Windows 10 setting is causing this or is it specific to bash or is it specific to gradle? How to fix it?
I believe this is neither related to WSL nor to the shell, but to the terminal. And even in case of WSL the terminal is still conhost, which is also used by the regular Windows cmd prompt.
That said, I don't believe there's a fix / setting for this right now, but you might have luck seeing this address in the new terminal app being created currently by Microsoft. In its current state, though, I also see it auto-scrolling to the bottom for ongoing output.
I build a fullscreen GUI application for Windows (using LabVIEW but the language should not matter much) that should start with Windows.
I want it to be fullscreen (hiding the Windows taskbar), so I set the window bounds to the screen's resolution.
When I manually launch the exe from explorer, the window hides correctly the taskbar.
But when I launch it from a scheduled task at Windows logon, it is behind the taskbar, until I click on the application. Same thing when I run the scheduled task manuallay in the task scheduler.
I tried the Win32 API function SetForegroundWindow but without success. Maybe the conditions are not met but I do not understand why, there is no other visible window.
How could I force the fullscreen of the app when it auto-starts?
If this is impossible from the application itself, an external solution to the application's code might be ok (e.g. some script running with the scheduled task), but I don't see one either.
Hey so I was having the same trouble when I scheduled a full screen application to run at login. the way I got around this was by creating a mouse click macro and scheduling it at user login with the app (had to set a 10 second delay to allow for the app to load).
It's a bit dodgy but it got it done for me
I just installed Neo4J community for windows10 . The menu can launch Neo4J and shows the small window with 'choose database' and 'stop' and 'start'.
Everything seems ok, i can start, use the db, and stop.
I can restart or stop, as long i don't close this small window.
If i do, i can no more start Neo4J as it is still running in background (seen in task manager ) and never show again this small window.
As a workaround, i kill the app in task manager, then the window re appears on next start .
any idea ?
Even though the window has gone away, the process itself is still running (neo4j-ce.exe). If you open the task manager, look under "Background Processes" and find it there. Select it and then press "End task". You can restart Neo4J after that. I haven't found an answer as to why you have to do this, but it seems to have popped up with the 3.1 version.
When the Neo4j database is stopped by clicking the stop button and the GUI closed by clicking the X in the corner, the Neo4j process continues to run in the background as described by chrisvest Neo4j process still in memory after stopping and closing the window. This is a feature. However, trying to launch the GUI again from the exe or a link to the exe will not work. You will have to locate the small Neo4j icon in the taskbar and click on it. The GUI will reappear. There is no need to kill the Neo4j.ce thread or restart the computer.
I want to disable / block the mouse click and keyboard typing for 6 seconds after launching a .exe file while displaying a advsplash.
Currently I manage to run a .exe file, activate the splash, block the keyboard and run a second .exe, but then, I need to restart the computer to unlock the mouse/keyboard.
Any idea on how to disable it without restarting the machine ?
This sounds like something you should never do.
If you want to do UI automation Windows already has support for that, using SendInput or keybd_event is not a good idea. Some apps steal foreground focus, this is just a fact and if that happens at the wrong time you end up sending input to the wrong window.