Topic: 20.0

[MeasureUp]

Supposedly r2015 version number is to be 19.2 as r2014 to 19.1
Heard that it jumpes to 20.0 for r2015

[Crank]

That's correct. AutoCAD 2015 breaks with the 3 years cycle.
The file format is still AutoCAD 2013, but you'll have to recompile your code

[gile]

Hi,

Only ObjectARX/C++ codes need to be recompiled, .NET apps targeting A2013 or A2014 work on A2015 w/out recompiling.

[irneb]

Oh, so they've now broken the file version adherence to the release number. Does this mean the next file version would be 20.1 = 2016? Or will they re-invent number theory when they burn that bridge?  I can see a few tools which will go screwy due to this.

[Kerry]

Oh, so they've now broken the file version adherence to the release number. Does this mean the next file version would be 20.1 = 2016? Or will they re-invent number theory when they burn that bridge?  I can see a few tools which will go screwy due to this.

I think we have enough to concern ourselves with now without worrying about something as inconsequential as this until we have enough data to make a rational decision. Trying to determine our actions based on second guessing random events leads to almost certain disaster.

If you asked AutoDesk for an answer I'm positive the response will be "We don't comment publically on future releases."

[irneb]

I think we have enough to concern ourselves with now without worrying about something as inconsequential as this until we have enough data to make a rational decision. Trying to determine our actions based on second guessing random events leads to almost certain disaster.

I understand fully.

Though I'm not only referring to the future. It would already break some current stuff. E.g. if a tool is figuring out which version of file by reading the R number and only looking at the integer part - it'll not get the correct picture.

I just thought I'd put it out there as a warning. So I'll now pop me some corn and watch as people thread about tools which worked perfectly before - "suddenly" not doing what they used to.

[irneb]

Actually ... just thought of something more prevalent than file versions: What about command-line options? Many routines (especially the lisp stuff) check acadver to figure how the options need to work for various versions of acad.

Anyone know of something changed from 2012 to 2013-15? And can you think of anything in the pipeline about future command options? So many of the lisp routines using something like this might find issues:

Code - Auto/Visual Lisp: [Select]

1. (cond
2.   ((< (atoi (getvar "acadver")) 19)
3.    ...
4.   )
5.   ((< (atoi (getvar "acadver")) 20)
6.    ...
7.   )
8. )

They'll need to change to something like:

Code - Auto/Visual Lisp: [Select]

1. (cond
2.   ((< (atoi (getvar "acadver")) 19)
3.    ...
4.   )
5.   ((< (atof (getvar "acadver")) 20.15)
6.    ...
7.   )
8. )

Oh the joys of using "magic" numbers 

[Marc'Antonio Alessi]

This is my table also for Bricscad:

Code: [Select]

(cond
  ( (> (atof (getvar "ACADVER")) 19.1 ) (setq #AcVer "R20"  ) ) ; = 20.0 A2015
  ( (> (atof (getvar "ACADVER")) 19.0 ) (setq #AcVer "R19_1") ) ; = 19.1 A2014
  ( (> (atof (getvar "ACADVER")) 18.2 ) (setq #AcVer "R19"  ) ) ; = 19.0 A2013 - Bricscad V14.1 "19.0 BricsCAD"
  ( (> (atof (getvar "ACADVER")) 18.1 ) (setq #AcVer "R18_2") ) ; = 18.2 A2012
  ( (> (atof (getvar "ACADVER")) 18.0 ) (setq #AcVer "R18_1") ) ; = 18.1 A2011 - Bricscad V13 "18.1 BricsCAD"
  ( (> (atof (getvar "ACADVER")) 17.2 ) (setq #AcVer "R18"  ) ) ; = 18.0 A2010 - Bricscad V12 "18.0Bricscad"
  ( (> (atof (getvar "ACADVER")) 17.1 ) (setq #AcVer "R17_2") ) ; = 17.2 A2009 - Bricscad V11
  ( (> (atof (getvar "ACADVER")) 17.0 ) (setq #AcVer "R17_1") ) ; = 17.1 A2008 - Bricscad V10   
  ( (> (atof (getvar "ACADVER")) 16.2 ) (setq #AcVer "R17"  ) ) ; = 17.0 A2007 - Bricscad V9
  ( (> (atof (getvar "ACADVER")) 16.1 ) (setq #AcVer "R16_2") ) ; = 16.2 A2006
  ( (> (atof (getvar "ACADVER")) 16.0 ) (setq #AcVer "R16_1") ) ; = 16.1 A2005
  ( (> (atof (getvar "ACADVER")) 15.06) (setq #AcVer "R16"  ) ) ; = 16   A2004
  ( T                                   (setq #AcVer "R15"  ) ) ; = 2000 2000i 2002
)


[roy_043]

This is my table also for Bricscad:
...

For BricsCAD using _VERNUM is easier:

Code: [Select]

(getvar '_vernum) ; => "14.2.09 (UNICODE)"

[ChrisCarlson]

Why err how does the version number of AutoCAD affect past and present lisp routines?

[BlackBox]

Why err how does the version number of AutoCAD affect past and present lisp routines?

Version dependent calls to vla-GetInterfaceObject come to mind. 


Although, as a generalization, (substr (getvar 'acadver) 1 2) is often sufficient.

Cheers

[irneb]

Why err how does the version number of AutoCAD affect past and present lisp routines?

Another where this version numbering would help though is when loading a specific ARX. E.g. loading the correct OpenDCL.ARX. And I think that is why Adesk did this - to make it simpler to figure which ARX to load. But now it's disconnected from many of the other stuff - e.g. DotNet DLL's.

But we're all used to these types of inconsistencies aren't we? This is probably rather minor in the greater scheme of things going different between versions. 

[Marc'Antonio Alessi]

This is my table also for Bricscad:
...

For BricsCAD using _VERNUM is easier:

Code: [Select]

(getvar '_vernum) ; => "14.2.09 (UNICODE)"

Thanks Roy, I use this for AutoCAD/Bricscad and Doslib:

Code: [Select]

(defun ALE_Doslib (BitFlg / ArxNam PrcArc AcaVer)
  (setq
    AcaVer (getvar "ACADVER")
    PrcArc (getenv "PROCESSOR_ARCHITECTURE"); restituisce "AMD64" anche su processore Intel e "x86" su 32 Bit
    ArxNam
      (cond
        ( #BCFlg  ; is Bricscad
          (if (eq "x86" PrcArc)
            (cond
              ( (= 17.1 (atof AcaVer)) "DOSLib10.brx"); V10   "17.1 Bricscad"
              ( (= 17.2 (atof AcaVer)) "DOSLib11.brx"); V11   "17.2 Bricscad"
              ( (= 18.0 (atof AcaVer)) "DOSLib12.brx"); V12   "18.0Bricscad"
              ( (= 18.1 (atof AcaVer)) "DOSLib13.brx"); V13   "18.1 BricsCAD"
              ( (= 19.0 (atof AcaVer)) "DOSLib14.brx"); V14.1 "19.0 BricsCAD"
            )
            (cond
              ( (= 18.1 (atof AcaVer)) "DOSLib13x64.brx"); V13   "18.1 BricsCAD"
              ( (= 19.0 (atof AcaVer)) "DOSLib14x64.brx"); V14.1 "19.0 BricsCAD"
            )
          )
        )
        ( (and
            (< 1 (strlen PrcArc))
            (eq "64" (substr PrcArc (1- (strlen PrcArc))))
          )
          (strcat "DOSLIB" (itoa (atoi AcaVer)) "x64.ARX")   ; DOSLib18x64
        )
        ( T (strcat "DOSLIB" (itoa (atoi AcaVer))  ".ARX") ) ; DOSLib18
      )
  )
  (if DOS_COPY
    (if (= 0 BitFlg)
      (arxunload ArxNam nil)
    )
    (if (= 1 BitFlg)           ;if DOSLib non è gia' caricato
      (if (findfile ArxNam)
        (arxload ArxNam nil)
        (prompt "\nDOSLIB not found. Verify your Asso Tools folders. ")
      )
    )
  )
)but I do not really like, is there anyone who has something more concise?

[Kerry]

< .. >  is there anyone who has something more concise?

No hoop jumping to Demand load both those.


After Installation of OpenDCL
(command "OpenDCL") in one of the Autoloading files.


After initial drag and drop or appload of Doslib
(dos_demandLoad T)

[roy_043]

"Processor_architecture" is probably not the best way to determine if a 32 or 64 bits version of the CAD program is running. This has been discussed before on this the BricsCAD forum:
http://www.bricsys.com/common/support/forumthread.jsp?id=17883