Issue printing complex visuals - c#

I've had a report from the client who had issues printing (my) charts in WPF with a large number of data points. On the screen everything is visible. Here's a screenshot
But when he prints it the part of the graph disappears in a pretty strange way. Here's a screenshot from printed PDF (same thing happens with actual printer)
The printing is done using simple PrintVisual code
PrintDialog dialog = new PrintDialog();
if (dialog.ShowDialog() == true)
{
dialog.PrintVisual(chart, "Chart");
}
I've tried to debug this but it seems that none of my rendering code gets called on printing (or at least no breakpoints get hit in Visual Studio) so I'm out of ideas of where to look.
If number of data points is relatively small everything prints out as expected.
Any ideas?
Thanks!

If found out that this issue is cause by the use of OpacityMask in the rendering process (which is not needed most of the time). If I don't use OpacityMask everything works just fine.

Related

Visual Studio C# Error creating handle but built app runs fine

I have a winforms app (>75k lines of source code), I have just added some new functionality and a new form and I'm getting the 'can't create window handle' error but only when running inside VS. The app builds OK and when i run it as the executable it is using 597 handles, 94 GDI and 83 USER and the new form works just fine apart from my logic errors in it. So as far as I can tell; my app is well below the 10,000 limit where things start to break therefore the problem is in/with VS somewhere but I may have hold of entirely the wrong end of the stick or possibly completely the wrong stick.
I have cleaned, rebuilt, rebooted etc and it stills falls over.
I'm using Process Explorer (thats where the previous numbers came from) but can't seem to find VS in there to check what its total handle count is.
VS2017 on Win 11.
Yes, I have googled it and explored things to look at but I can't find a result that matches 'Studio falling over but the exe running fine', any help / pointers very much appreciated as I obviously can't debug the new form which does make things somewhat difficult.
The underlying issue was to do with a pop-up form being generated by the parent form during its load processes, I found that the parent hadn't been issued a handle before it was trying to show the pop-up. Before you ask... I'm capturing data from a network sensor via the pop-up, which, once the user has accepted the incoming value, feeds the data back to the parent form. I assume that in run-time everything runs faster and it doesn't hit that 'un-coupled' point. Changed the code in the instantiate/load/shown cycle it runs and all is well.
Thanks once again Hans, headache solved.

Program only works correctly in debug mode

Here is my previous question, if you want some further information regarding my current problem:
WinForm: Inherited Panel wont Autosize
If you don't want to read through it, I'll give you some general information:
I'm not working directly via the programme, I'm just editing a specific DLL, that is used by this programme
That means, that I don't have any access to the source code of this specific programme
That also means that I have to fix this problem via some changes in the DLL, that is - as I mentioned before - used by this programme.
What I found out so far:
It works without any problems, if I attach the programme to the DLL's source code in VS2015.
But it has some glitches if I build the code and then copy the DLL into the programme's folder - that's also my actual problem: it somehow shrinks the tableLayoutpanel to half its actual size and I get some weird glitches in the other half of its actual, in normal start somehow not used, size.
What I tried out:
I changed the size manually, not via "Dock = Fill" or "Autosize = true" and it worked. But that's, as you all may know, not the best solution and we only want to use it, if there is absolutely no other way around it. No one likes to hard-code.
I tried to inherit its Parent's Size via:
this.tablelayoutPanel.Size = this.Size;
and
this.tableLayoutPanel.Size = new Size(this.Height, this.Size);
So do you guys have any ideas?
Okay, I did not figured out why the debuger worked and the release/debug build not. But I just forced a redraw on the tableLayoutPanelMainwith with Application.DoEvents(). I never tried this out before, because Invalidate() + Update() or Refresh() did not work - I was like: okay, that wont be that easy, so just forget about that.
But after some trial & error and a lot of time...well, I was working for two weeks on it...I tried the simpliest thing out and YEAHY, it worked!
Anyways, thank you for your help, guys. I appreciate that.

Window emitting a sound when I try to restore it from the taskbar

I'm working on a rather big project with my team and after a while, we struck into a big problem.
Infact when we minimize the main window of the application, clicking on the taskbar to restore it results in a "bing" sound (the one that windows uses when you are trying to interact with a background window when a modal dialog is opened on it). I can't restore the window except if I press ENTER button (after obviusly clicking on it).
We are using XNA to render something inside a WindowsFormsHost component in our WPF application and the problem comes out when we change something that is not connected directly with wpf (something inside the rendering engine, so it works only with XNA).
I can't post any code because I don't own any rights of it and would be meaningless because the project is enough big.
So my question is: what are the things that can produce a problem like this one (unable to restore window sound) when you click on the taskbar?
At least I can understand where to search for this bug, because I don't even understand where I shall dirt my hands in.
Important notes: I'm using a splash screen and the problems come up when I do something on a second window (so not directly the main one) which is not modal
Thanks for any suggestion
We solved the problem by finding out that there is a bug with an external component that we used inside our application. Still I don't understand how this bug has been created, if someone has a better answer I'll mark it.

Printing Multiple Windows Using PrintVisual()

I'm currently using PrintVisual() in a wpf application to do printing. This is working perfectly at the moment, the only issue I now have is when processing large amounts of data I need to paginate, whereby I want to render the window multiple times to a buffer and then execute a print job. Currently PrintVisual() creates multiple print jobs, which works, but is not very eloquent.
I have attempted to use reflector to get the source for PrintVisual() in hopes of implementing that into an IDocumentPaginatorSource, unfortunately reflector is failing.
Perhaps I should try rending the window to a FlowDocument? Although I'm not too keen on having to code the printing layout.
Any suggestions?
Thanks In Advance!
I came right by calling RenderTargetBitmap() on each page's canvas.

How can I disable the input panel for a form?

I've created a Windows CE 5.0 application which runs on a handheld scanner. The scanner has its own (hardware) keypad and almost all input comes from the scanning unit.
Unfortunately whenever the text box receiving the scanned characters is focused the input panel appears at the bottom of the screen, blocking almost a third of the screen space.
Is it possible to deactivate it in my form or in the whole application?
If you're not doing it manually via the InputPanel control, then I assume you have aygshell in the image and they are being rendered with a WC_SIPPREF control. I'm not certain if you can remove that control manually - I've never tried. There may be an agshell function that will allow you to disable/remove it, or maybe some work with the InputPanel for your app can remove it.
You may also want to see this blog entry for a bit more detail.
That last time I worked with CE was back when it was called pocketpc 2002 (I still have my old iPaq 3870 - one of the first devices with bluetooth and one of the last without wifi), but at that time the simplest way around this was to set the device to use a hand-writing recognition mode that didn't pop up anything. That may or may not be an option for you and things may have improved since then.

Categories