I'm having a rather odd problem with a C# and WPF HMI I am working on currently. The HMI is a fairly complex program which allows the use to add and remove modules from a work area, dragging and resizing them to make the page they work on customizable. It works well, and after optimizations actually runs smoothly and works wonderfully with touch and animations. One gesture in particular is rather helpful, as you can (using multi-touch) place two fingers down on the screen and swipe left or right to change pages.
However, I have lately been getting complaints from our apps department that the touch will randomly stop working for any sort of complex movement, read as any sort of multi-touch. I spent a few hours tracking down what the problem was and it turned out, oddly enough to be linked to windows Calculator. Whenever calculator is opened, and subsequently closed, multi-touch ceases to function, and any breakpoints placed in the code show only a single touch being used. I took to the internet, and found a few articles corroborating the issue, but nothing even hinting at a fix other than don't allow calculator to work, which is sadly not an option as this HMI is meant for engineers who are manufacturing precision parts and they are a bit attached to calculator.
I stripped the problem down to its basics in which I made a simple c# and WPF touch app which kept track of how many touches it got, just to make sure its not just shoddy programming in the HMI. After getting the same results, no matter what I tried, I came here hoping someone else has run into and perhaps fixed this issue.
Here are some specs:
This HMI runs on Windows 7 and it is fully updated.
It is a C# program using Unity containers, Prism, and WPF
The touch is being handled through simple OnPreviewTouchDown and
TouchDown events
It doesn't matter if I run calculator through a Process in C# or if we run it from the actual OS, nor how we close the program, all permutations result in the same effect on every machine in the building with a touch screen.
It is an ELO touch screen with the newest drivers, though I have also tried it with a Vista Multitouch simulator and get the same results
Any sort of assistance or direction would be much appreciated. Thanks!
You are right. Microsoft released a fix recently for this issue for Windows 8 and other OS's, perhaps it applies to Windows 7 too.
Multi-touch gesture does not work after you exit the Calculator in Windows
Symptoms
This issue occurs in applications that are started before you
close the Windows Calculator (calc.exe) in Windows 8.1, Windows RT
8.1, or Windows Server 2012 R2.
Cause
This issue occurs because the Calculator exits and changes a
property. This causes the affected applications to stop responding to
multi-touch.
Resolution
We have released an update to resolve this issue.
See https://support.microsoft.com/en-us/kb/3024755
Workaround
To work around this issue, close and reopen the affected applications after the Calculator exits.
Related
I've recently had the idea to create a little app that desaturates your screen (with luminance) when you press a shorcut, and it brings back the screen to the normal colors when you press it again.
I've started learning c# some months ago exclusively in Unity, recently I've tried some shader coding and I can make the desaturation with CGPROGRAM, but I have no idea how to make an app outside of Unity or how to get the pixels of the screen and process them in real time.
I've tried some quick searching on how to do this but didn't found much, is there any resources or tips you can link me to so I can do this?
Thanks!
This normally requires an API close to the operating system.
For Windows, try DirectX.
I am developing a WPF application that displays a directX scene.
The code that generates the directX scene is not mine and I have no access to it. (Its not a public code I can references you guys to)
Everything was working fine until I had to format my PC and installed Windows 10. (Before that I had Windows 7)
Now I can't see the DirectX scene and the RenderCapability.Tier on WPF returns 0.
The code works on other computers (Windows 7 and Windows 10) so I'm guessing its something to do with my computer but nothing changed hardware-wise..
I tried reinstalling DirectX and I tried reinstalling the display driver (tried several different drivers) but nothing works I still get RenderCapability.Tier = 0.
The code that displays the DirectX scene is mostly taken from this link:
https://www.codeproject.com/Articles/28526/Introduction-to-D3DImage
I couldn't find any help around the internet that actually solved my problem.
Any help would be appreciated.
Thanks!
Run dxdiag.exe, Display tab, ensure it prints "D3D acceleration: enabled" and "No problems found".
Also the linked sample has a bug, on some systems you must use a query to wait for completion of rendering before passing the texture to WPF. Otherwise WPF may show incomplete renderings, or none at all. If you render with DX9, see this, you need D3DQUERYTYPE_EVENT query, issue D3DISSUE_END after you've done rendering, then sleep until GetData returns S_OK.
This is a C# winforms project.
This has been driving me crazy for over a week. It would be difficult to show the code, because most of it is generated by visual C itself and it would be quite long.
I have a form quite quite a few controls. The form and the program work just fine on my desktop. When I move to my laptop, which has a lower resolution and which is windows 8, the form, which is taller than the window.
This happens even if I resize the form programatically to fit ahead of time. The form will fit inside the laptop resolution, but half of it would be cut off just as if it ran off of the edge of the screen.
It is important to note,t hat when I set the resolution of my desktop down to the same level as my laptop I so not have this problem. The only different that I can think of is that my desktop is running 2007 and my laptop is running Windows 8. I have tried this on two different win 8 laptops with the same result, but my program has worked on multiple desktops. I do not have a laptop with high enough vertical resolution to contain the form before it is resized via the program.
Is there anything windows 8 does differently in this regard? If so, is there anything I can do to fix it? I am baffled--but it is very important that this program work on my laptop. I designed it to help grade papers, and I need to be able to take it with me.
There are so many controls for my program it would be more than a major undertaking to try to resize them all so that they would fit, by default, at a lower resolution. This is winforms, and because of the way they are laid out grabbing them all and resizing makes half of the controls disappear.
Has anybody else had this problem when moving a program with a large form from win 7 to a win 8 laptop?
Sorry this post is so long, but since it was not reasonable to post the code, I wanted to give a detailed explanation.
I had this happen to me before. What I did was make sure the laptop was in its highest resolution (best quality). Then I played with the resolution to get a close fit. If the resolution is 1228x790 then make sure your form is half the size.
The OS has nothing to do with it. It's a monitor to monitor ratio. Base your app on the laptop resolution instead of the desktop. Then with it smaller you can always maximize the form with the maximize button on the form.
Just be sure to anchor everything properly.
I hope this helps. This is what I always do.
While running performance tests my application suddenly started giving blue screen shortly after the UI was loaded.
In the code im receiving the following error:
{"Error HRESULT E_FAIL has been returned from a call to a COM component."}
"The GPU device instance has been suspended. Use GetDeviceRemovedReason to determine the appropriate action.\r\n"
After looking around on google i wasn't able to find anything usefull. The main answers given didn't work such as installing driver updates or reinstalling the application. Keep in mind this is an app in development and it was working fine earlier this day. Between two test launches this happened.
EDIT
After testing the application on a tablet it turns out the development pc is the only machine with the UI loading bug. Going to look into it some more and ill let you guys know if i find a solution.
Edit 2
So after testing the app on the tablet and finding that it works fine there we decided to test the app on a 2nd development pc. Needless to say the same thing happened... in other words its a rendering issue that happens on windows 8.1 PC's but not on a tablet.
Facts as of now:
- Code worked yesterday, no longer works now
- Works on tablet but not on PC
- Nothing changed in the code since it worked
- Seems to happen in the rendering stages
- Bug happens when loading more than 23 items in a listview, app restores itself then
- Any more than 23 items and it stays bugged (dark blue screen but still responds to clicks)
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).