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.
Related
i recently started to play Second Life and I would like to know if there is a way to write a program outside of SL viewer that allow to click on sl menu's button automatically.
Not unless You really feel like writing Your own 3rd party viewer. The only time I've seen this done is through SmartBots, but even that is using a custom coded viewer to host the bot.
You can always use external programs such as AutoHotkey to do clicks at certain locations on-screen.
Do note that all UI elements in SL viewer are drawn not using the OS's GUI component system, but actually drawn by SL viewer itself using OpenGL calls, so you'll have to do coordinate calculations yourself, and click at certain relative coordinate to the viewer's window.
We've been working on an application for the last few months that's aimed at Windows 7 tablet PCs. So we've used the Surface 2 SDK for most controls and it's all touch-happy.
I have noticed recently, though, that one of our custom controls isn't working as it should. This control provides popout menus, and these are achieved through the Popup control. On a developer's laptop, this works fine and the menus vanish when you click away from them. I've noticed, though, that on our test tablet they have a tendency to stay open.
I found that there was a SurfacePopup in the first Surface SDK, but I can't find one in the Surface 2 SDK. Did they get rid of it? Is there a 'best practice' approach?
If there's no simple solution, I may have to go old-school and add a window-sized hidden SurfaceButton below the menu when it appears, that hides itself and the menu when clicked or touched.
Beyond that I've noticed that sometimes the SurfaceScrollViewer within the popups won't work. I'm guessing this is because it's not picking up touch events properly. I tried adding this extension method to the window..
this.EnableSurfaceInput();
..but I get a NullReferenceException on System.Windows.Input.Mouse.get_LeftButton() which bizarrely suggests that it can only enable surface inputs for controls when there's a mouse plugged in.
Any ideas? They'll all be welcomed with open arms!
There's no SurfacePopup in the Surface SDK 2.0, however you can use a normal WPF popup. Then you need to make sure that it receives Touch Events by using the extension method you suggested above on the popup, not the window:
((HwndSource)HwndSource.FromVisual(popup)).EnableSurfaceInput();
Edit: As I just found out, this only works when the popup is initially open. To get it to work when the popup is opened later on, you don't need to use the popup, but the parent of it's child (see this question).
For the benefit of Daniel, and anyone else who needs a solution to this, I'll try to cast my mind back two years and explain how we got this working.
As far as I can remember, the answer was to use an adorner layer instead of a popup. Basically, every WPF control has an adorner layer, which sits above the control's UI stack. By default it contains nothing, but you can add whatever you like to it.
I got this all working by writing a custom control that allows you to place that control, with content, in the XAML and then show and hide it whenever you need to. When it's shown, it moves its contents into the adorner layer of the containing window, and when it's hidden it moves the contents back into the control itself, which is hidden from the user.
Afraid I can't go into any more detail than that, but as far as I can remember this was the ultimate solution; replacing popups (which never quite worked very well) with a custom control that uses the adorner layer.
Hope that helps!
I have a C#.NET winforms project, and some controls are moving in design view whenever I build the project. Its only some of the controls (a panel with a label and datagridview in it, a button, a link button and a label) are all moving up on each build.
Has anyone seen this before or know how to fix it?
I think it is because of the AutoScaleDimensions. My guess is that your form was originally created on another machine.
Per MSDN.
"The AutoScaleDimensions property represents the DPI or font setting
of the screen that the control was scaled to or designed for.
Specifically, at design time this property will be set by the Windows
Forms designer to the value your monitor is currently using. Then,
when the form loads at run time, if the CurrentAutoScaleDimensions
property is different from the AutoScaleDimensions, the
PerformAutoScale method will be called to perform scaling of the
control and all of its children. Afterwards, AutoScaleDimensions will
be updated to reflect the new scaling size."
My guess is that for odd some reason when you build you project property (maybe some others) gets adjusted, but not on design time.
I think about few possible reasons:
You work on multiple monitors and/or there is some odd stuff with your adapter.
There is some problem with auto-generated designer file. Maybe it
edited manually somehow.
To fix I propose to do something I would do:
Recreate form from scratch if possible, by copy-pasting bits
one-by-one.
If not take some merging tool and insert fresh form
properties.
Also here is another interesting question on AutoScaleDimentions.
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'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.