Ever since I started working with ICM, I have been tasked with automating aspects of it. I started my journey with knowing nothing about ICM, Ruby scripting, or even SQLs for that matter. Initially I automated ICM like I automate most applications, using low-level Windows APIs.
https://www.youtube.com/watch?v=zHVeZP6DQ2Q
I still remember having a conversation with an Innovyze support employee, while I was reporting a 'bug' where a dialog button wasn't being 'clicked' when I used PostMessage, but was only if I used SendMessage... In the end though, it wasn't really a bug, but myself misunderstanding which windows messages are used for which purposes.
Gradually over the years I have built up my knowledge of how ICM works and how to automate each aspect of it. Whether that be autonymously creating, setting up and running sims, finding and performing actions on database model objects, exporting a number of model networks, or using Ruby scripting to perform detailed analysis on the network itself.
This has also given me a very deep understanding of how the ICM client works at a programmatic level, and of course how to make ICM seg-fault (lol). Anyway, without further ado, let's dig into how the ICM GUI works and how we can programmatically inject ruby scripts into the ICM client for our own benefit.
Originally, pre-1992 all software developers who developed software on windows had to use the core Windows API. The Windows API contains thousands of functions used for performing actions on desktop computers. The API includes functions for file management, the creation and management of windows, code to interact with the user, network and socket management and much much more. In 1992 the microsoft foundation class library (MFC) was released which provided an object oriented wrapper around the Windows APIs. Now, with MFC, many of the convoluted management of handles was replaced with the much simpler management of objects. User event handlers which used to use Windows Message loops were now replaced with C++ macros (via Message Maps).
This is important because InfoWorks ICM, to the best of my knowledge, is likely built in Visual C++ using the MFC framework. One tell tail sign is the use of the prefix "Afx" on all window classes used in the software.
One of the major reasons why someone might like to know more about an application is that it brings to mind options you might consider if you wanted to automate aspects of the application. For instance, I've just mentioned "Afx" and "MFC", so now you might even like to google "AFX Functions" or "MFC functions" which may lead you down a very long path across numerous websites which may be of use.
Messages - https://msdn.microsoft.com/en-us/library/bb982948.aspx