I am maintaining a large MS Access Project. Over time the number of modules and classes has grown, at this moment it contains 90 modules. More and more time do I spend searching for a specific class in the list. (I know about Shift+F2 :))
Is there any way to organize the list of modules in the VBA editor, i.e. some kind of Addin? My idea would be subfolders in the tree or a filter-as-you-type textbox.
Best regards,
Torben
First of all try: MZ-Tools. It has free version for MS Access. HomePage
It's a toolkit that help maintain access project in many aspects: create automatic documentation; create, modify and maintain procedures, functions and properties etc.
Develop a logical naming system. You can't get a tree per-se, but you can name things in a way that they are easier to find.
Module 1: A_systemtools
module 2: __systemtools_a
module 3: B_programitems
etc...
Related
It's taking more than 15 minutes to search for Library entry.can anybody suggest how i can remove slowness of the application?
Below image
Big PBLs mean slow searches. Segregate your objects. Many people separate by object type. If you are in a hurry then this will work in a pinch. I work with huge applications. I organize PBLs by application function. This can also improve your compile time.
Back up your PBLs then optimize them. In the library painter (shift-F10) right click on the PBL and choose Optimize.
Our application has libraries that never change like the PowerBuilder Foundation Class PBLs. You can build runtime libraries (PBD) for them, then in your library list, change .PBL to .PBD. If you need to change an object in one of your "static" libraries, just change .PBD back to .PBL in your library list.
I export my objects to a folder and use my favorite text search tool. Windows search will also work on exported objects. I can search 7200 objects in less than 15 seconds.
Export all source file and search them by a modern text editor.
Like vscode or notepad++
I'm a complete VBA newbie, having decided to teach myself over a weekend, so forgive the stupid question(s). I'm trying to automate some routine tasks involving generating Word documents or emails from an Excel Spreadsheet. Because there will be multiple software versions involved, I am using late binding to open Word and Outlook. My question is: Where can I find a simple reference telling me what the index numbers are that correspond to the application constants? I have killed a lot of time googling to learn that, for example, the Outlook foldertype for "Contacts" is "10". Maybe someone knows of a web link that could save me countless hours of searching?
Update: http://msdn.microsoft.com/en-us/library/office/gg278936%28v=office.14%29.aspx seems to have some of the information I need, although it's not always intuitive where the information is. For example, if it contains the outlook folder type constants, I haven't found them yet.
See here
Enumeration http://msdn.microsoft.com/en-us/library/office/ff860961(v=office.15).aspx
OlDefaultFolders Enumeration http://msdn.microsoft.com/en-us/library/office/ff861868(v=office.15).aspx
I would recommend to add the relevant object libraries to your project as References during development time. You do this by using the Tools - References Menu in the VBA Editor. This makes developing a lot easier as you can use intellisense while writing the code.
If you need only a few Enums or single Constants in your code the easiest way to get their values is to hit [F2] in in VBA Editor while the object libraries are still referenced. Then search for the constants name and copy its value to your code.
Just using the numeric values of the constants in your code makes the code pretty hard to read. So I would recommend to re-declare all the Enums/Constants you actually use in a module in your own project. That massively improves the readability of your code.
So, instead of just copying the value from the VBA Object Browser, I suggest you copy the name and the value and put it your own code as a constant declaration. For your example of the Outlook contacts folder this will look like this:
Public Const olFolderContacts = 10
You can then use the constant in your procedures as you would do with Early Binding.
Should you work on a larger automation project using many of the constants from any one of the Office Object Libraries, you can download ready-made VBA modules containing all the Office constants from my website. You can then just import the relevant modules into your project and are ready to go.
After you finished the main development work, you remove the linked libraries from your project and declare the relevant object variables As Object instead of the actual type.
Always remember to compile your project not to miss any declaration that does not work late binding.
I develop quite complex Excel VBA application (several thousands lines of code spread across modules, class modules and form modules). There is a need to translate it to multiple languages, which means to replace (almost) all of the strings in application and use some kind of hash-table with records for each language.
My question is what is the most efficient and convenient way to gather all strings used in application and replace them with some kind of language variables. Could anybody recommend some kind of best practices for this type of task for VBA project environment? Thanks in advance.
One option is to use source tools addin to export all your code into source files under one folder. Example below:
Now you can write scripts to modify the files, and also now you can put them in source control. When done you can re-import them into the VBA project with changes.
I'm investigating how to implement use case extension points in DOORS requirements. To this end, I wanted to know if a DOORS object in one module can reference or link to a DOORS object in a second module. If so, I figure I can have my use cases with the extension points in a high level module, then I can have extension variations in a separate DOORS module, with each one referencing the DOORS object with the extension point it is instantiating. Any thoughts on that?
You can definitely link an object in one DOORS module to another. That's one of the main features of DOORS so that you can track your requirements between modules. For example systems level statement of work type documents may be your initial source of requirements, kept in a high level module, and then that can be linked bidirectionally with finer grained software requirements, and then can be further linked to software components or lines of code or test cases.
If you right click a requirement you should see the "Link" option I believe it's called. I think you need to have both modules open, or it at least makes it easier.
You can only link from one object to another. The objects can be in different modules.
Sometimes we wanted to link to a whole module. We created a first "title" object in the module we wanted to link to, and we linked to that.
DOORS is really dismal. Glad we ditched it.
I've inherited a collection of largely undocumented ssis packages. The entry point package (ie: the one that forks off in a variety of directions to call other packages) defines a number of variables. I would like to know how these variables are being used, but there doesn't seem to be an equivalent of "right click/Find All References"
Is there a reliable way to determine where these variables are being used?
A hackish way would be to open the dtsx file in a text editor/xml viewer and search for the variable name.
If it's being used in expressions, it should show it and you can trace the xml tree back up until you find the object it's being used on.
You can use the bids helper add-in thats gives you visual feedback on where variables are used in your package. Thats makes it very fast and easy to detect them.Besides that, it offers several other valueable features.
Check out: http://bidshelper.codeplex.com/