Creating software is a difficult, highly skilled, professional occupation; it sometimes can make rocket science seem comparatively easy. You need to be confident that you are able to deliver, particularly if you are being commissioned to author a solution for somebody else. They won’t thank you if you make a mess of things, and you may not thank yourself either. However, there are many ways in which you can acquire real confidence in your abilities to author Impact automation and integration solutions.
Having Confidence
Training
Arden offers training courses on the specifics of our automation interface and solution development in order to fully equip you to be able to effectively leverage its power. Our in-house team of fully-qualified and highly experienced software engineers are always keen to share their secrets, and are here to help and motivate you. Your success is as important to us as it is to you.
Other Qualifications
Authors need to have an understanding of general software development analysis and design processes, together with knowledge of the technologies and languages they may use. Many academic institutions and bodies such as Microsoft offer certification and degree courses and training. You may already have relevant qualifications and transferable skills.
Professionalism
We encourage authors who wish to take the occupation seriously to become a member of a professional body such as the IEEE Computer Society, the Association for Computing Machinery (ACM), or the British Computer Society (BCS). Such bodies ask their members to follow a code of conduct/best practice on such matters as confidentiality, competency, fairness, quality, responsibility and integrity, and offer support and protection to both their members and those that employ them.
Ability
Authors may need to have an understanding of the industry, together with a mathematical/CAD background, in order to efficiently and effectively utilise the features in the automation interface.
Fun
Having said all that, whilst challenging, authoring solutions using our technology is extremely rewarding and fulfilling. Don’t forget to enjoy the experience.
About The Interface
In order to allow you to write macros, scripts and plugins that can automate and integrate our software with other systems, we provide a programming interface for you to use.
IML vs COM
Our first attempt at such an interface, the Impact Macro Language (IML), was powerful but ultimately limited by the technologies available at the time. It has been superseded by Impact COM and nServer, which uses Microsoft’s industry standard Component Object Model (COM) technology. Although authors can still use macros, we no longer support or develop the IML. You should use Impact COM and nServer for all new Impact Automation projects.
Abstraction
Impact’s COM libraries offer an interface which you can use to access key Impact functionality via a script or plugin. The methods and properties of the CAD system that are exposed in this interface are carefully planned and controlled; there are many internal aspects of the CAD system that are not exposed, and will never be exposed. Impact’s COM libraries are not a direct representation of the internals of Impact, but an abstraction of them. This abstraction makes the libraries easier for you to understand and use, but does not give them the same degree of power and control as our developers have in-house, with direct access to the internals. Impact is not open source. Also, necessarily, this means that systems that use Impact’s COM libraries to deliver a solution will perform less well than a system written by our in-house team in native code; there is an overhead in going through the COM interface. Although it may be low down your list of priorities, we cannot guarantee that the performance of any system using the Impact COM and nServer functionality will always meet your expectations. Please contact us if this becomes an issue for you.
Implementation
As we have discussed, an Impact automation may take the form of a macro, a script or a plugin library. It is also possible to create a standalone application or script, which is intended to run independently of Impact. Each has advantages and disadvantages. It is up to you to choose which to implement for each task.
Macros
Although Impact allows you to write macros using IML, they cannot utilise Impact COM and nServer, and you should not write new ones. They are supported purely for backwards compatibility.
Scripts
Impact and nServer allow you to write scripts using Microsoft’s Visual Basic Script (VBScript or VBS). These scripts may be embedded directly within the object that uses it (such as templates, text entities, auto tasks, plugin tool/menu item) within Impact, or may be stored in an external file (or files using includes, new in Impact 2014). VBScript is supported in Windows by default, and so there is nothing additional to install to the workstation. Embedded VBScript is useful for small, simple solutions, particularly as it doesn’t require files to be distributed or placed in a location which the workstation can access. However, it can be difficult to manage and edit the source code when it is embedded in this way, as you can only do it inside the Impact environment. You can also distribute updated script files without having to modify the objects themselves, which may be an advantage if you are modifying the scripts in a test environment prior to distributing the changes to a live or other system. Scripts are human readable and easier to create and edit than plugin libraries and standalone applications. It is quick to develop small utilities using them, and they can be prototyped in the Script Toolbox within Impact.
Plugin Libraries
Instead of scripts, you can write a library in any language that supports COM. A single plugin library can support multiple interfaces, each of which can be used in place of a script within an object within Impact. They are harder to develop, but much more powerful. Unlike macros and scripts, you require an Integrated Development Environment (IDE) such as Microsoft Visual Studio or Embarcadero RAD Studio in order to do this, although there is a free (Express) version of Visual Studio available which has limited debugging capabilities. You have a bigger choice of language than for scripts, including VB.Net, C# and C++, as long as it supports COM. If you use Visual Studio, you will have full access to the .Net Framework, which gives authors access to an additional set of powerful tools. Libraries need to be compiled, creating binary files (.dll or .tlb) that are not human readable, but this is often desirable as run-time performance is improved and the code can be obfuscated (see Protecting Your Intellectual Property). These libraries then need to be installed and registered on each Impact workstation, which may require you to also create an installer if you wish to distribute them. Ideally, such installers should not require that the library is installed for all users of that workstation, as this usually requires administrative rights. You cannot recompile a library if Impact has already loaded it, so development testing can be complicated by the need to restart Impact each time you change the code.
Standalone Applications
You can also write a standalone application, which is entirely independent of Impact, but which still utilises Impact COM and nServer. They are much more limited, compared to plugin libraries, as they cannot be used by objects within Impact; they can just run alongside it. It is not recommended that authors create standalone applications that are required to interact with Impact itself. Although marginally easier to develop than a plugin library, they still require an IDE, still need to be compiled into binary files (.exe) that are not human readable, and still need to be installed.
Innovation
In common with all other successful, living software products, Impact is continually evolving, expanding and improving. We are committed to innovation. The internals of the CAD system are no exception to this process. This is a key reason why Impact’s COM libraries are an abstraction rather than a direct interface; otherwise, the interface would change too regularly, and authors would continually need to redesign/rewrite their scripts and applications in order to keep up. For your benefit, we try our best to maintain the Impact COM & nServer interface functionality between each release of the product, only adding to it rather than changing existing methods and properties. Thankfully, low level functionality such as drawing structure and traversal is less likely to change significantly over time than high level functionality such as Impact’s user interface. It is difficult for us to expose functionality that is in a state of flux via COM, whilst still maintaining the interface between versions. Therefore, we choose not to expose such high level functionality via COM, or provide it with very little granularity. The author should not feel limited by what they can achieve using Impact’s COM interface. They are free to write whatever code they like, or even use third-party APIs, in order to achieve things that Impact’s COM interface does not currently directly support. We cannot guarantee that the Impact COM and nServer functionality will remain unchanged into the future. Just as technological advances led to IML becoming obsolete, so may they do the same with COM. This is beyond Arden’s control. Authors are responsible for keeping their systems consistent with any future changes.
Testing
We have full access to our own systems, and put a great deal of effort into fully testing all our software products prior to release. Should a bug or issue come to light after release (as inevitably they do from time to time in all software products), we are able to investigate and address the issues efficiently in-house, and with full consideration for the effects any changes may have to other parts of the system, as we have all the source code and documentation under our control. We are committed to providing quality maintenance and support for all our software products. Regrettably, we cannot offer the same guarantee to any software you author. We cannot test that any code you have written, and that we have no access to or don’t even know about, against every version of the software that we release. The responsibility for testing and maintaining any source code that uses Impact’s COM and nServer interface with each release must lie with the author. Any errors that exist purely in your code need to be addressed by you. Whilst we always endeavour to address any errors that exist in our code as quickly as possible, if such errors can only be reproduced via your code, it can be difficult to identify exactly where the fault lies, particularly without the full cooperation and assistance of the author. This can be a problem if the source code is of a commercially sensitive nature. Arden can assure customers that it will always act in their best interests and never divulge such information to others.
Preserving Your Hard Work
In-house, Impact’s source code and accompanying industry standard technical design documentation is stored securely, for now and for the future. Should any disaster befall us, either as individuals or the company as a whole, there will be others who will be able to rescue the source code and, using the documentation to help them understand it, continue to serve our customers into the future. As an author of source code, the same principle applies to you. It is your responsibility to make sure that any work you do is preserved into the future.
Backups
Make regular backups of your code. It can be devastating to lose your work due to a hardware failure or other event outside your control. Consider using a source code management tool, which can also help you track changes to your code, and get organised to make it easier to reuse code you have written for different purposes.
Documentation and Code Comments
It is very difficult for another person to understand source code that hasn’t got accompanying documentation, or even comments within the code, when they haven’t written it themselves. If you can’t understand it, you can’t maintain it. If you are being commissioned as an author to deliver a solution to someone else, it is unprofessional to just deliver a solution without considering how that customer’s business may be jeopardised should you not be available to maintain it for them both now and into the future, however tempting it may be to achieve an easy lock-in to them using your services. Don’t supply a solution that works just now, but may not in the future. Supply source code and documentation. Usually, your customers will thank you for this, and will be more likely to commission you again. Even if you are unconcerned about other people understanding your code, unless you have an eidetic memory, in six months’ time you will find it very difficult to remember and understand even your own code without documentation! It will be as if somebody else wrote it.
Escrow
In situations where you do not want to supply source code and documentation to a customer, then using the services of a third-party to hold the information on your behalf, may be an option.
Protecting Your Intellectual Property
There are measures that may be taken by an author in order to protect their intellectual property.
Code Security
Authors may wish to secure their code so that it can only be used within their organisation or with their permission. Scripts are human-readable text files and are therefore are easily modified, and so are open to abuse. Instead, plugin libraries (and standalone applications) are compiled binaries and therefore more secure, but still are files that can be copied and reused. It is within the power of the author themselves to build in whatever security that they feel is necessary to protect their company’s intellectual property. There are many ways to do this, the simplest of which is for the plugin library (or application) to obtain the Impact licence number for the workstation or organisation and check this against an approved list of licences in order to protect against unauthorised use. Moreover, if the author wishes to distribute and sell their plugins to third parties, then Arden Software can assist by the use of “library objects” which control access to the plugin library across Impact’s worldwide customer base. Additionally, the developer should protect binaries against reverse-engineering by third-party debugging tools. For .Net applications, there are several popular obfuscation tools available to do this.
Examples
The following simple VBScript example illustrate how easy it is to retrieve the licence information from Impact.
Retrieving the licence number
licenceNumber = Impact.System.Licence.Id
Note that the number will be unique for the workstation, or the site, or your organisation, depending on your preference when ordering the licences.
Checking for a library object
‘ This is the name of the library object to find,
‘ supplied by Arden for your application
name = “Mega Corp\Plug-ins\Mega Plugin 1”
‘ find the library object
Set libraryObject = Impact.System.Licence.LibraryObjects.Item( name )
If libraryObject Is Nothing Then
‘ This Impact licence does not include the specified item,
‘ so tell the user then exit from the app
Else
‘ The licence is valid, so continue…
End If
Before Distributing Your Products
It is relatively easy to author some source code that does what you want it to. On your machine. With one particular drawing. On a Friday. With a following wind. It takes much longer to build upon that, to polish that source code, and produce a solution that works in enough different scenarios reliably enough to be considered ‘finished’ (of course, no software is ever finished), or at least, fit for purpose and distributable. This process always takes longer than anyone thinks.
Robustness
The code you write should be robust, in that it makes no assumptions about the result of any single operation or function call. Check every result, and generate error messages (there are facilities in the COM library to write these to Impact’s debug log, which are very useful) that will help you troubleshoot any problems that may, and will, arise. Test your solution with lots of examples, lots of realistic cases, lots of off-the-wall cases. The vast majority of your time authoring source code is spent testing it rather than typing it.
Audience
Impact and nServer have a vast array of different configuration options, which mean that no two Impact workstations are ever the same. If you are authoring code specifically for one company, it will be tempting to save time by only considering the options that they use. This risks problems if they decide to change those options at some point in the future, but you may get away with it. For sure, you won’t get away with it if you are intending to distribute your solution. These are a few of the many things you need to consider:
- Will your solution work with different databases (Oracle, SQL Server…)?
- Will your solution work with different languages (English, German…)?
- Will your solution work with different localisation settings (Metric, Imperial…)?
- Will your solution work with different appearance settings (Colours, Visibilities…)?
- Will your solution work with different users (Permissions, Sites…)?
Distributing Your Products
Share
A key principle of software engineering is that you should never write code that somebody else has already written. Why waste your time when it would be more efficient (and cheaper!) to use (or buy) the existing code from them? Of course, in order to do that, you need to know that somebody else already has written some code to do what you need. Although authors may wish to protect their intellectual property and the details of a solution they have developed, it is rare that the existence of such a solution needs to be a commercial secret. You would be right to brag about it. We are keen to hear about any solutions you author. With your permission, we can even help market them as products.
Impact Auto Plugins
New for Impact 2014, Impact Auto Plugins (IAP) will allow the author to simply, easily and effectively distribute packages of automation functionality to other Impact users. These users benefit from seamless integration of these automation tools with their normal Impact installation, environment and appearance settings. It is anticipated that this will encourage authors to share, trade and market their IAPs, and establish a stronger marketplace for third-party Impact software solutions.
Conclusions
Business doesn’t accept a one-size fits all approach to the software it requires. Impact automation allows authors to customise, integrate and extend our software in ways even we can’t imagine, to give either themselves or their clients a real competitive edge in the marketplace. Let us help you do it.