Share
 
 

Release Notes

These items are related to this release of ObjectARX and the AutoCAD Managed Classes.

ObjectARX API Compatibility

AutoCAD 2025 breaks binary compatibility with AutoCAD 2021 through AutoCAD 2024. ObjectARX applications developed for AutoCAD 2024 and earlier releases must be recompiled before they can be used with AutoCAD 2025-based products.

Managed .NET API Compatibility

Managed .NET applications should be updated to target .NET 8.0 for AutoCAD 2025 rather than the previous supported version of 4.8 .NET Framework. In addition to changing .NET versions and prior compiling your project, the following needs to be added to the ItemGroup element of your CSPROJ or VBPROJ file: 

<FrameworkReference Include="Microsoft.WindowsDesktop.App"></FrameworkReference>

Development Environment

Microsoft® Visual Studio® 2022 version 17.8.0 must be used when compiling ObjectARX projects for use with AutoCAD 2025. Applications that require the use of Microsoft .NET should target the 8.0 version.

Linker

The Linker is *25.lib.

Registry Key

The Registry key has changed from "R24.3" to "R25.0".

Changes to the AcString Class with Variadic Functions

Changes made to the AcString class may require you to update your programs when using functions, such as printf() and similar style of functions. Previously, AcString was just a pointer and could be passed by value to a variadic function.

To resolve this problem, in most cases you just need to use the constPtr() function of the AcString class. For example, the first code statement below shows the code statement that worked in earlier releases prior to AutoCAD 2025, while the second statement shows the use of the constPtr() function to resolve the problem. 

// Problem statement
acutPrintf(ACRX_T("\nBlock %s converted %d results"), blkName, it->second);

// Updated statement
acutPrintf(ACRX_T("\nBlock %s converted %d results"), blkName.constPtr(), it->second);

For more information, see the Autodesk ObjectARX for AutoCAD 2025: Migration Guide.

Changes to the acgi.h file

An include for the dbpl.h file has been removed from the acgi.h file. Includes for dbpl.h have been added to the following files to help avoid errors when recompiling existing programs:

  • dbdim.h
  • dbents.h
  • dbsymtb.h
  • dbxutil.h
Note: If your programs rely on members in dbpl.h but you only previously had an include for acgi.h, you will need to update your existing programs to now include dbpl.h.

For more information, see the Autodesk ObjectARX for AutoCAD 2025: Migration Guide.

Changes to the dbmain.h file

An include for the dbmain.h file has been removed from the acgi.h file.

Note: If your programs rely on members in dbmain.h but you only previously had an include for acgi.h, you will now need to add an include for dbmain.h before recompiling your programs.

Additionally, the AcCmColor class has been removed from dbmain.h and added to a new header file named AcCmColor.h. This change is meant to help reduce the number of headers that are included in your programs. An include to AcCmColor.h has been added to dbmain.h to avoid problems when recompiling existing programs. If you need to work with the AcCmColor class in new programs, add an include to either AcCmColor.h or dbmain.h based on your needs.

For more information, see the Autodesk ObjectARX for AutoCAD 2025: Migration Guide.

Global Function Changes in the dbmain.h file

The following global functions and classes were moved from the dbmain.h file into the new acutacstring.h and dbObject.h files:

  • acutacstring.h
    • acutAcStringToAChar() function (2 overloads)
    • acutGetAcStringConvertToAChar() function (2 overloads)
  • dbObject.h
    • AcDbObject class
    • acdbOpenObject() function (5 overloads)

For more information, see the Autodesk ObjectARX for AutoCAD 2025: Migration Guide.

AcGiContext Class vtable Changes with AutoCAD 2022 Update 1 and 2

A shift in the vtable related to the member functions of the AcGiContext Class was made that may impact the compatibility of programs built for AutoCAD 2022, and loaded into AutoCAD 2022 with Update 1 or 2 installed. One of the functions affected is forceUseFillTrait(). This issue isn’t a binary compatibility problem with the SDKs or programs built for AutoCAD 2022 as they should load and run in AutoCAD 2023 as expected. The solution is to install the latest update for AutoCAD 2022.

Clear the Clipboard Before Calling LoadCatalogs()

It's strongly recommended to call the Clipboard.Clear() method to clear all current catalogs from the Tool Palettes Manager and empty the clipboard prior to loading new catalogs with the LoadCatalogs() method.

The following code demonstrates how to clear the Clipboard prior to loading the new catalogs. 

public void ClearClipboardAndLoadCatalogs()
{
    IDataObject dataObj = System.Windows.Forms.Clipboard.GetDataObject();
    string[] fmts = dataObj.GetFormats();
    bool bFound = false;
    foreach(var fmt in fmts)
    {
        if (fmt.IndexOf("ACTC") != -1)
        {
            bFound = true;
            break;
        }
    }

    if (bFound)
    {
        System.Windows.Forms.Clipboard.Clear();
    }

    Autodesk.AutoCAD.Windows.ToolPalette.ToolPaletteManager.Manager.LoadCatalogs();
}

32-Bit Application Support

Starting with AutoCAD 2020, 32-bit support is no longer available.

Icon Transparency Support

In AutoCAD 2017 and later, opaque bitmap images that still use RGB 192,192,192 as their background color are no longer supported. It is recommended that these bitmap images should be converted to transparent PNG images.

Changes to AcDbDatabase::saveAs() API

Starting with AutoCAD 2016, DWG files can no longer be saved with passwords. The password will be ignored and will return an error if any password information is passed in the pSecParams parameter.

Support for Microsoft® Visual Basic® for Application (VBA) 7.1

Starting with AutoCAD 2014, VBA 6.5 was replaced by VBA 7.1 which was designed for both Windows 32 and 64-bit operating systems. As a result of this change, the AutoCAD ActiveX library was updated to remove methods and properties that were originally defined to support Windows 64-bit. VBA projects that rely on the use of 32-bit libraries and controls will need to be updated to properly run on AutoCAD 64-bit.

Changes to the Adesk::Boolean, Int32 and UInt32 Types in Native C++ ARX, and Possible DWG File Compatibility Issues

This applies to developers using native C++ ARX and the Adesk namespace. Until now, in Windows, the Adesk::Boolean type has been defined (typedef-ed) as int. This was for historical reasons, as the earlier compilers did not support a native bool type. The Adesk::Int32 and UInt32 types have been defined as long and unsigned long, respectively. On the Mac platform, however, Adesk::Boolean has always been defined as bool, and Adesk::Int32 and UInt32 have always been defined as int and unsigned int.

As of this release, however, the Windows types match the Mac types, so that Boolean is always defined as bool and Int32/UInt32 are always integer/unsigned integer. See the definitions in adesk.h. This provides consistency across platforms and better type checking.

Code which uses only the Adesk types should not be affected. But, code which uses a mix of Adesk types and other types (such as native int and bool, or Win32’s BOOL) may encounter some compiler warnings or errors. For instance, you might have a function which takes an (int &) or (int *) argument, and you were passing an Adesk::Boolean variable to it. This will now cause a compiler error, because the variable’s type was previously int and now is bool. The fix would be to change either the variable type or the function’s arg type, depending on which makes more sense in your code.

A more subtle problem involves the AcDbDwgFiler::writeItem() and readItem() methods (see dbfiler.h). These are "helper" overloads which forward the call to lower level methods such as writeInt32, readBool, etc. Again, if your code is only using Adesk types, then things should work as before. But if you have variables declared as type int or BOOL, and you are calling writeItem and readItem on them, then this may cause a file compatibility error. Previously, such calls resolved to writeBoolean and readBoolean, but now they will resolve to writeInt32 and readInt32. This will cause a difference in the binary data format being read and written by your readItem and writeItem calls. Note that there might not be any compiler warning or error message in this case.

The way to detect such problems is to verify that your rebuilt code still correctly reads drawing files which were created by previous versions of your code, and conversely, that previous versions of your code correctly read drawing files that are created by your new code. If the problem occurs, then you may get warnings from AutoCAD while the drawing is being opened that says the objects were improperly read. This testing should always be done when porting to a new SDK version, but it’s especially important now.

The recommended fix for these problems is to change the variable from int or BOOL to type bool, or to type Adesk::Boolean. It is also a good idea to call the lower level readInt32, writeBoolean etc methods directly rather than the readItem and writeItem overloads, just to make it clearer what types your code is working with.

Was this information helpful?