I'm using a DocumentViewer to view a FixedDocument and on 2 machines (out of over 500) the document viewer does not show the document.
Edit: ok, it's not a bug in WPF and the DocumentViewer control works perfectly, I'm leaving this question unchanged in case someone else hits the same problem, see my answer for the solution.
The document viewer is using a custom ControlTemplate based on this MSDN sample (mostly to remove the search box)
The toolbar, scrollbar and background all show up but the scrollbar is disabled and the content are is blank (background color)
I'm sure the document is ok because printing the document works.
I don't have any access to those machines, one of them is running Vista in what looks like a standard configuration, I don't even know what version of Window the other one is running.
The application is targeting .net 3.5
Did anyone here ever had a similar problem? do you have any idea what's causing it?
Thanks.
Here's what happened, I was using PrintDialog to get the default printer's paper size in order to create the FixedDocument, according to the docs and all my tests you can use PrintDialog without actually opening the dialog or actually printing anything and everything works just fine.
But on some computers (probably due to misbehaving printer drivers) this doesn't work, so on those computers the returned paper size was incorrect, I actually don't know it the size was too small or two big but it caused the code generating the FixedDocument to fail some internal sanity check and produce and empty document - that the DocumentViewer control then displayed correctly by showing nothing.
Related
We have a Windows Forms application used for testing our products that has had pretty much the same forms and dialogs for nearly 10 years now. AutoScaleMode in the designer is set to Font for both forms, and that hasn't changed since the original design. AutoSize is set to false and just for good measure (I guess) AutoSizeMode is set to GrowOnly. The following source lines are in Program.cs:
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Remember, this has been working flawlessly for years...
One of the recent updates to VS2017 included AutoScale support for monitors with different DPI. I have a relatively high DPI monitor, so when I made some changes to a Settings dialog (adding controls, etc) I started getting bright yellow banners cross the top of the designer surface telling me that AutoScaling was set to 125%, and would I like to change that? I tried going back and forth, and when in 100% mode (Autoscaling off) I was warned that XAML forms might not display correctly. Fine, I am working with Forms so I went back to "normal" scaling and the form looked fine.
Until I tried running the program. Now when I start the program the main form looks like this (details deleted to protect the guilty):
...but when I open the settings dialog it looks like this:
Yikes! It looks worse in practice, the relative images here don't do justice to the difference in size and scale.
I have no idea what got changed or how / why this is happening, but there's no way I can put this into production. I've tried changing the AutoScale settings, to no avail. Can somebody point me in the right direction here?
Thanks in advance!
EDIT: It seems the rescaling only happens on my machine when I run the app in Debug. Whatever is messing up the display of the forms on my machine doesn't do that on my associates' machines and isn't replicated to the executable produced by the build server.
On another note, I tried every DPI-related setting I could find, added those that weren't there due to the program's age, all to no avail. Nothing I have tried has had any effect on the program's display weirdness on my machine. Ugh.
I tried all the tricks I could find, short of disabling AutoScale completely, and nothing worked. I finally merged our develop branch in to my feature branch and inspected all 270 edits, choosing the oldest settings I could find for all size parameters, all controls. Ugh.
Along the way I stumbled across the following line in the Designer.cs file for the form:
this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F);
This setting is NOT accessible from Visual Studio's designer, as far as I can tell, nor can I find anything about how or why it gets set. What I did find was that in the earlier version that did work as expected, the values were (8F, 17F) -- so I manually edited the line to match the older, working version. Success!
I also checked my Windows display settings, and the Custom Scaling value was at 100%, so I used the registry hack mentioned in one of the articles I found following the first link from the comment above (thanks, #Jimi) to disable auto-scaling in Visual Studio, then turned off the notification. Now I'm (finally) back in business.
Registry hack is here:
https://learn.microsoft.com/en-us/dotnet/framework/winforms/disable-dpi-awareness-visual-studio
If one uses the registry hack mentioned in the answer from DaveN59, and there is already entry for your ...\devenv.exe (mine was previously set to run as admin) then add the DPIUNAWARE string to the end of the "Data". Make sure to use a space as a separator.
Example: ^ RUNASADMIN DPIUNAWARE
I'm not sure what the ^ is for, but it was there and I just added DPIUNAWARE string. Also, if you just add this string, it will come up unscaled, but you will still see the yellow banner. To turn that off you'll need to select that option from with in Visual Studio. The instructions are in the link for the registry hack, also provided above. For conveinece here's the menu navigation path.
To disable notifications, choose Tools > Options to open the Options
dialog. Then, choose Windows Forms Designer > General, and set DPI
Scaling Notifications to False.
I've implemented a printing feature to print some of the Financial charts in my WPF application by using PrintVisual method. Since the user is free to change his/her window size and/or screen resolution I've use a LayoutTransform, Measure and Arrange methods to make sure that the printed charts gets spread across the entire page evenly irrespective of the size of the application window. All works absolutely well when the user prints on an actual printer or selects PDF Print Driver to print. Layout transform takes effect behind the scene and that shows up in the print, but the user doesn't experience any flicker or change in display on his screen.
The problem comes when the user selects XPS Document Writer. When user does that, the layout on the screen also changes. When the "Save As" dialog box comes up the screen layout changes based on the LayoutTransform provided, which makes the charts go smaller or bigger. The moment user saves the XPS file OR hit cancel on the Save as dialog box the layout goes back to normal. But the strange part is, this happens only when we select XPS Document Writer.
But, user doesn't want to see this.. What can I do to prevent this to happen in the case of XPS Document Writer?
Please suggest. Thanks
perhaps you can make a clone of your canvas or visual prior to applying your transform. clone is not built-in to wpf UIElements but you can use XamlWriter.Save() and XamlReader.Load to clone via XmlReader. google "wpf clone UIElement" or I can post some code if you feel that's the way to go.
A few of my users are experiencing a strange bug. I have a simple WPF window that contains a few textblocks and buttons. After a short time using my application successfully the users that experience the problem report that the window's content becomes empty and only the border of the window is visible.
After remoting onto their machines I have confirmed that it looks like the content of the window is frozen. When the window first opens it appears like its see through and displays whatever is behind it. If I move the window around the same frozen image of what was behind the window when it opened stays there. If I bring something in front of the Windows (such as a browser) the "frozen image" in the contents will change to a frozen image of whatever was in front of it. I have discovered that the buttons are still active and clickable in the window, so it's not completely frozen it just seems not to be drawing the content properly.
The issue only seems to affect a small percentage of my users and I cannot recreate this issue on any of my test machines. Any ideas about what is happening would be greatly appreciated.
If you have a user that's willing to experiment to find a solution, have them Disable Hardware Acceleration in WPF. If this fixes the issue, then it's most likely a graphics driver problem.
I have a very strange issue in my WPF project. The main window contains several wpf controls and winforms RichTextbox(don't ask me why) within WindowsFormsHost element.
Richtextbox contains text. In some cases Richtextbox is not properly rendered when loading window (the right part is white like somebody uses erase tool and clears a rectangle).
This situation is not so common (~20 users / 30 000) and it probably depends on hw. It occurs on XP machines. I have tried to force sw rendering, but it didn't help.
Application is built in .net 3.5 SP1.
Any idea?
The problem was caused by user's unusuall dpi settings in Window. Strange, but with normal values, it works
When I try to use Morae Manager 3.0 to run a Screen Text search on a recording of our prototype (coded in WPF, .NET version 3.5 SP1), the only things that come up are the window titles. We are using Windows XP.
Even when I search for something that is editable, like text typed into a text box, it does not come up.
Screen text for things outside the prototype (e.g. desktop icons) still comes up perfectly.
I contacted TechSmith support on two separate occassions and both times the reply I got was it must be an issue with our technology, since the screen text search does work for other things, and that the support people are not developers and thus do not know what might be causing this.
Does anyone know:
what precisely might be causing this -- e.g. does WPF's rendering engine bypass some sort of Windows layer where Morae looks for text (please forgive me for any errors in terminology)
if there is anything I can tweak in the prototype to fix it
how I can get through to someone at TechSmith who knows the answers to 1. and 2.
P.S. Morae is a wonderful product and we've usually had great support from TechSmith. We are only having problems with this one little thing, and one can hardly blame Morae for not being compatible with something as new as WPF.
I have no idea what Morae is or how it works, but one big difference between WPF and for example WinForms is the following, copied from here:
When you create a WPF Window, WPF
creates a top-level HWND, and uses an
HwndSource to put the Window and its
WPF content inside the HWND. The rest
of your WPF content in the application
shares that singular HWND.
If Morae depends on HWNDs to find texts on the screen, this could explain why it can not find the text box. In contrast, i believe in WinForms every control (button, textbox) has its own HWND.