ActiveX Editor Control

[berard]

Has anyone had any luck embedding the ActiveX Editor Control within another
application?

According to PTC support, from 5.4 on, there is an available ActiveX control
that can be used. They even embed it within Arbortext itself as a font
preview (see: lib\dialogs\modifyfont.xml)
<activex disabled="true" height="80"&lt;br"/>id="editor" progid="Arbortext.EditorControl" resize="both" width="385">Dtl?></activex>

Pretty cool to say the least if I can get it to work, since our writers are
very familiar with the way the editor behaves, but are also dependent upon
external tools. Embedding it would allow me to keep the authoring
environment within a separate toolset context.

Given that we are a Seattle company, I've mainly been trying to do this
within a .NET GUI through COM interop, but I'm curious if anyone's tried
this from any other language/platform (C++, Java, etc).

Keith Berard
Milliman Care Guidelines

[ClayHelberg]

Hi Keith-



We've done a few implementations where the editor ActiveX control is
embedded in the IE browser using an <object> tag, and driving behavior
using JScript. There is a trick to really making it work well though.
The direct ActiveX interface is very restricted. However, you can
instantiate a separate Epic.Application object that will give you full
access to the AOM API.



If you're familiar with programming using ActiveX controls, it should be
pretty easy to get started--just add the control to your application the
way you would any other ActiveX control, create an Epic.Application
object to handle operations beyond the crippled interface the control
provides, and you should be good to go.



--Clay



Clay Helberg

Senior Consultant

TerraXML

[ClayHelberg]

And yes, it *is* pretty cool. 🙂



Clay Helberg

Senior Consultant

TerraXML

[berard]

Clay,

That's fantastic news. I should start off by saying this is somewhat of an
intellectual exercise at this point pending what I'm able to get working,
and how well it works.

That said, I've done plenty of work with the Application/ACL class
libraries, both through .NET (via COM bridge) and directly in Java, so I
pretty much figured that was the way to go as far as interacting with the
control. I also know that the Java interface was (as of 5.3) WAY faster
than going through COM, especially when doing iterations over all nodes.

Our current system consists of Arbortext with some custom XUI to handle
normal CMS checkout/checkin, as well as some other common authoring tools
for citation management, etc. Anything outside of this we handle through a
.NET application to take advantage of more rich UI constructs, so our
general workflow lifecycle, communications with our library, research APIs,
etc.

Since the majority of our authoring is still done in XML, and all of our
writers are familiar with how Arbortext works, it doesn't make much sense to
move to something else. However, working with multiple interfaces all the
time, not to mention different languages on the programming side, is not
ideal. My thought is that if I can embed the portions of the editor that
we know and love within the other application, it would allow for better UI
controls... which sounds somewhat like what you're doing within IE.

Would you be able to send me a little code snippet of how you're embedding
within a webpage? I'm not terribly familiar with ActiveX in that way, and
have tried a couple of class IDs with no real luck:
<object classid="CLSID:ECDED982-9C55-4E04-8741-00995ACE7F09" id="Arb1"&lt;br"/>width="200" height="200"></object>
<object classid="CLSID:2F891043-0DB4-11D3-9837-00104B3E04A0" id="Arb2"&lt;br"/>width="200" height="200"></object>

I get a similar result when I try to put the control into a WinForms/WPF
frame, presenting a large grey box with nothing in it.

One last thing... are you able to handle multiple windows in some way? I
ask because using disconnected code in the past relies on the active window,
and loses context if more than one instance is running. This might not be
a problem with the AX control, since I'm guessing you are referencing it by
ID in the Javascript, but worth mentioning.

Thanks,
keith

[ClayHelberg]

Hi Keith-



Here's the <object> tag we use to embed the editor control in a web
page:



<object<br/>
classid="clsid:3990811F-C23D-448E-B893-54549C334960" height="400"

id="editor" width="800"
codebase="Arbortext_Editor_Installer_5.4F000.exe"></object>



Note that we use the codebase attribute to point to a streamlined
Arbortext installer created with the Deployment Kit (which you can
download from PTC's support site). That way users who don't have
Arbortext installed yet have an easy way to download and install it.
With the Deployment Kit, you can configure the installer to set up
everything unique to your environment, e.g. environment variables,
zipped customizations, license server locations, user preferences, etc.
Another very slick piece of technology.



Anyway, some sample code to interact with the control might look
something like this:



<script type="text/jscript">

var resource = "c:\\www\\root\\activex\\demo.xml"

var app = new ActiveXObject("Epic.Application");

var doc = null;



function openFile() {

win = editor.open(resource);

winobj = app.Acl.getWindow(win);

doc = winobj.activeView.document;

alert("Now viewing " + doc.name);

}



function selectTitle() {

var title = doc.getElementsByTagName("title").item(0);

var titleoid = title.firstOID;

app.Acl.eval("oid_select(" + titleoid + ")");

}

....

</script>



As for the gray box, that probably means the control is loading OK. It
doesn't get "populated" with toolbars and such until you actually open a
document (call the open() method on the control). I get the same thing
in my web-embedded configuration, until I click the button that loads a
document. Then I see the full UI in addition to the document. So if you
haven't done it yet, run your code that gives a gray box and try loading
a document. That will tell if your control is working or not.



I haven't done much in the way of handling multiple open documents in
this environment, so I can't really say for sure what would work for
that. But I don't think it should be too hard to work out a system that
keeps multiple window/doc objects distinct so you can make sure you are
acting on the correct context. (In that case, I suspect you would still
want to share a single Epic.Application object and control action
targets using window or doc ID's, but I might be wrong about that. You
might have to do some experimenting to see what works best.)



Good luck, and let us know how it goes.



--Clay



Clay Helberg

Senior Consultant

TerraXML

[berard]

We only just started using the deployment kit style, but so far so good with
that.

Makes sense about not showing anything until open. I have a feeling that's
what's tripping me up. When I call open within .NET, I get an exception
(asks to check the HRESULT, but that's null). When I try in IE, it just
fails.

Do you recall how you went about getting the classid? I don't have 5.4
installed (just 6), so I went to Control Panel -> Admin -> Component
Services, drilled down within DCOM, and got the CLID from properties on the
"Arbortext Editor" or "ArbortextEditorModule"

[ClayHelberg]

Hi Keith-



I got the class ID from the documentation. Look at the topic
"Integrating Arbortext Editor with web pages" for more details.



--Clay



Clay Helberg

Senior Consultant

TerraXML

[berard]

*Face-Palm*

I guess in all of my Deployment Kit testing, I never even though of just
installing the full package to check samples. Turns out there's actually a
C# ActiveX embed example in there.

The "new" Deployment mechanism is great, but not so great if you're the
developer who needs the whole shebang.

Live and learn. Thanks again, and I'll keep you posted as to how it all
goes.

keith