|
I just wanted to see why I should go to Office 2016 and found this: 13+ Reasons You Should Upgrade to Microsoft Office 2016[^].
Looking at it I just could not see any justification. I would love it if they would allow you to use C# or Visual Basic instead of vba for macro programming. I recently did some coding and it was such a pain because vba now has very little in common with even Visual Basic.
I would like to have a more reasonable listing for addresses, phone numbers, email address, etc. You cannot have an arbitrary number and no custom labels. Also the display is just as rigid as it was in 1997.
The location on the appointments has no flexibility, such as being able to use web lookups for things like restaurants, or local lookups for items in your address book.
What the hell has Microsoft Office group been doing for the last 20 years. Not much from what I can tell.
|
|
|
|
|
|
This is why Office365 is sold on a subscription basis. They have made so few real enhancements to Office over the years many people just don't update it. I have an old version, about that age actually, that works just fine for me and it will not be updated.
|
|
|
|
|
The only reason to go as high as 2007 in my mind is that is when they started using XAML for storage. Sure to have compatibility with programs that access the files.
I upvoted you.
|
|
|
|
|
I'm still on Office 2007. It's paid for. I don't see why I should pay repeatedly for 'features' that I'll never use. Also (and I hate to admit it but), all of my 'home' applications (media library, contacts list, accounts, etc) are written in MS-Access because it has a reasonable database for single user usage, good front-end, and adequate programmability - or at least it was in 2000 when I originally wrote them (in Office 97). I can get a free database engine and write everything in a free language e.g. C#; but what is the point of rewriting something that has work well for nearly two decades and any mods can be done directly in one place without needing compilers etc; especially just so I can pay for unwanted features. So, I agree with the others who say stick with Office 2007- I'm beginning to get used to the new (in 2003) ribbon UI as the old menu short cuts still work.
|
|
|
|
|
Actually I am on 2016, but that is only because I basically got it for free. Was on 2010 for the longest time.
Ribbon was the stupidest thing that Microsoft ever came up with. Basically just a fancy toolbar, and when originally implemented did not even have the ability to customize which absolutely sucked since they got rid of the menus and the only way to get to things was the Ribbon. Ribbon is fine for simple programs, but for complex ones it just has its limitations. Funny is that you see menus all the time in web apps including this one (codeproject).
I also use access. It does what it needs to do in one nice compact file which includes the macros. My problem is that, as stated, VBA is so different from anything current and struggled significantly with the syntax.
|
|
|
|
|
jsc42 wrote: and I hate to admit it but
It's a real pity that Access gets such a bad reputation around here when, as you mention, it works quite well for single-user apps...especially as just a simple datastore, without the VBA. Since we're confessing, my company still offers Access (v. 2002) as a database option for smaller customers.
In fact, I'm aware of one company that still uses access 97 for a commercial inventory system.
"Go forth into the source" - Neal Morse
|
|
|
|
|
The first company I worked for, had the whole personal management for worked hours / holidays and so on in Access for all 20+ workers.
It worked quite fine, I had only one problem in the over 2 years I worked there.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
|
15 years old now LOL. And I am not happy since I have to work with Visual Studio 2013. LOL. Actually I was not too big on this upgrade and thought 2010 was about as good, but really like what was added to Visual Studio 2015.
|
|
|
|
|
|
No question in my mind that 2012 and 2013 were a waste. Did think that 2015 added some really good stuff to C#.
|
|
|
|
|
PIEBALDconsult wrote: VS 2010 was the peak.
Agreed! which is why I still use it when I can...still does almost everything I need and starts fast. I can have multiple projects open without the crippling my main workstation...not so with 2015 which seems to have a lot more overhead. I've started using 2017 occasionally and it seems much better than 2015 as far as resource usage.
As for Office, I switched around 5 years ago to Office 365...works for me as all 5 licenses are being used. I only keep two older Office products around...Access 2002/3 and Photo Editor. I really can't stand the UI in Access 2007+, however I've just found the tab view option that might just convince me to drop the older version. (WU always has issues with it anyhow)
"Go forth into the source" - Neal Morse
|
|
|
|
|
Only 1 reason I can think of - everything is synched across all platforms. Not sure if this was ever achieved in earlier versions.
And yes it pisses me off having to buy it every year for no benefit. When I have time I may well look for an alternative platform.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Well, yes, as many have pointed out the basic functionality has been there for a great many years.
Form a user's point of view, there's really a limit to how much genuinely useful stuff you can add to a spreadsheet or a word processor.
From a developer's point of view, there's a gaping hole where a good API should be.
98.4% of statistics are made up on the spot.
|
|
|
|
|
Very true, and you can see that they have not upgraded VBA, nor added security features so that you can have different levels of risk. Still you cannot add a background to Excel, which really sucks since you could scan an form, and then put the input fields in the foreground. Also I find the search in Excel to not be very good. In word they still have the same horrible format box from 20 years ago. Lots of things they could do.
The one I think is horrible are the improvements they could make in Outlook. Not really fond of their focused emails.
|
|
|
|
|
Yes, the search in Excel is ghastly!
As far as VBA goes, it has clearly been abandoned but it can't be formally deprecated as it hasn't been replaced. Yes, there's lots of stuff that has been effectively replaced by VSTO/VSTA, but the Visual Studio approach doesn't cater for the kind of power-user who used to chuck a bit of automation at their spreadsheets directly through Excel. As such, there's a whole heap of VBA/VB6 out there which is now completely insecure but still alive because people haven't really figured out how to replace it.
98.4% of statistics are made up on the spot.
|
|
|
|
|
Also, the nice thing about VBA is that it goes with the file, and is not something separate. Lot easier also just to throw a simple macro together, and Excel and Word have recorders making it even easier
|
|
|
|
|
PeejayAdams wrote: Visual Studio approach doesn't cater for the kind of power-user who used to chuck a bit of automation at their spreadsheets directly through Excel.
Having done some of both, I must concur that VSTO doesn't fully replace VBA. OTOH, there is relatively little that can't be accomplished fairly readily with VBA as it is today. Conversely, if security is an important consideration, as well it should be, a seasoned VBA programmer can work the same kinds of magic with VSTO, and it isn't really all that hard. Once you add a reference to the correct object model, IntelliSense helps immeasurably with the interactions with Excel, and the rest is plain old C# or VB.NET. More significantly, it's comparatively easier, IMO, to construct C# applications that talk
to two or more Office products.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
Clifford Nelson wrote: What the hell has Microsoft Office group been doing for the last 20 years. Not much from what I can tell.
That's why they're still ptofitable!
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Which is the reason that Microsoft wants to sell subscriptions and not products
|
|
|
|
|
So I brought our entire system to it's knees yesterday. What did I do? I entered some text into a varchar column in one of our database tables.
Why was that bad? When this column was created it originally held text, but then somebody decided that this text would be better served in a lookup table. Instead of creating a new column for the lookup key (an integer), they simply changed each value in column to its corresponding number in the lookup table.
And then they created views that join the table and lookup table which our company's programs tightly couple to. Microsoft, in their ever unceasing efforts to be helpful says you can join a varchar column to an integer column - so long as EVERY item in the varchar column casts to an integer. But if there is even one row that doesn't cast ... <rant>Why they couldn't cast the integer column to a varchar for us, only Microsoft can answer that.<end rant="">
So, to make a long story short, I added my text as a new lookup item and now there is a number where my text used to be and everything and everybody is happy again.
Brent
|
|
|
|
|
Because it's handled as a transaction.
And it needs to cast each and every value in the column to find out if there is a match for the join, and when it can't it throws an exception.
There's just one thing that's wrong with that.
If you make a join between an int and a varchar it wouldn't make a narrowing conversion on the varchar to int. It would make a widening conversion of the int to a varchar.
Which wouldn't throw any exceptions.
So I assume the join in the view contains an explicit cast to integer.
<edit>So there are at least three errors happening here</edit>
|
|
|
|
|
Jörgen Andersson wrote: If you make a join between an int and a varchar it wouldn't make a narrowing conversion on the varchar to int. It would make a widening conversion of the int to a varchar.
Nope - int has a higher precedence than varchar . If you try to join int to varchar , SQL will try to convert all values to int .
Data Type Precedence (Transact-SQL) | Microsoft Docs[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
F*** me, you're right.
But why?
|
|
|
|