I have a winform within a remote desktop application that is built dynamically with a container panel for a toolbar with large (regular) buttons. The application is writen in C# and .NET 4.0. The application is viewed as it should only if I do not maximize the window (meaning restored view is fine).
Now, after RDP login - within most client computers - the application looks fine (even when we maximize and restoring). Within low resolution client computers (800x600), the buttons on the toolbar are not displayed in the right position (such as in the 1024x768 clients).
I used double buffering and it didn't help... the problem may or may not be depended on the screen resolution (it can be memory issue or something). It is not a problem of localization layout.
The following image shows the Fine and Bad states: http://imgur.com/gO4UJ,v7O9K
What can I do to resolve this issue?
OK, so in case anybody gets to this kind of case, this is the thing that made the issue:
In the form, there was an empty repaint override. The programmer that created the form was overriding the repaint with an empty method (don't know why, I guess I'll ask my team for the business logic).
How did I reproduce it in the development environment? Following Albin Sunnanbo's note, I ran the RDP application in minimized version during initialization, and I noticed that it occurs with large resolution clients also in this use case... So, I know repaint occurs while performing a window resize - and this made me suspicious about the method...
==> On a side note, I guess this is why inheritance is so bad, and going on to WPF is better. It took me 3 days to understand why this issue occurred.
Related
I am working on a program that starts several other c# WPF applications and checks wether there are errors (using .NET Automation Services / UITesting).
One of the requirements of it is to take a screenshot of the main window and to put it into a word document. I alread got it working quite fine when it´s one application at a time (using code from this site: http://www.developerfusion.com/code/4630/capture-a-screen-shot/) , but as soon as i am using parallelism (say, checking 5 applications in a parallel manner), i am running into the problem that the screenshots of the windows may be overlapped by other windows that just popped up or that are always brought to the front (e.g. splash screens). Bringing the window to the front does not really help.
There was an older similar thread not directly regarding to WPF applications, and sadly, without a clear solution: Taking screenshot of a partially hidden window in a programmatic way
Is there a way to get a "clean" screenshot, may be with the use of the windows AutomationElement instance?
How can I create a window which is fully apparent to the user but is not visible in screenshots. I know that this is possible since Neo SafeKeys (an onscreen keyboard to defeat keyloggers) does not appear in the screenshots taken by keylogging software I installed.
To give you an idea, the window is fully visible to the user, however when a screenshot is taken, the Neo SafeKeys window does not appear at all (as if it does not even exist).
Neo SafeKeys states that it uses an invisible protection layer above the window to protect against screenshots. I have searched all over the internet to see how can I reproduce this, to no avail. Does anybody know how this can be performed (windows which is visible to user but invisible in screenshots)?
What you can do is you can prevent the PrtScn key from doing anything when pressed. Take a look at this article while shows you how to do this.
What this article is doing is clearing out the clipboard. What you can do instead is capture the screen image and digitally remove your application, then put the revised image on the clipboard, thus giving the "Effect" of making your window transparent.
Also, you might want to look at this SO question which gives an alternative way to make your window just appear "blue", though its not easy to do.
Does anybody know how this can be performed (windows which is visible to user but invisible in screenshots)?
Use DirectX to render directly to the device.
In your C# application you can set up a global hook to monitor keyboard events. Then your application becomes the global handler for print screens. Now if another application managed screen prints natively, can't stop that, but anything running through windows, you can get at.
The WM_KEYBOARD_LL hook is one of the few global hooks that can be used in managed code because it doesn't require a DLL to be injected into every target.
For some code you can visit here:
Adam's Blog
Keep in mind that these are global hooks so you want to make sure nothing else (other applications) are effected. I've used these in the past as we hosted showing a power point in an application we worked on. Basically we didn't want the user to invoke any powerpoint menus or keyboard short cuts so we used a global hook. We always checked to see whether the users was in a certain area (screen) and in our application, otherwise we would effect other applications functionality (including our own!)
Microsoft Information:
Hooks Overview
There's this.....
visual cryptography
live example here
But this could be easily coded against by taking multiple screenshots and laying them overeachother and such...
If you are using Windows, and you can avoid that screenlogging happens, you can implement a nice solution like a virtual desktop to embed your process into it. When a process is running inside a virtual desktop it is possible to bypass an screenlogger tool that runs over win32 Api.
Check out this article so you can sneak a peek how to implement a nice solution to scape from screen and keyboard monitoring.
http://www.codeproject.com/Articles/7392/Lock-Windows-Desktop?fid=62485&select=3139662&fr=101#xx0xx
Okay. Just when you think you've figured it all out, you haven't.
I have coded and tested a functional appbar class. When I use a simple Windows Form to extend and test the class, it works without issue in both XP (SP 3, 32 bit) and Windows 7 (64 bit). Other windows are accessible, and they all maximize appropriately. However, when I take my "complex" Windows Form (i.e. it is an application) and derive it from the appbar class, the desktop seems to "kick" it out. By this I mean that everything sizes appropriately initially, but then the desktop resizes itself back to its former size. Sometimes this happens rather quickly after putting the form into appbar mode, other times it happens when I click outside the form (to open a browser, for instance), and other times it happens when the form calls a MessageBox. I have put all of the Forms functions in a background worker thinking that may be the issue, but the result is the same. I've posted three images below. The first one shows the application as its initial WinForm. The second shows the appbar "functioning." The last shows the appbar not "functioning." If you're having issues seeing the problem, pay attention to the Recycle Bin. Any ideas?
Edit:
I found these calls via logging. They appear to fire off each time the desktop resizes to "normal." Now I'm trying to see if there is or is not a similar pattern in the "simple" version.
msg=0x6 (WM_ACTIVATE) hwnd=0x1e03ea wparam=0x0 lparam=0x0 result=0x0
msg=0x1c (WM_ACTIVATEAPP) hwnd=0x1e03ea wparam=0x0 lparam=0x1a90 result=0x0
msg=0x1a (WM_WININICHANGE) hwnd=0x1e03ea wparam=0x2f lparam=0x9fe048 result=0x0
msg=0x1a (WM_WININICHANGE) hwnd=0x1e03ea wparam=0x18 lparam=0x9fe038 result=0x0
So this was one wild goose chase. In the event my last comment sounded absurd, it was. While I am still not 100% certain as to this theory (someone please prove/disprove at your leisure), the two different handles came from (1) instantiation of the Form and (2) the actual handle when the Form is loaded. I presume the API follows the same concept of QUERY_POS and SET_POS, that being it initially checks for and assigns a valid handle. Then, prior to the Form being shown, it double checks the handle value.
Long story short, one line of code to verify the handle value in the Load event solved the entire problem.
EDIT:
Better yet, the HandleCreated event is irreplaceable.
The main form of my application constantly turns white in the designer when I perform the following steps:
1) Open form in design mode (All controls are visible at this point)
2) View source code for form
3) Switch back to design view
After performing the steps above, there is nothing visible in design mode for the form (not even the form). I only have this issue with one form in my application and, unfortunately it is my main form where there is a lot of logic. The workaround is to always close the form and reopen it in design mode show that all the components are visible again. I have experienced erratic errors with the designer when I am low on available memory but, this form always produces this symptom and is the only one. Any ideas as to what is causing this? I guess I could always create a new form and try moving all the controls and logic over but, I'd prefer to avoid the work if there is a simpler option.
The diagnostic is that the Paint event or OnPaint method of a control is misbehaving. These methods run at design time so you'll get an accurate visual representation of the control, the way for example that you can see the Image property of a PictureBox at design time. When such a paint event gets stuck in a loop then the entire form stops rendering properly. Beyond a simple bug, the typical reason is that the code is getting confuzzled by the non-standard runtime environment in design mode. You use the DesignMode property to ensure that such code won't cause trouble and is disabled in design mode.
Finding the misbehaving code is the challenge, especially when these are not controls you wrote yourself. Short from removing controls one by one to find the troublemaker, you can use the debugger by starting another instance of Visual Studio and use Tools + Attach to Process to attach to the first one.
From personal experience, I can confirm that this is an occasional issue in both Visual Studio 2003 & 2005 whether VB or C# is used. We patched both versions to the latest service pack and even got hotfixes directly from Microsoft, neither of which resolved the issue.
In the case of VB in Visual Studio 2003, the disappearance of the controls also removed the underlying designer code so we kept having to restore the deleted code from our version control system. Very annoying - as we'd often lose code changes and have to start over.
You defiantly should check the next link:
https://weblog.west-wind.com/posts/2019/Feb/14/WPF-Hanging-in-Infinite-Rendering-Loop?fbclid=IwAR23ZnUrz7buVpFLXOX2qQin1WcifQ6h280EO25URO74NTGDkTedx1TDRb4
here's a quote from the page:
Using the StarDefinitionsCanExceedAvailableSpace Override This setting
overrides the new GridRendering behavior and basically lets you run
with a .NET 4.7.x target in your project, but keeps the old behavior
that was used in previous versions.
There is a configuration setting that can be set in app.config for
your application:
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true"
/>
</runtime>
</configuration>
I can verify that using that switch lets me run 4.7.1 and not see the lock up in any scaling mode. After I
had my running version in 4.6.2 back, I once again moved up to 4.7.1
in a separate branch to try this out and sure enough the switch made
the application run targeted with 4.7.1. So there's a hacky
workaround.
It's a workaround though. This 'fix' according to Microsoft improves
grid rendering allocations, providing more precise sizing and also
improves performance and reduces memory usage. On paper this is a
great improvement, but... well, side effects 😃
I suspect this issue is not wildly common as there was not very much
info to be found about it. I think Markdown Monster makes this issue
come up because the startup sequence has a lot of window manipulation.
MM uses the MahApps UI framework which uses Window Animation and extra
rendering frames for the main window, and MM itself moves the window
offscreen for initial render and adjusts window sizing based on screen
sizes and DPI settings if the window doesn't fit on the screen or
would otherwise be offscreen. IOW, there's a bit of gyration to get
the initial window onto the screen that is more likely to hit this bug
than a simple WPF form.
So I doubt that every application needs to worry about this, but if
you have a 4.7.x WPF app it might be a good idea to try it out at
various resolutions and scale levels just to see how it fares.
I'm working on a .NET 4 WPF application, and just the other day, came across a very peculiar bug. I have three Windows 7 Pro machines involved: laptop (1366x768), desktop (1680x1050, multi-monitor), and the remote machine (resolution unknown). Our application is installed on the remote machine.
Consider the following events: I remote desktop into the remote machine from my laptop, start our application, and launch a particular feature (an mdi child) within the application. If I connect to the same remote session from my desktop (thus closing the session on my laptop), this feature within my application becomes completely unusable. By unusable, I mean combo box drop downs are showing in the top/left corner (much like what's described here), other controls aren't laid out correctly, and some controls don't even show at all. Mouse coordinates appear to be off in that clicking certain controls no longer invokes the appropriate actions. It's the strangest thing I've ever seen.
If I close the application and launch a new instance on my desktop, things work great. Also, it only seems to happen when I launch the feature on my laptop, then move to the desktop. Never the other way around.
I wish I could show some code, but I don't really even know where to start or what to show. I can say that it only happens on certain features. Some features handle the resolution change perfectly.
Has anyone else seen these types of symptoms? Or know what could cause them or how they could be fixed?
This is a little embarrassing. After a few hours of "process of elimination", I found that another developer had added some unmanaged code to automatically maximize the window. The approach they followed is documented here. This approach does not work through remote desktop sessions. Lol.