I have a program that modifies desktop workarea using SystemParametersInfo(SPI_SETWORKAREA,...)
It restores original area on exit, but if I kill the program, it won't restore original area and no programs will maximalize. I can restore original area by logging off from windows.
Is there any way how to restore workarea programatically on program start?
Related
I want to run a batch file which set in task scheduler without display console window, my batch need open one wpf app at the end. I tried to set Security Options in task scheduler like this https://i.stack.imgur.com/IgfjU.png, the console window really disappear but my app run in background process (see in task manager) so that I can see it in screen. Since this reason, I change to lock screen by using LockWorkStation(); of user32.dll but I can't auto unlock it. So could I do to unlock the screen?
If can't do it, I want to display a image full screen on top while run batch to hide every thing or any else to notify user that machine under maintenance or in idle as ATM machine do. Currently, I can only open an image with maximized but not full screen. Please help me solve this.
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.
In macOS, Terminal.app, like most native apps store their window state. So if you quit terminal and then relaunch, you get all your tabs back, and each tab is in the same working directory as before quitting. I want to restore this window session from another computer, but I cannot find where it is stored on disk. I have checked for ~/Library/Saved Application State/com.apple.Terminal and ~/Library/Containers/com.apple.Terminal/Data/Library/Saved Application State, neither is present on my system.
~/Library/Preferences/com.apple.Terminal.plist is present, but that appears to only store saved preferences, including optionally explicitly named and saved window-states, but not the implicit "last session" window state.
Can anyone help find where on disk the last session for Terminal is stored?
I imagine this is too platform-specific and may need to be 'hacked on' to emacs rather than being a preexisting feature (if it even can be done)... but I'll ask anyway.
You know how Windows can aggregate all the windows associated with a given process (whether multiple instances of the process or multiple windows tied to the same process) into a single icon on the taskbar?
I'm wondering if I can have a single emacs process and a single window but multiple buffers open, and be able to see each buffer represented as a window when I hover over the emacs icon on the taskbar--when I click on the virtual window from the taskbar corresponding to a given buffer, it switches to that buffer in the process window and pops it?
Nope, I don't think this is possible, at least not out of the box.
Actually, what you see grouped under the same task-bar icon is the list of Emacs frames, not windows or buffers. MS Windows knows nothing about Emacs buffers or windows. It knows Emacs frames as MS Windows windows.
I'm trying to make an simple anti-idle script (that moves the mouse or whatever) to prevent an application from stopping.
How can I keep it running after screen lock ?
It seems like this is explained in the Autoit faq :
http://www.autoitscript.com/wiki/FAQ#Why_doesn.27t_my_script_work_on_a_locked_workstation.3F
On locked station any window will never be active (active is only dialog with text "Press Ctrl+Alt+Del") In Windows locked state applications runs hidden (behind that visible dialog) and haven't focus and active status.
So generally don't use Send() MouseClick() WinActivate() WinWaitActive() WinActive() etc.
Instead use ControlSend() ControlSetText() ControlClick() WinWait() WinExists() WinMenuSelectItem() etc. This way you may have your script resistive against another active windows. It's possible to run such script from scheduler on locked Windows station.
You can't automate anything after your screen is locked. User input is simply ignored. A much easier way would be to prevent your screen from locking, for example, by moving the mouse randomly every 30 seconds.