I am trying to create smartart org charts using excel 2007 vba.
I tried to first record the macro to see what objects are involved but with no luck. Nothing was recorded. There are some examples online of smart art and vba in excel 2010 but nothing for excel 2007. Does it mean that smart art is not accessible using vba in excel 2007? Is there maybe some workaround?
It is possible, but is not a simple task.
Read more on
http://msdn.microsoft.com/en-us/library/office/gg583880(v=office.14).aspx
You need manipulate a XML part of file to create new options of SmartArts.
For me, very big work to very small results...
Related
I recently wrote a form in VBA for Outlook and saved it to my personal form folder.
Now this form should get exported in a userfriendly fashion. What is the best practise here?
I know that you can go to File -> Export file... in VBA, but this seems to have caused some problems in the past and doesn't seem very intuitive to use both the frm and the frx files.
The form is supposed to be accessed by employees to book their holiday.
That is COM add-ins were invented for. They are designed to be installed on multiple machines and users. VBA macros are not designed for transferring the code - the infrastructure doesn't provide anything for moving solutions automatically like you could do in case of COM add-ins. You need have do that manually in VBA.
If you consider moving your solution to the add-in rails, see Walkthrough: Create your first VSTO Add-in for Outlook to get started quickly. You may choose VB.NET which has a similar syntax with VBA.
Is it possible to write VB.NET code to be used in an Excel spreadsheet without using Visual Studio? In other words, is there a built-in VB.NET editor for Excel that can be easily accessed like the built-in VBA editor? Or can I coerce the built-in VBA editor to allow me to write VB.NET code?
If the answer is no, do you know why Microsoft has not implemented this in Excel? It seems the ease of accessing the VBA editor is one of the reasons people still write new VBA code today. If Microsoft wants to be rid of VBA then why not make VB.NET more accessible in Excel? I'm not interested in speculation but instead any official word from Microsoft.
Some direct answers to the direct questions:
is there a built-in VB.NET editor for Excel that can be easily accessed like the built-in VBA editor?
Answer: No
Or can I coerce the built-in VBA editor to allow me to write VB.NET code?
Answer: No
If the answer is no, do you know why Microsoft has not implemented this in Excel?
Answer: since I'm not a Microsoft insider, No (but I could speculate...)
There are, of course, a variety of non-built in ways to interact with Excel. But I'm sure you already know that.
That's kind of a silly question. The internal language for MS Excel currently happens to be VBA. And frankly. VBA is pretty darn close to both VB6 as well as VB.Net, IMHO. Certainly the two are more similar than, say C++, Java, Perl or any of a million other languages.
So why isn't doesn't Excel use VB.Net (or, for that matter, C#)? Because Excel doesn't come with its own .Net runtime, and doesn't require you to have a .Net runtime to use it.
So why can't use use VB.Net (or C#) with Excep? If course you can use them with Excel. You can write a VB.Net program that reads and writes Excel spreadsheets, that invokes Excel functionality, that uses Excel as a datasource, etc etc etc.
So what more could you ask for ;)?
I'm currently working on an vba project to help document developers do their work better and faster.
The tool is helpful during the developing, but however, it's no longer needed after the document is complete.
So, is there any ideas, about how to export a pure document without vba code automatically? Or shall I do this stupidly by opening vba and remove all of its code?
Further more, Is there any ways, to automatically apply vba code to an existing document?
You can create an add-in. Your VBA code lives in the add-in, but operates on your documents. The add-in can create a custom menu to run your various routines.
Here is a question for my Father. He has been using VBA in Excel for more than two decades going from Excel 5 to this day where he is using Excel 2002.
As he has used VBA in Excel for so long, making extensive use of the ability to record macros, he has continued to invest in Excel as it has been rather stable (in terms of its VBA functionality) across each version. Now, he is considering upgrading to a newer version of Excel, however I have read reviews that Microsoft completely botched their VBA interpreter in Excel 2007, as scripts that used to work in Excel 2003 or earlier would become painfully slow or stop functioning altogether. Then looking into Excel 2010, I've read that a lot of the issues with Excel 2007 "haven't been fixed". As I am not sure as to the credibility of these reviews, which I have read I am posing this question For all those folks out that are currently making heavy use of VBA in Excel:
Would it be advisable for someone who has a great deal of time and work invested in VBA from Excel 2002 or earlier to upgrade to either Excel 2003, 2007 or 2010?
There were several performance issues with Excel 2007 VBA. Many of these were fixed in Excel 2007 SP1. There were also a number of macro recorder problems with Charts and Shapes.
My personal recommendation would be Excel 2010: the VBA performance and Macro recorder issues have been fixed and I find the overall stability of Excel 2010 to be superior to most recent versions (but YMMV).
Migrating from Excel 2002 to 2007 or 2010 will involve learning to use the ribbon: some people like it and some people hate it, but it certainly will require effort for a long-term Excel user. Note that the VBA IDE has not changed.
If your father survived the migration to Excel 97, the switch to 2007 or 2010 will feel like a cakewalk. Other than the new GUI, the changes are of the more-better variety. I haven't run into any compatibility issues including the big jump from 97 to 2003.
To get up to date, I'd recommend John Green et al's Excel 2007 VBA Programmer's reference.
Most of the VBA/Excel programs that I developed in Excel 2003 work just fine in 2007 and newer without modification (It seems like I remember most issues being chart related). Of course it's possible that at least some of his recorded macros or hand coded VBA will not work in Excel 2007 and newer. However with a little debugging the old code can likely be converted without too much headache (search the line that errors and you will likely find out how to rewrite the line).
There are free add-ins such as UBitMenu and others to bring back the old style menu menu.
I wrote a benchmark for Excel VBA earlier this year that contains 6 different performance tests. The results submitted by 373 people so far clearly show that excel 2007 is the slowest of all versions. Among Excel 2003, 2007, 2003, 2002, Excel 2010 performs best on most tests followed by Excel 2003. Between 2010 and 2003 the composite results are fairly close, but the individual benchmark tests show that Excel 2003 is much faster at displaying data on a chart while 2010 is faster with complex VBA based calculations. The complete results from the benchmark are located at http://exceltrader.net/et2/benchMark.php.
I have a series of big excel files that work like a program, but I hate beeing tied up (stuck in VBA for excel 2003), so...
Whats the best way to implement a gui over a excel vba program (office 2003)? (are there any tools for that... I want to move away from the office suite, but still have it in the background)
Or what's the easiest alternative for migrating this code to a more open language.
Any ideias?
Have you looked at VSTO?
Resolver One is a Python spreadsheet system with strong support for importing from MS Excel. It's often used for the situation you describe.