Following on from my last post in which I provided an overview of the ways that you can customise EA, I have spent some time exploring more of the capabilities of EA scripting. Although I’ve used VBA extensively I’ve rarely used scripting either within EA or in a windows environment so I was keen to see how much you could really do.
I start by assuming that most of the stuff I do when accessing an EA project model with an EA AddIn can be done with scripting, however I needed to check this out as well as look at some other areas which are needed to support potential EA related applications. Hence, look at scripting and how to interact with the user, system and other applications.
The mindmap below illustrates my target list and I warn you I don’t get to the end in this post. But let’s start and look at what I found during my exploring so far:
Well, let’s start and look at what I’ve found so far – basically items 1 .. 7 – where my aim for each is as follows:
- User Interface – what can I do in providing the user with information and getting results back
- Library access – what existing code exists that I can use and what capabilities does it offer
External access – can EA scripts interact with stuff outside of EA for example:
- File access – can I read / write files?
- Network access – what communication capabilities exist?
- System access – what services exist?
- Application interoperability- can I interact with other applications e.g. Office
I’ll now outline what I found and in a future posts look at the missing items as well as resolve some of my outstanding issues.
In each of the areas I’ve been testing using VBScript, and assume but not tested, that the functionality I outline is available with the other scripting engines; that may be a very bold statement! Also you need to remember in writing the code it’s important to note that VBScript is not VB, as I found out and I often needed to check the syntax.
1. EA model access
This is the area I expected all to work but wanted to check access to packages, elements, diagrams etc and that information can be exchanged between the script and EA projec. To do these tests I used the code samples provided in the EA manual and, with making relevant syntax changes, all seemed to work fine. No surprises and none expected so that was a good start.
Key to the operation is access to the currently open repository through a predefined object “Repository”. Methods are selectable using Intelli-sense with access to the help file for access to the EA Object Model reference material. All fine so far.
2. User Interface
For me the user interface is a key component, so I was keen to understand what capabilities are available. I half expected it to be a basic command line text interface but as you will see there is potential for much more.
To start with it is worth a moment looking at how a user will access scripts. There are 2 basic mechanisms that I would expect to be used.
The scripting window access from Tools | Scripting which presents a list of the available scripts. And either using the run button in the tool bar or context menu the user can run the script.
or from the context menu – in which case those scripts created for the relevant script group will be available i.e. if you create a script with a Diagram group then that script will only be available when working within a diagram.
So having got the script started in most cases there is a need to interact with the user whether asking questions, capturing data or presenting results.
To support this requirement EA provides a Session object which supports input, output and prompt methods which provide a basic capability e.g.
Session.Output “Some information for the user”
The prompt method can capture a result from user input.
Also provided with EA is a library of helper functions (EAScriptLib). This is supplied as an MDG so if not present in your list of scripts then check your Settings | MDG Technologies to ensure that it has been enabled.
You then have a set of scripts functions available in several scripts in the EAScriptLib group. You will need to look at the script source to see the available functions and usage information.
If you want to use any of the functions within these library files you will need to include the relevant library in your script e.g. !INC EAScriptLib.VBScript-Dialog before you can use it.
For example, a simple input box could be accessed as illustrated below.
When looking into other options I soon discovered there were more options.
For example, VBScript provides some standard functions such as
MsgBox(prompt[, buttons][, title][, helpfile, context])
Dim shell : Set shell = CreateObject("Shell.Application")
Dim file : Set file = shell.BrowseForFolder(0, "Choose a file:", &H4000)
if (not file is nothing) then
BrowseForFile = file.self.Path
BrowseForFile = "No file selected"
It soon became clear that it was possible to create quite sophisticated dialogs, although I found nothing as powerful as a custom form; perhaps I have missed something.
As with most programming languages there are libraries of functions available for scripting, as you will have read I have already discovered a few. But when I started with VBScript I was unaware of the range of functions that were available and just a quick search on the Internet found many more. For example, there are scripts covering most things that I needed including:
- Hardware information
- Operating systems information
Already we have seen that EA has its own Sparx provided EAScriptLib which provides some helper functions – see above for details. Then there is the standard VBScript library ( see VBScript language reference at MSDN) plus access there is access to a range of other application objects such as:
- Shell application which has its own functions see MSDN reference
- File system object – see MSDN reference
- Network – HTTPRequest object – see MSDN reference
- System information – Wscript object – see MSDN reference
- Windows management instrumentation – winmgmts – see MSDN reference
- Database – in addition to the supplied Repository.SQLQuery method to access the current project you can use the ADODB.Connection object
And with that I think I can do most of the tasks I need so onto a few tests. A quick search provides examples for most of these.
4. File access
With the ability to interact with users and libraries available, accessing files should be straightforward. And this was indeed the case. The function below worked fine –
Sub MakeHelloWorldFile (FileName)
'Create a new file in C: drive or overwrite existing file
Set FSO = CreateObject("Scripting.FileSystemObject")
If FSO.FileExists(FileName) Then
Answer = MsgBox("File " & FileName & " exists ... OK to overwrite?", vbOKCancel)
'If button selected is not OK, then quit now
If Answer <> vbOK Then Exit Sub
'Confirm OK to create
Answer = MsgBox("File " & FileName & " ... OK to create?", vbOKCancel)
If Answer <> vbOK Then Exit Sub
'Create new file (or replace an existing file)
Set FileObject = FSO.CreateTextFile (FileName)
' and put some content into the file
FileObject.WriteLine "Time ... " & Now()
FileObject.WriteLine "Hello, World"
MsgBox "File " & FileName & " ... updated."
With that I was happy that basic file functionality is available using the File System Object so left it there.
5. Network access
Next on the list was communication. Perhaps a simple test to retrieve information from a web server, so try accessing a web page. Once again network access was straightforward using the HTTP request. For example, the few lines below were able to read a web page and output as text string.
Set o = CreateObject("MSXML2.XMLHTTP")
o.open "GET", "http://eaforms.exploringea.co.uk", False
' o.responseText now holds the response as a string.
Looking at script examples I found there is clearly I much more functionality readily available whether it be parsing the content, sending emails,..
6. System access
Next I looked at system access, and this was probably the biggest surprise to me. How much could I do from scripts in terms of accessing and manipulating system information? Well it turns out that you can do a lot, although I suspect that windows security will prevent normal users doing anything catastrophic (I hope so!).
My findings were that EA can happily run the scripts that access all types of system tasks using WScript or get information using the winmgmts objects.
For example, using the File system object you can create a batch file and then using the shell object run the batch file. e.g.
Set objShell = CreateObject("Wscript.Shell")
objShell.run("%comspec% /c C:\Users\adrian\Documents\mybatchfile.cmd")
This was clearly an area with plenty of functionality that would go far beyond the normal day to day needs of the EA user. For those interested there is plenty to explore – I stopped myself as I suspect I could have spend hours or even days as I have only scratched the surface.
7. Application interoperability
So to the area of greatest interest to me – applications working together.
Having used VBA more than a decade ago to transfer information from Excel to EA my first task was to discover what could be done the other way round, then look further at the general capabilities for interacting with external applications.
With the knowledge that it was possible to create an application object with VBScript, and my experience of writing several EA AddIns for MS Office products applications, I was confident that I should be able to connect. And this was the case .
For an external application that is available as a COM server you can create a reference to the server, and use that to interact with the relevant files. In the case of Excel this is done as follows:
Set objExcel = CreateObject(“Excel.Application”)
And the following lines illustrate how to create a workbook, adding some dummy data into the worksheet and setting some cell formatting.
strFileName = "C:\Users\adrian\Documents\c1.xls"
Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = True
Set objWorkbook = objExcel.Workbooks.Add()
' now makes visible and then puts some data into the sheet
objExcel.Visible = True
objExcel.Cells(1, 1).Value = "Name"
objExcel.Cells(1, 1).Font.Bold = TRUE
objExcel.Cells(1, 1).Interior.ColorIndex = 30
objExcel.Cells(1, 1).Font.ColorIndex = 2
objExcel.Cells(2, 1).Value = "Test value 1"
objExcel.Cells(3, 1).Value = "Test value 2"
objExcel.Cells(4, 1).Value = "Test value 3"
objExcel.Cells(5, 1).Value = "Test value 4"
Set objRange = objExcel.Range("A1","A5")
objRange.Font.Size = 14
Set objRange = objExcel.Range("A2","A5")
objRange.Interior.ColorIndex = 36
Set objRange = objExcel.ActiveCell.EntireColumn
For other MS Office applications (Word, Project, Powerpoint, Outlook) the approach should be very similar, although I have not tested all. But what other applications? Using Create object I assume that a script could connect to any application that provide a COM interface. So I started Visual Studio and looked at the COM references are available. There are 100’s on my system, however I suspect that not all are available and/or useful. I did test with a few application objects and soon realised that I have a lot more exploring to do in this area. Although, I suspect, purely for general interest as I’m not sure many of these applications will be useful with EA. I’ll find out.
Although there are still some areas, as listed on my mindmap, left to explore and I will get onto these in due course. However, as usual I’ve discovered some interesting stuff along the way which I want to explore further, and find some answers before moving onto the next topic. So I’ll leave it here for today, with some questions in my mind regarding application interoperability, and the promise that I’ll check out some more of the EA Scripting capabilities.
If you have experiences of scripting or questions feel free to add a comment.
Have fun EXploringEA