This could very well be another silly question, but I can't seem to find the answer (or any for that matter), so here goes.
I have a command line program that uses SIGWINCH on Linux to detect the window size change, and I apparently have a user who is using the program on Windows. The problem, is that the program uses SIGWINCH to detect changes in the window size and this signal is unsupported on Windows. I've tried Googling for every combination of search terms I can think of, but due to the relationship between SIGWINCH and changes in the size of the window, I'm having trouble finding any useful results. I'm looking for a Windows equivalent, or the method most often used to detect changes in the window size on Windows computers.
How do you detect changes in window size on Windows?
Since I don't think you can subclass console windows (and thus catch WM_SIZE messages), you may just have to poll GetConsoleScreenBufferInfo.
EDIT: Upon further investigation (not tested!), it might also be doable without polling using ReadConsoleInput. Summary: Call SetConsoleMode to turn on window input events. From a different thread, wait for the console input handle to become signaled using WaitForSingleObject or a similar function. Read all pending console events; the presence of window buffer size events means something's resized your console window.
I am making a program called "BasicSys". It is a BASIC System simulator that uses a textbox for the console. So far I have everything working great but I need to have the text box act like a command prompt window. It needs to be able to ask for input and retreive the value without allowing the user to modify anything outside of the prompt space (the space where the user should only be able to type is after a ":" or a ">"). Some feilds are password feilds that require either no echoing or having the chartacters replaced by *'s. Is it possible to make a console out of a textbox?
P.S. I also want to know if there are any small BASIC v2 compilers for Win32 so BasicSys can compile and run BASIC programs.
Depending on how realistic you want it to be you can use the API to open a real console window and interact with it. There are many examples available that you can find by searching such as this one. My suggestion though would be to fake it with a multi-line textbox. It would not be very tricky. Set an index every time you draw the prompt, then as long as the cursor is positioned after the index the textbox is read / write. If the user scrolls backwards make the textbox read only. It should be fairly simple using the KeyDown event and setting the ReadOnly property True / False to get a passable "command" window.
Can SendInput be used to simulate a drap & drop operation?
I've got an application that accepts files of a certain format that are dropped on it, but not from the command line, and I want to associate it with a file. I thought I'd create a small tool that finds the window, and simulates a drag & drop of the file - is this at all possible? Do I need to use SendInput or possibly SendMessage? What would be the parameters?
Yes, pretty likely. SendInput injects mouse events at a very low level. SendMessage won't work.
You'll need a thread since DoDragDrop is a blocking call. Fake the mouse down first, start the thread, call DoDragDrop. The thread should sleep to give enough time for DoDragDrop to get started, then fake mouse move and mouse up. Keep fingers crossed that it works the first time, it is impossible to debug if it doesn't.
The shell already has a function that simulates a drop: SHDoDragDrop, no need for hacks like faking mouse input.
Since you are talking about the commandline, XP added support for simulating D&D for applications/registered file types: How do I accept files to be opened via IDropTarget instead of on the command line?
I am quite confused about the stdin and the key_events of GUI widget.
Usually in my mind, I thought stdin is the ordinary way to get the keyboard input for a process. E.g., If I have a process, then I could use stdin to have the keyboard inputs. And this is usually used to make I/O direction for the subprocess to get keyboard inputs. E.g., I could make subprocess.Popen(stdin=PIPE)
On the other hand for GUI, I am using wx.TexCtrl or py.Shell.shell, to catch the key events, like inputs.
So I am quite confused here, if I have a GUI or pyShell running, when I am typing via the keyboard, is it via the stdin or via the GUI key event catching system? If via the GUI key events system, how can I get the keyboard stdin? Can I still simply redirect the keyboard inputs to my child process (inside the GUI) as the ordinary non-GUI programming?
Thanks a lot for any comments.
When you type, the input comes from the GUI event mechanism, not from stdin. You asked how to get the "keyboard stdin", and the answer to that is the same as for any other type of program: you read it (but it will almost certainly be empty). It's important to realize that the GUI probably doesn't have a stdin if it was started by double-clicking on an icon on the desktop.
And no, you can't "redirect keyboard inputs to [your] child process", if I understand your question. Stdin really has absolutely nothing to do with GUIs at all. How keyboard input is read via a GUI is completely disconnected from stdin.
I have a bit of a challenge.
In an earlier version of our product, we had an error message window (last resort, unhandled exception) that showed the exception message, type, stack trace + various bits and pieces of information.
This window was printscreen-friendly, in that if the user simply did a printscreen-capture, and emailed us the screenshot, we had almost everything we needed to start diagnosing the problem.
However, the form was deemed too technical and "scary" for normal users, so it was toned down to a more friendly one, still showing the error message, but not the stack trace and some of the more gory details that I'd still like to get. In addition, the form was added the capabilities of emailing us a text file containing everything we had before + lots of other technical details as well, basically everything we need.
However, users still use PrintScreen to capture the contents of the form and email that back to us, which means I now have a less than optimal amount of information to go on.
So I was wondering. Would it be possible for me to pre-render a bitmap the same size as my form, with everything I need on it, detect that PrintScreen was hit and quickly swap out the form contents with my bitmap before capture, and then back again afterwards?
And before you say "just educate the users", yes, that's not going to work. These are not out users, they're users at our customers place, so we really cannot tell them to wisen up all that much.
Or, barring this, is there a way for me to detect PrintScreen, tell Windows to ignore it, and instead react to it, by dumping the aformentioned prerendered bitmap onto the clipboard ready for placing into an email?
The code is C# 3.0 in .NET 3.5, if it matters, but pointers for something to look at/for is good enough.
Our error-reporting window has these capabilities:
Show a screenshot that was taken when the error occured (contains all the open windows of the program at the time, before the error dialog was shown)
Show a text file containing every gory detail we can think of (but no sensitive stuff)
Save the above two files to disk, for latter attaching to an email or whatnot by the user
Sending the above two files to us by email, either by opening a new support case, or entering an existing support case number to add more information to it
Ignore the problem and hope it goes away (return to app)
Exit the application (last resort)
We still get screenshots from some users. Not all, mind you, so my question is basically how I can make the PrintScreen button help us a bit more for those users that still use it.
One option: Put the stack trace and other scary stuff into the error screen using small, low-contrast type -- e.g. dark gray on light gray -- so that the user doesn't really even see it, but the Print Screen captures it.
But if you want to detect the PrintScreen and do your own thing, this looks like an example of what you want.
Wouldn't it be possible to disable the Print Screen button altogether when the error popup is active? Have it display a message along the lines of "Please use the clearly visible button in the middle of your screen to report the error" I agree it breaks expected functionality, but if your users are really that stupid, what can you do...
Alternatively, have it report errors automatically (or store the data locally, to be fetched later, if you can't send without asking for some reason), without asking the user. If you want to be able to connect print screened screenshots with detailed error data, have it send a unique ID with the data that's also displayed in the corner of the popup.
What about offering them a "Print Screen" button that performs these actions as well as performing the print screen? If you're locked into this method of having your customers send error details, this may be an easier route to take.
Lifted from my comment below for easier reference (looks helpful, perhaps):
codeproject.com/KB/cs/PrintScreen.aspx
This is in theory...the best way to deal with it I would think
Intercept a WM_PRINT message or inject one into your process... see this article here
Install a system-wide keyboard hook and intercept the print-screen key and swap it around with your contents prior to the capture. Now, I can point you to several places for this, here on CodeProject, and here also, keyboard spy, and finally, global Mouse and keyboard hook on CodeProject.
Now, once you intercept the print screen, invoke the WM_PRINT message by capturing the contents that you want to capture.
I know this is brief and short, but I hope this should get you going.
The only solution i came up with was to offer big, large, easy to read toolbar buttons that give the user every opportunity to save the contents of the error dialog:
Save
Copy to clipboard
Send using e-mail
Print
And after all that, i use the Windows function SetWindowDisplayAffinity in order to show the user a black box where the form should be:
This function and GetWindowDisplayAffinity are designed to support the window content protection feature that is new to Windows 7. This feature enables applications to protect their own onscreen window content from being captured or copied through a specific set of public operating system features and APIs. However, it works only when the Desktop Window Manager(DWM) is composing the desktop.
It is important to note that unlike a security feature or an implementation of Digital Rights Management (DRM), there is no guarantee that using SetWindowDisplayAffinity and GetWindowDisplayAffinity, and other necessary functions such as DwmIsCompositionEnabled, will strictly protect windowed content, for example where someone takes a photograph of the screen.
If their screenshots show a big black box, hopefully they'll get the hint.
I did add a defeat, if they hold down shift while clicking "show error details", i don't add the protection during form construction:
//Code released into public domain. No attribution required.
if (!IsShiftKeyPressed())
SetWindowDisplayAffinity(this.Handle, WDA_MONITOR); //Please don't screenshot the form, please e-mail me the contents!