It was in 1994 that Microsoft declared Office a development platform, and released the Office Developer’s Kit 1.0 for coders to turn out useful utilities. Using Visual Basic and COM automation, programmers could control Office applications using software. Automating, say, document editing in heavyweights Word and Excel in the …
Web apps in excel docs?
There's a TLA for that!
Can anyone explain why I (or my employer, for that matter) would want to code macros/apps for a confidential company spreadsheet that contains 'server side' (i.e. in the 'cloud') code?
At least VBA is still in there.
Oh yeah. My employers are just going to *love* that.
Having said all of that, I suspect it's technology that nobody will use. People will kick the tyres, and go "Oh, look, I can post a form using HTML GET from my spreadsheet. Groovy."
Then the bost will slap them and they'll go back to VBA and get on with their work.
Problem is VBA is NOT on the RT version
"Macros, third-party add-ins, and VBA support will all be dropped from the Office 2013 RT edition"
You speak of sandboxing as if it is a good thing. It can be; but sandboxing Office apps. takes away a major functionality aspect.
For example; in my Office 2010 I have a lot of address information stored in Outlook. Whenever I need to write a letter I use a Word template (VBA) which then accesses the address list in Outlook to retrieve the contact information I need.
And there's plenty more where that came from. Searching OneNote information and being able to setup stats in an Excel sheet. Going through all the Word documents marked as "bill" on my system from Excel, when identified it grabs information from the document such as payments and tax and such. All data is then put into a graph which helps me keep an (easy) overview of company revenue.
Office was build for interaction... If they need to sandbox the whole thing online then my conclusion would be that MS Office wasn't build for this.
"You speak of sandboxing as if it is a good thing. It can be; but sandboxing Office apps. takes away a major functionality aspect."
"For example; in my Office 2010 I have a lot of address information stored in Outlook. Whenever I need to write a letter I use a Word template (VBA) which then accesses the address list in Outlook to retrieve the contact information I need"
From my reading of this, there's no reason you can't do this. I think you are thinking that an app gets embedded in a document or spreadsheet and is then sandboxed within and thus cannot get the information from Outlook's address book into your Word template. Correct?
What you (or a developer creating such an App) would do, would be create a "manifest" file, which is a description of the application in terms of what it can and cannot do, and when you installed the application, you'd be able to review these permissions and check they were what you wanted the App to have access to. The Manifest file also shows when and where the application shows up. So you could make it an App inside Outlook if you wanted (or in Word if you preferred), and when you ran it, assuming it had the right set of permissions, it would be fine to read addresses from Outlook, find the appropriate template and create your letters. You might find this interesting as it goes into how the permissions break down. Check out the diagram about 3/4 the way down. As you can see it's possible to give or withhold permissions in a far more sophisticated and elegant way than was possible with chunks of VBA or DLLs. That page is specific to Outlook but it will give you a good idea.
"And there's plenty more where that came from. Searching OneNote information and being able to setup stats in an Excel sheet. Going through all the Word documents marked as "bill" on my system from Excel, when identified it grabs information from the document such as payments and tax and such. All data is then put into a graph which helps me keep an (easy) overview of company revenue."
There's nothing in there that I think shouldn't be just as possible with the new system. But you'll be able to lock it down in ways that you cannot with VBA. When I mentioned sandboxing, I was primarily talking about a sandboxed runtime, though of course it also sandboxes what data sources it can communicate with based on the manifest file. E.g. if when you install it the manifest file says it can only talk to server.mycompany.com, then that's all it can talk to. It can't go off and talk to server.myrival.com.
"Office was build for interaction... If they need to sandbox the whole thing online then my conclusion would be that MS Office wasn't build for this."
Honestly, I think you should probably take a few hours to read through some of how Office 2013 and Win8 are set up for development. You obviously have a lot of experience and can put together a good argument. But I genuinely think you haven't actually read through these documents as you have some significant misconceptions about some of these things. Don't rely on El Reg for detailed analysis of this stuff, judge it for yourself!
"Office apps that work seamlessly locally or on the web is compelling"
Or you could download Dropbox for free, tell it to sync a directory, still keep a usable version of Office (2003 being the most usable, followed by 2007/2010), and not pay yet more cash to Microsoft for the privilege of owning (or is that renting?) the latest most user-unfriendliest version yet of their Office suite.
And here we go again...
"Programmers can get started with Apps for Office by signing up for an Office 365 developer pass."
When I want to develop stuff for my Office environment all I have to do is either open up whatever program supports VBA and start coding. Or if I want to build external stuff I simply pick up VS Express and get to it.
All for free.
What El Reg doesn't mention is that "signing up for an Office 365 developer pass" is only free during the Office 2013 preview. You can see as much here (MSDN Office page).
So in the near future you'll need to cough up some big bucks if you wish to develop stuff for the new Office.
Gee; that reminds me of my Windows Phone. If I want to use C# and such to create programs for it then I need to cough up approx. $100,-/year. Even if I have no desire - what so ever - to publish stuff, but only wish to have fun with my own phone. The tools are free, but accessing my /own/ phone isn't.
With these developments I seriously wonder how long the VBA environment will remain a free feature. I wouldn't be surprised /one bit/ if that policy would change as well in the future, in an attempt to gross in even more money. So then you'd have a trimmed down Office and a (much more expensive) "Pro Office" which could feature many things you may not need, but need to purchase anyway if all you want to do is being able to program VBA macros.
Java.... Java... ECMAScript!
The sane one, running for the hills!
@ShelLuser, heh. What an amusing contrast to Android. No fees for the SDK, I can always put apps on my own phone with it. A one-time $25 fee to publish (which they say they charge just to encourage high quality apps... i.e. spammers would start fake publishers if it was free.) And, besides the android SDK, technically I could install AIDE (Android Integrated Development Environment) and develop Android apps *on* the device.