Re: Getting at VBA

Laurel wrote:
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.

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.

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.
--
..NET: It's About Trust!
http://vfred.mvps.org


.

Relevant Pages

  • Re: HowTo: Unregister a DLL/Control when the File no longer Exists
    ... "registry bloat" by not cleaning the registry properly over a period ... The main project references one of the DLLs, ... another DLL. ... MyProject still exists, but now there is one alongside it called ...
    (microsoft.public.vb.general.discussion)
  • Re: Excel References
    ... registers the DLL properly on the user's machine then there shouldn't be any ... I re-establish the References, XL runs fine. ... "Joe" wrote in message ... Click OK and the VBE will register the DLL ...
    (microsoft.public.excel.programming)
  • Re: HowTo: Unregister a DLL/Control when the File no longer Exists
    ... Tony Proctor wrote: ... recorded in the registry. ... However, matching them up without the original DLL ... The main project references one of the DLLs, ...
    (microsoft.public.vb.general.discussion)
  • Re: Excel References
    ... <<If I have the References dialog open, I can't get to the Browser (as ... Click OK and the VBE will register the DLL and add it to ... the Browser lists it in the dropdown of available ...
    (microsoft.public.excel.programming)
  • Re: HowTo: Unregister a DLL/Control when the File no longer Exists
    ... projects, in the correct order, and deals with this exact situation Karl ... "registry bloat" by not cleaning the registry properly over a period ... The main project references one of the DLLs, ... another DLL. ...
    (microsoft.public.vb.general.discussion)
Loading