You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using the XpsDocumentWriter class - specifically using the WriteAsync(FixedDocument) method.
Here is the code I am using to call this WriteAsync method:
_PrintDocumentImageableArea area = null;
var xpsDocumentWriter = PrintQueue.CreateXpsDocumentWriter(ref area);
var fixedDocument = GenerateDocument();
xpsDocumentWriter.WritingCompleted += DocumentWriterOnWritingCompleted;
try
{
xpsDocumentWriter.WriteAsync(fixedDocument);
}
catch
{
Console.WriteLine("Error occurred");
}
The issue that I have is that when I print a document to say test.pdf, if I open that file in a PDF viewer, and then try to print to that filename again, it throws an exception (due to the file being open) - this exception is caught in the try-catch statement above.
This is fine on my PC, and on a few other peoples PCs, but there's 2 PCs I've located that when subject to the same circumstances, they don't throw an exception. I've also checked the WritingCompleted event for errors, using the following code:
private void DocumentWriterOnWritingCompleted(object sender, WritingCompletedEventArgs e)
{
if (e.Error != null)
{
Console.WriteLine("Error has occurred");
}
}
This code does not catch anything on those machines in question.
Additional information - I've checked, and the document is NOT overwritten on the PCs where no error is detected, it simply fails to write the document silently. The WritingCompleted event is fired on all machines, but no errors on any.
The weirdest part is that this is the code I temporarily set up to create the FixedDocument:
public FixedDocument DocumentGenerator()
{
FixedDocument fixedDocument = new FixedDocument();
for (int numberOfPages = 0; numberOfPages < 50; numberOfPages++)
{
PageContent pageContent = new PageContent();
FixedPage fixedPage = new FixedPage()
{
Width = new Size(96 * 8.5, 96 * 11).Width,
Height = new Size(96 * 8.5, 96 * 11).Height
};
//Add a canvas with a TextBlock and a Rectangle as children.
Canvas canvas = new Canvas();
fixedPage.Children.Add(canvas);
TextBlock textBlock = new TextBlock();
textBlock.Text =
string.Format("Page {0} / {1}\n\nThis Is Page {0}.",
i + 1, 1000);
textBlock.FontSize = 24;
canvas.Children.Add(textBlock);
Rectangle rect = new Rectangle();
rect.Width = 200;
rect.Height = 200;
rect.Fill =
new SolidColorBrush(Color.FromArgb(200, 20, 50, 200));
canvas.Children.Add(rect);
((IAddChild)pageContent).AddChild(fixedPage);
fixedDocument.Pages.Add(pageContent);
}
return fixedDocument;
}
When numberOfPages is ~> 30, no error is shown on the problem PC, but when the numberOfPages is ~< 20, an error IS shown on the problem PC. These boundaries change depending on what is being rendered on the page (so it appears to be dependent on size/complexity of document somehow).
So I was wondering if anyone's ever seen anything like this before? Why on earth would the content that is in the FixedDocument have any effect on whether an error is thrown due to attempting to overwrite a file that is locked by another program?
I've tried updating to .NET Framework 4.8 - this does not fix the issue.
Additional info:
On my computer and the other PCs where an error successfully shows up when trying to overwrite a file, the error is the following: -An object that does not derive from System.Exception has been wrapped in a RuntimeWrappedException.
The stacktrace is the following:
at System.Printing.InternalPrintSystemException.ThrowIfNotCOMSuccess(Int32 hresultCode)
at MS.Internal.PrintWin32Thunk.XpsCompatiblePrinter.StartDocPrinterW(DocInfoThree docInfo, PrintTicket printTicket, Boolean mustSetPrintJobIdentifier)
at System.Printing.PrintQueue.CreateXpsOMSerializationManager(Boolean isBatchMode, Boolean isAsync, PrintTicket printTicket, Boolean mustSetPrintJobIdentifier)
at System.Printing.PrintQueue.CreateAsyncSerializationManager(Boolean isBatchMode, Boolean mustSetJobIdentifier, PrintTicket printTicket)
at System.Windows.Xps.XpsDocumentWriter.BeginWrite(Boolean batchMode, Boolean asyncMode, Boolean setPrintTicketHandler, PrintTicket printTicket, PrintTicketLevel printTicketLevel, Boolean printJobIdentifierSet)
at System.Windows.Xps.XpsDocumentWriter.WriteAsync(FixedDocument fixedDocument)
at WPFTest.MainWindow.PrintDocumentAsync() in C:\Projects\Misc\PrintingTest\WPFTest\WPFTest\MainWindow.xaml.cs:line 194
at WPFTest.AnotherClassProbablyReceiver..ctor(MainWindow wind) in C:\Projects\Misc\PrintingTest\WPFTest\WPFTest\AnotherClassProbablyReceiver.cs:line 24
at WPFTest.MainWindow.DoStuff() in C:\Projects\Misc\PrintingTest\WPFTest\WPFTest\MainWindow.xaml.cs:line 64
at WPFTest.MainWindow.ButtonBase_OnClick(Object sender, RoutedEventArgs e) in C:\Projects\Misc\PrintingTest\WPFTest\WPFTest\MainWindow.xaml.cs:line 244
at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
at System.Windows.UIElement.RaiseEvent(RoutedEventArgs e)
at System.Windows.Controls.Primitives.ButtonBase.OnClick()
at System.Windows.Controls.Button.OnClick()
at System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(MouseButtonEventArgs e)
at System.Windows.UIElement.OnMouseLeftButtonUpThunk(Object sender, MouseButtonEventArgs e)
at System.Windows.Input.MouseButtonEventArgs.InvokeEventHandler(Delegate genericHandler, Object genericTarget)
at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
at System.Windows.UIElement.ReRaiseEventAs(DependencyObject sender, RoutedEventArgs args, RoutedEvent newEvent)
at System.Windows.UIElement.OnMouseUpThunk(Object sender, MouseButtonEventArgs e)
at System.Windows.Input.MouseButtonEventArgs.InvokeEventHandler(Delegate genericHandler, Object genericTarget)
at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
at System.Windows.UIElement.RaiseTrustedEvent(RoutedEventArgs args)
at System.Windows.UIElement.RaiseEvent(RoutedEventArgs args, Boolean trusted)
at System.Windows.Input.InputManager.ProcessStagingArea()
at System.Windows.Input.InputManager.ProcessInput(InputEventArgs input)
at System.Windows.Input.InputProviderSite.ReportInput(InputReport inputReport)
at System.Windows.Interop.HwndMouseInputProvider.ReportInput(IntPtr hwnd, InputMode mode, Int32 timestamp, RawMouseActions actions, Int32 x, Int32 y, Int32 wheel)
at System.Windows.Interop.HwndMouseInputProvider.FilterMessage(IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
at System.Windows.Application.RunDispatcher(Object ignore)
at System.Windows.Application.RunInternal(Window window)
at System.Windows.Application.Run(Window window)
at System.Windows.Application.Run()
at WPFTest.App.Main()
This error is thrown on the WriteAsync call, where it should probably be part of the WritingCompletedEventArgs (but the completed event simply reports a successful print.
On the problem PC where the error doesn't show up, if we set the page count to >30 to trigger the error, the error on that PC is the following:
System.Printing.PrintingCanceledException: Printing was canceled. Win32 error: The operation completed successfully.
at MS.Internal.PrintWin32Thunk.XpsCompatiblePrinter.EndDocPrinter()
at System.Printing.PrintQueue.DisposeSerializationManager(Boolean abort)
at System.Windows.Xps.XpsDocumentWriter.ForwardWriteCompletedEvent(Object sender, XpsSerializationCompletedEventArgs args)
Which is successfully caught through the 'WritingCompletedEventArgs'.
Why is all of this behaviour so intermittent, and why are errors thrown on the WriteAsync call on some PCs, and on other PCs, the WritingCompletedEventArgs only produce an error when the page count is >30 using my specific rendering technique (this page number appears to vary wildy depending on whats rendered on the page - in some cases with different rendering I have not found a number which triggers this).
Original Comments
Aidan.Horton on 9/12/2019, 05:52 PM:
(private comment, text removed)
Feedback Bot on 9/12/2019, 06:25 PM:
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
Feedback Bot on 10/18/2019, 01:03 PM:
I have detected that for the last 35 days, this issue didn't have any product team activity and a very small amount of new votes or comments. Based on this, its severity, and affected area, it’s my experience that this issue is very unlikely to be fixed.
Original Solutions
Aydin Homay solved on 4/3/2020, 02:10 AM, 0 votes:
I have this issue too
Aidan.Horton on 4/3/2020, 05:07 PM:
Hi Aydin,
I'm afraid there's still no solution to this issue. All I can suggest is the following:
The 'Problem PCs' I mentioned above that don't throw an error were using an earlier version of Windows 10 (I believe 1703) - we updated these PCs to be inline with all other PCs (up to 1903 of Windows 10) and this put them into the following state:
- An error is always thrown, but the error is a 'RuntimeWrappedException'. This is not ideal as the error doesn't really describe the issue, and is not passed into the 'WritingCompletedEvent' as arguments, but it's better than no error whatsoever.
So basically my suggestion is that to make this issue slightly less worse, upgrade to 1903 of Windows 10!
Michael Sanders solved on 9/25/2020, 10:42 AM, 0 votes:
I also have a very similar issue.
Basically, cannot overwrite a previuosly save XPS file, as it says the file is open, as discussed above
Using WIndows-10 2004 with Visual Studio 16.7.4
The text was updated successfully, but these errors were encountered:
This issue has been moved from a ticket on Developer Community.
I'm using the
XpsDocumentWriter
class - specifically using theWriteAsync(FixedDocument)
method.Here is the code I am using to call this
WriteAsync
method:The issue that I have is that when I print a document to say
test.pdf
, if I open that file in a PDF viewer, and then try to print to that filename again, it throws an exception (due to the file being open) - this exception is caught in the try-catch statement above.This is fine on my PC, and on a few other peoples PCs, but there's 2 PCs I've located that when subject to the same circumstances, they don't throw an exception. I've also checked the WritingCompleted event for errors, using the following code:
This code does not catch anything on those machines in question.
Additional information - I've checked, and the document is NOT overwritten on the PCs where no error is detected, it simply fails to write the document silently. The WritingCompleted event is fired on all machines, but no errors on any.
The weirdest part is that this is the code I temporarily set up to create the
FixedDocument
:When
numberOfPages
is ~> 30, no error is shown on the problem PC, but when thenumberOfPages
is ~< 20, an error IS shown on the problem PC. These boundaries change depending on what is being rendered on the page (so it appears to be dependent on size/complexity of document somehow).So I was wondering if anyone's ever seen anything like this before? Why on earth would the content that is in the
FixedDocument
have any effect on whether an error is thrown due to attempting to overwrite a file that is locked by another program?I've tried updating to .NET Framework 4.8 - this does not fix the issue.
Additional info:
On my computer and the other PCs where an error successfully shows up when trying to overwrite a file, the error is the following:
-An object that does not derive from System.Exception has been wrapped in a RuntimeWrappedException.
The stacktrace is the following:
This error is thrown on the
WriteAsync
call, where it should probably be part of theWritingCompletedEventArgs
(but the completed event simply reports a successful print.On the problem PC where the error doesn't show up, if we set the page count to >30 to trigger the error, the error on that PC is the following:
Which is successfully caught through the 'WritingCompletedEventArgs'.
Why is all of this behaviour so intermittent, and why are errors thrown on the
WriteAsync
call on some PCs, and on other PCs, theWritingCompletedEventArgs
only produce an error when the page count is >30 using my specific rendering technique (this page number appears to vary wildy depending on whats rendered on the page - in some cases with different rendering I have not found a number which triggers this).Original Comments
Aidan.Horton on 9/12/2019, 05:52 PM:
(private comment, text removed)
Feedback Bot on 9/12/2019, 06:25 PM:
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
Feedback Bot on 10/18/2019, 01:03 PM:
I have detected that for the last 35 days, this issue didn't have any product team activity and a very small amount of new votes or comments. Based on this, its severity, and affected area, it’s my experience that this issue is very unlikely to be fixed.
Original Solutions
Aydin Homay solved on 4/3/2020, 02:10 AM, 0 votes:
I have this issue too
Aidan.Horton on 4/3/2020, 05:07 PM:
Hi Aydin,
I'm afraid there's still no solution to this issue. All I can suggest is the following:
The 'Problem PCs' I mentioned above that don't throw an error were using an earlier version of Windows 10 (I believe 1703) - we updated these PCs to be inline with all other PCs (up to 1903 of Windows 10) and this put them into the following state:
- An error is always thrown, but the error is a 'RuntimeWrappedException'. This is not ideal as the error doesn't really describe the issue, and is not passed into the 'WritingCompletedEvent' as arguments, but it's better than no error whatsoever.
So basically my suggestion is that to make this issue slightly less worse, upgrade to 1903 of Windows 10!
Michael Sanders solved on 9/25/2020, 10:42 AM, 0 votes:
I also have a very similar issue.
Basically, cannot overwrite a previuosly save XPS file, as it says the file is open, as discussed above
Using WIndows-10 2004 with Visual Studio 16.7.4
The text was updated successfully, but these errors were encountered: