Bring back Macros
I am amazed you've decided to remove Macros from Visual Studio. Not only are they useful for general programming, but they're a great way to be introduced to the Visual Studio APIs.
If you are unwilling to put in the development time towards them, please release the source code and let the community maintain it as an extension.
I would like to execute a macro after I press F5. IE:
Enter username/password in a LoginForm
A messageForm displays.
Press the Ok Button.
The MainMenu Form displays.
Change the value of a ComboBox
Click on an item in a ListView Control
This wil load the form i'm currently working on and stop the debuuger on a breakpoint.
I heard only 1% of folks use this feature therefore it was cut from VS 2012. I really need a way to automate things inside the IDE such as creating files. Writing an extension to do this is way too much work. It would take a very long time to payback the dev hours needed to code up an extension. Keep in mind that 1% is only the 1% of folks that chose to opt into having their usage tracked.
Last week I tried to use Macros and I noticed that feature was cutted out from VS11 Beta. So I have to do it through Notepad++ and finally copy the code into VS11.
We are currently reviewing the feasibility of delivering a scripting capability in a future version of Visual Studio. Please continue to offer your comments on what scripting capability we should offer while we research this suggestion.
Tony Goodhew, Program Manager, VS Pro.
and you have my vot !
this votes are for real. the comments are balanced with the votes !
Please bring them back! I do not understand MS's rationale for removing them. They were there, they worked. Why mess with it?
We're developers because we're lazy and like the computer to do mundane, repetitive tasks.
"comments on what scripting capability we should offer"
Just be able to record keystrokes and execute them.
I've just migrated from VS2010 to VS2013 (today Feb 2014) and have just discovered that the macros command in the tools menu has gone !!!
I can't tell you how useful I found the macro feature, it was one of the few joys I had working in the VS IDE (I won't mention the number of runtime bug and IDE crashes I've had !!) but using the macro comand was simple and easy, please bring it back !!!
Macros are very usable.
I use them when I need to update lots of code by doing the same things over and over.
by using Macro I reduced the time that such actions cost.
Please return the macros
Rick Fleischer, I use Visual Studio 2013.
I craft C#/EnvDTE80 macros and assign them
to keystrokes and toolbar buttons; to wit:
Microsoft is altering the way macros work,
and, in the process, breaking stuff.
Imagine a portable device,
like Google's Android and/or Chrome,
that ran only one app: Visual Studio.
As unlikely as it seems, still, this is
how Microsoft has been thinking, I fear.
Google/Samsung and Apple are winning this battle.
Rick Fleischer commented
Release by release, you give us a bigger sack of vanilla. 2010: no custom buttons; 2013: no customization at all.
I quit commented
You're reviewing the feasability?? It's had it for as long as I can remember, every other IDE supports it... even Word does - I've wrote software that supports scripting in my spare time!
Of course it's fukcing feasable! Just get on with it and give us something that's worth the $500+ (minimum) per year!
Save your research dept. some time... download Notepad++ and see how they managed this spectacularly high-tech feat!
Surely one of your developers have used macros in Visual Studio once? Poach them back off Google, ffs.
I'm used to attach debugger with macros. This saves me lots of clicks/scrolls
When someone tells me my code is "obfuscated",
I tell them that it's complex, with depth,
like the Washington Post is, compared to Dilbert.
Anyway... nice to meet you.
Like you say, this isn't the place to discuss this.
@Jeff Why thank you!
I always try to write code that I (or anyone else working with me) can maintain without unnecessary difficulty (preferably even on a bad day when they have a hangover and when the coffee has run out...).
As a result I try to write in a style that's consistent, readable and doesn't do anything unexpected (at least, not without a comment to indicate it's doing something unusual and why).
I try to use static analysis (mostly PC-lint, but not exclusively) and measuring cyclomatic complexity to remind me not to wander too far away from my ideals. Although a lot of the issues analysis tools find are harmless at the time, I've learnt over time as the code evolves new code paths can make some of them harmful - so I fix them up front as a matter of course.
I also compile at warning level 4, of course - and at times I've even found "Warnings as errors" to be a useful project setting.
Of course the behaviour of any analysis tool is always going to be a compromise. Where my style and a tool disagree, I tend to try to be humble and accept that it's easier for me to adapt than to try to get the tool modified to accept my oddball way of doing things.
It probably doesn't hurt that I enjoy refactoring, either. :)
Anyway - I think we're wandering way off topic for this thread...
I'm in awe of you, I like you.
Lint isn't bad; in fact, it's kind of "good".
Still, I've never liked -pedantic- "errors".
I should be able to do this:
> __int32 A ; float B ; wchar_t *C ;
> A = B = C = 0 ;
The compiler should just handle it,
no nominal "errors", no warnings.
To some who didn't know my source code intimately,
lint "errors" might distract from the real issue:
customers (who've been using my code for decades).
Porting my code to Visual Studio 2013,
from VS⋅2010, lint⋅like "errors" appeared.
Basically, it prompted me to re⋅examine some
ultra⋅complex code. Although it took many hours,
I was -happy- to revisit the code,
some of which hadn't been touched for decades !
Although no -genuine- errors were discovered,
I initialized the uninitialized variables anyway,
thus removing the (nominal) "errors".
One way or another, I remove all level 4 warnings;
> #pragma warning( disable: 4100 4101 4102 4127
> 4146 4189 4244 4305 4430 4508 4554
> 4701 4702 4706 4709 4996 )
@Jeff I've been working on Visual Studio plug-ins since VC6 days, and after a while you start to see patterns.
FWIW I started using PC-lint heavily as a result of being involved with a project which had a growing quality problem. It not only helped us fix the things we are looking for, but found quite a few issues we hadn't even suspected were there. What I do now is a direct result of wondering about how we could make that process a bit easier.
But I digress. YMMV, of course.
As Sergey Vlasov's Visual Commander
( http://Jeff-Relf.Me/Macros.HTM ) shows,
Visual Studio 2010 could've ( indeed, should've )
ran the macro editor in a ( text editor ) tab,
instead of launching Visual Studio 2008.
I -love- how well informed you are
re: Visual Studio "upgrades".
Visual Studio 2013 ( vs. 2010 ) is massively better
at searching text/code -- and, thanks to Vlasov,
adding macros to the Toolbars is -much- easier ! !
Like you said, Microsoft will, most likely,
fix this "missing macros" problem.
I carefully read -all- of your prior posts,
including most of your links there.
I spent a lot of time following the links.
One glance at my code ( http://Jeff-Relf.Me/X.HTM )
and you'll see that I'm not a fan of lint.
I do contract work for the ABA ( http://ABA.COM ).
They give my a -wide- berth; I do as I please.
Many coders have worked with my code,
including one who works for Microsoft,
developing Visual Studio.
So the ABA truly knows what I'm worth, $$$,
compared to them.
The macro editor in VS2010 was VS2008. I suspect there was a limit to how long Microsoft could ship an old IDE along with their latest IDE just to edit a bit of VBA code.
@Jeff thanks for the information.
AFAIK the only one of those we use is EnvDTE::ItemOperations::OpenFile() - I've not noticed any regressions in that case, but I can certainly take another look.
It's probably no consolation but we're *very* used to seeing regressions on EnvDTE (and VCProjectEngineLibrary) interfaces when a new version of Visual Studio arrives. For example, VS2010 had completely broken command bar interfaces on release.
EnvDTE seems to be the poor relation of VSX, and (I assume) doesn't get seem to get tested anywhere near as exhaustively as the VSPackage interfaces that Visual Studio language services rely on. That's not to excuse that of course - but it's not a new pattern in VS2012 and VS2013.
Finally: I'm not a heavy user of macros, but removing support for them is nuts. If it helps, I wouldn't be surprised if it wasn't an intentional omission but happened as a consequence of re-engineering elseware and them running out of time (like in the case of the C++/CLI intellisense *****-up a while back).
EnvDTE80, Visual⋅Studio⋅2013 vs. 2010,
has these bugs:
"DTE.Find.Execute()" now changes your
Solultion: use "DTE.Find.FindReplace()" instead.
> By the way, I put "not found" messages
> in the ＜StatusBar＞, like this:
> > DTE.StatusBar.Text = @" Not a ■⏎⏎■⏎ file." ;
no longer works properly because the edit⋅tab
never gets updated when its file is changed
by something outside the editor.
Solultion, use this instead:
This no longer works properly because
modified tabs/files ( in Visual Studio )
don't reflect the update:
Solultion, use this instead:
For more details, see:
EnvDTE actually works the same way in Visual Studio 2012 as it does in previous versions (our Visual Lint plug-in uses those interfaces).
However, the ability to write macros which use it has (very wrongly, in my opinion) been removed.
Jim Ｓtringer, Microsoft hobbled the desktop
to "win" the phone market.
Google Android is Java⋅on⋅Linux, not Gnu⋅on⋅Linux.
Like C#/EnvDTE, Java is a virtual Operating System.
Google Chrome and FireFox are also (semi)OS'en.
So it's The Battle of the Virtual Machines, I guess.
Starting with Visual Studio 2012,
they changed the way EnvDTE worked
and junked the macro⋅editor.
Microsoft continues to lose billion$$ each year
on this -- a triumph of hope over reason.