I have written a console application which uses UDC (universal document convertor) to convert visio diagrams to an image (more specifically a jpeg).
Everything is working fine (for visio files in 2007 and 2010), and I am using Microsoft.Office.Interop.Visio version 14.0.0.0. I thought I would do a test by creating a visio diagram in Visio 2003 and testing the application. It works fine however, I get the following popup "The Microsoft Visio building plan shapes in this drawing must be updated to function in the current version of Visio". If I click "Yes" then the program works fine. This code will eventually be running as a service and I was wondering if there is anyway to supress these warnings? Or tell it to do any conversion automatically?
We seem to have found the answer (trying nearly every property on the Visio.Application class!):
vApp = new Microsoft.Office.Interop.Visio.Application();
vApp.Visible = false;
vApp.Settings.ShowFileOpenWarnings = false;
vApp.EventsEnabled = 0;
It seems the EventsEnabled = 0 did the trick!
Hope this may be useful to someone eventually.. I spent about 4 hours on it :)
You can set vApp.AlertResponse = vbYes, which suppresses the dialog and chooses Yes for you.
Related
I have this single line of code in a Word VSTO add-in project which used to work but suddenly doesn't anymore:
Microsoft.Office.Interop.Word.Document doc = Globals.ThisAddIn.Application.ActiveDocument;
Before it just returned the Document object as it was supposed to, and I could read from and manipulate it without issue. But now it throws a System.Runtime.InteropServices.COMException exception. "Word has encountered a problem." Very helpful. The exception contains an HRESULT of 0x800A13E9, which hasn't helped me so far either. Out of memory or something? Idk.
The new behavior seems to have started around New Year's Eve (not sure since I wasn't using the add-in for the past couple of weeks), and it started while the add-in was installed, i.e. nothing in the code was changed, recompiled or reinstalled to make it happen. I've since rebuilt the project, thinking maybe a certificate had expired or something, but the error still occurs.
It's maybe worth noting that I can still access other properties of the Application instance. For instance, this line does not throw an exception:
int numDocuments = Globals.ThisAddIn.Application.Documents.Count;
But then when I iterate over the Documents collection with foreach, it just skips over the loop as if the count was zero.
The only thing I can think of is that an update to Office (365) has broken something related to VSTO. But where do I even begin debugging this?
Okay, so I tried creating a new Word VSTO add-in, changing none of the default project properties, but adding a single ribbon with a single button and the following method:
private void button1_Click(object sender, RibbonControlEventArgs e)
{
try
{
var x = Globals.ThisAddIn.Application.ActiveDocument;
}
catch (Exception ex)
{
;
}
}
It throws exactly the same exception on getting the ActiveDocument property. I did however notice that there are two more exceptions thrown when loading the add-in, and they're also thrown when loading the original add-in (that used to work fine):
Exception thrown: 'System.Deployment.Application.DeploymentException' in System.Deployment.dll
Exception thrown: 'System.Security.Cryptography.CryptographicException' in Microsoft.VisualStudio.Tools.Applications.Hosting.dll
They don't prevent the add-in from loading and running, but maybe they're related to the problem anyway? I don't know if they were also thrown last year before the problem appeared.
I do however have a couple of Excel add-ins that still run fine with the same version of VSTO, Visual Studio and Office, and they don't throw the above two exceptions when loading. So the issue seems to be specific to Word.
And now I tried rolling back to Office 365 version 1810, the October release, which definitely worked before, so I think it's probably not a problem introduced by an Office update. It's something else. Probably.
Not that it really helps me much, but at least I've ruled that out. Probably.
The problem seems to be triggered by the Windows 10 October 2018 Update (or November). The affected customers had special Windows regional settings: Example: "English (Switzerland)".
Solution:
Change the Windows regional settings format to "English (UK)" or "English (US)"
The VBA Editor also no longer worked correctly for the affected customers (without installed add-ins). The error "Word has encountered a problem" (Visual Basic Error 5097) occurred directly during opening. The same error that occurs in C# for Application.ActiveDocument
Well, rolling back to the previous version of Windows 10 (1803 in my case, apparently) fixed the issue, and I can't reproduce it at the moment, so I'll mark this as solved for now.
While I still have no clue what exactly the deal was, I did at least learn in my research that clicking the "Check for updates" button in Windows 10 instantly makes you a beta tester for Microsoft. As in, they deliberately put you on the unstable update train, without any sort of notice, let alone a warning that you're about to install updates that they don't consider ready for release yet.
Anyway, I hope they got some good telemetry from my many, many hours of trying everything I could think of, so that maybe the issue is fixed by the time the update is forced on me. If not, I guess I'll be back to ask the same question again. At least I'll know where to start looking for the cause.
From my experience :
when i was closing the Active Document at that time i was refreshing Ribbon Menu according to the active document.
If the closing document was the Last document i wasn't able to read any property of
Microsoft.Office.Interop.Word.Document doc = Globals.ThisAddIn.Application.ActiveDocument;
and i was facing the same issue like you.
whenever i close any document i check
if(Globals.ThisAddIn.Application.Documents.Count = 1){
LastActiveDocument = true;
}
And when i refresh the Ribbion Menu i check
if(!LastActiveDocument){
// then only read any property of Active document
}
Microsoft has fixed the issue
Microsoft has released an Office update to fix this issue.
With Office Version 1902 (Build 11328.20158) the issue is fixed on my side.
I have a Solution that has a windows forms project in it. I have added a Word Document to it so that I could use this for a reporting tool. It seems that I have run into some problems while trying to open this.
I found this, which helped me out a lot but now when I try to use the code below, I'm getting an error message that tells me "ThisDocument does not contain a constructor that take 0 arguments."
wrd.Application wrdApp = new wrd.Application();
ThisDocument doc = new ThisDocument();
So I look at the tool tips and they say "Mircosoft.Office.Tools.Word.Factory, IServiceProvider". Can someone explain what these are?
I'm trying to automate a tedious process that currently involves launching Word, Creating a new document from a .dot, saving it, running one or two plug-ins that were written in C# using VSTO, saving it again, exiting the document, and exiting Word.
I want to write a C# commandline app that the user can launch with one or two args (conveying all the information that would normally require interaction with dialogs in Word), then walk away from as it runs without further interaction... suppressing any and all focus-stealing by Word while it's running if necessary and possible.
Is there some straightforward way to accomplish this? Here's a Java-like pseudocode example of what I have in mind:
// magic to non-interactively launch Word and expose it as an object
WordHost word = xx;
// create new Word document based on a specific template that isn't the default one.
WordDocument doc = MSWord.create("z:\path\to\arbitraryTemplate.dot");
// If we can avoid physically saving it at this point and just assign a concrete
// file path, it would be even better because the network is glacially slow.
doc.saveAs("z:\path\to\newDoc.docx");
// someZeroArgPlugin and aTwoArgPlugin are VSTO plugins written with C#
doc.someZeroArgPlugin();
doc.aTwoArgPlugin("first", "second");
// done!
doc.save();
doc=null;
word=null; // something like word.unload() first?
// now do more things that don't involve Word directly...
Assuming I'm on the right track...
I'm pretty sure I can find most of what I need to know by searching... once I figure out what I need to be searching for. What should I be searching for?
What kind of project do I want to be creating in Visual Studio? A .net 4.5 C# console application? A Word 2010 Add-In? Some other kind of project?
Details that might or might not make a difference:
my program will only be run on computers that have Word 2010 installed. Compatibility with older versions isn't necessary.
It would be nice if it can run under Vista, but it only has to work under Win7.
I have Visual Studio Ultimate 2012
Here's what you'll need to do:
Have Visual Studio and Office installed.
Create a C# console project using the .NET framework of your choice (recommend 4.0 or above).
Add a reference to the Word COM library (Project menu => Add Reference, COM tab, Microsoft Word XX.0 Object library -- Word 2010 is 14.0).
Set the Embed Interop Types setting to false for the references added above
Expand References in Solution Explorer
Select Microsoft.Office.Core, Microsoft.Office.Interop.Word and VBIDE
Right-click and select Properties to bring up the Properties panel for the references.
In the Properties panel, set Embed Interop Types to False
Code away.
Here's some sample code.
using System;
using Microsoft.Office.Interop.Word;
namespace CSharpConsole
{
static class Program
{
[STAThread]
static void Main()
{
var application = new ApplicationClass();
var document = application.Documents.Add();
document.SaveAs("D:\test.docx");
application.Quit();
}
}
}
For more information, see http://msdn.microsoft.com/en-us/library/office/ff601860(v=office.14).aspx
I am trying to figure out how to drag and drop an email from Outlook 2010 into my .NET application. I've seen quite a few articles, most with very complex solutions. My thought is it shouldn't be that complex ... but I could be wrong.
Any help would be much appreciated!
A easier solution has been posted here: Get body from Outlook email [Drag’n’Drop]
Outlook.Application outlook = new Outlook.Application();
Outlook.Explorer oExplorer = outlook.ActiveExplorer();
Outlook.Selection oSelection = oExplorer.Selection;
foreach (object item in oSelection)
{
Outlook.MailItem mi = (Outlook.MailItem)item;
Console.WriteLine(mi.Body.ToString());
}
It uses Microsoft.Office.Interop.Outlook.dll. (It's on NuGet with the same name)
The two answers above are both good. However, there are a couple of things you need to know.
In the first answer you can download the sample program and run it and you will find that everything works great so long as you are running it on a 32 bit computer, otherwise, you have to recompile your program from "AnyCPU" to "X86". I spent most of today trying to figure out why the first two characters of the .msg file names (of the emails) I was dragging and dropping were missing. As soon as I recompiled with "X86" it all started working.
In the second answer you will find that yes you can use the code and it is a whole lot easier, however, if you need your application to run on some other version of outlook (other than the one you added to your references) it probably will not work. I used to use the same kind of Office objects referred to in the second answer and I ran into problems all the time when someone wanted to use my program on a different version of Office (i.e. if I pulled in Office version 14 and they wanted to use it on Office 2007).
I want to implement a paperless filing system and was looking to use WIA with C# for the image acquisition. There are quite a few sample projects on CodeProject, etc. However, after downloading every one of them that I can find, I have run into a problem.
In each and every one of them, the reference to WIALib is broken. When I go to add "Microsoft Windows Image Acquisition" as a reference, the only version available on my development workstation (also the machine that will run this) is 2.0.
Unfortunately, every one of these sample projects appear to have been coded against 1.x. The reference goes in as "WIA" instead of "WIALib". I took a shot, just changing the namespace import, but clearly the API is drastically different.
Is there any information on either implementing v2.0 or on upgrading one of these existing sample projects out there?
To access WIA, you'll need to add a reference to the COM library, "Microsoft Windows Image Acquisition Library v2.0" (wiaaut.dll).
add a "using WIA;"
const string wiaFormatJPEG = "{B96B3CAE-0728-11D3-9D7B-0000F81EF32E}";
CommonDialogClass wiaDiag = new CommonDialogClass();
WIA.ImageFile wiaImage = null;
wiaImage = wiaDiag.ShowAcquireImage(
WiaDeviceType.UnspecifiedDeviceType,
WiaImageIntent.GrayscaleIntent,
WiaImageBias.MaximizeQuality,
wiaFormatJPEG, true, true, false);
WIA.Vector vector = wiaImage.FileData;
(System.Drawing)
Image i = Image.FromStream(new MemoryStream((byte[])vector.get_BinaryData()));
i.Save(filename)
Thats a basic way, works with my flatbed/doc feeder. If you need more than one document/page at a time though, there is probably a better way to do it (from what I could see, this only handles one image at a time, although I'm not entirely sure). While it is a WIA v1 doc, Scott Hanselman's Coding4Fun article on WIA does contain some more info on how to do it for multiple pages, I think (I'm yet to go further than that myself)
If its for a paperless office system, you might want also check out MODI (Office Document Imaging) to do all the OCR for you.
Heres how to target WIA 1.0 also so you can ship your app to Windows Xp. Something I was desperately looking for!!
How to develop using WIA 1 under Vista?
Update: I'm adding this separately since its a different answer (a year later). I learnt XP has WIA 1.0 and Vista onward has WIA2.0. You can however install WIA 2.0 for Windows XP Sp1+ from here.
I then also made a small library with code I found somewhere on the interweb here, it also has the ability to scan multiple pages:
http://adfwia.codeplex.com/
It doesn't need to be WIA. I was mostly looking at the WIA setup because it offers the same basic interface for different scanners. I've got 3 scanners on this machine and the TWAIN drivers/software for all of them suck (like blocking the screen during scanning).
For document management, I'm really looking for simple 200dpi grayscale scans, so most of the stuff in the TWAIN drivers is overkill.
That said, asking here was part of my last attempt to figure out how to do it in WIA before moving on to TWAIN.
Another note: You have to download the WIA 2.0 dll from Microsoft.com and then browse to the dll and add it to your project.