
For anyone that does VBA and has recorded a macro.
Activecell.Offset
Users running Excel on either Windows or Mac PCs will soon be able to automate many of the now-manual tasks in their spreadsheet software, something that currently is only available to those using the web application. According to new entries in the Microsoft 365 roadmap, starting in October, users will be able create, edit, …
I stand corrected. Apparently 1993 (v5) is when Excel acquired a scripting language.
However, I do take issue with your implication that internet integration is required for it to be a fair comparison. Cloudy Excel only needs internet-ready scripting because some doofus has chosen to put an internet between the script and the spreadsheet. This is re-inventing something that we already had, to solve a problem that most of us didn't ask to be created.
Excel had a scripting language. You put Excel commands in cells in a spreadsheet, and ran that script.
Excel scripting was replaced with VBA, and the ability to create script sheets was removed, but Excel still had the ability to run script sheets for many years after that. Dunno if that is still supported or not in the desktop version: It's not in the online version.
Odd that. I distinctly remember using Excel in 1987, when it included an embedded version of Windows 2 runtime.
I don't recall whether it had any scripting language or the other stuff you mention. It certainly had a macro language, which it would have required to possess any kind of relevance at all against Lotus 1-2-3.
-A.
The original version of Excel came with a macro language, using XLM, you had to add a special worksheet of type "XLM" in order to write macros in it.
I wrote a timesheet management system in Excel for a factory in 1989 using XLM macros to open the individual worksheets of the employees, pull out their work times and place the results into consolidated departmental and site worksheets.
That was long before VBA came along.
It was actually a great improvement over Lotus 1-2-3 scripts, even if it wasn't a full scripting language, like VBA.
Re: Users can record what they've done with Action Recorder, which creates a TypeScript language script that can be run again whenever it's needed. Scripts created and edited with the Code Editor can then be shared across the organization, enabling coworkers to automate their workflows, according to a Microsoft online document about Office Scripts.
"A macro by any other name..."
Indeed. Why use a database management system when you can frig a piece of software, which wasn't designed to manage data, to try and do the same job in a much more complicated and error prone way that can literally kill people. Think losing thousands of safety critical Covid data records whilst using Excel to share the data.
Why indeed.. It's usually because the people tasked with whatever job they're trying to accomplish don't have the training, tools, time, support, resources or funding to create a database management system, they typically have other technical skills and responsibilities.
Additionally, a database represents a certain level of crystallisation of processes which may not yet have settled down yet in an excel model.
I have good reason to believe that Microsoft is creating a database that does not need "...the training, tools, time, support, resources or funding to create a database management system" to work with. Microsoft began from queries-formulas, and I guess Microsoft will introduce the method for data-records soon.
The problem Microsoft is facing, and which is not too difficult to solve, is to make sure that "...losing thousands of safety critical Covid data records while using Excel to share the data" does not happen. It is important not only to find, but also not to lose anything!
I think that the vast number of people who think they've got a database in Excel will be more than happy** to have an improved toolset for sorting, matching, analysing, querying, reporting, or whatever it is they do with their data.
The people who really need a database or understand the difference between a database and a collection of spreadsheets will carry on using whatever their or their comapnies'/clients' preferred database software is.
I'm in the former group - I work mostly with Excel "databases" of info that I need to analyse, query and report/present. On the odd occasion where it was apparent that a database was needed for what I was doing I found a database bod, explained what I wanted, gave them the job number and let them get on with it. I think that my years of using Excel have rendered my brain incapable of understanding proper databases and their associated software. One develops habits that need to be unlearned - a bit like trying to learn classical guitar after years of playing electric - and I'm too old for that. Maybe a project for retirement.
**although the security aspects of this could temper some of that happiness.
“On the odd occasion where it was apparent that a database was needed for what I was doing I found a database bod, explained what I wanted, gave them the job number and let them get on with it.”
This is an analogue of Machine Learning. Microsoft started working on this database 6-7 years ago, adding Machine Learning to it. What is it? This is adding annotations to records, among other things. That is, you will explain to the computer what you need (instead of people); it will find; you will check whether it is found, chat with the computer; your explanation will be saved as an adition to the annotation. In the future someone else will search already having your annotation; adds his one and so on.
The security problem is likely to be solved, Microsoft has considerable experience in this.
Excel and spreadsheets will be a composed part of the database Microsoft may ofer soon. “May” because I would do it first of all. Microsoft needs this database for everything itself.
There is a software that uses databases to fill Excel sheets. It's called Axiom Software. You can enter, save and retrieve data from within an Excel file (like refresh it). People can have their own files or use a common read-only file, that when refreshed, shows the relevant data as entered by everybody. Databases knowledge is needed in the background but not for all end users.
> What makes it different?
A VB script runs at machine speed and is fast and efficient.
These new recorded macros will run at the speed the person recorded them so you can see them select a cell, unselect, select another, then go back to the first one, then type the data in wrongly, correct it and eventually press enter on a single cell. Then change the colour to highlight, realise they are on the wrong cell, undo the colour, go back to the right cell, change the colour and on and on and on.
Great new excuse for when the boss catches you twiddling your thumbs: I'm sorry boss, I'm just waiting for Mavis' macros to run. About another half hour to go ...
It’s only mentioned in “archive” web pages!
https://developer.apple.com/library/archive/documentation/LanguagesUtilities/Conceptual/MacAutomationScriptingGuide/index.html
(Scripting was pretty much never useful for anybody except for hackers, which is why MS Office was ultimately forced to disable macros “by default”! Odd that they feel the need to resurrect this again…)
"Until now, sharing spreadsheets within a Teams meeting has been a fairly one-sided experience," Meenakshi Bhatia-Naren, principal product manager at Microsoft, wrote in a blog post at the time. "You share a file, and everyone else watches while you make the updates. But what if your group could use that meeting time to get the work done together?"
Er... this problem has already been solved: Excel supports collaborative editing already. E.g. just store your sheet on OneDrive/Sharepoint; if needed, send a link (with edit permissions) to everyone required (assuming the file isn't already in a shared location they can already access); everyone can then open and work on the sheet at the same time. This feature has existed in Excel for a while, as long as the file is stored online and not in legacy storage.
If you also need to actively show and demonstrate to people what you're actually doing, such as show them how to use the sheet, then you just share your screen (or Excel app window) in your Teams call. They can still have the file open, for their own collaboration and editing, in their own Excel, at the same time.
Admittedly, it's a wee bit more of a faff than an 'instant share' inside a Teams call, as you either need to tell people which file to open (or where it is) in your shared storage, or send them a link. Directly sharing the file within a call would at least eliminate that bit.
A/C.
Imagine thousands of Office-Cloud and Power-Asinine Scripts sharted out by naive "Users" and self-hyped "Citizen Developers" no longer in that department. Imagine that some of those Scripts of screwy, bastardized, and canned code do things on which various teams of the remaining naive staff do not know that they rely. Imagine that the rest of the cryptic crayoned Scripts sit unused, and anyone discovering them is afraid to delete them.
Alas, a thousand monkeys, each with multiple Kindergarten-level code creations: Who wants to support that steaming, cloud-tied pile of Crayola code on which the department pays never-ending cloud rent every month?
No one in his right mind, certainly.
Microsoft has gotten users to pay rent on their own macros, many of which do not at all need to be in the cloud. Brilliant!