compare 2013 & 2014

my company traditionally spend a long time evaluating our "next" version of AutoCAD so we are usually several years behind. We got 2013 last year so I wasn't expecting anything soon but I notice Autodesk are sort of forcing us to move.

Bottom line, by next February we have to change to 2014 (yes, I know 2016 will probably be in full swing by then but we are company driven).

Is there anything I should be weary off before I commit? We have been promised an install that will include VBA so hopefully our routines will continue to work. Does the "export 2013 custom settings" import in to 2014?

AutoCAD360/Autodesk360 integration, and SECURELOAD are the two biggies to be aware of IMO.

360 will try to sync drawings and settings to "the cloud" and even if the user opts out during installation, the components are still installed. Uninstalling AutoCAD360 after the fact can cause the Properties Palette to stop functioning (similar to what sometimes happens when using a registry cleaner)

SECURELOAD is a new security feature that will pop up a warning when trying to load executables/lisps/VBA. You can disable the feature entirely, otherwise you have to add the path to these files to the TRUSTEDPATHS to have them load automatically.

Other than that, I don't think 2013 > 2014 caused any major headaches... but enjoy it while it lasts... 2015 is a different story.

Thanks nestly. Our parent company is very anti cloud based software so we may get an installation without those "luxuries". I'll keep an eye out for them though.

In view of the speed that updates usually arrive (I am sure this one has been prompted by AutoDesk's revised upgrade model) it might be a close thing between me retiring and the company getting 2015.

You can migrate settings from a previous release.

For an in-depth review of new and/or enhanced features, etc. in AutoCAD 2014 read this...

http://www.jtbworld.com/autocad2014.htm

More information than the average user will ever want to know.

Who does the review of new AutoCAD releases in your company, Congress? That would explain the inordinate amount of time it takes I suppose.

I didn't have any trouble when "migrating" settings from 2013 > 2014, but I did with 2015

Print and circulate in your office. At least you'll get a running start.

http://lynn.blogs.com/ACAD2014_TipsnTricks_final.pdf

Your VBA Engine in AutoCAD 2013 was VB6 and 32 bit regardless of if you are running AutoCAD 64 bit. In AutoCAD 2014 and later the VBA Engine is VB7.1 which is only available in a 64 bit version. That means you will most likely have to upgrade all of your VBA software.

The main problems are that no 32 bit controls will run in VB7.1, the database Jet Engine (MS Access) is not supported and certain 'commands' such as SHELL are no longer available. Most of the 32 bit controls have 64 bit equivalents, but not all, such as the progress bar and the common dialogs, which means you have to resort to the Windows API to implement file opening, saving, etc.

Regardless what you decide you have some work in front of you, did you ever get any of your VBA stuff migrated to VB.NET?

B.

The main problems are that no 32 bit controls will run in VB7.1...

Migrating to .NET would certainly help here, as .NET supports Any CPU, x86, and x64 compiling for environment-dependent assemblies, and with the advent of dynamics one is no longer relegated to early/late-bindings for COM-dependent API calls.

What I'm most intrigued by, but have no time to pursue at the moment, is Core Console's (aka AcCoreConsole.exe, AcCore.dll) ability to be run in parallel (aka multi-threaded), as well as sequential (single-threaded, like Acad.exe) for batch processing... As an ambigious example, you saw production gains when you first took that manual procedure and automated with VBA, iterating through drawings performing the same task in each, one-by-one... Now imagine performing same, all at once.

/OffTopic

Cheers

OH DEAR. Thanks Tyke & BB.

That is indeed a show stopper. We have one bit of VBA that I haven't managed to migrate that is used on just about every drawing along with the drawings we get done by another family member in another part of the world. I feel the need for an email to all DO points coming on.

I have two problems with translating this code. The first being that I have forgotten just about everything I ever knew about .Net programming. The second being I know I hit a wall trying to convert the program but can't remember where. Looks like I have a busy couple of months ahead. Oh, third problem. We have to account for every minute of the day on our new timesheets and there isn't a "helping improve throughput" booking code.

OH DEAR. Thanks Tyke & BB.

 

That is indeed a show stopper. We have one bit of VBA that I haven't managed to migrate that is used on just about every drawing along with the drawings we get done by another family member in another part of the world. I feel the need for an email to all DO points coming on.

 

I have two problems with translating this code. The first being that I have forgotten just about everything I ever knew about .Net programming. The second being I know I hit a wall trying to convert the program but can't remember where. Looks like I have a busy couple of months ahead. Oh, third problem. We have to account for every minute of the day on our new timesheets and there isn't a "helping improve throughput" booking code.

Don't fret.

Just because 2014 is available - well, so is 2015, and we're testing 2016 - the point is, just because something new is available doesn't mean you need to implement it. If you're on subscription, that's fine, as you can still 'produce' in whatever version you have licensing for.

As for customization, it's a double edged sword as you've correctly identified... To implement such an positive impact on production easily yields dependent users... The implicit responsibility, is the ongoing maintenance (if not enhancement as APIs evolve) required to continue such a dependency.

Code does not write itself any more than drawings manifest 100% accurate designs whilst user is in the break room sipping their morning tea/coffee, and management needs someone to manage their expectations as to this fact, that it is not a one-time, written in stone, all supporting efficiency initiative, and they should be prepared for what is required to perform such per annum (or whatever your anticipated version update schedule may be).

You may have already done all of this, but if not, I'd tactfully grease those skids post haste.

Cheers

Don't fret.

 

Just because 2014 is available - well, so is 2015, and we're testing 2016 - the point is, just because something new is available doesn't mean you need to implement it. If you're on subscription, that's fine, as you can still 'produce' in whatever version you have licensing for.

For some reason we operate by Panic management. I am sure I can get a booking code once the "it doesn't work" date has passed, but not before.

I get the feeling Dave is TOLD what version he has to use, not that he has a free choice. One of the drawbacks of working for a large multi-national.

I don't know how much VBA Code you have, but surely someone has to see that not updating it is somewhat counter productive and there must be a catch-all code on the time sheet that you can stick it all in. Have a word with the boss and see if he will back you on the updating front. When I updated my code it was a matter of finding the problems by running the old code and seeing what problems cropped up. Some of the old code ran without any modification and when a problem did crop up it was just a matter of noting down the solution and reusing it again when the same problem cropped up elsewhere. If you get stuck on a point, post it up here and we'll get it sorted for you.

I get the feeling Dave is TOLD what version he has to use, not that he has a free choice. One of the drawbacks of working for a large multi-national.

The other problem of a large multi national is that each PM has to keep to a budget and no one is willing to let a bit of "company good" come off their bit. If I wasn't so ambivalent about it I would get really frustrated. You can only work for such a company if you are willing to use the SEP field rather than take it personally.

http://en.wikipedia.org/wiki/Somebody_Else's_Problem

The other problem of a large multi national is that each PM has to keep to a budget and no one is willing to let a bit of "company good" come off their bit. If I wasn't so ambivalent about it I would get really frustrated. You can only work for such a company if you are willing to use the SEP field rather than take it personally.[/url]

I am so glad that I have it all behind me now, I'm my own boss and I decide what and when it shall all be done and I have to accept the EMP field (Everything's My Problem). I quite like it actually. I also get to tell the troublesome client that he can stuff his job where the monkey stuffs its nuts, and that is extremely satisfying. Workload? Far too much at the moment, I'm turning jobs down because I don't have the capacity to do them.

You are of course correct.

 

The other problem of a large multi national is that each PM has to keep to a budget and no one is willing to let a bit of "company good" come off their bit. If I wasn't so ambivalent about it I would get really frustrated. You can only work for such a company if you are willing to use the SEP field rather than take it personally.

 

 

http://en.wikipedia.org/wiki/Somebody_Else's_Problem

Having also worked for a large international firm, sometimes the fastest way to get your way, is to let their idea fail ... And then follow up that failure with, 'now here's how we fix it'... To which those whom like their positions generally reply with a 'yeah, great idea. Let's do that'.

Having also worked for a large international firm, sometimes the fastest way to get your way, is to let their idea fail ... And then follow up that failure with, 'now here's how we fix it'... To which those whom like their positions generally reply with a 'yeah, great idea. Let's do that'.

But back to my problem - to summarise.

Any code I have running in vb.net should continue to work. Any code I have running in VBA will need investigating. Is that a fair summary?

But back to my problem - to summarise.

 

Any code I have running in vb.net should continue to work. Any code I have running in VBA will need investigating. Is that a fair summary?

That is correct , all of your VB code will continue to function. Some of your VBA code could still run, it all depends what you have in there, but it could well be some of your VBA code might need to be tweaked a bit.

Thanks Guys,

I have asked if the two can be run side by side to allow me time to investigate. I will see what the head man says. If that's not recommended I'll probably install over Christmas and hope there's a spare machine available if I need it.

And I'll dig up the VB.Net guide book I have and start reading it again, again.

I set up our 2015 pretty quick, we have all our own stuff in partial menu's so a simple menuload, all the config stuff is via a lisp so all the pathing and printers work straight away. We continued to use our default dwt and it seemed ok CIV3D. We loaded our ARG and then customised an icon to point to correct profile. We make a user workspace for each person they like certain toolbars etc making sure save changes is not ticked on.

Down side our pc's do not run 2015, graphics card is not supported after 15 mins it starts so we could at least set it up and test. As we need around 10 pc's its a corporate upgrade so we keep working on 2013. Also we are happy were we are at performance etc

2013 to 2014 was not a big jump for me. 2015 crashes and won't open for me (even after uninstall/reinstall) so have had to stick with 2014.