I would also like to see ConvertToHtml and ConvertToRtf methods. But what about using Range.XML along with a transform?

Yes, that should work. I got the same response from the folks on the Word team. Thanks for caring ;-)

Of course that should be Word to HTML conversion... Word can't fix all typos for me ;-). Also I should mention that using the XML features in Word ROCKS -- once I had mapped the schema (pretty darn easy), I could just get at the text in the document without worrying about Ranges or Paragraphs or anything else; just a simple hierarchy of XML nodes.

Would you be able to post the code for your Word client? It'd be neat to use it as an entry mechanism for other blogging tools (livejournal, custom others, etc). Thanks, --Oren

I'll clean it up a bit and see if I can get it posted here at gotdotnet

Thanks!

I want WordBlogX now!!!!!

> Couple this with the fact that JScript almost certainly (90% sure, but I didn't write the code) generalises operations on literals to be the same as operations on arbitrary expressions Correct. In theory, the interpreter should take the literal, create a new in-memory object wrapper around the value, and then call the appropriate prototype method on the wrapper, and then destroy the wrapper. In practice, the engine is a little smarter than that -- we detect this situation at runtime and dispatch to the appropriate method without actually doing the work of creating an in-memory item. Eric

> Every now and then, people talk about "compiled" versus "interpreted" languages, and how they are different. This distinction is both arbitrary and vague, and indeed, JScript Classic blurs the line considerably. JScript Classic acts like a compiled language in the sense that before any JScript Classic program runs, we fully syntax check the code, generate a full parse tree, and generate a bytecode. We then run the bytecode through a bytecode interpreter. In that sense, JScript is every bit as "compiled" as Java. The difference is that JScript does not allow you to persist or examine our proprietary bytecode. Also, the bytecode is much higher-level than the JVM bytecode -- the JScript Classic bytecode language is little more than a linearization of the parse tree, whereas the JVM bytecode is clearly intended to operate on a low-level stack machine. JScript .NET is even harder to characterize as "compiled" or "interpreted". Like JScript Classic, the JScript .NET compiler produces bytecode, but this time it is Common Language Runtime Intermediate Language (IL) bytecode. Instead of interpreting the bytecode, the CLR JIT-compiles it into native machine language. But that's not all -- to implement features like "eval", JScript .NET also provides the ability to generate a parse tree and then run an interpreter _directly_ on the parse tree. In JScript .NET, calling "eval" does not generate a byte code which is then interpreted, it generates a parse tree which can interpret itself. "Compiled" and "interpreted" have ceased to be useful buckets for categorizing programming languages. There are some "interpreted" languages which are faster than some "compiled" languages, there are some "compiled" languages which are more flexible than some "interpreted" languages -- at some point you have to look at the actual relevant characteristics of each tool rather than trying to summarize them as "just another interpreted language" or "just another compiled language". Eric

You're on my list, man.

I read your blog and your newsgroup posts ;-) Learn a lot from them. Even when it's on something that I already know, i still always get something from it -- another angle to things, view points, etc, so it's great. I particularly like the recent Paranoia blog entry since security is a hobby of sorts. It was very interesting. So, do please keep blogging whevener time allows.

Yeap I read, keep it up :)

Yup

I've found your blog few days ago and found it quite interesting, so I've added it's RSS feed to my aggregator and will keep reading it (as long as you'll keep writing, of course). Thank you for the articles.

I subscribe to man of the GotDotNet blogs.