Without going into why I need OLE.. I need to embed a managed C++ custom control into MS Word 2007 (2003 also would be nice).
So the question is How do I make this managed (.net 3.5) control OLE compliant ?
It seems that I need to do something akin to implementing an interface. But an up-to-date tutorial is something that is proving difficult to find.
I've read the wikipedia article on OLE. All the information that I could google out is ancient (1994) and/or VB centric (4.0-6.0). Anything that makes sense to current times... links/books please post.
Thanks for reading..
Andrew Whitechapel writes about managed controls as ActiveX controls in Office documents. You can read his article here: http://blogs.msdn.com/andreww/archive/2008/11/24/using-managed-controls-as-activex-controls.aspx.
Update: See also this related question.
Related
If not, is there a way to do that with either docx4j or Aspose?
I've stumbled across the question
docx Template Docx4j replacing text in Java. It describes the actual problem I'm facing, which are template variables (like ${some.variable}) breaking across text runs due to spell check. However, his solution won't work well for me. The best solution I could achieve would be to disable (and maybe re-enable) spell check automatically under the hood.
There isn't at this point in time, but you can give feedback on https://officespdev.uservoice.com/ to request it to be added in future updates to the APIs.
Thanks,
Philip, Software Engineer on the Office Extensibility Team
This is a general question about the topic. I ran across a post which gave VB script code for version control. I've been developing with Access for a while, but have learned entirely on my own and can be pretty ignorant of the the broader IT world. I got
the code to work for me, but I'm lost on how to put it to work as a system.
To give some context, I have an example situation that maybe this kind of thing could solve. I'm now working on two versions at once (1.2 and 1.3) because the first version we'd like to release has to be tested where it's to be used in China. They were out of the office for a week due to the Chinese new year, in the meantime, I'm working on 1.3. Now, any changes I have to make to 1.2 of course have to go into 1.3. Actually, it's worse than that because clarity over the fact that we'd have to do this in two separate releases didn't emerge until work had been done which in hindsight went further than we could incorporate in 1.2.
The code in the post basically dumps all of the info about forms, reports, VBA, and macros into a bunch of text files (for some reason not tables, and maybe that has something to do with the fact that I'm working with Access 2010 rather than whatever version this code was created for.) Apparently, it can then reconstruct an application from those same text files.
What do I need to understand about source code control to make such a thing work for me? I recognize that might not be something you'd want to explain in a post, but can you point me in the right direction information-wise?
While this question is 3 years old, it might be of interest to some to have an answer anyway.
AFAIK, accesssvn.codeplex.com -cited by #Robby Shaw - is not working and not maintained.
Today I see 2 products usable products for VCS inegration:
one is https://github.com/timabell/msaccess-vcs-integration which is quite active
the other one is Microsoft Access 2010 Source Code Control for which I don't know if it works with more recent versions of Access
Apart from VCS, you could also use a database compare tool like Microsoft's Database Compare 2013
Also worth considering, Accdbmerge, a tool to merge 2 databases.
I'm new with this Perl Win32::OLE automation. I have been reading and trying out some examples. I have a few questions (excuse me if i'm using incorrect terminologies - do correct me):
Can OLE be used to automate Visual
Studio 2005? I only found examples
with Word, Excel and IE. How do
you know which app can be used?
How do I get the name of the program ID
to be used. For instance, "Excel" in
Win32::OLE->new('Excel.Application')
How do I get the available functions
for each programs. For instance,
Workbook, only can be used with
Excel, not Word.
Thanks for your time :)
The Win32::OLE documentation provides a rudimentary starting point.
As for your questions:
I do not think VS 2005 provides an OLE automation interface.
See this post on PerlMonks.
An excellent source of information for Microsoft Office applications is the Object Browser. You can access it via Tools -> Macro -> Visual Basic Editor. Once you are in the editor, hit F2 to browse the interfaces, methods, and properties provided by Microsoft Office applications.
Typically, the OLE automation model is up to the software you are trying to automate. You can usually figure it out by looking at the documentation, for example for the Microsoft products it will be in MSDN. For Visual Studio and the Office tools, you can also use the macro recorder to help figure out the syntax, since you can record a script that does vaguely what you want and then modify it.
Also, Visual Studio comes with the tool called "OLE/COM object viewer" (Oleview.exe) which can be used to open and read the type libraries for some target software. The type library is usually contained within a .tlb or .dll file and contains the more or less full description of the OLE Automation types defined for the application. You can look at the .idl thus reverse engineered and try to figure out what kind of things are possible.
To get a brief overview and introduction I would suggest looking at this The Perl Journal #10. Created by Jan Dubois.
Also here are some examples, if you havn't stumbled across it yet Examples
Hope it helps
How would I go about extending the functionality of windows explorer in XP?
Is there some way whereby I could create a "plugin" of some sorts that could hook into explore.exe to add additional folder browsing functionality? What language could I use to achieve this?
This is an expansion of a question I asked here.
There's a great series of tutorials on CodeProject which might help you. C++ is required there.
There is an old O'reilly book called 'Visual Basic Shell Programming' that explains the API's for this in some detail. While taken from a VB6-centric point of view, the API's are all exposed through COM, so they can be used from any language that supports this. This article discusses using the windows shell with .Net and a tool to build an interop assembly.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
The people writing the user manual are not necessarily programmers, and they need a visual editor. A major issue is the internal format of the authoring tool; it should be readable text/html, so it's easy to compare versions of individual pages checked into version control.
DocBook
(source: docbook.org)
Microsoft HTML Help Workshop can be used to create good quality professional CHM help files. All you need is a bunch of HTML files. The tool "compiles" all these and bundles into a single Help file.
The HTML files can be generated using Microsoft Word/Frontpage or even Dreamweaver. You might want to consider source controlling these HTML files.
Latex. Lyx provides WYSIWYM for writing latex files.
At my old job they used a tool by madcap software called flare.
It seemed to work really well.
There are other professional products which allow help file writing and they have support of "context ID" which makes context sensitive help possible. Doc To Help and RoboHelp are these type of products.
A good combination to consider is Subversion, DocBook and Publican.
Version control = Subversion
Content Authoring = DocBook
Publishing = Publican
Optional WYSIWYG = Serna
At the moment, this is one of the toolchains in use by the world's largest provider of open source solutions, and the name behind much of the world's use of Linux-based operation systems in the enterprise market. Most (and close to all) of Red Hat's official documentation is created in such a manner. Same goes for Fedora.
The major "pro" here is that these are freely available tools, with a strong overlap in the market of technical writers. All of which will be able to (but might not want to) write in XML, and picking up DocBook is like picking up HTML in the 90's. Subversion is a very common version control tool, that like DocBook is relatively easy to implement and use. Publican is a great publishing tool that can take DocBook XML, and publish it to PDF, HTML, HTML-single, etc. Obviously your writers can use a WYSIWYG like Serna, but I use snippets in Geany (on Fedora) or TextMate (on OS X) personally.
The major "con" is the perception of technicality. Your writers might want WYSIWYG (and can have it), and depending on your documentation needs, this might be what you end up using. As you would know, there's a market out there for "Technical Writers" who specialize in fixing Microsoft Word styles (and markup), so the arguments for separating "authoring" from "publishing" are based on proven but distinct use cases for organizations that require documentation to be held up to the same standards of the engineering/programming/source production.
Some of the extreme advice you will get comes from people and companies that have been exposed to the value of XML documentation, and especially those in the realms of DITA, where certain multi-nationals have a reputation for acquisitions that are influenced by the format and availability of the product knowledge. there are also the arguments that locking your documentation into a "sticky" or closed format doesn't help the future maintenance requirements. This is where the open source options gain support on a corporate level. Plus, obviously, it's free.
You can use Subversion and MGTEK Help Producer. Help Producer makes help files from Word documents. TortoiseSVN comes with scripts to compare different revisions of Word documents, in Word itself (Word has a version compare tool).
Your users are going to want a visual diff tool that resembles the one they are editing in. If they are just slightly not-technical, DocBook or Latex aren't going to work (I've tried giving my users both, and I even tried Epic Editor as a DocBook editor which is very expensive but didn't work out very well after all). Sticking to something they know (Word) will prevent you many headaches.
I was very reluctant to go this route at first too, because I wanted a solution that was more 'technically perfect', but I realized over time that having happy and productive users was more important. Just saying that I know where you're coming from, but try the Word route - it works much better in practice than all the 'pure' text-based solutions that are out there. Regular users don't like markup based editing.
If you're using Visual Studio, take a look at SandCastle - http://www.codeplex.com/Sandcastle.
There's also a couple of tools that help you build sandcastle files, try searching "sandcastle" on codeplex. One of them is SandCastle Help File Builder (http://www.codeplex.com/SHFB), but I've never used it so I don't know if non-technical users will be happy with that.
Mapcap Flare is the best commercial tool around. Written by the ex-developers of Robodoc
I created a documentation system called Mandown (Markdown/Html/Javascript/file-based relatively linked documents for portability) which would easily go under version control. The visual editor part you would have to figure out separately - I sometimes use HTML-Kit which at least has a preview feature.
See What is the best way to store software documentation?
Here's another tool to check out: Xilize
We are using APT. It integrates well with the CI (standard build artifact) and is more alive than for instance word document. It is also possible to generate PDFs and other formats when needed.