• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

Feedback on VBA Forms for Microsoft

Joined
6/19/09
Messages
3
Points
11
Dear Quantnet Members,

I am a PM at the VBA/Excel team at Microsoft and am here again to get the feedback from avid VBA/Excel users. We are conducting research in the area of improving the VBA forms experience in future version of Excel. For this, we request Quantnet members to share scenarios they use forms in VBA. In addition, please also share your experience with the forms, things you would like to see changed and/or added.

I would like to inform that we appreciate you sharing sources and solutions, they could be used by Microsoft for internal research and presentation. It will however NOT be shared with any outside companies. So please rest assured for your IP.

My team and Microsoft appreciate your feedback and are always open to hear your thoughts. I believe this is a great forum to bring together the Quant Community and I look forward to meeting some of you in the near future.

Thank you.
Sincerely,
Riyaz Habibbhai
Program Manager
Microsoft
 
I agree. That is what we are looking into as well. However, to research the best technology solution for VBA users, we need to collect information about some scenarios that people use VBA forms. For example:

1. We have seen some people not use VBA forms at all and treat Excel as a UI in itself. To these VBA users, it doesn't matter what forms solution is used in the future.
2. There is another group of people who rely heavily on VBA forms to capture user input and wire it up with VBA in the background. To these users, the future form solution needs to be at parity and equally robust.

For our research, we want to collect as many different examples as we can to be able to provide a good comparision between various Microsoft technologies.
 
VBA is a good tool. Its ubiquitous adoption in many areas is a good evidence. One often-heard complaint against VBA is its support for code maintenance, i.e.. version control, which is a headache in a team development environment.

There are also some minor technical issues. For example, after stopping the debugger in the middle of code execution, object references will be reset/lost. But I think these are relatively much less significant than the version control issue.
 
1. We have seen some people not use VBA forms at all and treat Excel as a UI in itself. To these VBA users, it doesn't matter what forms solution is used in the future.
2. There is another group of people who rely heavily on VBA forms to capture user input and wire it up with VBA in the background. To these users, the future form solution needs to be at parity and equally robust.

You probably see this either because people are lazy, and don't want to bother designing forms or, equally likely, they switch interfaces depending on the inadequacies of one or the other. I definitely do both.
 
Back
Top