Several years back, I innocently tried to write a little app to save my tactically placed desktop icons because I was sick of dragging them back to their locations when some event reset them. I gave up after buring WAY too much time having failed to find a way to query, much less save and reset, my icons' desktop position.
Anyone know where Windows persists this info and if there's an API to set them?
Thanks,
Richard
If I'm not mistaken the desktop is just a ListView, and you'll have to send the LVM_SETITEMPOSITION message to the handle of the desktop.
I googled a bit for some c# code and couldn't find a example, but I did found the following article. Torry: ...get/set the positions of desktop icons?. It's delphi code, but I find it very readable and with some P/Invokes you'll be able to translate it to c#.
The desktop is just a ListView control and you can get its handle and send messages to it to move icons around using LVM_SETITEMPOSITION.
Getting icon positions using LVMGETITEMPOS is a bit more complicated, though. You have to pass a pointer to a POINT structure as your LPARAM. If you try to do that, you will likely crash Explorer. The problem is you passed it a pointer in your address space, which the control interpreted as a pointer in Explorer's address space. Ouch!
The solution I've used is to inject a DLL into the Explorer process and send the message from there. Then you just have to have a way to get the position info back to your process.
I am still looking into this and will post the result once I finally get something working. I'm posting this because, thanks indirectly to Davy's post, I also found a classic VB implementation:
Shuffle Desktop Icons Using Interprocess Memory Communication
and that will probably be the basis for my code.
I have no idea about the API, but I know Ultramon (http://www.realtimesoft.com/ultramon/) has a feature included for preserving icon placement (although I've never used it for preserving icon location, it is indispensable for multiple monitor usage). The latest beta release works flawlessly with Vista (except for sometimes having a minor glitch or two when initially logging into my machine via RDP), and of course, haven't had any issues with XP. I've used it for over four years now.
And did I mention that it's the best utility for multiple monitor usage?
may be you want this one?I find it in 《WindowsCoreProgramming 5th》 https://github.com/wang1902568721/WindowsCoreProgramming
Related
I'm interested in begin able to manipulate windows programmatically. Perhaps by clicking on a window so it has focus, then by using some key combination, I can move the windows. Also, I'd like to move the windows in the z-direction, which would mean that it would appear to get smaller as it went deeper into the screen and bigger as it was moved toward me.
I would like this to apply to any existing window, being a text editor window, a browser window, or even the calculator program window.
The problem is that I have no idea what technology would be needed to accomplish that.
Any ideas?
You'd need to use the Win32 API (using P/Invoke).
"Manipulating" a window would need several different API functions depending on what you want to do... these are a few:
FindWindow (pinvoke.net link) will allow you to find the window handle so you feed it into the other functions (there are more ways to find a window handle depending on your needs, but this one is by far the easiest)
MoveWindow(pinvoke.net link) allows you to set position and size
SetWindowPos (pinvoke.net link) to set the z-order of top-level windows
etc.
Use http://pinvoke.net to find out how to call Win32 API functions from c#, and use the MSDN (this link: http://msdn.microsoft.com/en-us/library/windows/desktop/ff468919(v=vs.85).aspx in particular) for a reference of all functions to handle Windows.
Update
Rereading your question it looks like you want to "simulate" a 3D-like effect in your windows. This is not in the API and there's no standarized way to do it as far as I know (the modern accelerated DWM does it, but I don't think you can access any functions to do that via its API).
You could research into capturing the window contents to a bitmap, and render that bitmap scaled into your own window. It's not impossible, but it's not precisely easy and would be WAY too long to explain how to do this here.
Update 2
There's actually a DWM API (link to MSDN), but even with it, I doubt you can do what you want in a practical manner with it
i need to block any screen capture software on the computer from taking screen shots. Since all of them are work on standard API-functions, i think i could monitor and block them.
I need to use C#.
All i have found is how to monitor and block them in a certain program (screen capture program). They are looking for a function in the program, then they change it address on mine function address.
But how can i do it, if i haven't any certain programs? I need to block anyone which tries to take a screenshot.
If your final goal is possible or not I don't know, but for the hooking the API portion I can help you out.
I have used the library EasyHook many times in the past, this will let you hook and intercept system function calls from C# code fairly easily. Just read through the PDF tutorial for setup instructions.
For actually finding the API's I recommend Rohitab's API Monitor, it's still in Alpha stages but it works really well and is free. You just hook it on to a processes and it tells you every external DLL call it makes (with the parameters it passed if you have the xml definition file for the DLL, the program comes with almost all of the windows API dll's pre-defined).
The combination of EasyHook and API Monitor is a great 1-2 punch for mucking with other program's calls.
It is not possible to prevent screenshots from being taken. The battle is already lost because of the DWM (Desktop Window Manager). It's lower level than Win32 and device contexts.
If you want to protect the text in your program, there are a lot easier ways to extract it than doing screenshots and OCR. TextOut and/or Direct2D hooking and accessibility APIs.
If there's a lot of IP in your program. Then don't make it all available onscreen. Make sure it's tedious to crawl the GUI for text, and hard to automate it. And don't load whole texts in memory of the program.
Possible solutions:
1. To prevent copying of text. Draw the text as an image.
2. To prevent accessibility technologies, like screen readers - override WndProc in your control, handle and ignore the window message WM_GETOBJECT.
3. To make it harder if they try to use OCR. Draw graphics behind the text. Human readable, but much harder for a machine to interpret it.
Neither of these methods are invasive for the user.
** A very invasive suggestion **:
If you are really serious about preventing anyone from "stealing" your content.
Implement mouse and keyboard hooks. Filter out typical copy shortcuts. Prevent the mouse from leaving the boundaries of your application.
Allow your application to only run when the OS runs well-known processes and services.
If any process starts which you don't recognize, black out the application and notify the user about it, and request the user to close it. And ofc make sure someone is not just spoofing a well-known process.
Monitor the clipboard as you suggested yourself.
You can ofc soften some of these suggestions based on the context of your application.
As Scott just posted it likely can be prevented with API hooks to see that paint events only go to desktop bound handles and not others, and refuse to paint otherwise. However, you need to consider the following scenarios and see if they're relevant threat to your approach or not:
Your software may be running in a virtual machine like VMWare. Such software has capapbilities to capture screen that does so at "virtual hardware" level, and your API hooks will not be able to discern it - and this would be the easiest way approach if I wanted to bypass your protections.
As a post suggests here, nothing also prevents someone to take monitor cable and plug it into another computer's capture card, and take screenshot that way. Again, your hooks will be helpless here.
Bottom line, you can make it somewhat harder to do, but bypassing such protection may be pretty trivial thing to do.
My 2c.
Recently I’ve been working on a windows wallpaper manager. It will scan multiple directories for images and have a settings window to customize. In addition, I want to bypass the built-in wallpaper and instead use a windows form based off the ideas discussed here: Setting a Windows form to be bottommost to allow for greater control over image placement. I have built the file operations to find the wallpapers, and various other support operations.
However, I am stumped on how to implement a windows form properly. Not just the one in the Stack Overflow post above. So far none of my CompSci classes (7 so far) have discussed GUIs, and thus I have no knowledge to work from. I turned to the internet to learn how to work with GUIs. While I learned plenty to start a thread, or show a form, I was never able to find anything that described the proper way to engineer an application with a GUI. All I have learned in respect to engineering the application is to limit the number of threads, and try to separate the GUI from the non-GUI related code (if that makes sense).
Like I have said, I have no clue what I am doing. If someone would be willing to give me pointers or even a link to something on this subject, that would be amazing!
EDIT: I have been using this as a learning exercise, and I have mostly been learning from trial and error, probably mostly error
To draw on the true desktop, you need to get a handle to it: GetDesktopWindow is the function to use. But to change the wallpaper you do not draw on the desktop, but instead you use the dedicated API for handling the desktop wallpaper: SystemParametersInfo(SPI_SETDESKWALLPAPER, ...). There is also the legacy COM Shell interface, IActiveDesktop and IActiveDesktop::SetWallpaper.
As you can see, none of the APIs to manipulate the desktop and the wallpaper are managed (C#, .Net) so you will have to jump through some hoops to get this working from C#. If your goal is to learn C# style UI, I would recommend to stick to the 'blessed' way of doing this (winforms, WPF etc) and do not try to jump straight to p-Invoke and COM interop. Perhaps you can pick another project, eg. display the images/pictures in a carousel in a form.
If you're curious still, Google for C# and SystemParametersInfo or IActiveDesktop and you'll find examples of how to do this from managed C#, many examples right here on StackOverflow.
Bonus: of course Raymond Chen has a blog on this topic: How do I put a different wallpaper on each monitor?.
I need to capture the visual output (like a screenshot) of a DirectX window.
Currently, I use this approach.
But, when the window is in background, it captures whatever is in front of it.
I see that DirectX windows render even when minimized or in background, so this should be possible.
But, how? (It also needs to be fast, and it needs to work on Windows XP too, unfortunately...)
Edit: I am very busy these days... Don't worry, I'll put the bounty back if it expires.
To capture Direct3D windows that are in the background (or moved off screen), I believe you have the following options:
Inject and hook Direct3D within the target application via the link you have already posted or this more up-to-date example (EasyHook can be difficult to get setup but it does work really well) - you can always ask for help about getting it working. I have used that technique for capturing in a number of games without issues (most recently for an ambilight-clone project). The problem with this approach is your concern about game protection causing bans, however FRAPs also uses hooking to achieve this, so perhaps your concerns are exaggerated? I guess gamers being banned for a screen shot is an expensive way of finding out.
For windowed applications on Vista/Win 7 - you could inject and hook the DWM and make your capture requests through its shared surface. I have had this working on Vista, but have not finished getting it working on Windows 7, here is an example of it working for Windows 7 http://www.youtube.com/watch?v=G75WKeXqXkc. The main problem with this approach is the use of undocumented API's which could mean your application breaks without any warning upon a windows patch release - also you would have to redo the technique for each new major Windows flavour. This also does not address your need to capture in Windows XP.
Also within the DWM, there is a thumbnail API. This has limitations depending on what your trying to do. There is some information on this API along with other DWM API's here http://blogs.msdn.com/b/greg_schechter/archive/2006/09/14/753605.aspx
There are other techniques for intercepting the Direct3D calls without using EasyHook, such as substituting the various DLL's with wrappers. You will find various other game hooking/interception techniques here: http://www.gamedeception.net/
Simply bring the Direct3D application to the foreground (which I guess is undesirable in your situation) - this wouldn't work for off-screen windows unless you also move the window.
Unfortunately the only solution for Windows XP that I can think of is intercepting the Direct3D API in some form.
Just a clarification on Direct3D rendering while minimised. During my fairly limited testing on this matter I have found this to be application dependant; it is generally not recommended that rendering take place while the application is minimized (also this reference), it does continue to render while in the background however.
UPDATED: provided additional link to more up-to-date injection example for point 1.
A quick google and i found this Code Project which relates to Windows XP. I dont know if you can apply this knowledge to Windows Vista and 7??
http://www.codeproject.com/Articles/5051/Various-methods-for-capturing-the-screen
EDIT:
I found this article as well:
http://www.codeproject.com/Articles/20651/Capturing-Minimized-Window-A-Kid-s-Trick
This links off from Justins blog post here from the comments. It seems he was working on this with someone (i see thats your link about).
http://spazzarama.com/2009/02/07/screencapture-with-direct3d/
The code that you linked to (from spazzarama), which you said you were using in your project, captures the front buffer of your DirectX device. Have you tried capturing the back buffer instead? Going from the code on your linked site, you would change line 90 from
device.GetFrontBufferData(0, surface);
to
Surface backbuffer = device.GetBackBuffer(0, 0, BackBufferType.Mono);
SurfaceLoader.Save("Screenshot.bmp", ImageFileFormat.Bmp, backbuffer);
This would also involve removing lines 96-98 in your linked example. The backbuffer might be generated without the obstructing window.
EDIT
Nevermind all of that. I just realized that your linked sample code is using the window handle to define a region of the screen, and not actually doing anything with the DirectX window. Your sample code won't work around the obstruction because your region is already drawn with the other window in front of it by the time you access it.
Your best bet to salvage the application is probably to bring the DirectX window to the top of the screen before running the code to capture the image. You can use the Wind32API BringWindowToTop function to do that (http://msdn.microsoft.com/en-us/library/ms632673%28VS.85%29.aspx).
How to prevent terminal (Windows-CE) from shut-down after 5 minutes
the terminal is Motorola MC3190 (Windows-CE) and if i dont touch the screen for 5 minutes
the terminal shut-down. how to prevent this ?
i need the solution in C# code.
thanks in advance
I initially voted to close, but have been thinking more about this, and I think the question you've asked may have been missing an important piece of information.
I think what you need to look at are the Windows CE Power Management functions, specifically SetPowerRequirement. This allows you to indicate that your application is using some device within the system. If not, it's unclear why your application, absent some device interactions, wants to prevent power management from doing its job.
No code needed for this. Go to Start->Settings->Power and uncheck the box next to "Turn off screen if device not used for".
If you tried to do this programmatically, you would be draining the battery power faster than the user intends. That will probably irritate your user.
If your heart is set on doing this, then you can modify the value in [HKLM]\System\CurrentControlSet\Control\Power\Timeouts
I also gave this answer on the MSDN forums
-PaulH
I dont know Windows-CE and i Dont know C#, but I found you an answer on google. Here you go. And now I want to try programing something for some station. Would be great home control device.
Is your Motorola MC3190 configured to Turn Off if it is running on Battery Power? Will it ever turn off if on External Power?
NOTE: I had to post as answer to show image, but this isn't really an answer.
EDIT: If this is what you are interested in, consider reading the device's SystemState property. There are many members to SystemState, and one of them just may be what you are after.
There is no easy technique for what you are wanting to do, because the devices are designed to power down when not in use. If the battery goes dead, the devices have to be completely reset. Make sure this is what you want to do, because there is a reason it is hard to get around.
You'll likely have to register for a BatteryStrength changed event (like >> THIS <<), then try to trick it somehow ...maybe by popping up a dialog box or simulating a key press.
You'll most likely need to P/Invoke some of the lower level coredll.dll functionality (examples >> HERE <<) to get what you want, as this stuff doesn't come wrapped up in the standard WinMobile SDK.
EDIT 2: Here's a Great example that someone wrote to read and control as much of the Power State as possible: techlicity blog I liked it so much I've copied the code to a class in my Mobile Project!