1 Reply Latest reply on Nov 21, 2008 8:08 AM by chris_czernel

    Common automation object model within the flow ?



      Hi all,



      we have many tools in the EE flow. For all tools you have different automation object models, methods and so on.



      In an enterprise with a programming group, it is very hard for the software engineers always to switch between the tools and their

      object models. Automation shows the same as the tools itself. You see that they have a different origin and so their look alike and

      their gui are different. 

      Another example is the NSE. It still has an Tcl API, so you have additionally a second language to support.



      There is much work to do for unifying the automation objects and methods within the flow.



        • 1. Re: Common automation object model within the flow ?

          Hi Andreas,


          You have some great observations here. It is true, it can take significant work to become familiar with all the object models across many tools. I'm not aware of any work on unifying automation objects and methods across the flow, but perhaps others in the Community can provide insight in that area.




          After some research on the web, I was able to find some interesting alternatives to functions within an application's automation layer.




          Let me first state that my environment is Windows, my programming language of choice is vb.net, and the customer I work with most closely also runs in a Windows environment.  So please keep that in mind, and not everything I say here would be applicable outside of the Windows environment.




          Let's suppose that we have a need to automate something in DxDesigner or Expedition, however there is no API provided in the automation layer for the function we want to automate. Are we stuck? Not necessarily.  There are methods to execute menu commands of an application directly using Windows functions. I found good information here http://www.vbforums.com/showthread.php?t=247833 and google searches will turn up many other examples.




          Once a menu command or dialog is launched, items in the dialog can be dispositioned - checkboxes checked on or off, text inserted into text fields, and so on. To do this, you can loop through running processes to find the process in question, get it's handle, and then use Windows functions to get child handles. Then, you can use SendMessage type functions to click controls, enter text into controls, or do whatever you want within that dialog.




          Using these techniques, I've been able to successfully automate many exports from both Expedition and DxDesigner.  




          Will this work for all Windows applications? Nope. For some applications (e.g. java apps) these techniques would not  work. However, blends of this technique did work for me for both DxDesigner and Expedition, therefore I'm sharing the information here. Perhaps this approach can help construct some coding techniques that will indeed work across multiple products in a flow, or allow you to automate something that does not otherwise have an API that you can call directly.




          I hope this helps.