Getting at VBA

[Laurel]

I have inherited some VB code which is used to create a dll that contains a
bunch of calls to Word. I have to modify it for Word 2007. I am not a VB
programmer - just some experience via Access. And I'm not a VB6 programmer.
But that's the tool I've been using. A colleague told me I should be using
VBA - not VB6 to work with this code. But he is not available to tell me
how to do that. I can see how to get to VBA via a .dot file... and via
Access. But how do I get to this standalone VBP and all its cls files?

 

[Karl E. Peterson]

Hi Laurel --

I have inherited some VB code which is used to create a dll that contains a
bunch of calls to Word. I have to modify it for Word 2007. I am not a VB
programmer - just some experience via Access. And I'm not a VB6 programmer.
But that's the tool I've been using. A colleague told me I should be using
VBA - not VB6 to work with this code. But he is not available to tell me
how to do that. I can see how to get to VBA via a .dot file... and via
Access. But how do I get to this standalone VBP and all its cls files?

It's *very* tempting to start casting aspersions in the general direction of your
colleague! I shall try to resist.

Do you know what the code in the DLL is supposed to be doing? Are you familiar
enough with it that you can get in there and really get your hands dirty, so to
speak? How about your colleague? If so, you could be on the right track, but it's
a pretty questionable adventure if you (or your friend) haven't any idea how to
answer those questions.

To be blunt, there is no way to load a VBP in VBA. The concepts are just totally at
odds with one another.

You *can* load individual modules from the VB6 project into VBA, though. Just open
the editor (alt-F11), and import the files (ctrl-M). Not sure how far this will get
you, but only you know what the DLL is supposed to be doing and *why* you'd want to
pull that functionality directly into your documents and/or templates.

Did the colleague happen to mention *why* he thought this was a good way to go?

 

[Laurel]

Very interesting. When he returns I will be equipped to ask trenchant
questions.

But first, to you, how do I get into the VBA editor? I only know how to do
it from a .mdb or .dot.

To answer your other questions, all I need to do is change "normal.dot" to
"normal.dotm" and change another statement as illustrated below. This is
for Word 2007 compatibility. I AM able to make the changes and make a dll
that will work on computers other than my own. I was hoping that the
VB6/VBA discussion would address the problems I have RUNNING against the dll
on my own computer.

'Remove the Autotext entry from NORMAL.DOT
WordApp.OrganizerDelete Source:="Normal.dot", _
Name:=Current_AutoText,
Object:=wdOrganizerObjectAutoText

Change to something like the following, but the exact following won't
compile.
WordApp.
NormalTemplate.BuildingBlockEntries(Current_Auto_Text)Delete

Not only can I not USE the dll I create in my own environment, each time I
close VB6 I get an error that I'm supposed to send to Microsoft... My next
step is to try to uninstall VisualStudio.NET which is on my computer, but
which I no longer use.


Thanks again for your perspective!

 

[Karl E. Peterson]

Very interesting. When he returns I will be equipped to ask trenchant
questions.

But first, to you, how do I get into the VBA editor?

Same way as in Access. Either Alt-F11 or Tools-Macros-VBE.

I only know how to do it from a .mdb or .dot.

That's confusing. Makes me wonder.

To answer your other questions, all I need to do is change "normal.dot" to
"normal.dotm" and change another statement as illustrated below. This is
for Word 2007 compatibility. I AM able to make the changes and make a dll
that will work on computers other than my own. I was hoping that the
VB6/VBA discussion would address the problems I have RUNNING against the dll
on my own computer.

I've followed the saga. <g> Your colleague has as well, perhaps? One of the
advantages of moving all the code into VBA is you're through messing with the binary
compatability issues that seem to be plaguing you, at the expense of massive
proliferation of redundant code.

'Remove the Autotext entry from NORMAL.DOT
WordApp.OrganizerDelete Source:="Normal.dot", _
Name:=Current_AutoText,
Object:=wdOrganizerObjectAutoText

Change to something like the following, but the exact following won't
compile.
WordApp.
NormalTemplate.BuildingBlockEntries(Current_Auto_Text)Delete

I believe it. It's clearly missing at least one dot separator. No idea if it's
part of the object model. Is the DLL early or late bound to Word?

Not only can I not USE the dll I create in my own environment, each time I
close VB6 I get an error that I'm supposed to send to Microsoft...

Screw them.

My next
step is to try to uninstall VisualStudio.NET which is on my computer, but
which I no longer use.

Oh, but you *do* know how to make this guy smile, don't you?

Thanks again for your perspective!

Worth every penny you paid, and then some, lemme assure you! ;-)

 

[Laurel]

SEE BELOW - NOT YELLING - JUST DISTINGUISHING MY ANSWERS FROM YOURS

Same way as in Access. Either Alt-F11 or Tools-Macros-VBE.

BUT WHERE AM I STARTING FROM? IF I JUST OPEN WORD AND CLICK ALT/F11 I'M IN
VBA, BUT WITH NO WAY TO OPEN MY PROJECT, TRACKER.VBP. THE FILE MENU DOESN'T
HAVE AN "OPEN" OPTION. WHERE AM I WHEN I ENTER ALT/F11???????

That's confusing. Makes me wonder.

WELL, SEE ABOVE. IT'S A MATTER OF BEING SOMEWHERE WHEN I ENTER ALT/F11.

I've followed the saga. <g> Your colleague has as well, perhaps? One of
the advantages of moving all the code into VBA is you're through messing
with the binary compatability issues that seem to be plaguing you, at the
expense of massive proliferation of redundant code.

I DOUBT THAT COMPATIBILITY IS THE PROBLEM. THIS DLL WORKS FINE ON OTHER
MACHINES, EVEN WHEN I MAKE CHANGES ON MINE. I JUST CAN'T RUN AGAINST IT. I
SUSPECT ANOTHER RESPONDENT IN THIS THREAD WAS RIGHT WHEN HE SUGGESTED THAT
MY ERROR, WITH NO LINE OF CODE, MEANS THAT YET ANOTHER DLL IS BEING CALLED
AND IS INCOMPATIBLE. I ALSO HAVE VISUALSTUDIO.NET ON MY MACHINE AND AM
TRYING TO FIGURE OUT HOW TO REMOVE IT. I'M WAITING FOR DISKS TO ARRIVE IN
THE MAIL, SINCE YOU CAN'T REMOVE WITH ADD/REMOVE WITHOUT THE DISKS.

I believe it. It's clearly missing at least one dot separator. No idea
if it's part of the object model. Is the DLL early or late bound to Word?

DON'T KNOW WHAT EARLY OR LATE BINDING IS. WHERE'S THE DOT MISSING FROM?

 

[Karl E. Peterson]

SEE BELOW - NOT YELLING - JUST DISTINGUISHING MY ANSWERS FROM YOURS


BUT WHERE AM I STARTING FROM? IF I JUST OPEN WORD AND CLICK ALT/F11 I'M IN
VBA, BUT WITH NO WAY TO OPEN MY PROJECT, TRACKER.VBP. THE FILE MENU DOESN'T
HAVE AN "OPEN" OPTION. WHERE AM I WHEN I ENTER ALT/F11???????

Well, I did answer that previously. The two concepts are simply not compatible.
Instead, you need to import the modules, one by one. You can do this with Control-M
or from the File menu directly. Your "project" is history, though. You'll need to
rewire the code back together, so it makes sense in the context of a
document/template.

WELL, SEE ABOVE. IT'S A MATTER OF BEING SOMEWHERE WHEN I ENTER ALT/F11.

You are no where, to speak of, I understand. That's the point. The concept of a
project just isn't the same anymore. Now you've entered the world of documents and
templates.

I DOUBT THAT COMPATIBILITY IS THE PROBLEM. THIS DLL WORKS FINE ON OTHER
MACHINES, EVEN WHEN I MAKE CHANGES ON MINE. I JUST CAN'T RUN AGAINST IT.

I don't think you *know* what you're "running against" -- and that really isn't as
insulting as it may at first appear. If you question this observation, tell me how
you determined what you're "running against" on your machine.

I SUSPECT ANOTHER RESPONDENT IN THIS THREAD WAS RIGHT WHEN HE SUGGESTED THAT
MY ERROR, WITH NO LINE OF CODE, MEANS THAT YET ANOTHER DLL IS BEING CALLED
AND IS INCOMPATIBLE.

Yep, which is pretty much what I'm saying.

I ALSO HAVE VISUALSTUDIO.NET ON MY MACHINE AND AM
TRYING TO FIGURE OUT HOW TO REMOVE IT. I'M WAITING FOR DISKS TO ARRIVE IN
THE MAIL, SINCE YOU CAN'T REMOVE WITH ADD/REMOVE WITHOUT THE DISKS.

Oh good grief; sounds viral.

DON'T KNOW WHAT EARLY OR LATE BINDING IS.

It's the difference between:

Dim obj As New Word.Application
and:
Dim obj As Object
Set obj = CreateObject("Word.Application")

(I'm a VB guy, so any example I offer that directly uses the Word object model is
suspect! <g>) The first is early-bound, the second is late-bound. The difference
is *enormous* in the world of COM. Repectfully put, you're not going to wrap your
head around binary compatibility without having basic concepts like this nailed down
tight.

WHERE'S THE DOT MISSING FROM?

OK

Sensible response.

 

[Jonathan West]

You are no where, to speak of, I understand. That's the point. The
concept of a project just isn't the same anymore. Now you've entered the
world of documents and templates.

A very good introduction to this world, at least for Word, is Bill Coan's
excellent article

Getting To Grips With VBA Basics In 15 Minutes
http://www.word.mvps.org/FAQs/MacrosVBA/VBABasicsIn15Mins.htm

 

[Laurel]

Well, I did answer that previously. The two concepts are simply not
compatible. Instead, you need to import the modules, one by one. You can
do this with Control-M or from the File menu directly. Your "project" is
history, though. You'll need to rewire the code back together, so it
makes sense in the context of a document/template.


You are no where, to speak of, I understand. That's the point. The
concept of a project just isn't the same anymore. Now you've entered the
world of documents and templates.

My colleague, who told me I was using VBA, turned out to be having an
early-middle-age-moment. It's true that our application uses VBA in the
form of Word .dot files, but the stuff I'm working with is in a dll and, he
now agrees, once again, that has to be accessed from VB6.exe. So, think you
for your efforts, but I will have to ignore anything that assumes I'm in the
world of documents and templates.

I don't think you *know* what you're "running against" -- and that really
isn't as insulting as it may at first appear. If you question this
observation, tell me how you determined what you're "running against" on
your machine.

Well, I register the dll that I create. So I assume that's the one I'm
running against. I'm sure the tracker.dll file is created by me because of
the date/time and because when I send it to another computer, it shows the
changes.

BUT - Who knows what other dlls I'm running against. That's why I'm going
to try to uninstall VisualStudio.net.

 

[Laurel]

Thanks for the article.

As I mentioned above, it turns out the colleague who told me I was working
only in VBA was having an early-middle-age-moment. We have some pieces in
VBA (.dot files), but the dll I'm wrestling with is accessed via VB6.exe, he
now agrees. Can VBA even be used to make a dll?

 

[Karl E. Peterson]

My colleague, who told me I was using VBA, turned out to be having an
early-middle-age-moment.

It's true that our application uses VBA in the
form of Word .dot files, but the stuff I'm working with is in a dll and, he
now agrees, once again, that has to be accessed from VB6.exe.

You really need to be more precise with your vocabulary. Saying "has to be
accessed" is just screwy in this context. If you want to work on the code, yes,
that's true. But it's demonstrably untrue in that you're writing to code *to be
accessed* from VBA and/or other COM clients! Words have meaning and, I don't mean
this to sound quite as harsh as it surely must, it's important that as a programmer
you use words as they're meant to be used.

So, think you for your efforts, but I will have to ignore anything that assumes
I'm in the world of documents and templates.

Again, that's not necessarily true. I've already explained how it's very possible
to (potentially!) move your code into the VBA realm. Granted, the transition
usually goes the other way, but there could be reason to follow that route.

Well, I register the dll that I create. So I assume that's the one I'm
running against.

Very bad assumption. Very, very bad assumption. Probably the single assumption
that's led to these endless threads.

I'm sure the tracker.dll file is created by me because of
the date/time and because when I send it to another computer, it shows the
changes.

The only way to know for sure is to check your references in the VBA project that's
using the DLL. See what file they're actually pointing to. The fact that your
debugging adventure didn't go as anticipated leaves me at five-nines confidence that
you're not using the DLL you think you are.

BUT - Who knows what other dlls I'm running against.

Well, for starters, *YOU* should! These aren't great mysteries.

That's why I'm going to try to uninstall VisualStudio.net.

Not that there's anything wrong with removing defective software, of course. <g>

 

[Karl E. Peterson]

Can VBA even be used to make a dll?

No.

 

[Laurel]

Very bad assumption. Very, very bad assumption. Probably the single
assumption that's led to these endless threads.


The only way to know for sure is to check your references in the VBA
project that's using the DLL. See what file they're actually pointing to.
The fact that your debugging adventure didn't go as anticipated leaves me
at five-nines confidence that you're not using the DLL you think you are.


Well, for starters, *YOU* should! These aren't great mysteries.

Yeah.... well.... that's why I came to the newsgroup. To get things solved
that are mysteries to me. As I said early on, I'm not a VB programmer and
have never worked with dlls.

Since I didn't even know that my dll was in the reference list, complete
with file location, this looks like something to explore.
If you were a little more into manners, I'd probably say thanks.

Since we're just exchanging info, and not out on a date, perhaps I could
continue the conversation with a couple of other questions?

1 - I got a copy of a colleague's references and when I compared the
references I found that my entry for tracker.dll (the one I'm creating) had
disappeared altogether. I had had it before, but I can't get it back.
I did a MAKE, which created a new *.dll file, but didn't result in an
entrance in the references list.
I refreshed all of the vb source - still wasn't there.
Tried to add it by hand via References/Browse (which I'm sure I had not
done before), but got "Name conflicts with existing project, module or
library."

Suggested next steps?

Note - Somewhere, I think in this thread, but maybe in a web article,
someone had said "the location of the file is not important - it's what's in
the registry that counts." Hence my confidence in registering the dll.
Just in case you're losing sleep over how someone could be so stupid as not
to check the location listed at the bottom of the references window (had
never noticed it before.)

2 - Since completely refreshing the VB code doesn't get everything back to
its original state, where else are things saved, apart from the registry
entry for the dll that results when I register it?

 

[Laurel]

Please ignore the message of 10:56 on Feb 5 - Except for this part, which
remains relevant.

"Yeah.... well.... that's why I came to the newsgroup. To get things solved
that are mysteries to me. As I said early on, I'm not a VB programmer and
have never worked with dlls."

It turns out that I was getting mixed up between forums. There's been an
ongoing confusion between VB and VBA, by me and by a colleague who's
advising me (remotely, and in another department, so sporadically). I was
writing the 10:56 response from the perspective of working in VB to create a
dll. Your comment about references, together with an earlier e-mail
exchange with him, where he showed me references from a .dot file (not
relevant to my problem) made me think my output dll had to ALSO be a
reference in my VBP project.... well, that shot a morning. Not your fault,
of course. I will now depart from this forum and confine miself to the VB
forum.

 

[Karl E. Peterson]

Yeah.... well.... that's why I came to the newsgroup. To get things solved
that are mysteries to me. As I said early on, I'm not a VB programmer and
have never worked with dlls.

Fair enough.

Since I didn't even know that my dll was in the reference list, complete
with file location, this looks like something to explore.
If you were a little more into manners, I'd probably say thanks.

Sorry if it comes across that way. No judgement implied, generally. Just trying to
be very straight-forward.

Since we're just exchanging info, and not out on a date, perhaps I could
continue the conversation with a couple of other questions?

Heh, by all means. I'll let you know if you step over the line. ;-)

1 - I got a copy of a colleague's references and when I compared the
references I found that my entry for tracker.dll (the one I'm creating) had
disappeared altogether. I had had it before, but I can't get it back.
I did a MAKE, which created a new *.dll file, but didn't result in an
entrance in the references list.
I refreshed all of the vb source - still wasn't there.

Right. Nothing automagic about it. That reference needed to be established
manually from the get go, *unless* the VBA code is using the DLL in a late-bound
manner. If there's not a reference to the DLL in the VBA project, it should simply
blow. Except in that *unless* case. How, exactly, is the VBA using the DLL?

Now, I just want to be entirely sure we're using the same meaning of "References"
here. In this case, I'm talking about the list that appears when you highlight a
project and select Tools-References from the menu.

Tried to add it by hand via References/Browse (which I'm sure I had not
done before), but got "Name conflicts with existing project, module or
library."

Suggested next steps?

This is Word we're talking about, right? I'd start a new project, add a reference
to your DLL, and start looking for conflicting names. Did you attempt to import
some of the (public) DLL modules into your VBA project, and forget to remove them?

Note - Somewhere, I think in this thread, but maybe in a web article,
someone had said "the location of the file is not important - it's what's in
the registry that counts."

That's true. The registry will point to the actual DLL file that's "registered."

Hence my confidence in registering the dll.
Just in case you're losing sleep over how someone could be so stupid as not
to check the location listed at the bottom of the references window (had
never noticed it before.)

Well, it's very possible to have multiple copies of the DLL on the disk, and think
one is registered when in fact another is. That's why that file location in the
References dialog serves as a good sanity check.

2 - Since completely refreshing the VB code doesn't get everything back to
its original state, where else are things saved, apart from the registry
entry for the dll that results when I register it?

I don't know what "completely refreshing the VB code" means?

But, the *important* point is, if the VBA project is missing a reference to the DLL,
it won't work.

 

[Karl E. Peterson]

Please ignore the message of 10:56 on Feb 5 - Except for this part, which
remains relevant.

"Yeah.... well.... that's why I came to the newsgroup. To get things solved
that are mysteries to me. As I said early on, I'm not a VB programmer and
have never worked with dlls."

It turns out that I was getting mixed up between forums. There's been an
ongoing confusion between VB and VBA, by me and by a colleague who's
advising me (remotely, and in another department, so sporadically). I was
writing the 10:56 response from the perspective of working in VB to create a
dll. Your comment about references, together with an earlier e-mail
exchange with him, where he showed me references from a .dot file (not
relevant to my problem) made me think my output dll had to ALSO be a
reference in my VBP project.... well, that shot a morning. Not your fault,
of course. I will now depart from this forum and confine miself to the VB
forum.

I think it's important for you to actually see something through to completion.
I've followed your threads in both places, and in neither case do you seem to ever
actually get to the bottom of what's going on. Lemme know if/when you're ready to
get to that point.

 

[Karl E. Peterson]

Please ignore the message of 10:56 on Feb 5 - Except for this part, which
remains relevant.

"Yeah.... well.... that's why I came to the newsgroup. To get things solved
that are mysteries to me. As I said early on, I'm not a VB programmer and
have never worked with dlls."

PS -- As I said in another message, "Words Matter!" The advice you've been getting
has consistently been on point. To be a programmer, VB or VBA or anything else, you
must be *precise* in your use of language. You'll probably find that a rude thing
for me to be saying. Hopefully, in time, you'll come around to appreciate how
simply true it is.