Happy to find your blog.
Sorry! my question is not related to macros. if you will make us so happy if you find a solution for it.

well, We have an Excel file with about 20 tabsheets, each contains numbers, texts, pictures and some formulas to each other and another excel file. It was always about 2-7 M-bite but after we lost the file one time and we used an archived history file (saved by protection setting automatically by Excel) it is now 150 M-bite! about 10 times bigger! and very slow.

I tried to move the sheets to a new book but didn’t work and it was still about 140 M-bite. then I tried by copy and use paste special such as “formula and numbers formatting”+”column width”+ “formatting”. but the formulas referred to previous file not the new file. (I hope my sentence be clear, as English is not my native language. I tried to save as the file as a new file but it just helped to get ride of 30 M-bite. and it is still 129 M-bite.
The file is shared with keeping history for 10 days.

Thank you

You record a macro in 2 secs get a glimpse of the awful code and it jogs your memory enough to piece together the syntax for a rough Google query. It returns a load of rubbish with pages requesting your loyal registration and pop ups, but jogs your memory enough to just get on with it. Half way through your choosen New-Wheel invention you remember where you last wrote this code and go hunting for the file and tediously fail to find it. Shortly after finishing your new wheel shaped masterpiece you click F12 and go searching for the folder that best suits this new magnum opus only to stumble upon last years doppleganger which has a few clever extra bits that you considered doing but ran out of time.

Long live VBA long live the macro recorder.

Where I’ve seen problems is when someone spends ten minutes recording a 700-line macro. That’s when it’s easy to become swamped by the extraneous lines of code.

Ideally, a .NET macro recorder would have to allow for recording in VB.NET or C# (or certainly in VB.NET, at least), and preferably would allow for choosing to record either with ‘Option Strict On’ or with ‘Option Strict Off’. (Or perhaps simply detecting the current ‘Option Strict’ setting within the document into which the recording is being made.)

I know that this is a high standard, but, ideally, the macro recorder would also record with better syntax than it does today. Improved output is even more necessary with .NET, which is strong typed when using VB.NET with ‘Option Strict On’ or when using C#. In VBA the current macro recorder will typically create output that looks like the following:

The same commands would look pretty much the same when called using VB.NET with ‘Option Strict Off’:

However, I think I would prefer to see code such as:

I know that this is longer, but it is much more explicit, and a lot closer to what coders should be using for their own code. This could be vastly harder to create, however, than simply scripting selections and actions, I don’t know. It does look a lot harder. But I think that it could really be worth it.

I could also envision a setting for “Ignore Selections” in which case commands such as .Select are simply ignored. Typically one would not want to use .Select in their code no more than one would want to use SendKeys(). There is a place for it, but it is rare. With the option “Ignore Selections” set to True, I the recorded results could look as follows:

Of course, one could ignore the range variable declarations and boil it all down to the following:

And this would be fine, but I think there is an advantage, especially for the learning coder, to see a variable explicitly declared, set, and then used. Certainly if a given object is to be used more than once, then I think that it should be created once, assigned to a variable, and then that variable used multiple times.

The macro recorder gets really interesting with .NET — and more important — if one could record with ‘Option Strict On’, in which case CType() declarations would be required, and hopefully created correctly by the macro recorder as needed.

A C# macro recorder would be even more complicated — and quite possibly not necessarily worth the effort in the first version since the majority of the audience that would require a macro recorder would be VBA programmers transitioning over to .NET. That said, C# coders could use it for two important reasons: (1) the syntax for calling the Microsoft Office object model from C# is not that intuitive, even for a C# coder, and (2) a C# coder is less likely to be proficient with the object model in the first place than would be a VBA coder.

If one has limited resources and cannot roll out all of these capabilities, at least not in the first version, then deciding which aspects have the best “bang for the buck”, could make for some difficult decisions. But I think as we transition towards .NET, the macro recorder will become vastly more important again. It will verge on critical for any coder in the initial months of switching over from VBA, or any coder first learning to program on the Microsoft Office platform when using .NET.

In the spirit of answering the question, if there was a near-perfect documentation of Excel help – which there never will be – I would not use the MR personally. I prefer help. I like good documentation, examples, related topics/items, a quick search capability and good menus. But since that will never happen, as long as we have a macro recorder for VBA, I’ll still use it occasionally.

I did the colour chart thing very early on in my macro/VBA education as a way to practise loops and cell references. Excel + macros recorder + VBA are an excellent route into other stuff. I’m a scripter not a programmer but VBA allows to to believe otherwise sometimes!