Hi,
I wrote a windows form script in visual studio, which opened a connection to Eviews (choosing the existing or new option). It was working fine. In short, the user interface takes the input from the application and sends it to Eviews via the app.put function. An Eviews addin then interprets the inputs and produces charts based on those inputs.
I noticed that i wasn't exactly sure which instance of Eviews it chooses, and had some issues trying to close the instance of eviews where the variables had been sent. So i tried to play around with existingonly, existingornew and newinstance. Like so:
Imports EViews
Public Class Form1
Dim mgr As New EViews.Manager
Dim app As EViews.Application = mgr.GetApplication(CreateType.ExistingOrNew) ''''This is where i changed the syntax to try to figure it out
Since then, I've been getting this error every time i try to run it (always on the first attempt of app: "System.Runtime.InteropServices.COMException: 'No active workfile.'" I have a workfile open, so i suspect when i played around with the code, it's been unable to locate the active workfile (or the proper instance of Eviews).
This is where i get the error to be exact:
If Trim(Samplechoice.Text & vbNullString) <> vbNullString Then
Dim Val As String = Samplechoice.Text
app.Put("Samplechoice", Val, DataType.DataTypeAuto)
End If
Any thoughts or ideas as to what could have happened?
Thanks!
COM automation
Moderators: EViews Gareth, EViews Jason, EViews Moderator, EViews Matt
Re: COM automation
So it worked when i restarted my computer. I've gone through this link (http://www.eviews.com/download/whitepap ... mation.pdf) to try to figure out how exactly the Eviews instances work. From what i understand, i can specify a session ID, to only use that instance of Eviews.
Here is what i'm trying to do: I would like users to open the app from within Eviews via an add-in that spawns the executable file (and for the App to only connect to that version or instance of Eviews).
I may be misunderstanding the process.
Here is what i'm trying to do: I would like users to open the app from within Eviews via an add-in that spawns the executable file (and for the App to only connect to that version or instance of Eviews).
I may be misunderstanding the process.
-
- EViews Developer
- Posts: 798
- Joined: Tue Sep 16, 2008 3:00 pm
- Location: Irvine, CA
Re: COM automation
My guess is that you have some orphaned instances of EViews running in the background (hidden) that you're not aware of. This can happen if your calling application crashes or stops midway without properly telling the EViews instance it was talking to that it is no longer needed. In these cases, even if you ask EViews directly to quit, EViews will hang around hidden in the background because it thinks the calling application still needs it. Hence it sits around forever because the calling application is no longer there (and EViews can't detect that). This type of situation can happen often during development and is a normal occurrance for COM automation programming.
To prevent this type of confusion, you'll need to make sure you force quit any rogue instances of EViews running the background before you start your application. To do this, use the Windows Task Manager to look for the EViews executable.
Another thing to keep in mind is that if your application is running under a different user account (e.g. "Local System") than your own, Windows will keep the various EViews instances separate in memory as a security precaution. Meaning if you run EViews first under your own account, and then try to run your application under "Local System" (which is the default account used for applications that run as Windows Services), your application won't be able to connect to the already running instance of EViews since the user account is different.
Because of this, when you check for rogue instances of EViews running in Task Manager, make sure you click the "Show processes for all users" button on the Windows Task Manager window (if you see one) before looking thru the list. This way you'll see all instances, regardless of who the owner user is.
Also, I'm not sure why your application would want to talk to a visible running instance of EViews that already has a workfile open (other than debugging your application). Allowing this can be dangerous because a lot of our EViews commands perform their action on the currently window that has focus. If the user can see the EViews window while your application is running, he/she can change the focus while your application is attempting to run a command and this can cause unexpected errors. In most cases, when you're controlling EViews thru COM, you would want to make the window hidden (default) so that the user can't interfere with workfile focus, or start a new command while your application is trying to use it.
Steve
To prevent this type of confusion, you'll need to make sure you force quit any rogue instances of EViews running the background before you start your application. To do this, use the Windows Task Manager to look for the EViews executable.
Another thing to keep in mind is that if your application is running under a different user account (e.g. "Local System") than your own, Windows will keep the various EViews instances separate in memory as a security precaution. Meaning if you run EViews first under your own account, and then try to run your application under "Local System" (which is the default account used for applications that run as Windows Services), your application won't be able to connect to the already running instance of EViews since the user account is different.
Because of this, when you check for rogue instances of EViews running in Task Manager, make sure you click the "Show processes for all users" button on the Windows Task Manager window (if you see one) before looking thru the list. This way you'll see all instances, regardless of who the owner user is.
Also, I'm not sure why your application would want to talk to a visible running instance of EViews that already has a workfile open (other than debugging your application). Allowing this can be dangerous because a lot of our EViews commands perform their action on the currently window that has focus. If the user can see the EViews window while your application is running, he/she can change the focus while your application is attempting to run a command and this can cause unexpected errors. In most cases, when you're controlling EViews thru COM, you would want to make the window hidden (default) so that the user can't interfere with workfile focus, or start a new command while your application is trying to use it.
Steve
Re: COM automation
Steve,
Thank you for the info. So I've already built the project, and i'm testing the application through the executable file. I prefer that users run the app from within Eviews because they can click on the run button and see the chart. I can use the app.show function at the end, to bring Eviews into focus once the chart has been created (it takes a second to run so there is little risk of a user having enough time to change the focus window in Eviews).
It seems to me like the best option in this case would be to open a connection when the 'Run' button is clicked, and close it once the app runs and all the input is sent to Eviews (in which case the connection is no longer needed since all the work is being done in Eviews). Alternatively, it would also work if i close the connection when the user exits the form. Is there a function that closes the connection? This way, the instance of Eviews wouldn't hang (thinking that it is still needed by the app). I know the function to open is:
Dim mgr As New EViews.Manager
Dim app As EViews.Application = mgr.GetApplication(CreateType.ExistingOrNew)
Thank you for the info. So I've already built the project, and i'm testing the application through the executable file. I prefer that users run the app from within Eviews because they can click on the run button and see the chart. I can use the app.show function at the end, to bring Eviews into focus once the chart has been created (it takes a second to run so there is little risk of a user having enough time to change the focus window in Eviews).
It seems to me like the best option in this case would be to open a connection when the 'Run' button is clicked, and close it once the app runs and all the input is sent to Eviews (in which case the connection is no longer needed since all the work is being done in Eviews). Alternatively, it would also work if i close the connection when the user exits the form. Is there a function that closes the connection? This way, the instance of Eviews wouldn't hang (thinking that it is still needed by the app). I know the function to open is:
Dim mgr As New EViews.Manager
Dim app As EViews.Application = mgr.GetApplication(CreateType.ExistingOrNew)
Re: COM automation
I'll be more specific.
I tried to use dispose to close the connection and it seems like it is not supported. Is there an equivalent that I can use to force close the connection between the application and Eviews?
I tried to use dispose to close the connection and it seems like it is not supported. Is there an equivalent that I can use to force close the connection between the application and Eviews?
-
- EViews Developer
- Posts: 798
- Joined: Tue Sep 16, 2008 3:00 pm
- Location: Irvine, CA
Re: COM automation
In VBA, to let go of an object, you have to set your variables to Nothing. So in your example:
And even then Excel may not actually let go of the COM objects until the spreadsheet file is closed or Excel is shut down. If you're not having much luck with this, try using global variables to hold your mgr and app objects instead of local variables to see if that makes a difference.
Currently, there isn't any way to tell EViews to close the COM connection. Again this is usually done when all references to the object has been dropped. Excel keeps it's own pointers to your COM objects in order to perform its own cleanup so EViews has to stick around for Excel to actually let go.
Code: Select all
Public Sub Test()
Dim mgr As New EViews.Manager
Dim app As EViews.Application
Set app = mgr.GetApplication(ExistingOrNew)
'use app
'clean up
Set app = Nothing
Set mgr = Nothing
End Sub
And even then Excel may not actually let go of the COM objects until the spreadsheet file is closed or Excel is shut down. If you're not having much luck with this, try using global variables to hold your mgr and app objects instead of local variables to see if that makes a difference.
Currently, there isn't any way to tell EViews to close the COM connection. Again this is usually done when all references to the object has been dropped. Excel keeps it's own pointers to your COM objects in order to perform its own cleanup so EViews has to stick around for Excel to actually let go.
Re: COM automation
Declaring the sub as public worked. Now I can close Eviews without forcing it via the task manager or command prompt.
Thanks!
Thanks!
Who is online
Users browsing this forum: No registered users and 37 guests