I would like to write a series of articles on WinFX --or Avalon, or whatever the name for new technology for writing Windows Application in Longhorn will be.
Probably, when Longhorn gets into beta and things get more well defined I will start posting some of my findings here. The new batch of technologies making a debut in Longhorn will surely keep us busy for years to come and I am certainly looking forward to sink my teeth on all the information related with the new UI model.
I've tried to used this article http://www.codeproject.com/csharp/CsAutomateWord.asp?target=Word to create a character sheet.
I have a CCharacter class, that contains all information about a character, and I want to generate a MS Word document with these information.
So I've created .dot document, with thinks like
Name _Name_ Age _Age_
in arrays (I've tried also without the array, directly in the text). _XXX_ is code that I will use for replacement.
Now, to the code:
// Create a Word application
Word.ApplicationClass vk_word_app = new Word.ApplicationClass();
// Open the .dot
object FileName =Directory.GetCurrentDirectory()+"\\Models\\Sheet.dot";
Word.Document vk_my_doc = vk_word_app.Documents.Open(...
// Create a new document
Word.Document vk_new_doc = vk_word_app.Documents.Add((...
// Copy the .dot into the new document
// close the .dot
vk_my_doc.Close( ref vk_false, ref vk_missing, ref vk_missing );
All the previous steps work. I get a new document, build from my template.
Now, I'd like to fill it with actual information. So I do this
// Select the new doc
// Define some variable
object vk_false = false;
object vk_true = true;
object vk_num = Word.WdFindWrap.wdFindStop;
object vk_find = "_Nom_";
object vk_replaceWith = Name_Familly; // This one is a member of CCharacter class
object vk_replace = Word.WdReplace.wdReplaceOne;
The form is probably closing because you're not handling the exception like you should be. Users should never see an exception thrown but should see a nice little error message without your app crashing.
As far as the COMException, I'm betting the problem is where param values should be an empty variant but you're passing a reference to false. This is not the same in the world of COM. Instead, try the following:
object empty = Missing.Value;
Anywhere you need to pass an empty argument, pass a ref to empty (or whatever you call it).
Also, .NET naming conventions recommend that you don't use the hungarian notation, like putting "C" before a class name. Just consider how all the classes you use in the .NET Base Class Library (BCL) are named, as well as the methods, properties, etc. Using the same conventions is important, because anyone using your library or extending your application - and that's any language that targets the CLR like C#, VB.NET, MC++, COBOL.NET, and many others - should be consistent to avoid confusion and other hastles.
Thank you for your answer. I agree that user should never see an exception, but I think it is even better to write correct code and avoid the exception, rather than displaying the error message. Exception would be nice if for instance the .dot file doesn't exist, but here it seems to be different.
About the empty : the Find.Execute function takes 15 parameters. The VBA help of Word gives me the feeling that none are supposed to be empty, but false. I have tried to use empty with some of these parameters, that are supposed to be facultative, but it changed nothing.
So I'm in need of more specific solution.
About the naming convention: I usually don't use hungarian notation, except in two cases. First, to differentiate between some parameters (like if I have a member Param, and a parameter Param), or when I'm porting an old C++ code, which is the case here, and I forget to rename a few classes or function.
Stephane David wrote: but I think it is even better to write correct code and avoid the exception, rather than displaying the error message.
I don't agree, exceptions are meant to happen and be handled, it doesn't necessarily mean they are bad. Since you need to properly handle them and using a MessageBox to the user is typically a good option, when it is pertinent. Some exceptions can be handled internally, however when they are of value to the user, they should be informed.
That's what I meant. In that case, the only information I can provide the user with is "this function doesn''t work, and I don't know how to make it work". If the error happens 100% of the time, then is it not an exception, it really is a programming error. It doesn't prevent me from handling the exception, but it is not a solution to my problem.
Stephane David wrote: I agree that user should never see an exception, but I think it is even better to write correct code and avoid the exception, rather than displaying the error message.
This is a bad assumption! Did you write Microsoft Word? I'm betting you didn't, so why trust the work of other people whom you probably don't know, and code in another application where a whole different set of problems exist? Never do. Never trust user input, and never trust another application. Always account for problems that might occur. Do you think that Word blindly accepts input from calling functions?
And just because a parameter takes a value of true doesn't mean that the converse is false. Look again at the type: Variant. When a variant isn't specified, it is an empty or missing variant, hence using Missing.Value (or sometimes you see
I found this example on MSDN: <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_wrcore/html/wrtskhowtosearchfortextinworddocuments.asp">How to: search for text in Word documents</a>[<a target=_blank title='New Window' href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_wrcore/html/wrtskhowtosearchfortextinworddocuments.asp">^</a>]. They use <code>Type.Missing
to find text. You have the right values for the ReplaceWith and Replace parameters. Also, you can search over the whole document (since in the example they set the range to the first two paragraphs) by using Document.Content instead of Application.Selection.Range, which - if I remember correctly - is an empty range anyway. I don't know about that, though - it's been a while since I programmed with the Office libraries. In any case, Document.Content is a Range over the whole document, which seems to be what you wanted anyway. Good luck!
Ok... I've tried to use an ActiveDocument.Content. I've tried with Selection. I've tried using Missing.Value with several parameters. Nothing works. I always get the same error... The execption starts to be not very... exceptional...
And to close the topic of exception, I never said I don't want to handle an exception. I said I don't know how to correct this one. Right now, my function always raise an exception, so it is useless....
I'm using this simple exemple directly from the article you linked for me. And it still doesn't work!!!
Would there be something else? Like not a simple parameter error, but perhaps a difference if I'm using Office XP or Windows XP?
That was on purpose. As the replace doesn't work, I've tried the very basic, with the simpliest exemple I could find in the library, just find a text. And I still get the exception.
In this exemple, they do not use a parameter, but Word.Find.Text instead
You could always make a second set of icons to add to your image list that are offset by the length of the original images (so you can simply shift the image index by the number of colored images). You'll have to extend the ToolBar class, however, in order to draw the buttons using those images, most likely having to override WndProc since the ToolBar control is just a wrapper to the Windows Common Control's Toolbar class. Messages are sent/posted and notification messages are handled. You'll have to do the same.
To see what's happening behind the scenes with the class, you should get yourself a good decompiler like .NET Reflector[^]. Understanding the Windows Messaging system and the Win32 APIs is necessary.