Really folks?



  • Just tried to look at two different files in Excel 2010, in different folders, that happen to have the same filename...


    [IMG]http://i.imgur.com/xTEiOIp.png[/IMG]

    Alrighty then...

    • What kind of developer writes an application which can't cope with two files with same filename? Not instance ID... Not even path... FILENAME...
    • Why, when they wrote the code to show the messagebox, did it not occur to them that perhaps software development wasn't their calling?

  • Discourse touched me in a no-no place



  • Funny - I read the answer on SO today which explained the problem.


    Excel adresses cells in other workbooks with the name of the Workbook.


    If you could open two workbooks with the same name, a lot of problems would pop up - like which wb was intended by the adress?

    So I wouldn't blame this on Microsoft stupidity - it's the result of a reasonable design choice.



  • So why is there no link to the help files in the dialogbox for the explanation?



  • @HerrDerSchatten said:

    Funny - I read the answer on SO today which explained the problem.


    Excel adresses cells in other workbooks with the name of the Workbook.


    If you could open two workbooks with the same name, a lot of problems would pop up - like which wb was intended by the adress?

     

     


    So I wouldn't blame this on Microsoft stupidity - it's the result of a reasonable design choice.

     

    TRWTF is addressing cells in other workbooks directly by name only, they should have used relative path or some such

     



  • @HerrDerSchatten said:

    Funny - I read the answer on SO today which explained the problem.


    Excel adresses cells in other workbooks with the name of the Workbook.


    If you could open two workbooks with the same name, a lot of problems would pop up - like which wb was intended by the adress?

    So I wouldn't blame this on Microsoft stupidity - it's the result of a reasonable design choice.

    Design choice of DOS 1.0?



  • @HerrDerSchatten said:

    Excel adresses cells in other workbooks with the name of the Workbook.


    If you could open two workbooks with the same name, a lot of problems would pop up - like which wb was intended by the adress?

     

     I should think that would be easily remedied. Refer in the UI by name but internally but a UID. If there's an ambiguity, pop a dialog to the user asking to choose between the pathnames (which will be unambiguous).

    Surely Microsoft has enough programmers on hand to sort this out?

     



  • @HerrDerSchatten said:

    Excel adresses cells in other workbooks with the name of the Workbook.

    ...

    So I wouldn't blame this on Microsoft stupidity - it's the result of a reasonable design choice.

    I wouldn't consider allowing cross-workbook references a reasonable design choice.


  • Not?

    They can save you a TON of time, if used properly.



  • @HerrDerSchatten said:

    Excel adresses cells in other workbooks with the name of the Workbook.


    If you could open two workbooks with the same name, a lot of problems would pop up - like which wb was intended by the adress?


    So I wouldn't blame this on Microsoft stupidity - it's the result of a reasonable design choice.

    That's a semi-reasonable explanation, EXCEPT, as the OP pointed out, as soon as they created the dialog box which says "You can't open two files with the same name, even if they are in different directories" they should have realized that they were doing it wrong.

     



  • @HerrDerSchatten said:

    Funny - I read the answer on SO today which explained the problem.


    Excel adresses cells in other workbooks with the name of the Workbook.


    If you could open two workbooks with the same name, a lot of problems would pop up - like which wb was intended by the adress?

    So I wouldn't blame this on Microsoft stupidity - it's the result of a reasonable design choice.

    It isn't a particularly reasonable design choice. A reasonable design choice would be using GUIDs internally instead of names, and transparently mapping the two. However I have a suspicion that there is some legacy cruft that prevents MS from doing this.

    @henke37 said:

    So why is there no link to the help files in the dialogbox for the explanation?

    Because said explanation would confuse the bejeezus out of most Excel users.



  • @oheso said:

    @HerrDerSchatten said:

    Excel adresses cells in other workbooks with the name of the Workbook.


    If you could open two workbooks with the same name, a lot of problems would pop up - like which wb was intended by the adress?

     

     I should think that would be easily remedied. Refer in the UI by name but internally but a UID. If there's an ambiguity, pop a dialog to the user asking to choose between the pathnames (which will be unambiguous).

    Surely Microsoft has enough programmers on hand to sort this out?

     

     

     

    You're suggesting it prompt every single time an ambiguous workbook name is referenced?

     


  • Winner of the 2016 Presidential Election

    @The_Assimilator said:

    @HerrDerSchatten said:
    Funny - I read the answer on SO today which explained the problem.


    Excel adresses cells in other workbooks with the name of the Workbook.


    If you could open two workbooks with the same name, a lot of problems would pop up - like which wb was intended by the adress?

    So I wouldn't blame this on Microsoft stupidity - it's the result of a reasonable design choice.

    It isn't a particularly reasonable design choice. A reasonable design choice would be using GUIDs internally instead of names


    Just in case the user wants to open a few trillion trillion trillion instances?



  • Everything old is new again



  • @El_Heffe said:

    @HerrDerSchatten said:

    Excel adresses cells in other workbooks with the name of the Workbook.


    If you could open two workbooks with the same name, a lot of problems would pop up - like which wb was intended by the adress?


    So I wouldn't blame this on Microsoft stupidity - it's the result of a reasonable design choice.

    That's a semi-reasonable explanation, EXCEPT, as the OP pointed out, as soon as they created the dialog box which says "You can't open two files with the same name, even if they are in different directories" they should have realized that they were doing it wrong.

     


    My guess is that the issue wasn't noticed until long after it was implemented, and when it was finally discovered they just said "WTF? I don't want to deal with this now, just tell the user they can't do that. I need a drink."



  • Want more Excel filename fun? Try saving a workbook with [ or ] in it's name.



  • @ender said:

    Want more Excel filename fun? Try saving a workbook with [ or ] in it's name.

    Want more Excel fun? Do something, save a copy, and then undo so you can keep working on the previous document.



  • @HerrDerSchatten said:

    Funny - I read the answer on SO today which explained the problem.


    Excel adresses cells in other workbooks with the name of the Workbook.


    If you could open two workbooks with the same name, a lot of problems would pop up - like which wb was intended by the adress?


    So I wouldn't blame this on Microsoft stupidity - it's the result of a reasonable design choice.

    I didn't even know that was a valid use case. Excel just keeps getting better every day!

     



  • @Ben L. said:

    Do something, save a copy, and then undo so you can keep working on the previous document.
    Haven't we covered this before?



  • @mott555 said:

    @HerrDerSchatten said:

    Funny - I read the answer on SO today which explained the problem.


    Excel adresses cells in other workbooks with the name of the Workbook.


    If you could open two workbooks with the same name, a lot of problems would pop up - like which wb was intended by the adress?


    So I wouldn't blame this on Microsoft stupidity - it's the result of a reasonable design choice.

    I didn't even know that was a valid use case. Excel just keeps getting better every day!

     

    It's meant for accountants so they can do dumb shit like making a huge ugly financial summary sheet that directly references cells in your auto-generated reports (which they export and keep in My Documents, naturally), either via formulas or VBA macros that would terrify the elder gods, and then they bitch and moan because you had to update the generated report format and move something to a different column since Excel has no concept of decoupling presentation and data.



  • It'd break VBA.

    Excel will NEVER introduce a change or fix that'll break VBA.

    Because something like 60% of the world's economy is reliant on VBA scripts embedded in Excel sheets and if they stopped working for any reason the shit would hit the fan.

    I'm barely exaggerating.



  • @blakeyrat said:

    It'd break VBA.

    Excel will NEVER introduce a change or fix that'll break VBA.

    Because something like 60% of the world's economy is reliant on VBA scripts embedded in Excel sheets and if they stopped working for any reason the shit would hit the fan.

    I'm barely exaggerating.

    Shoot, with some of the stuff people do with VBA, that might even be literally true. Bets on sewage treatment facilities with Excel VBA controlling mechanical processes?



  • @kilroo said:

    @blakeyrat said:
    It'd break VBA.

    Excel will NEVER introduce a change or fix that'll break VBA.

    Because something like 60% of the world's economy is reliant on VBA scripts embedded in Excel sheets and if they stopped working for any reason the shit would hit the fan.

    I'm barely exaggerating.

    Shoot, with some of the stuff people do with VBA, that might even be literally true. Bets on sewage treatment facilities with Excel VBA controlling mechanical processes?

    The most amazing thing I've heard of was a set of Excel sheets that communicated with each other through sockets.

    They apparently worked fine until someone moved offices, and the hard-coded IP addresses all broke. The fix, of course, was to have them poll a file on a shared server. Hilariously, the file was plaintext rather than another excel workbook.



  • @Buttembly Coder said:

    @kilroo said:
    @blakeyrat said:
    It'd break VBA.

    Excel will NEVER introduce a change or fix that'll break VBA.

    Because something like 60% of the world's economy is reliant on VBA scripts embedded in Excel sheets and if they stopped working for any reason the shit would hit the fan.

    I'm barely exaggerating.

    Shoot, with some of the stuff people do with VBA, that might even be literally true. Bets on sewage treatment facilities with Excel VBA controlling mechanical processes?

     

    The most amazing thing I've heard of was a set of Excel sheets that communicated with each other through sockets.

    They apparently worked fine until someone moved offices, and the hard-coded IP addresses all broke. The fix, of course, was to have them poll a file on a shared server. Hilariously, the file was plaintext rather than another excel workbook.



    Meh, that shit's not so bad. Some witchery to get an internal process working fine is one thing.

    It's a whole other kettle of fucked up fish though when the excel black magic is packed into a commercial product and sold to people. That's the real WTF.

     



  •  @kilroo said:

    Bets on sewage treatment facilities with Excel VBA controlling mechanical processes?

    You have no idea. 



  • @BC_Programmer said:

    You're suggesting it prompt every single time an ambiguous workbook name is referenced?
     

     

    Ja. Da. Si. Hai. And why not?

     



  • @mikeTheLiar said:

    "WTF? I don't want to deal with this now, just tell the user they can't do that. I need a drink."
     

     

     SOP in these parts ... thank god!

     



  •  @blakeyrat said:

    It'd break VBA.

    Excel will NEVER introduce a change or fix that'll break VBA.

    Because something like 60% of the world's economy is reliant on VBA scripts embedded in Excel sheets and if they stopped working for any reason the shit would hit the fan.

    I'm barely exaggerating.

    This is what we call the sad truth.

    Before I got the job I have now, I interviewed with a company that does administration for medical supply distribution. Currently, most of their office operations consist of monkeys copypasting from AS/400 terminals into Excel spreadsheets to generate invoices and other "business documents" with glacial VBA scripts, the bulk of which are then in some probably unspeakable way stored in local Access DBs, which are updated over the network at night using file shares.

    I was meant to move them to a modern, browser-based system, which would clean up pretty much 90% of this cruft, not to mention replacing their two fixed-width mainframe systems from the 90s with a scaleable cloud (I fucking hate that word) database, properly normalized.

    I was looking forward to this massive overhaul, but they passed me by because I don't have the management experience they wanted. So, they hired a guy who used to be a lead on one project of three devs, never hired an actual development team, and now he maintains and 'fixes' their current cruft.

    They pay him more than I make now, and more than double what they had offered me; I had been unemployed for nearly a year and they could have gotten away with hiring me for beans.

    I sure as hell dodged that bullet.

     


  • Winner of the 2016 Presidential Election

    @VaelynPhi said:

     @blakeyrat said:

    It'd break VBA.

    Excel will NEVER introduce a change or fix that'll break VBA.

    Because something like 60% of the world's economy is reliant on VBA scripts embedded in Excel sheets and if they stopped working for any reason the shit would hit the fan.

    I'm barely exaggerating.

    This is what we call the sad truth.

    Before I got the job I have now, I interviewed with a company that does administration for medical supply distribution. Currently, most of their office operations consist of monkeys copypasting from AS/400 terminals into Excel spreadsheets to generate invoices and other "business documents" with glacial VBA scripts, the bulk of which are then in some probably unspeakable way stored in local Access DBs, which are updated over the network at night using file shares.

    I was meant to move them to a modern, browser-based system, which would clean up pretty much 90% of this cruft, not to mention replacing their two fixed-width mainframe systems from the 90s with a scaleable cloud (I fucking hate that word) database, properly normalized.

    I was looking forward to this massive overhaul, but they passed me by because I don't have the management experience they wanted. So, they hired a guy who used to be a lead on one project of three devs, never hired an actual development team, and now he maintains and 'fixes' their current cruft.

    They pay him more than I make now, and more than double what they had offered me; I had been unemployed for nearly a year and they could have gotten away with hiring me for beans.

    I sure as hell dodged that bullet.

     

    It sounds like that bullet dodged you.


  • @blakeyrat said:

    It'd break VBA.

    Excel will NEVER introduce a change or fix that'll break VBA.

    Because something like 60% of the world's economy is reliant on VBA scripts embedded in Excel sheets and if they stopped working for any reason the shit would hit the fan.

    I'm barely exaggerating.

     

    The exageration is, of course, in the fact that VBA breaks all the time, without any change from Microsoft, and nothing happens. The part about 60% of the owrld's economy being dependent on it is probably an understatement, you just failed to grasp the fluidity of the codebase.

     


  • Discourse touched me in a no-no place

    @Mcoder said:

    The part about 60% of the owrld's economy being dependent on it is probably an understatement, you just failed to grasp the fluidity of the codebase.
    UK Government gets bitten on the ass by spreadsheet. (West Coast franchise farce for those vaguely aware of what that link's about. Another link)


  • Discourse touched me in a no-no place

    @PJH said:

    @Mcoder said:
    The part about 60% of the owrld's economy being dependent on it is probably an understatement, you just failed to grasp the fluidity of the codebase.
    UK Government gets bitten on the ass by spreadsheet. (West Coast franchise farce for those vaguely aware of what that link's about. Another link)
    Excel. The world's favorite way of automating management blundering.



  • It is a bit of a dumb limitation, but there are valid reasons to disallow this.

    Try this scenario:

    User wants to create a new version of some file, let's say it's Budget.xlsx. Current version sits in /Budgets/2013/Budget.xlsx

    User copies this file to new folder, /Budgets/2014/Budget.xlsx. He opens both files in Excel so he can edit the 2014 version and compare it with the 2013 version.

    Now he's got Excel open with Budget.xlsx and Budget.xlsx ... he starts editing, swapping back and forth. Saves his work.. ARGH! He accidentally put some of the 2014 changes into the 2013 file by mistake (they've got the same name). Now he's got two files, both corrupted with invalid values.

    If he'd been editing Budget2013.xlsx and Budget2014.xlsx it would have been that little bit harder to mess up.


  • Discourse touched me in a no-no place

    @Quango said:

    If he'd been editing Budget2013.xlsx and Budget2014.xlsx it would have been that little bit harder to mess up.
    Real users manage many “amazing” things when it comes to doing the Wrong Thing with computers.



  • @VaelynPhi said:

     @blakeyrat said:

    It'd break VBA.

    Excel will NEVER introduce a change or fix that'll break VBA.

    Because something like 60% of the world's economy is reliant on VBA scripts embedded in Excel sheets and if they stopped working for any reason the shit would hit the fan.

    I'm barely exaggerating.

    This is what we call the sad truth.

    Before I got the job I have now, I interviewed with a company that does administration for medical supply distribution. Currently, most of their office operations consist of monkeys copypasting from AS/400 terminals into Excel spreadsheets to generate invoices and other "business documents" with glacial VBA scripts, the bulk of which are then in some probably unspeakable way stored in local Access DBs, which are updated over the network at night using file shares.

    I was meant to move them to a modern, browser-based system, which would clean up pretty much 90% of this cruft, not to mention replacing their two fixed-width mainframe systems from the 90s with a scaleable cloud (I fucking hate that word) database, properly normalized.

    I was looking forward to this massive overhaul, but they passed me by because I don't have the management experience they wanted. So, they hired a guy who used to be a lead on one project of three devs, never hired an actual development team, and now he maintains and 'fixes' their current cruft.

    They pay him more than I make now, and more than double what they had offered me; I had been unemployed for nearly a year and they could have gotten away with hiring me for beans.

    I sure as hell dodged that bullet.



    See, the sad truth is, (and what I need to make damn sure that I do on my next interview) you often get paid based on how much overconfidence and swagger you bring in on salary negotiations. If you walk in demanding a massive salary and have the ego to pull it off, you're more likely to get it than if you try to justify a low paycheck as being cost-savings. And the cost-savings just hurts you down the road come raise time.

     



  • @Snooder said:

    @VaelynPhi said:

     @blakeyrat said:

    It'd break VBA.

    Excel will NEVER introduce a change or fix that'll break VBA.

    Because something like 60% of the world's economy is reliant on VBA scripts embedded in Excel sheets and if they stopped working for any reason the shit would hit the fan.

    I'm barely exaggerating.

    This is what we call the sad truth.

    Before I got the job I have now, I interviewed with a company that does administration for medical supply distribution. Currently, most of their office operations consist of monkeys copypasting from AS/400 terminals into Excel spreadsheets to generate invoices and other "business documents" with glacial VBA scripts, the bulk of which are then in some probably unspeakable way stored in local Access DBs, which are updated over the network at night using file shares.

    I was meant to move them to a modern, browser-based system, which would clean up pretty much 90% of this cruft, not to mention replacing their two fixed-width mainframe systems from the 90s with a scaleable cloud (I fucking hate that word) database, properly normalized.

    I was looking forward to this massive overhaul, but they passed me by because I don't have the management experience they wanted. So, they hired a guy who used to be a lead on one project of three devs, never hired an actual development team, and now he maintains and 'fixes' their current cruft.

    They pay him more than I make now, and more than double what they had offered me; I had been unemployed for nearly a year and they could have gotten away with hiring me for beans.

    I sure as hell dodged that bullet.



    See, the sad truth is, (and what I need to make damn sure that I do on my next interview) you often get paid based on how much overconfidence and swagger you bring in on salary negotiations. If you walk in demanding a massive salary and have the ego to pull it off, you're more likely to get it than if you try to justify a low paycheck as being cost-savings. And the cost-savings just hurts you down the road come raise time.

     

     

    I've been practicing being an asshole in anticipation for my next job hunt.

     



  • @blakeyrat said:

    It'd break VBA.

    Excel will NEVER introduce a change or fix that'll break VBA.

    Because something like 60% of the world's economy is reliant on VBA scripts embedded in Excel sheets and if they stopped working for any reason the shit would hit the fan.

    I'm barely exaggerating.

    The whole problem with Excel is that it is the most common and widely-used programming environement in the whole world, with most programmers being amateurs who don't realize they are programming.

    The software engineering research group of my university actually do research on this (with obligatory spin-off startup company)



  • The problem with Excel is that apparently, at the very core of its being, it was created with the notion that nobody would ever, EVER want to look at two unrelated spreadsheets at the same time. Hence why it can't manage the seemingly trivial task of having multiple windows active at the same time. Open two Excel documents? Sure, it'll happily show two buttons on the taskbar, but then you realize they're both being shared by a single fucking window. Argh.

    Granted, with some hackery it's possible to make Excel run a new instance of itself for every document so you can accomplish black magic like comparing two spreadsheets on multiple monitors, but it breaks some common tasks in the process.



  • @pjt33 said:

    @HerrDerSchatten said:

    Excel adresses cells in other workbooks with the name of the Workbook.

    ...

    So I wouldn't blame this on Microsoft stupidity - it's the result of a reasonable design choice.

    I wouldn't consider allowing cross-workbook references a reasonable design choice.

    Agreed. If you need to reference data from another source, you need a database, such as, for example, Microsoft Access. Excel is not a database. Excel is not a database. Excel is NOT a database! Excel is amazing and can do all sorts of things, but IT IS NOT A DATABASE.



  • @anotherusername said:

    Agreed. If you need to reference data from another source, you need a database, such as, for example, Microsoft Access. Excel is not a database. Excel is not a database. Excel is NOT a database! Excel is amazing and can do all sorts of things, but IT IS NOT A DATABASE.

    Databases have shitty usability (with a few unique exceptions.)

    As long as people can't figure out how to use an actual database, Excel is the best thing they can figure out how to use.

    If you want to repeat some mantra, the mantra should be: "usability is important, usability is most important, usabilty is the most important thing to any software product."



  • @blakeyrat said:

    @anotherusername said:
    Agreed. If you need to reference data from another source, you need a database, such as, for example, Microsoft Access. Excel is not a database. Excel is not a database. Excel is NOT a database! Excel is amazing and can do all sorts of things, but IT IS NOT A DATABASE.

    Databases have shitty usability (with a few unique exceptions.)

    As long as people can't figure out how to use an actual database, Excel is the best thing they can figure out how to use.

    If you want to repeat some mantra, the mantra should be: "usability is important, usability is most important, usabilty is the most important thing to any software product."

    I thought we were talking about professionals, where the motto should be "If you don't know how to computer (or internet), hire somebody who does". Not "use whatever the boss's nephew recommends and he's really good with Excel!".


  • @blakeyrat said:

    @anotherusername said:
    Agreed. If you need to reference data from another source, you need a database, such as, for example, Microsoft Access. Excel is not a database. Excel is not a database. Excel is NOT a database! Excel is amazing and can do all sorts of things, but IT IS NOT A DATABASE.

    Databases have shitty usability (with a few unique exceptions.)

    As long as people can't figure out how to use an actual database, Excel is the best thing they can figure out how to use.

    If you want to repeat some mantra, the mantra should be: "usability is important, usability is most important, usabilty is the most important thing to any software product."



    The problem is not "people can't figure out how to use an actual database" it's "people who have no business using a database don't have the training to understand what a database is or does."

    See, a large part of what makes a database actually useful are the things that make it complicated. If you strip out the complexity, you also strip out the usefulness. Which is why such people should simply leave it to people who actually know what they are doing.

     



  • @Snooder said:



    See, a large part of what makes a database actually useful are the things that make it complicated. If you strip out the complexity, you also strip out the usefulness. Which is why such people should simply leave it to people who actually know what they are doing.

    What if we made some kind of lightweight database? Like an application where you could enter values, and program relationships between values in simple formulas, and maybe save everything in a single file for practicality... it would be good for simple computations.

    Perhaps some kind of 2D grid...



  • @Snooder said:

    The problem is not "people can't figure out how to use an actual database" it's "people who have no business using a database don't have the training to understand what a database is or does."

    If they've build an Excel app that you think should be moved into a database, then demonstrably they do have business using a database.



  • @Snooder said:

    The problem is not "people can't figure out how to use an actual database" it's "people who have no business using a database don't have the training to understand what a database is or does."

    If they've build an Excel app that you think should be moved into a database, then demonstrably they do have business using a database.

    @Snooder said:

    See, a large part of what makes a database actually useful are the things that make it complicated.

    Bullshit.

    @Snooder said:

    If you strip out the complexity, you also strip out the usefulness.

    Double-bullshit.

    @Snooder said:

    Which is why such people should simply leave it to people who actually know what they are doing.

    Mega-ultra-super-bullshit.



  • @blakeyrat said:

    @Snooder said:
    See, a large part of what makes a database actually useful are the things that make it complicated.

    Bullshit.

    Wow. I'm totally convinced now.



  • @anonymous234 said:

    @Snooder said:


    See, a large part of what makes a database actually useful are the things that make it complicated. If you strip out the complexity, you also strip out the usefulness. Which is why such people should simply leave it to people who actually know what they are doing.

    What if we made some kind of lightweight database? Like an application where you could enter values, and program relationships between values in simple formulas, and maybe save everything in a single file for practicality... it would be good for simple computations.

    Perhaps some kind of 2D grid...

    Note that this specifically excludes the question of you ever thinking "I need to reference some data that is stored in another spreadsheet".@blakeyrat said:
    If they've build an Excel app that you think should be moved into a database, then demonstrably they do have business using a database.
    Just because someone has a need for a professional tool doesn't mean they're able or qualified to properly and safely use that tool.


  • @anotherusername said:

    Just because someone has a need for a professional tool doesn't mean they're able or qualified to properly and safely use that tool.

    Right. Which means the maker of that tool has a lot of work to do to make it usable.



  • @blakeyrat said:

    @anotherusername said:
    Just because someone has a need for a professional tool doesn't mean they're able or qualified to properly and safely use that tool.

    Right. Which means the maker of that tool has a lot of work to do to make it usable.

    Hmm, now tell me how you feel about the makers of the Pi not selling a kit so you could try to bake its package-on-package RAM with a 0.5mm pitch. Because if you can't do it yourself, it's obviously a usability problem, right?



  • @anotherusername said:

    Hmm, now tell me how you feel about the makers of the Pi not selling a kit so you could try to bake its package-on-package RAM with a 0.5mm pitch. Because if you can't do it yourself, it's obviously a usability problem, right?

    Right.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.