I want to intercept Russian keys in a specific application and send it something else. I don't really know the steps required to achieve it.
Is there a way to write an app in C++ that captures key presses and sends different ones to a specific program, process?
I guess I had to find the answer myself so I've duckduckgoed and found this: C++ KeyBoard hook
Seems like I have to inject a DLL in a process and call SetWindowsHookExA function that supposedly ought to intercept and transform key events that are sent to the process.
I'm working on a program to automatically change the brightness of my displays directly using DDC/CI. Currently I'm using ScreenBright's command line arguments to do this just to get things working, but I would like to move to doing it directly now that things are working.
There is a Windows API, the Monitor Configuration API, to do this, but I don't know how to integrate this into my project, and any usage is only given in C++. The only other thing I can find is doing this from Python, which is no use either.
Any help would be much appreciated.
Currently i'm working on a security monitoring app that continuously monitor new processes created.
For that im using wim and event watcher, witch works fine in VB.NET.
But there are 2 features that im missing.
I need to monitor process API calls, and I've been searching the web like mad, and come up empty.
Basically i need to monitor process WaitForSingleObject, LoadLibraryA, CreateProcessW and WriteProcessMemory. And registry access/changes as well.
Im hoping this can be done without a system wide hook, but form what i can find, it cannot be done via WMI.
So the question is, how to, and what can i do with managed code.
I'm gonna focus on the second point as i don't have experience on your first.
For checking if a process is signed i am using the sigcheck.exe from Mark Russinovich, because of the various methods it uses to verify files. Some are catalogsigned, some have the key embedded, there is iirc another weird method. There is no easy way to do it yourself. Had weird false detections with trying self-built methods to cover all possibilities. Hope that info helps
We have an unattended app w/o a user interface that is is periodically run.
It is a VB.NET app. Instead of it being developed as a service, or a formless Windows application, it was developed with a form and all the code was placed in the form_load logic, with an "END" statement as the last line of code to terminate the program.
Other than producing a program that uses unneeded Windows form resources, is there a compelling reason to send this code back for rework to be changed to put the start up logic in a MAIN sub of a BAS file?
If the program is to enter and exit the mix (as opposed to running continuously) is there any point in making it a service?
If the app is developed with a Form do I have to worry about a dialog box being presented that no one will respond to even if there are no MessageBox commands in the app?
I recall there used to be something in VB6 where you could check an app as running unattended, presumably to avoid dialogs.
I don't know whether there are conditions where this will not run.
However, if the code was delivered by someone you will work with going forward, I would look at this as an opportunity to help them understand best practices (which this is not), and to help them understand that you expect best-practice code to be delivered.
First of all, you don't need it to be run in a Form.
Forms are there for Presentation, so it should not be done there.
If you don't want to mess with converting the application a Service (not difficult, but not very easy neither), you shoud create a Console Application, and then, schedule it with Windows Task Scheduler.
This way, you create a Console Application, with a Main function, that does exactly what you need.
Anyway, the programmer could show windows, so there should not be any messagebox. Any communication should be done via Logging to: local files, windows events, database.
If you want more information on any of them, ask me.
If you don't want it to be a service, nothing says that it has to be a windows service. Scheduling it to run via the Task Scheduler or something similar is a valid option.
However, it does sound like the developer should have choose a "Console App" project, instead of a "Windows Forms" project to create this app.
Send it back. The application is bulkier and slower than it needs to be, although that won't be much of an issue. It is somewhat more likely to run out of resources. But the main reason: converting it to a console app is very easy.
If you don't prefer for the Console window to popup, simply do the following.
Create a new class "Program.vb", add a public shared Main() method, and move the "OnLoad" logic from the form to this method.
Next delete the form, and change the project start up object (Available in the project properties window) to use the Program.Main instead of the Form.
This will have the same effect, without the windows forms resources being used. You can then remove the references to System.Windows.Form and System.Drawing.
Hoepfully someone can shed some light on a problem - I am trying to listen to\intercept all windows messages generated by an application and dispose of certain types, for example Notify or Gesture messages.
I have been reading articals on how to do this using the Microsoft.WindowsCE.Forms.MessageWindow and creating a class which inherits this, overrides the WndProc method but I have been unalbe to get this start listening\watching the message queue automatically when the application starts.
I know it is possible to do this with the OpenNetCF framework and the Application2 namespace however I would prefer not to use 3rd party software at the moment - no offence to the OpenNetCF guys.
Hopefully this makes sense. Also, i am using C#2.0 and Windows Mobile 6.5.
Thanks for your help,
Morris
The solution, then, is pretty simple - all you have to do is spend your time duplicating what the Smart Device Framework code is doing.
You need to create your own message pump via P/Invokes to GetMessage, TranslateMessage and DispatchMessage (it will look just like it does in C). Use this pump instead of calling Application.Run (so there can be no calls to Application.Run in your application).
Inside that new message pump insert your filtering logic.