I'm writing a microsoft word macro and having difficulty with vb.net. Please help.
Check out the answers here - VB6 is almost identical to VBA.
You will need to add a reference to the Microsoft Scripting Runtime if you want to use FileSystemObject
Or you can just drop in the CDirDrill class which means you won't need any external references.
A Word Macro is usually written in VBA rather than VB.Net, I'm assuming that you meant VBA?
Use the FileSystemObject to access the filesystem and then use recursion to "walk" down. Here's a sample:
http://www.java2s.com/Code/VBA-Excel-Access-Word/File-Path/RecursiveSearchusingtheFileSystemObjectModel.htm
If it's actually VB.Net you're using, the idea will be the same but use System.IO.Directory rather than the FileSystemObject.
I personally like the FileSystemObject approach. i normally set up a recursive search function like the one found here and have never had any problems.
Related
I have a large project in VBA with lots of functionality that I would like to use in my program. When I run the program I get this
How can I make the prjGlobalPPT a part of VBAProject?
You need to refer to the project explicitly:
Application.Run prjGlobalPPT.ADV_UpdateChart
I found the solution. I had to include prjGloabalPPT by filling in the properties under Tools.
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.
In C#/.NET I am able to open a DOCX file as a ZipPackage, then manipulate its XML parts separately by getting them as PackageParts and reading from / writing to their Streams using .GetStream().
As far as I'm aware, VBA is a million miles away from having this functionality (especially given that I've not found anything about it after a lot of web searching), but I just thought I'd check: can any VBA aficionados confirm or deny whether VBA has some kind of built-in functionality for manipulating DOCX ZipPackages, or would you pretty much have to write your own VBA DOCX parser from scratch?
Mostly the answer is no, but there is a glimmmer of yes.
Regarding your specific question of managing PackageParts from their streams. You could probably do this with some kind of "unzip" utility and then knowing the OPC structure, navigate to whereever you want in the Parts and change things with XSLT or other XML manipulation technologies - but you wouldn't be able to do this on the ActiveDocumentbecause its stream is already in use by nature of it being open. You could use VBA to create a copy of it and manipulate that one in a really cumbersome manner and when your manipulation is done, have VBA close and delete the current ActiveDocument and open your manipulated one as the new ActiveDocument.
On the other hand, there is a way to manipulate WordprocessingML for the current ActiveDocument from VBA, but it would be incredibly difficult to do. Have an open document, select something and then to the VBE. Then run this:
Sub InjectXML()
Dim wd As Document: Set wd = ActiveDocument
Debug.Print wd.Range.WordOpenXML
End Sub
You'll see all the WordprocessingML spit out in the immediate window. This is actually "Flat OPC WordprocessingML" as it is all maintained in a single string of XML. By using ActiveDocument.Range.InsertXML, you could technically insert Flat OPC-type of WordprocessingML back into the document at the selected location. Here's an example of someone using C# to do this via interop and Linq-to-XML. To do this in VBA would be incredibly hard.
So again, the answer is mostly "no", but a little bit of "yes".
You do not state your ultimate aim, but I guess one possibility is to use Microsoft.office.interop.word to manipulate the word document.
I am trying to programmatically make a PowerPoint presentation from the contents of a Lotus Notes document. This is relatively straight-forward using CreateObject("Powerpoint.Application") but I fail to find a way to access the various constants that are used in VBA.
One solution is of course to hard-code the (ten or so) values into my script, but for obvious reasons I'm a bit uneasy about that solution.
Is there a way to lookup the value of for example msoTrue or ppLayoutText with LotusScript? For example a way to query the Powerpoint.Application object for the values?
(In more compentet languages adding various Interop libraries seems to do the trick, but I haven't found a way to do that in LotusScript.)
Edit
I prefer a solution that will work without any extra installation of software or dlls, apart from Office.
You can have your code lookup these MS constants by creating an OLE object of type "TLI.TLIApplication" object (defined in tlbinf32.dll), and then querying that object for all of the office VBA constants. There is an MSDN article describing this technique in general here:
http://msdn.microsoft.com/en-us/magazine/bb985086.aspx
There is also sample code for exactly this procedure in a LotusScript environment here:
http://noteslog.com/post/ole-constants/
Note that this is a runtime-only technique. This inspection method will make all of the constants available to your code, but will not make the constants available through Intellisense in the Domino script editor.
This is what I use for MS Office constants: Microsoft Constants Database. There is a script library that has recently been added for Word and Excel.
I am maintaining an old VB6 application, and would like to include SQL scripts directly in part of the project. The VB6 application should then extract the text of this script and execute it on the server.
The reasons for this approach are various - among others, we want to deliver only an updated executable rather than a complete update/installation package. Hence, the SQL scripts need to be compiled into the application just like a resource file. And, obviously, one has to be able to get at the content from code, in order to send it to the database server.
Does anyone have a good way to do this?
The simplest solution is to just create a VB module with the scripts as strings.
If you want to use a resource file instead, you can do that too. You can associate a resfile with a VB project (I don't remember how to do this directly in the VB IDE but the VBP file supports a ResFile32 parameter).
EDIT: It seems like the issue here is mostly about formatting -- you don't want to store SQL queries as one long string, but formatting the query nicely inside VB is tedious because you have to add quotes, add string concatenation operators to join the lines together, etc.
I would recommend placing the SQL in a text file and formatting it in whatever way you like. Write a script that will take the text and convert it into a VB module. The build process would be modified to always apply this script first before compiling the application.
For scripting, use your favorite scripting language; if you don't have a favorite scripting language, this is an easy enough task that you could do it in VB, C#, or any other language. If it were me, I'd probably use awk (gawk) or Python.
If you want to use a resource (.RES) to store your SQL, go to the menu:
Add-ins > Add-in Manager...
and select VB 6 Resource Editor. Configure the add-in to be loaded and to load at startup.
From the editor add-in, VB provides a simple interface to add resource strings. You will refer to these using the provided constant values. To load the strings at runtime, use the LoadResString function:
Public Const SQL_INSERT As Integer = 101
Dim strSQL As String
strSQL = LoadResString(SQL_INSERT)
(replace "101" with the constant value of the string you wish to load)
Just another thought on your approach. Because I find myself tweaking the program's behavior or UI for customers I might be in the middle of a change that either is not ready or has not yet been tested and approved. So if I have properties that change from time to time, but I want to maintain control of, for instance connection settings to our ftp server, I will create a resource only dll exposing my properties and use a resource file in the dll to supply the values. When my network manager changes something on the ftp server I change the strings in the resource maanger, recompile the dll and release just the updated dll. I'm sure there are many more solutions, but that is how I do it. If you don't think you might have to change your SQL scripts at the same time you are changing you exe this probably only complicates your work. It has worked well enough for me that now this is pretty much standard for me.