I'm new to .NET from an extensive VBA background. I'm building an Excel add-in and have been struggling to find any guidance on line about control of code structure and layout in visual studio.
Comparing to the VBA environment, what I want to do is have different modules for the different components (e.g. one module with all the calculation subs, one module with all the formatting subs, one module with all the custom charting subs, etc.) but cannot find any guidance on how to set this up.
I've put the skeleton of the ribbon tab in, with some icons etc. and VS has automatically created tabs as follows:
Ribbon1.Designer.vb, which appears to house setup code - adding groups and buttons etc.
Ribbon1.vb, which now contains a few subs I've written in 'Public Class Ribbon 1'. This is the bit I want to "modularise".
I have tried creating another public class which didn't work, and a few other things. I also saw mention of "sub classes" though could not find any instructions/examples and couldn't get this going myself (or if I need to specify inheritance from one to another?).
From a user friendliness perspective for me, one tab in VS per category of subs would be the ideal but I'm amateur so definitely open to learning how to structure it all properly. Yes, I wish I had software engineering training!
Screenshot
Related
Hello thanks for reading my question, I've build a user form with controls to control equipment via RS232 and USB. I've also added a separate class module "class.vb" to hold miscellaneous functions like writing to an ini file.
When I'm in the code section of the Form.vb and I type txb for text boxes that I have in the form visual studio pops up a nice list of all things in the form that start with txb.
However, when I do the same thing in my class.vb it does not do this and even if I type the whole thing such as txbModulation and then add the dot after it does not come up with the list of properties.
Does the class.vb have access to Form1.vb controls?
When I'm in the code section of the Form.vb and I type txb for text
boxes that I have in the form visual studio pops up a nice list of all
things in the form that start with txb.
This is because when you start typing a variable name, Visual Studio starts looking for a match. It looks in block scope first (a for or while loop maybe), then at local (function/sub) scope, and finally at class level (a form is a class). It will also look for any matches in Modules if you have them. See Scope in Visual Basic for more info.
Since the Form and your INI Class are different, they cannot see each other unless you pass references or somehow pass values via parameters to subs/functions.
I've got a dozen macros that have 90% similar code. I've created 4 sets of VBA in an add-in file so that I don't have to revise a dozen different places any time a change needs to be made. The plan is to end up with:
specific code
universal code A
specific code
universal code B
The users are not particularly tech-savvy so I want to make the distribution as painless and idiot-proof as possible.
Also, the add-ins don't have to be visible--no one is going to run them on their own, they're just going to be embedded and called upon from other macros.
I've looked around online and the closest thing I've found is this How to combine multiple VBA macros into one add-in file for Excel
It still looks like this is geared more towards having multiple buttons, which I really don't need (or want...I don't actually want ANY buttons)
Not really sure what kind of code I could show to help with this problem, since I don't know if this is even possible to do.
Once you save the XLAM file you just have to click on Excel Add-ins under the Developer tab, browse to the folder where it is stored, and open. It will then appear as an add-in package that you can click on.
Maybe a noobish question, but here it goes:
My goal is to install an Excel Add-in.
I have all the code in a Module, organized in several Sub()s. I saved the Add-in in the Excel Add-ins folder. When trying to add the Add-in as a button/custom menu
(File/Options/Customize Ribbon/Macros), I see all Sub()s listed.
Is there a way to hide some of the Sub()s from being listed ? I only need the main one; displaying all of them becomes confusing when using multiple add-ins, especially since most of the Sub()cannot run be run by themselves. Are there any good practices for organizing the code in order to prevent this ?
If you write Option Private Module on top and you make the subroutines private, they would not be visible.
See more here for Option Private Module.
I am writing an addin to Office (both 2007 and 2010), and have so far used the Fluent Ribbon XML to customize the different ribbons.
The problem I am having now with that approach, is that I want to have a bit more flexibility in my code, and have different modules add more buttons to the ribbon, without hard coding them in XML - The addin is composed of several disconnected modules, and it doesn't "know" exactly what ribbon elements it might need.
Is there a way to do it? I bumped into the LoadCustomUI method on the Application object, but it is not available in C#. Looks like just what I might have used for my scenario.
For .NET 4 (which I assume you're using because of targetting Office 2010), you'll override CreateRibbonExtensibilityObject. More info can be found on this page: Ribbon Object Model. This is also a good read: Updating the Controls on a Ribbon at Run Time.
How to programmatically get at outlook form code?
To clarify from one of the comments - Outlook form code is the VBA code that sits behind the form - it can be customised in the form design mode to do pretty much what the user needs to do.
Our product relies heavily on form code, but certain bits of it need to be customised per installation. We are looking for some way to automate this process, as we have upwards of 30 custom forms it is a tedious process to do it manually...:-)
Use a configuration file (use ReadFile etc)
Or put the configuration information in a "special" item in a public shared folder
You can also use the "Office Profile Wizard" to package it up with a custom vba module iwht the configuration information in that
You should never write out customised code, that is a big can of worms