So.. ODE menus light up in Office x64, and VBA7 code compiles in a Standalone project... Make doesn't quite work, because I need a public createable component, which I think I need to register the ActiveX designers for. So a little more work to get all the OCXs installed... but it's looking... possible.
Oh wait, I can't use 32-bit OCXs in 64-bit Office (duh). Might need to find \ build a 64-bit OCX?
Not sure - the original ODE is set up to make COM add-ins, and has the Add-in designer from VB6. It also lets you start with an Empty project, but not sure what the idea is there as you can't set public creatable on classes in VBA VBE
trying to find that DLL - I'm saying that RD can work in 64-bit even though it has the same dependency (IDTExtensibility2 comes from that DLL, but RD uses Extensibility.dll, provided by .NET, not the MSADDNDR.DLL)
> There are 5 steps you could take after which you could repost your code here.
Use 'Option Explicit' in each module and address the errors that this will show.
If you are able, install the RubberDuck addin. Use the 'RubberDuck' addin to do a code inspection and then address all the issues you find.
Thank you so much! I'd never heard of RubberDuckVBA, what a great tool. I did my best to follow your advice. I'm now using 'Option Explicit' and declared the variables I'd missed, did a code inspection and resolved all the errors/warnings, and did my best to use more descriptive variable names. There were a few places where I was unsure how to best replace the Hungarian Notation with more meaningful variable names such as with oRng, as I don't know that I completely understand it's usage. I've edited the post with the revised code if you have any additional suggestions. — AbernaughtyMar 10 at 4:23
so it's really trying to make this DLL. I can see the status box say "writing DLL", then a dialog pops up saying "could not execute Link.exe". I think that's the MSVC linker, so perhaps I just need the 64-bit version.
@rubberduckvba @ThunderXFrame He was a very good friend of mine. I will miss him greatly. I think he would be very pleased with this way of remembering him.
Having provided so much comment I thought it was only fair to post what my version of your code would be. There is a deliberate error in the code. I wonder what your thoughts are on how easy it is to spot? I also can't guarantee that the code will work as intended(although it does compile) as ...
@SimonForsberg shaking of the head would be a "No" then? Let's set @MathieuGuindon a real challenge, and get him to reproduce the Diamond Problem in VBA.... Now that would be a feat.
Dump of file C:\my\Shared\Project1.OBJ
File Type: COFF OBJECT
FILE HEADER VALUES
14C machine (x86)
D number of sections
5C8B91F7 time date stamp Fri Mar 15 11:52:23 2019
4C9C file pointer to symbol table
C5 number of symbols
0 size of optional header
0 characteristics
@mansellan I wonder if it might be trying to linking another obj file that's used to initialize the DLL. Do you know what command the link.exe is given?
In my case, I just wanna to have VBA code housed in a DLL, independent of the host file format.
For example, you cannot write VBA code in say, an Access file and then reference it from Excel VBA project
all hosts allow referencing only to their own file formats, which is pretty dumb if you ask me.
The other good reason to have a DLL is that it also means you can safely strip out the source code and thus get all the functionalities of an ACCDE just for your VBA code.
In theory though, you shouldn't need to do anything other than figure out the linker command at this point. I can't imagine it would give you a partial obj set.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4857?src=pr&el=h1) Report > Merging [#4857](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4857?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/189aa1ce552c0805e3591971c4389c494d02a92d?src=pr&el=desc) will **decrease** coverage by `<.01%`. > The diff coverage is `n/a`.
So, first, it was an urgent request "oh hey, we want deletion after all". (I as a dev had pointed out they missed deletion, and they were all "yeah, I know, we don't want it".
I'm imagining that it's injecting in a static module for initializing the DLL in VBA runtime or whatever. If that isn't updated or whatever, it might fail.
Then, when discussing the details of it, we now have to A) allow them to add items in additional cases, and B) track when the items were added for those cases so we can remove newly added items before we save, but not the already-saved items.
I'm just going to go with a hack work-around of a list of newly added items that can be deleted, instead of properly adding tracking state to the item (it's a list of strings).
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4857?src=pr&el=h1) Report > Merging [#4857](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4857?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/189aa1ce552c0805e3591971c4389c494d02a92d?src=pr&el=desc) will **decrease** coverage by `<.01%`. > The diff coverage is `n/a`.
I'd assume that anything that was generated by the build process that needed to be linked would output an obj file - if it didn't, the assumption would be that it would be dynamically linked.
If it's built into the obj file, it is by definition linkable at that point.
TBH, I'd be surprised if there was any static linking going on - that would make for a fairly brittle tool.
True, but if the build didn't output the obj file that it was going to be statically linked to, there would have to be an object cache somewhere that would need to be updated every time the compiler changed.
Or any of the linked resources. It would be a deployment nightmare.
I know very little about the C/C++ build process, TBH. Only enough that it's very fussy and as you said, possible to do boneheaded things like linking 32-bit obj file using a 64-bit linker
Eh, it's not so bad now that I figured an easier way of handling it.
For a bit, I thought I had a couple of hours of work ahead.
A couple hours of bug-prone, time-pressed work, that is.
I don't mind a couple hours of work as long as it A) isn't more likely to break other parts of the system than not and B) the deadline is sufficiently far out that I can take my time about it.
@Comintern Acquaintance I know told me he had a harder time firing people than having them realize they weren't suited for the job.
> You know you've been struggling a bit... If you just stopped showing up for work there wouldn't be any hard feelings. You'd do better with another company where you could succeed faster.
No wonder companies take forever to hire someone if it's that hard to no longer employ them.
> Version 2.4.0.4586 OS: Microsoft Windows NT 10.0.17134.0, x64 Host Product: Microsoft Office x86 Host Version: 16.0.11328.20146 Host Executable: EXCEL.EXE
When I open the VBE either using Alt-F11 or from the developer tab I get the RD loading logo then this is how the VBE looks: 
Attempting to resize the window causes Excel to lock up.
> > > > @SmileyFtW thanks! as @bclothier noted, this does reinforce the impression that class/module templates are a better idea though... what do you typically use MZ-Tools snippets for?
Before RD I used MZTools to hold all my bad habits... I have moved away from MZT in favor of RD. Henceforth, I will look into module templates to hold my newly acquired better (RD) habits...
> By "lock up", do you mean go into a non-responsive state? Also, to be clear - Excel is locking up, not just the VBE, right?
I also notice that you have MZ-Tools installed. Can you reproduce this with MZ-Tools disabled? How about with RD disabled and MZ-Tools enabled? If you have any other add-ins installed, I'd test them independently also.
If you could get a trace level log of this and post it here, that would be awesome.
> Interesting. I've had this weirdly-sized VBE occur to me (Excel 2016 x64), without MZ-Tools. I've mentally blamed in on Excel 2016, since RD doesn't do anything about the IDE window size.
Maximizing the IDE mainwindow worked fine though (didn't try resizing manually).
With my prototype, I'm going to insist that people build their changes DB-first (consulting DBAs as necessary), force-generate the model from the DB, and then create a migration to make easy to update all the other databases automatically when we run the CD pipeline.
When you are running single-tenancy for a dozen clients or more, you need to do the updates automatically.
and it's supposed to make it easy to propagate changes to a DB. Without all silly abstractions getting in the way like that one two letter framework that shalt remain unnamed.
Having provided so much comment I thought it was only fair to post what my version of your code would be. There is a deliberate error in the code. I wonder what your thoughts are on how easy it is to spot? I also can't guarantee that the code will work as intended(although it does compile) as ...
VBA Rubberducking
VBA Rubberducking