How to do you stop script execution when using the Scripting API inside a C# app?

[Former Member]

I am using the SAP GUI Scripting API 7.10.  My program is written in C#.  I am using the following code (I have removed a lot of code for clarity sake).

SapROTWr.ISapROTWrapper SapROTWrapper = new SapROTWr.CSapROTWrapperClass();

object SapGuilRot = SapROTWrapper.GetROTEntry("SAPGUI");

object engine = SapGuilRot.GetType().InvokeMember("GetScriptingEngine",System.Reflection.BindingFlags.InvokeMethod, null, SapGuilRot, null);

GuiApplication GuiApp = engine as GuiApplication;

GuiConnection connection = GuiApp.Connections.ElementAt(0) as GuiConnection;

GuiSession session = connection.Children.ElementAt(0) as GuiSession;

As soon as the program executes the last statement above, the SAP session indicates via the 'barber pole' that a script is being executed.  Basically, after the above statement my program will look at various text fields and complete it's need for its connection to the SAP scripting engine.  The C# program will continue to run as long as the agent is logged into his/her workstation.  The SAP program will continue to be used by the agent for data entry (they are in a call center).  The 'barder pole' still continues to indicate that a script is being executed.

Is there a way in the SAP GUI Scripting API to stop the 'script' execution?   Basically, my application is not a script and it does not look like the Scripting API was designed to handle this type of application.  The only solution I have discovered so far is to have my program terminate, but this is unacceptable.

Thanks,

Dan

[Former Member]

This is quite an old thread now ... did anyone ever find a resolution ?

My current code is amlost identical to Dan's first post and I am struggling to make sense of how to release the sessions without killing them for the user at the same time.

Any help appreciated!

[asdfasdfwef]

Late to the party. You need to release the engine object.

Try something like this; in C#.

engine = SapGuilRot.GetType().InvokeMember("GetSCriptingEngine", System.Reflection.BindingFlags.InvokeMethod,null, SapGuilRot, null);

System.Runtime.InteropServices.Marshal.ReleaseComObject(engine);

GC.Collect();

GC.WaitForPendingFinalizers();

[thomas_brutigam2]

Hi Dan,

What if you Connet to SAP only if you need it ?

Just in Case in VB i have build 2 Functions which are Called to Connet and Disconnet From SAP if needed...

This is what it looks in VB perhaps you can Translate to C#

Public sapsession

Public Sub CreateSAP()

If Not IsObject(sapApplication) Then

   Set sapGuiAuto = GetObject("SAPGUI")

   Set sapApplication = sapGuiAuto.GetScriptingEngine()

End If

If Not IsObject(SAPConnection) Then

    Set SAPConnection = sapApplication.Children(0)

End If

If Not IsObject(sapsession) Then

   Set sapsession = SAPConnection.Children(0)

End If

If IsObject(WScript) Then

   WScript.ConnectObject sapsession, "on"

   WScript.ConnectObject sapApplication, "on"

End If

End Sub

Public Sub Disconnect_SAP()

    Set sStatusBar = Nothing

    Set sTitlebar = Nothing

    Set sapsession = Nothing

    Set sapApplication = Nothing

    Set sapGuiAuto = Nothing

End Sub

[Former Member]

Thanks for the response.  I did attempt something like what you suggested a couple of weeks ago.   The first experiment dealt with setting my variables to null (similar to VB's setting to Nothing).  That did not help.  Next, I forced a GC to see if that would cause a 'disconnect'.  That did not help.

The one thing I discovered that did help was to not create a pointer to any GuiSession.  In the old way, when I did:

  GuiSession session = connection.Children.ElementAt(0) as GuiSession;

This would start the 'barber pole'.  After more experimentation, I realized that I could meet my basic needs with only using the GuiApplication object and not using the GuiSession.

All I really need is a way to use the 'FindById' method to get to specific controls on the interface.  Using the GuiApplication object to do this does not cause any user interaction issues.  (Sorry... In my first post I did not mention that once our application created the GuiSession object the agent's response time with entering in data to the interface was drastically affected: i.e. typing in data into a text field became very slow).

I am now getting back to this issue and am creating a prototype using only the GuiApplication to access the controls in the application (I am not creating a GuiSession object).   I should know if this approach works for my application by the end of the week.

Dan