Fixed the bugs we did. Better we made it. =;)-
It’s been a crazy day. I found out that we have users on the other side of the globe, Rubberduck doesn’t work in 64 bit versions of Office, and JetBrains gave us a free Open Source license of ReSharper. Oh… And I worked a full day putting out fires at the office. Some times things get surreal.
I just wanted to share this with everyone and let you know what’s coming down the pipe for the blog. I still owe you a look at what we’re planning for the next minor release of Rubberduck (Hint: it includes support for Office 64x…). I also want to do a small series about VBA attributes over the next few weeks. They’re very cool and under utilized in my opinion. That’s probably because there is next to no documentation available. So, I’m going to pick one or two to talk about at a time and document what I happen to know about them.
I came across a post on Programmer’s Stack Exchange yesterday that really irked me. It took me a little while to really digest what upset me about it, but I think I understand now. This developer was asking for more reasons to back up his claim that he should move his solution from VBA to C#. That in itself is fine. As I stated in my response, I understand his desire to move his solution to C#. I wish I could move all of my projects to the .Net platform myself.
No. Wanting to move to a more modern technology was not my issue with his question. My problem was with how he acted like working in an old technology gave him a pass on being a professional.
Version 1.2 of Rubberduck has arrived. I’ll follow up soon with some thoughts about it and where we’re heading next.
Originally posted on Rubberduck News:
I’m really excited to announce this, so I’ll get to the point…
The most visible change is all of the new Code Inspections. There were only a handful of them in Version 1.1, but now Rubberduck is finding all kinds of issues with VBA code. Everything from obsolete syntax to unused variables. It’s really very cool.
The other very visible change is the addition of an Extract Method refactoring tool. Highlight some code, and extract it into its own method. Awesome. This one is very much like the static code analysis was in the last version, just a glimpse at the great things to come.
There were also a lot of improvements under the hood. We entirely swapped out the parser that allows us to do much of what we’ve done. Along with that, we’ve fixed a verifiable crap ton of bugs and UX problems. I’m…
View original 28 more words
Originally posted on Rubberduck News:
Rubberduck has had a decent unit testing feature since 1.0. Version 1.1 introduced a concept of code inspections – a proof of concept really, a sketch of a vision of what we wanted Rubberduck to do with the VBA code in the IDE.
Upcoming version 1.2 has undergone massive changes in the parsing strategy – going from a home-made regex-based solution to a full-blown ANTLR [slightly modified] Visual Basic 6.0 grammar generating a lexer and parser. As a result, code inspection capabilities have gone exactly where we envisioned them from the start.
Here’s what version 1.2 can find in your VBA code (in alphabetical order):
- Implicit ByRef parameter
- Implicit Variant return type (function/property get)
- Multiple declarations in single instruction
- Function return value not assigned
- Obsolete Call statement
- Obsolete Rem statement
- Obsolete Global declaration
- Obsolete Let statement
- Obsolete type hint
- Option Base 1 is potentially confusing
- Option Explicit is not specified
- Parameter can be…
View original 208 more words
I’ve been fairly absent from this blog lately. I’ve been busy working on a new release of Rubberduck and, honestly, there are only so many hours in a day. More importantly, there are only so many concentrated thoughts to go around in 24 hours. So, I apologize for being gone for so long. I hope you can forgive me when you see the results. I’m really excited about our next release. There’s some really awesome things in there. You can download the pre-release now if you’re interested. There are a few kinks to work out, but things should be stable very soon.
To be truthful though, that project is the last thing I want to talk about right now. Rubberduck has become an obsession. There have been so many early mornings and late nights that I can’t possibly count them. There will be more. Many more. We’re only getting warmed up… and I’m going to talk about it anyway. It is an obsession after all. Like any addict, I just can’t let it go.
I’m taking a quick time out from getting Version 1.2 of Rubberduck ready to talk a little bit about working with COM Add-Ins and Installshield’s installer builder. (Awkward phrase, I know.) First, let me say that I’m not impressed with InstallShield LE, not even a little bit. As awkward as that phrase was, this tool is so much worse. Granted, it could be that it’s a great tool and I’ve just not tried the alternatives yet… but I doubt it. Something out there has to be better. When I find it, I’ll let you know.
I’ve digressed though. I’m here for a reason. I fight with this setting in the installer each and every time I build a new version. Enough is enough. This is my documentation. You see, I spent a few days creating a new installer. The installer would build without error and install without error, only for me to receive a
Could not load the add-in.
message upon opening the VBA IDE. It’s incredibly frustrating, but here’s how to do it right.
When creating an add-in for the VBA Editor, or any MS Office application really, you have to register the assembly for COM Interop. Most of the blogs and tutorials out there show you how to do this with Regasm or Visual Studio. That’s fine for development, but if you want any one else to ever actually use your software, you’ll probably need to create an MSI package and/or a Setup.exe. That program will need to register the assembly on the target machine.
Go to the Project Assistant, and then to the Application Files screen. You’ll need to take a couple of Actions here to properly create the installer. Obviously, you’ll need to add the Primary Output. What’s not so obvious is that you’ll also need to manually link the
*.tlb file by selecting installation folder, then the Add File button, and pointing to the file in your
The second not so obvious (and most frustrating) thing is you’ll need to set the properties on the assembly correctly. So, right click on the Primary Output, and select Properties. In the dialog, go to the COM & .Net Settings tab. Once you’re there, use the settings below.
You’ll need to do the same for the *.tlb file, only don’t check the COM Interop box this time.
Now when you build the Assembly & Installer and then install, your COM Add-in will properly load. There’s a little more to getting your installer perfectly right than that, but I’m short on time and that hidden property is what tripped me up for the last few days. So, hopefully I’ve saved some one some pain. Even if that someone is me a month from now.
Until next time, Happy Coding.