Restore MDI file handling (open all files in one window); Kill SDI (each spreadsheet opens in a seperate window)
In the good versions of Excel (prior to 2007) one could open multiple workbooks in the same window. Now, one has multiple instances of Excel (and every other Office app) whenever one opens more than one document / spreadsheet. Quite stupid.
(2016-04-27 Dan [MS] - updated title to fix MDI/SDI usage - they were previously being used "backwards")
Thanks for all of the votes – the team has definitely taken notice of the activity around this issue. We moved to SDI as a result of customer requests, but it looks like we’ve got work to do to really nail the use cases people care about. From a read over the comments, I see a number of cases that we will want to investigate further as we think through MDI vs SDI. We’ll get someone from the team to take a deeper look, and we may reach out to some of you for more clarification as we go. Thanks again for all the voting and passion here!
Jiri Kotek commented
This is a huge step backwards. Working with SDI is a trash from both user's as well as developer's perspective. I think it's not necessary to mention all the reasons at this point (just read thru all the comments and a lot more on other forums). Just wanted to voice my opinion on SDI.
Doug Reid commented
Dear John. Are you ever going to respond. It has been 509 days without any response from any Microsoft representative. Does anyone there even care?
SDI has some very basic pitfalls:-
1) Takes more time as it no longer remembers each file window size so constant resizing required on opening every file.
2) Wastes precious screen space as several ribbons duplicated.
3) Mishaps occur by inadvertant clicking of the wrong menu bar.
This is just from the perspective of your average office user for home/office. It must be far worse for some of the more specialist users.
It seems from other comments that the fall out adversely effects users at every level from elementary right up to the more complex.
Please give the option for MDI or SDI, The end user (and payer) should make the decision not microsoft!
Salil Gangal commented
Please restore MDI. Or at least give am option to choose how the user wants to excel as MDI and SDI.
I just "upgraded" to Office365 with SDI coding. It's a disaster for me. Multiple ribbons take up way too much vertical space on my screen and I was constantly having to shift my eyes to the top of each window looking for the formula bar and menus. Whoever coded SDI didn't have hardcore Excel coders in mind. I have had to downgrade to Office 2007 to get back the MDI functionality.
PLEASE RESTORE MDI FILE HANDLING OR GIVE USERS THE OPTION OF MDI OR SDI.
It used to be fun to poke fun at the advertising about "use Office whose programs all are built to work seamlessly with each other" failures. They never did more than Windows allowed anyway and they never will. But that's not even bruted about anymore so...
It's still ironic though, that the lack of working together is so deeply rooted that separate instances of the same Office program can't even coordinate better than the chosen program and Jim-Bob's shoe shine app do. Usually, "ironic" usually includes "sad, so freaking sad..." and this is no exception.
16 months... "You wait 16 months and what do you get? Another day older and... "
Maurice Lab, focus unavoidably shifts to the newly opened workbook. Best you can do is execute code to "jump back" to the workbook containing the userform that you want to stay on top. You would do this with code like "ThisWorkbook.activate". But that still leaves an annoying and very unprofessional-looking screen flicker.
I'm seeing Excel 2019 books in the local bookstore. Has the 2019 version addressed any SDI issues? Anybody know?
Maurice Lab commented
Macros don't work the same in SDI as they did in MDI. In MDI, the macro User Form would stay in front of all other workbooks opened via the macro. In SDI the User Form is behind every workbook opened via the macro, hence harder to see when the macro is completed on long running routines when a progress bar indicator is present, since the User Form in no longer in the foreground.
Customers who requested SDI are probably not heavy users of excel. I don't understand why someone would remove MDI... should have kept both. This is super irritating...
Martha, the good old Ctl-F4 still works for closing the workbook without closing Excel
Simon Ashton commented
There can be problems if you don't close Excel and re-open a new version... for me it leaves the old files' VBA scripts running.
Also, if the "old" file was large and not running very fast, the "new" file also seems slow and can be susceptible to unreliable glitches, eg custom ribbons icons not working (filter & freeze pane - yet their work on their original ribbon), and also when the cursor and arrow keys stop responding forcing you to click to another program and back again to get it to work.
So if you have glitchy or slow running issues, closing Excel and reopening from new can sometimes improve Excel's performance
Martha, one way around this is to customize a ribbon or the quick access toolbar and add either the "Close File" or the "Close All" command to it. The "Close File" command will close the current file, and if it was the only file open, will leave Excel open. The "Close All" command will close ALL open files (and prompt if you want to save all like it used to back in MDI days), and leaves Excel running. Either way, it's better than shutting down Excel and having to reopen it every time you want to close one file. Yet another reason SDI sucks.
To add the command, right click a ribbon and customize it, select the "All Commands" option, then scroll down to Close File or Close All (they're listed alphabetically).
Martha H Rendeiro commented
One result of the SDI is that when closing the last workbook, the entire Excel app closes and has to be reopened. In order to avoid that, the new workbook has to open before closing the last one. Of course the new workbook is in a completely new window and is probably on a different monitor in a dual monitor setup. Then go back to the old workbook which is somewhere else to close it. Much easier to be able to close the active workbook with the "little x" but leave the Excel app open until closing by clicking on the "big X." The "little x" seems to be gone entirely.
I didn't mean to hijack this thread to be a VBA discussion, so this will be my last post in this thread about VBA. But I did want to clarify a little.
VBA is simply the programming environment and it's associated language. VBA is the look and feel of the VBA IDE as well as the core language components of VB (IF-then-else, Do While, Case, etc.).
But VBA is NOT "Activecell.select" or "Selection.Cut". Those belong to Excel Libraries which are automatically added into your VBA project. This is what allows VBA to talk to Excel.
MS never said it will discontinue development of these Excel Libraries. In fact these libraries are probably exactly the same libraries that Excel itself uses to do virtually everything. If MS stops developing these libraries, then all changes (good, bad, or indifferent) to Excel would also stop.
So what I'm trying to say is that the VBA IDE and core VB language may no longer change, but the functionality within a VBA macro will continue to change and grow as Excel (and its libraries) change. This should include new MDI functionality (if we ever get that back) because Excel itself will be using the same libraries as VBA does.
Roy, I know what you're saying about using VBA to connect to other office apps. It's a major pain in the back end. But I've done it multiple time. I've used Excel VBA to pull data from Access databases based on user entry. I've even done that to MS SQL Server databases. I have also created macros that save the current worksheet (tab) to it's own separate workbook and then attached that workbook to an Outlook email and automatically sent it. All invisible to the user. And I've seen many other examples of people doing similar things.
So while it might be a PITA to accomplish inter-application functionality, I wouldn't rule that out as something thats never being done.
There, no move VBA discussion for me, at least not in this thread.
Wikipedia says (and it fits what I've read over the years):
"... implementation of Microsoft's event-driven programming language Visual Basic 6, which was discontinued in 2008 ..."
(VB6 being the thing discontinued, not VBA)
"... the VBA programming language was upgraded in 2010 with the introduction of Visual Basic for Applications 7 ..."
(apparently just added 64 bit support, though not complete support)
"Office 2013 and Office 2016 include VBA 7.1"
(nothing specified; just housekeeping for the new versions?)
"... Microsoft intended to add .NET-based languages to the current version of VBA ever since the release of the .NET Framework ..."
"... allowing even .NET-unaware applications to be scripted via .NET languages. "
(always wondered why not when they ended VB)
(oh, that would have been nice...)
"However, VSA was deprecated in version 2.0 of the .NET Framework, leaving no clear upgrade path ..."
(oh... I see... )
So, for now, I'd say our best hopes go with MS leaving the path open to other languages to write versions that, like Python to whatever extent, can replace, or work with/within VBA. That way, the onus is on others and their own development paths are not cut nastily short by decisions in other departments that they cannot really influence.
As for this applying to our issue though, I'm thinking a laundry list of deficiencies will get made up over time since MS is NOT going to address them. With luck, they will become a list of reasons to use one language or another that might step into the void rather than staying an ever increasing list of reasons to revile MS and Excel.
In particular, VBA was clearly never really pictured outside an MDI environment so there are definitely issues one might want to take note of in some of this Suggestion's comments. Flickering seems a small point (I know, important to the experience and some people's products) when compared to coordination issues that have been mentioned, for example.
The bottom line is SDI creates what are in essence entirely different programs running in Windows and even though they are fellow Office programs (how much more "fellow" could they be?), it just isn't seamless and never will be, or would have been. Excel had a fantasy if they thought it could be. Drinking the "Office works seamlessly with itself" Kool-Aid does NOT make the advertising a reality.
Evidence of that? Well, 30 years of living the dream... Of ALL the complaints in ALL the Suggestions you've all read, the sometimes complicated set-ups and uses of Excel, the writing of workflows maybe more complicated than many standalone software programs... of ALL those, when have you even one time read someone mentioning, even in passing, writing VBA code in Excel that reached out into other running Office programs to accomplish any task? Ever? On some other website? Some guru website telling you that your goal is best accompished by workign the material in Excel, perhaps, firing up Word to present it, and firing up Outlook to mail if off to 12,000 addresses. And using VBA from Excel, since it is the first program in the flow, to control it all, not just the Excel portion?
No one even tries to suggest doing something like that. Not even MS. So just how well can we ever expect VBA to coordinate, safely and accurately, two or twelve instances of Excel, even if it is "just" instances of Excel, in order to work with all the files required by the work flow?
Bring back MDI, allow one to set a choice, especially one available per spreadsheet rather than application-wide, and life is good for everyone.
People who want separate instances could even have a "/switch" in the program shortcut (like the "/e" switch I just love). The complaint about moving spreadsheets between monitors was always spurious, though it is often said it was either THE reason for this, or at least the straw that broke the camel's back. Anyone desiring that could have always opened separate instances, or they could have normal-windowed Excel, drug its borders to cover the screen, then drug the appropriate one over onto the other monitor/s and moved MDI windows in the huge workspace. So even the rumored thing never needed a nuclear fix.
It's all just sad and wretched. I'll eat a five pound pot roast with all the fixin's if it ever gets satisfactorily addressed. (I mean, I might do that anyway, but it's the thought that counts, right?)
Futski: You say MS has no intention of "dropping" VBA because of all the code that's already been written using VBA. Taking a step back it becomes clear that that must be the case. Even so, there's a difference between not dropping VBA and continuing to maintain/tweak VBA. I've heard that MS has stopped maintaining Excel VBA. Can you (anybody) confirm? If so, that will surely be important because the switch to SDI must affect the interface with VBA in various ways. One obvious effect is the inability (under SDI) to freeze the screen to prevent focus from shifting to a newly created/opened workbook. I would expect that little glitch to be handled by updating VBA methods but if MS isn't maintaining VBA any longer, how does that ever get fixed?
IMHO the real reason MS killed MDI, is for security / stability reasons (actual stability improvement is debatable). Anyway, one bad acting spreadsheet or VBA module gone awry was able to lock up or bring down all spreadsheets running under a single Excel MDI instance. I believe their intent was to prevent one spreadsheet from crashing them all and losing their associated changes. But in todays day, improved containerization of code and data should easily allow MS to fix the original problem, thus allowing them to bring back MDI. This is basically the same way bad acting web pages no longer bring down the whole browser, but rather just the bad page.
Mats Samuelsson, regarding Visual Studio, it is not a replacement for VBA, nor is VBA a replacement for Visual Studio. They are completely distinct entities with very little overlap except for the "Visual Basic" part of the name. One cannot create a simple VBA macro using Visual Studio, nor can one write code for an Arduino using VBA.
For those interested in the history, VBA is based on ancient Visual Basic 6. VB6 was discontinued 20 years ago. Visual Studio continued to advance VB.net into a very modern language today, but it's almost completely incompatible with old VB6 code. And with VBA being a derivation of VB6, there is almost no crossover available. Fortunately MS has no intention of dropping VBA because of the countless lines of code written in it.
Mats Samuelsson commented
Exactly David, the possibilities to connect different requests including advanced formulas when using Excel makes the usage of Access impossible. I've built my company's whole administrative system in Excel, including business calculations, registration of purchases, orders and invoices, statistics, warehouse ledgers etc., the whole shebang. As there are many different databases I've tried Access but I lost too many interactions between calculations and the databases. Why use two applicationss when you can do the same in one! I barely survive with Excel 365 with all the difficulties but it's most annoying, certainly travelling with a laptop is a **** job.
Mats Samuelsson There are reasons why Excel might be preferred for a database app over Access. One IMO very good reason is that Excel workbooks are easily created and other systems will generally be able to read them. So if you wanted a communications channel between system A and system B, you could use Excel spreadsheets as a common "language". But how to pass Access information between systems? Not so easily done. This is not esoteric nonsense. Vendors, for instance, submit price lists on Excel spreadsheets and a company sends information to back to vendors on spreadsheets. Vendors are foreign systems. Could this be done using Access? I'm not trying to downplay Access but I believe MS is finding that Excel is awkwardly more powerful than it realized.