How to get around the main difficulties when porting CAD applications to nanoCAD?
At the end of October 2014, the 10th anniversary conference “Software Development, CEE-SECR-2014” was held in Moscow, at which our report on the creation of cross-CAD platform applications was presented. The report consisted of a historical review, a story about the experience of porting CAD applications to nanoCAD and an analysis of the main difficulties in porting. In this article we will not dwell on the first two parts of the report - the entry is published at the end of the article, and we will examine in more detail the third part, finalized based on the results of the discussion on the sidelines of the conference.
When we started developing nanoCAD in 2008, we already had more than two dozen applications for AutoCAD. Work on porting applications was carried out in parallel with the development of a new CAD platform, application requirements to a large extent determined the direction of development. As a result of porting, the applications became cross-CAD-platform, earned money in nanoCAD and did not lose the opportunity to work in AutoCAD.
In the process of porting our own applications, as well as in the process of communicating with third-party application developers as part of the nanoCAD Developers Club, we found several duplicate patterns that prevent efficient porting:
- Waiting for the API to grow
- Reluctance to use a workaround that works on all systems
- Side effects
Template 1. Waiting for the API to “grow”
From time to time, we are faced with the fact that after the first unsuccessful attempt to port an existing application, the developer disappears, at best, writing: “I will wait until you finish the API”, without informing what exactly happened. Fortunately, not everyone does this, and with every nanoCAD release, we publish a list of API improvements requested by members of the nanoCAD Developers Club through the Club bug tracker.
Our experience shows that all applications mainly use the same API functions, but each application has its own specific needs. This situation is depicted schematically in the figure, where the central part is a common API, and the “paths” are specific needs. The diagram shows that the implementation in nanoCAD of specific functions for one application, as a rule, does not lead to the appearance of specific functions needed by another application.
This makes it clear why the “Wait until the API grows” approach does not work: if we do not know about the existence of a compatibility problem, it will not be fixed.
Solution: Register at the Developers Club and create tasks for revision in the bugtracker.
Template 2. Reluctance to use a workaround that works on all systems
The original image
Strictly speaking, this template is a special case of template 1, but it is so common that it makes sense to consider it separately.
Often there is a workaround that works across all CAD platforms. In this case, the request for revision is likely to be delayed, since it is obvious that other problems that do not have workarounds have a higher priority.
Solution: Is there a workaround? Use it!
Pattern 3. Using side effects
Original image
Side effects are different on different CAD platforms.
Abstract example: A print function is found to be able to multiply numbers. You should not use it for multiplication, in another platform this effect may not be.
Life example: In ObjectARX, after closing an object using pEntity-> close (), you can call some methods of an already closed pEntity object. This is contrary to the ObjectARX documentation, but works. In nanoCAD, after calling pEntity () -> close (), the object is destroyed and subsequent calls cause it to crash. If the application is brought into compliance with the documentation, it starts working on both platforms.
Solution: No side effects! Use the functionality for its intended purpose.
conclusions
Small applications that use the common part of the API can be ported to nanoCAD with little or no change.
Porting a complex application often requires both updating the missing functionality from the platform and making changes to the application. These changes, as a rule, are in the nature of refactoring and do not lead to loss of compatibility with AutoCAD. As a result, the resulting application is built from one source code for both nanoCAD and AutoCAD.
The bug club of the Developer Club is a way to influence the development of the nanoCAD API. The more developers vote for a particular API function, the sooner it will be implemented.
Report Recording and Presentation
Link to the presentation: www.slideshare.net/islobodin/ceesecr2014-41467249 .
You can also discuss the article on our forum .
PS In addition to the last slide, we cannot but share the link to the article “CAD in the USSR, or Kievnauchfilm presents” , which would certainly have got into the presentation if it had been published before the report.