We Keep Coding

Application crashes on element reader (pdftron)

I have an issue with pdftron, where opening a certain file, will cause our application to crash with following error:
An unhandled exception of type 'pdftron.Common.PDFNetException' occurred in PDFNet.dll
Additional information: Exception:
Message: Missing resource
Conditional expression: res
Filename : ContentResources.hpp
Function : trn::PDF::ContentResources::GetResource
Linenumber : 26
In our code: it's in the following line that the error occurs:
while ((element = elReader.Next()) != null)
When doing try/catch, we see that the only thing missing from the page is the text that's written diagonally on that page. Does this have anything to do with a missing font maybe ? Don't mind the cursor in the picture, it doesn't know where to go with the text missing.
I can send the pdf file on request.
PDF File

If you are not on the latest version of PDFNet, 6.7.1, then I would first try against that, as the issue might have been resolved already.
Otherwise, since the issue is document specific, you would need to provide that, by either sharing here, or sending to pdftron support.

In coded ui how do you correctly retrieve a browser window that contains an embedded Adobe PDF reader in browser

I'am running across this issue when I'm debugging or running my coded UI automation project, where i get the exception labeled "{"COM object that has been separated from its underlying RCW cannot be used." System.Exception {System.Runtime.InteropServices.InvalidComObjectException}" everytime i come from a browser window that contains a pdf reader embedded in it. This happens every time I retrieve the window and try to click back. It barfs when i perform the back method on it. I've tried different things but none has worked including the playback wait.
var hereIsmypdf = ReturnPDFDoc();
public BrowserWindow ReturnPDFDoc()
{
Playback.Wait(1000);
var myPdFdoc = GlobalVariables.Browser;
return myPdFdoc;
}
hereIsmypdf.Back();

The only way i was able to get around this issue was not to use the BrowserWindow class. I ended up using the WinWindow class and just getting the tab of the window from it. The BrowserWindow class seemed to trigger the exception "COM object that has been separated from its underlying RCW cannot be used." System.Exception {System.Runtime.InteropServices.InvalidComObjectException}" everytime i tried to retrieve it. I hope this helps someone one or maybe someone has a better way to handle this issue.
For the people that voted my question down, i really did try to figure it out. Sorry i wasnt clear about what i was asking the community or couldn't properly articulate what this pain was. I'm sure someone probably is going through the same pain i did and having a hard time articulating whats going on.
Here is my code on what i ended up doing
public WinTabPage ReturnPDFDoc()
{
WinWindow Wnd = new WinWindow();
Wnd.SearchProperties[BrowserWindow.PropertyNames.ClassName] = "IEFrame";
WinTabList tabRoWlist = new WinTabList(Wnd);
tabRoWlist.SearchProperties[WinTabPage.PropertyNames.Name] = "Tab Row";
WinTabPage myTab = new WinTabPage(tabRoWlist);
myTab.SearchConfigurations.Add(SearchConfiguration.AlwaysSearch);
myTab.SearchProperties[WinTabPage.PropertyNames.Name] = "something";
//UITestControlCollection windows = newWin.FindMatchingControls();
return myTab;
}

Why is PictureBox.Load locking image on some systems?

(Please see the edit on the bottom of the question, if you do not want to read the whole story.)
Hi,
I am new to stackoverflow. Don’t get me wrong, I use it quite often. But up until now I never actually posted something. This is because I did not have something new/useful to say and my English is not that good. The first thing (might have) changed, the latter did not.
I ran into a problem at a customer's Windows 7 system quite recently. I was shipping a C# .Net 4.0 Windows Forms application via ClickOnce. Basically, it is an application that creates a bitmap file and shows it to the user. If the bitmap exists prior to the creation, the existing file gets deleted first. After that the new file is created and loaded by a PictureBox.
The following thing occurred at the customer’s system: After starting the application the first creation succeeds – the second and all following ones do not. The file cannot be deleted, because some process is blocking it. This process is the application itself.
System.IO.IOException: The process cannot access the file “filename” because it is being used by another process.
Well, of course that is nothing unusual. The thing is I tested the application on several systems. None showed this exception. And until now I am unable to see an code error.
So I looked a little bit closer on the customer’s system: The only difference I could find is, that they changed the users folder so that they are not located on the windows partition, but on a different one (C:\Users --> D:\Users). I searched for an instruction on the internet and did the same thing on one of my test systems. To my surprise I got the same exception when I ran my application on it.
With that I could change my code so that the exception does not occur anymore. But I do not understand why that is. So maybe there is something wrong with my code and the error just reveals itself under that special circumstances. Or maybe the code is okay and the reason lies somewhere else. I just hoped that you might be able to help me.
So here is some code I put together, that shows the same behavior. I used 3 buttons, an OpenFileDialog and a PictureBox on a Form. First thing to do is to choose an image file. By pressing one of the two remaining buttons it gets copied into the main folder of the application. After being copied it is shown by the PictureBox. By the way, it does not seem to matter if it is a ClickOnce-application or a “normal” one.
String m_FileName;
private void btnChooseFile_Click(object sender, EventArgs e) {
if(openFileDialog1.ShowDialog() == System.Windows.Forms.DialogResult.OK) { // If file was chosen, set file name for later use and activate buttons.
m_FileName = "Test" + Path.GetExtension(openFileDialog1.FileName);
}
}
private void button1_Click(object sender, EventArgs e) {
// This is not working.
if(this.pictureBox1.Image != null) {
//Image img = this.pictureBox1.Image; // I was not sure, if maybe the pictureBox somehow prevents the disposing of the image, as long as it's assigned to it.
//this.pictureBox1.ImageLocation = null; // So I set them null, both the image and the image location.
//this.pictureBox1.Image = null;
//img.Dispose(); // Then I disposed the image.
this.pictureBox1.Image.Dispose(); // The short version. It is not working either way.
this.pictureBox1.Image = null;
}
(new FileInfo(openFileDialog1.FileName)).CopyTo(m_FileName, true); // But still this is where the Exception occurs.
this.pictureBox1.Load(m_FileName);
}
private void button2_Click(object sender, EventArgs e) {
//This is working.
if(this.pictureBox1.Image != null) {
//Image img = this.pictureBox1.Image;
//this.pictureBox1.Image = null;
//img.Dispose();
this.pictureBox1.Image.Dispose();
this.pictureBox1.Image = null;
}
(new FileInfo(openFileDialog1.FileName)).CopyTo(m_FileName, true);
pictureBox1.Image = Image.FromFile(m_FileName);
}
What happens now is the following: If I start the application and click button1 twice, I will get the exception (on the second click). If I start it and click button2 twice, I will not. If I start the application and click buttons1 first and after that button2, I will get the exception. So, the Picture.Load-Function somehow blocks the file, even if I dispose it.
When I searched on the internet, I found an article from microsoft: http://support.microsoft.com/kb/309482/en-us. But it does not hit the bull's eye.
Take into account, that both versions are working on all my test machines. I just get the exception when I change the users folder to a non-windows-partition.
Why is that? And where is the difference in the presented versions?
Edit
Okay, because of the first and only reaction so far, it seems to me, that it is still not clear, what really happens: If I take the above code, put it in a Windows Forms application, compile it and run it on different computers (at work, at home, does not matter) it works - both button1 and button2 (with the Click-functions linked to them) can be used as often as I like - no exception thrown. If I run the application on a computer, where I changed the users folder, and click button1 the second time - bam - IOException, file locked by process. Button2 works as long as I do not press button1.
The first answer implies, that I should get the locking on every system. But I DO NOT (as long as I do not change the users folder)! I tested it on every single computer I could get my hands on - no IOException. I set up a new system, just to rule out some special changes to the systems in my company - both buttonx_Click functions worked - no exception either. I even compiled the program on another computer - same behavior. The only three systems to throw that exception were the ones with the changed users folder.
So far I have no clue, why this difference in behavior occurs. Can somebody help me?
Anybody?

Yes, this is normal. Happens on any operating system, doesn't have anything to do with the Users folder location. The PictureBox.Load() method was intented to be used to load images from locations other than the file system. Like a web site. Which is slow, it avoids freezing the UI while the download is taking place.
It internally uses a FileStream when it discovers that the url you pass is actually a file and not a website name. This FileStream does not get disposed until the PictureBox itself is disposed or you call the Load() method again. A requirement because Image.FromStream() requires the stream to remain readable until the image is no longer used. It is this FileStream that keeps a lock on the file. Disposing the PictureBox.Image is not enough to also dispose the FileStream, the Image object doesn't know that it is being displayed inside a picture box.
There are several ways to solve this problem:
Use the Image property instead of Load(), assign it from Image.FromFile(). Disposing the Image now also releases the lock on the file. As you found out
Keep a dummy image around, one that perhaps displays a "Loading..." bitmap. Load() it first to release the lock on the file
Dispose the PictureBox and recreate it.

This works and unlocks the file
Image img= Image.FromFile(mypath);
Graphics g = pictureBox1.CreateGraphics();
g.DrawImage(img,0,0);
img.Dispose();

Check if there is any kind of PDF Reader installed

I have a Help function in my Application, that consists of one webbrowser control. That webbrowser control gets filled with a .pdf file, the source for that .pdf file is our own website.
The problem is, that not everyone will have a PDF Reader installed on their machine, so I want to check whether one is installed: Yes or No. I searched the internet and I mostly saw that users on Stackoverflow where wanting to check if Adobe Reader was installed, that is not what I want. I need to know IF there is a PDF Reader somewhere installed on the machine.
I did find the following code, that can possibly help me:
public void CheckPdfReaderAvailable()
{
RegistryKey key = Registry.ClassesRoot.OpenSubKey(".pdf");
Assert.IsNotNull(key);
}
As I look at the above code, my thoughts are that the code checks if the registry does know the .pdf format, but I'am not sure.
Can somebody tell me how to use the code above or provide me an example, about how I should take down this problem?
Thanks in advance!
EDIT:
The following answer helped my out: https://stackoverflow.com/a/774482/1661209
Another way to solve this problem, is to add a pdf reader lite to the prerequisites and make the users install that first, you don't have to check for a pdf Reader, because you know one is installed then, if it isn't you could say it is the mistake of the user that they can't use the help function, because you offered them a way to install the pdf reader easily using the published project.

Apart from whether it is useful to know or not, you could probable check the following registry key:
HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/pdf
This will have an entry CLSID, which points to the class ID of the default application.
If the registry key or CLSID value is not present, then the MIME type is unknown, or there is no default application to handle the MIME type application/pdf files.

You can query the registry directly but the recommended solution is to use the IQueryAssociations interface to see if there is a program registered to open pdf's. An example can be found on pinvoke.net.

C# implementation of the approach suggested by John Willemse (won't recognize Edge as default viewer on non-N version of Windows 10) :
private bool CanOpenPDFFiles
{
get
{
bool CLSIDpresent = false;
try
{
using (Microsoft.Win32.RegistryKey applicationPDF = Microsoft.Win32.Registry.ClassesRoot.OpenSubKey(#"MIME\Database\Content Type\application/pdf"))
{
if (applicationPDF != null)
{
var CLSID = applicationPDF.GetValue("CLSID");
if (CLSID != null)
{
CLSIDpresent = true;
}
}
}
}
catch (Exception)
{
}
return CLSIDpresent;
}
}

IVideoWindow::put_WindowStyle throwing "No such interface supported"

I've got a C# control wrapped around the DirectShow libraries. Though I'm not certain it's relevant, I'm running on Windows CE 6.0R3. When trying to play a WMA audio file using the control, the following code throws an exception of "No such interface supported":
m_graph = new DShowGraph(mediaFile);
m_graphBuilder = m_graph.Open();
m_videoWindow = (IVideoWindow)m_graph.GetVideoWindow();
if (m_videoWindow == null)
{
// this is not hit
}
try
{
m_videoWindow.put_WindowStyle((int)(WS.CHILD | WS.VISIBLE | WS.CLIPSIBLINGS));
}
catch (Exception ex)
{
// I end up here
}
The Open call looks like this (error handling, etc. trimmed):
private IGraphBuilder _graphBuilder;
internal IGraphBuilder Open()
{
object filterGraph = ClassId.CoCreateInstance(ClassId.FilterGraph);
_graphBuilder = (IGraphBuilder)filterGraph;
_graphBuilder.RenderFile(_input, null);
return _graphBuilder;
}
The GetVideoWindow call simply looks like this:
public IVideoWindow GetVideoWindow()
{
if (_graphBuilder == null)
return null;
return (IVideoWindow)(_graphBuilder);
}
Strangely, this all works just fine with the same control DLL, same application and same media file when run under Windows CE 5.0.
My suspicion is that it might have something to do with the fact we're playing an audio-only file (checking to see if the same problem occurs with a video file now), but I'm not overly versed in Direct Show, so I'd like to understand exactly what's going on here.
One of the large challenges in debugging this is that I don't have the failing hardware in my office - it's at a customer's site, so I have to make changes, send them and wait for a reply. While that doesn't affect the question, it does affect my ability to quickly follow up with suggestions or follow on questions anyone might have.
EDIT1
Playing a WMV file works fine, so it is related to the file being audio-only. We can't test MP3 to see if it's a WMA codec issue becasu the device OEM does not include the MP3 codec in the OS due to their concerns over licensing.

The graph's IVideoWindow is nothing but forward to underlying IVideoWindow of video rendering filter. With audio only pipeline you don't have the video renderer (obviously) and IVideoWindow does not make much sense. The interface is still available but once you try to call methods, there is nothing to forward, hence the error.