Apologies for the delay getting the next part of this series out, six weeks away from my development machine reduced my ability to thoroughly research (Read: Check backup archives) and obtain screen shots of the older systems. Links to the previous articles in this series can be found at the bottom of this article…
The third major overhaul saw a change from Adobe PageMaker to Adobe Indesign as the underlying printing application. Interaction with Indesign was performed using COM calls to the Indesign API, this was a welcome relief as the use of Tag files in PageMaker was extremely cumbersome to maintain.
2001 – 2004 – Delphi / Interbase / InDesign:
InDesign was released by Adobe as the successor to PageMaker (which was eventually discontinued in 2004). Indesign brought the advantage of a well documented and supported API which would allow third party applications to easily interact with Indesign. The initial development of the ID System overhaul was performed by Aden Diedrichs whom had joined the team to maintain the systems during my absence as I had moved over to Japan to work from 2000 to mid 2001.
Due to a naming convention issue (InDesign COM Server was called ‘Application’, which was a reserved word within Delphi), the initial DLL used for communicating with InDesign from the ID System was developed with Visual Basic 6.0. Visual Basic was also the scripting interface used by Adobe for interacting with InDesign, the added benefit of this was no translation of API and Code examples was required (as is often the case when interacting with 3rd Party COM servers or API calls from Delphi).
Similarly to previous years where multiple developers would work independently and produce new iterations of the ID System, once again we had multiple iterations rolled out, with each providing advanced functionality over the predecessor.
2001 ID System – Developed by A Dowling
2002 ID System – Developed by A Diedrichs
2004 ID System- Developed by A Dowling
Video Capture Integration:
A secondary change for the ID Systems, was the move away from using an external application for image capture (Ulead Media Studio) to using image capture functionality built directly into the application. Initial development of the image capture functionality started in 2000, however it was not widely implemented in the ID Systems until 2001. Video Capture functionality was provided by interacting with the Video for Windows API.
The built in capture functionality provided a live preview of a video feed streamed in via video camera, which could be frozen and the frozen image captured for printing purposes. It was necessary to have a system that would allow quick freezing/unfreezing as it was not uncommon to catch a person blinking when freezing the frame. Supported resolutions were 320 x 240 or smaller, with 640 x 480 being supported a few years later as clients requested it.
The Good:
The advantage of using COM to interact with InDesign meant that all font and style information for each text box could be stored within the InDesign form, with only the actual text data being updated programmatically. This provided our designers a more efficient method of making alterations to fonts and styles for the text attributes that would be printed on the form.
The built in capture functionality removed the need for using the Windows Macro Recorder to control a third party capture application. This increased the stability of the system, and allowed us to automate more of the ID Card Production process for the operator. We also gained the ability to easily manipulate the captured images and reduce occurrences of data corruption when saving captured images to network shares by providing redundancy checks on the save operations.
The Bad:
Because we utilised Delphi, the Video for Windows API calls had to be translated into Delphi, and 99% of help and documentation was focused on C, so it was difficult to develop a stable implementation. As development progressed, the stability of the built-in capture functionality increased, however it was quite frustrating at times trying to get external help when any problems arose.
“The Video for Windows technology was mostly replaced by the July 1996 release of its COM-based successor – ActiveMovie (later known as DirectShow) – first released as a beta version along with the second beta of Internet Explorer 3.0. ActiveMovie was also released as a free download, either standalone or bundled with a version of Internet Explorer. One component that was not replaced with ActiveMovie was video capture, which still required an install of Video for Windows until the release of WDM capture drivers, which only started to become popular in 2000″
Windows 2000, and Windows XP provided a WDM wrapper driver for devices that only had a Video for Windows driver, however it was often the case where not all of the functionality (mostly configuration options) were passed through from the older VFW drivers, and it was also not uncommon for older devices that used this WDM wrapper driver to have stability issues.
The Ugly:
During this period we had multiple client types, and often we would simply roll out a specific ID System for each type. We ended up with the following individual systems…
- University ID System
- Teachers College and Polytechnic ID System
- Schools ID System
- Corporate ID System
- HealthCare ID System
While most of the functionality was the shared between each of these systems they still required individual customisation. The ugly side of this was that any updates to shared functionality would require each system to be individually updated and tested, as while the functionality may have been shared the code behind the applications was not shared from a single repository. Cut ‘n’ Paste got the job done, however it did cause one or two headaches where naming schemas were different between applications.
Coming Soon:
We have almost caught up with overviewing the evolution of the ID Systems in development. The next instalment in the series will hopefully bring you up to the present, from there the aim is to provide entries related to not only software development, but also business development (Which should be more inline with the aim of this blog).
Related articles:
- Evolution of an ID System – Part 2 (antdowling.wordpress.com)
- Evolution of an ID System – Part 1 (antdowling.wordpress.com)
He’s back! Still think it’s classic that the whole system was scrapped at each iteration and 100% duplication occured during development! Funny
The functionality was duplicated but the code behind the scenes was certainly improved upon each iteration.
One issue was that we had no central development office so the independent development got a little extreme at times. The boss did question the need for the updates every 6-8 months.
However those were the early years and it was quite amazing how much progress and innovation one can make coding 20 hours a day.
Comparatively the systems in use today have been in use for over 5 years with only evolutionary updates rather than revolutionary.
Pingback: Pushing the Positive | Journey from Code to Sales