Form closing slow because of PDF viewer - winforms

We have a Winforms application that uses PDFViewer and AxAcroPDFlib. We previously had a problem where the form would hang when closing because the pdf control was having trouble closing. The solution, found here, was to assign focus to a different control during the forms closing event. This has worked with no problems since implementing.
This past week there was an update to Adobe Reader DC and the problem seems to have returned. There is a delay in closing the form again. When closing the form an Adobe Acrobat icon appears on the task bar for about 10 seconds, then disappears and the form closes. This is what happened before.
Does anyone have any idea how to correct this problem now?
I'd like to replace this control with another that doesn't rely on the user having Acrobat installed but until I have the time to do that I need a fix/workaround.

After trying many of the solutions I have found during the last 8 hours of trying to solve this problem I have finally found this as a solution.
During the FormClosing event add the following
Use the loadFile routine to load a PDF that doesn't exist
Change the focus to some other object
Let other events fire
Sleep for 50
See my C# code below. If I remove any one of these lines the hang on form close reappears.
if (this.axPDF != null)
{
axPDF.LoadFile("someFileThatDoesntExist.PDF");
cmdNext.Focus();
System.Windows.Forms.Application.DoEvents();
System.Threading.Thread.Sleep(50);
axPDF.Dispose();
}

I got the same problem.
Removing AxAcroPDF control from form's control collection when closing works
for me.
A

There was no delay in my application this morning. I checked Programs and Features and found that Acrobat Reader has been updated to version 15.023.20070. It looks like Adobe has fixed the bug. I'm not seeing the delay any more.
If you've been having this problem, check to see if the update fixes it for you. In the last couple weeks I saw several workarounds that others said were working for them that did not work for me so it's possible my problem was not the same as others so this update may not fix everyone's problem. It appears to have fixed mine though.

Related

sortablejs not working within SharePoint (webpart)

I have an application where items can be dragged and dropped between two lists. For this I use react-sortablejs (which uses sortablejs).
When I start my React application normally (in dev mode or deployed standalone) the drag and drop works as desired.
However, as soon as I embed the application in a SharePoint page (using webpart), the drag and drop feature starts to go haywire: the first drop works as desired, but all subsequent drops of the same item result in strange behavior, primarily duplication of the item.
After some debugging, it looks to me like the item remains in the old list and therefore an error occurs when the item is "pushed back" or a duplicate occurs because another item is pushed into the same list.
I therefore don't think that this is a problem of the library itself (also because I haven't found any similar error messages about this), but that it has something to do with SharePoint. I noticed in another context that classic context menus with absolute positioning also cause problems because event.pageX and event.pageY contain different values.
Anyway, at the moment I have no clue to get to the bottom of this problem, so I'm hoping that anyone might have had similar experiences before. Maybe this ticket will help someone else who runs into similar problems in the future.
My problem went away after setting forceFallack to true

WPF Designer crashed and stopped showing Test Data permanently

It happened again. My test data is not shown any more. I see only class and property names. Restarting does not help this time. Retracing neither.
I've been rewriting my whole project since that happened.
Now I tried to use Test Data class to address it from custom user controls so it would look like:
...d:DataContext="{Binding Source={DynamicResource TestData}, Path=Emploee}"...
//in resources
<main:TestData x:Key="TestData"/>
Not like it was previously:
...d:DataContext="{DynamicResource TestEmploee}"...
//in resources:
<shar:PVEmploee x:Key="TestEmploee" Name="Alpha" Surname="Omega" Phone="77777777" PVProfession="{DynamicResource TestProfession}"/>
<shar:PVProfession x:Key="TestProfession" Name="Some obnoxeously long profession name"/>
And right after those changes in this control (I've done it previously few times already to other controls, I've copied from previous project version) the designer crashed. Now I see
this ridiculousness, instead of test data
I am frustrated. Am I supposed to restart it again? Or there could be some way to fix it.
Answer to almost not realated question Actually worked well (the question was - how to crash a Designer =D ). If I kill designer in Task Manager, and click 2nd option in Studio. The Designer loads pretty well in a right way. All my Test Data right there. Or I found later that I can click small document icon on designer bottom to reload it with or without user code.
After a few such resets it started behaving. Marvelous!

On my second call to form.Show the System.Windows.Forms.Form does not appear

I have gone around and around with this problem using a combination of show(), showdialog(), bringtofront() and activate().
I am running CF 3.5 on a symbol MC50 PocketPC running Windows Mobile 5 (I think it is 5...)
This has to be simpler. Could someone please please give me some advice on this one?
If I use form.Show() the second time nothing happens.
If I use form.ShowDialog() the second time I receive this error:
"value does not fall within expected range"
If you call form.Close(), all resources within the instance of the form and the instance itself are disposed of. If you just wish to visually close the form but keep it around, you should use form.Hide(). This issue gave me quite a bit of frustration as well. Below is a note from the Microsoft documentation regarding this:
Note:
When the Close method is called on a Form displayed as a modeless window,
you cannot call the Show method to make the form visible, because the form's
resources have already been released. To hide a form and then make it visible,
use the Control.Hide method.

WPF AutoCompleteText - Solution that doesn't lag / lock UI on popup generation

I have tried about 4-5 different WPF solutions so far, including the WPF Toolkit and gradonz.actb (my favorite option) but every single one seems to be lagging when creating the dropdown. Once the dropdown is there, the data loads extremely fast, but on initial creation it is lagged and locks my UI. And this is not just a one time thing, each time it is created it appears to have a second or two lag / UI locking (I am assuming while it creates the object in my tree).
In advance I do know it is not my datasource as I have traced it and it never takes under 10 milliseconds to return to the search providers. I am also returning just 20 items max to the provider, so there is no reason that I can see for this delay. The problem is when it generates the list to show, and it happens on all of the solutions I have found.
Even if you know a licensed one that works well, I am willing to spend to solve this.
I appreciate any help
Anthony Greco
The issue was the popup class was lagging on show and it popped it up each time a new result started. A hack around this was popup on load, and when we don't need it, set the height to 0. Not ideal, but after 4 hours, at least it works.

WPF Combobox bug when form allowtransparency=true

I have found the following in WPF:
I have a form with AllowTransparency=true. Inside the form I put a Combobox.
I add some items to the combobox.
I run this application and click on the combobox. At first it does not seem to appear at all. On closer inspection (after adding more items) I see that it is actually appearing behind the form. If I add enough items it become visible from behind the form.
If I just change AllowTransparency=false, then all is fine.
This looks like a bug in WPF (3.5 SP1).
Any one know of a workaround for this?
Go to
https://connect.microsoft.com/dashboard/?wa=wsignin1.0
submit your feedback after searching #
https://connect.microsoft.com/VisualStudio
https://connect.microsoft.com/VisualStudio/feedback/CreateFeedbackForm.aspx?FeedbackFormConfigurationID=1160&FeedbackType=1
and mention steps to reproduce.
There was an update of 3.5sp1 but you could test,but I doubt
http://www.microsoft.com/downloads/details.aspx?familyid=6c095bba-6100-4ec9-9c54-6450b0212565&displaylang=en
AllowTransparency is slow and buggy and shouldn't be used - it's a great way to run into bug in various display drivers.
You can get almost anything you like without using AllowTrasparency, take a look at this post for examples:
http://blogs.msdn.com/wpfsdk/archive/2008/09/08/custom-window-chrome-in-wpf.aspx

Resources