Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

OCX / DLL Calls from a Word Document

0 views
Skip to first unread message

Remington270

unread,
Nov 17, 2000, 3:00:00 AM11/17/00
to
I am new to developing VB Scripts in Word documents. I have developed one
that can access a SQL Server Database and select records and place them on a
Word Document. Problem is this looks like its going to be a dream come true
for my end-users. So what I wanted to do was develop a DLL or OCX that I
could use for multiple forms and call thoes DLL from the Word document and
select whatever data I need and pass it back to the Word Document. I have
never developed a DLL or OCX much less know how to call one. Any help or
examples would be appreciated.

Scott

Perry

unread,
Dec 18, 2000, 5:11:04 PM12/18/00
to
Hi Remington,

> I am new to developing VB Scripts

VB Script or Visual Basic
or Visual Basic for Applications??

There's a signifant difference between the three above options
Which of the 3 are you aiming at ...

And:
VBA can't compile projects to DLL's or OCX components ...

Krgrds,
Perry

"Remington270" <smo...@siuins.com> schreef in bericht
news:eUBcofJUAHA.277@cppssbbsa05...

Pete McDonald

unread,
Apr 7, 2001, 10:33:59 PM4/7/01
to
Scott,

Depending on a number of things, this "technically" could be written in any
of the three.

However, I wouldn't personally keep vbs on the list. VBA and VB5/6/and almot
7 are the cf you truly want to have single module that can be called by
multiple TEMPLATES on a SINGLE MACHINE, as opposed to multiple users from
multiple machines, then you don't stricly have to make a ActiveX DLL. or
OCX.

If the database routines are small, just include them in each template that
needs them. i.e., simple, like a simple couple of read and write functions
that you pass record/field data to and from, where the database is
relatively simple, (only a couple of tables, and not a huge number fields,
then the code likely to be small enough that the only issue of just
including the code in every template is maintenance. However, if you are
diciplined, you can keep a master copy of the DB module and just import it
into each template that needs to use them. The only thing you lose is the
ability to edit the master and have all its childred updated at once.
However, if maintenance is likely to be minimal, this might be an acceptable
trade off for simplicity.

Otherwise, an activex DLL, or ocx would be _ideal_. You can still do it in
pure VBA, but relatively speaking, its a bit of a hack if you want to call
it from multiple different templates.

If you want activex anything, you need vb5 or 6. or co,omg

I personally tend towards activex components for anything and everything,
just because I believe in the paradigm, but you _can_ do it either way.

Good Luck with your project no sarcasm)

Pete
McDonald

Pete McDonald

unread,
Apr 8, 2001, 6:11:21 PM4/8/01
to
Sorry for all the errors, I thnk i need to stop working when I am falling
asleep. The below is what I really was trying to write.

To everyone reading, I appologize for the recent spate of errors, I promise
I will stop answering when I am falling asleep.

Pete
--


"Pete McDonald" <pmcd...@mcdonaldconsult.com> wrote in message
news:ek42cR9vAHA.2288@tkmsftngp02...


> Scott,
>
> Depending on a number of things, this "technically" could be written in
any
> of the three.
>
> However, I wouldn't personally keep vbs on the list. VBA and VB5/6/and
almot

> 7 are the choices. If you truly want to have single module that can be


called by
> multiple TEMPLATES on a SINGLE MACHINE, as opposed to multiple users from
> multiple machines, then you don't stricly have to make a ActiveX DLL. or
> OCX.
>

> Now, If the database routines are small, just include them in each
template that
> needs them. i.e., if they are simple, like a couple of read and write


functions
> that you pass record/field data to and from, where the database is

> relatively simple also, (only a couple of tables, and not a huge number
fields),
> then the code is likely to be small enough that you could include it in
ever template
> that needs it with the only issue being maintenance. However, if you are
> disciplined, you can keep a master copy of the DB module and just import
it
> into each template that needs to use it. The only thing you lose is the
> ability to edit the master and have all its children updated at once.
> But, if maintenance is likely to be minimal, this might be an acceptable
> trade off for simplicity of implementation.
>
> Otherwise, an activex DLL, or OCX would be _ideal_. Strictly speaking, you
can
> actually do a vba implementation that has a single module that is called
from various
> templates, but relatively speaking, its a bit of a hack in VBA to do this

>
> If you want activex anything, you need vb5 or 6. or the coming vb .net
product


>
> I personally tend towards activex components for anything and everything,
> just because I believe in the paradigm, but you _can_ do it either way.
>

> Good Luck with your project (no sarcasm)

0 new messages