Andrew, here is some information that I think will help.
First, forget about the MGCPCBReleaseEnvServer. It does not work, because there's no COM object for it that I've found. So I don't even know how you'd let your project know it exists. But no matter, because it's not needed.
There are two things you need to get:
1. The path to the currently registered version of mglaunch.exe.
2. The COM version number of the currently registered installation of the Mentor tools.
(an aside: it is possible to have more than one registered version active on a system. In that case, you'd need some other method of choosing the COM version and the mglaunch version. I will let the geniuses who decided a complete paradigm shift was necessary to accomplish this illogical scenario put in the time and effort to figure that out. We plan to keep one version registered at a time, the latest viable release. Naturally, my tools will be smart enough to figure out what that is, even when we change versions, so that install paths do not need to be hard coded into the software anywhere.)
You only need to use mglaunch when you are also using the CreateObject mode of starting an automation hook into one of the Mentor tools. If, on the other hand, you are creating an automation hook into an already running tool, use the GetObject mode, and then mglaunch is not needed.
How to get the mglaunch path before you run your externally compiled automation tool:
- Make a .vbs file. Call it whatever you want. I'll use Dx_Library_Automation.vbs as an example which will demonstrate how to load the PDBEditor and CellEditor. Both of these run stand-alone, meaning you will never have an existing session of them already running, and what to hook into it.
- The contents of the .vbs file would look something like this:
Optionexplicit
run
Sub run()
Dim objShell, regkey, mglaunch
Set objShell = CreateObject("WScript.Shell")
regkey = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\mglaunch.exe\"
mglaunch = objShell.RegRead(regkey)
mglaunch = mglaunch & " " & chr(34) & "path_to_your_automation_executable" & chr(34)
objShell.run mglaunch
set objShell = Nothing
Endsub
(I'm not sure if the subroutine is actually needed. I got that as an example long ago and just kept using it. vbs experts may know better)
So, what's going on here?
1. We create the objShell object, an instance of the wscript shell.
2. We give it the name of the Windows registry key where the path to mglaunch.exe is stored, and then read that key's value into the mglaunch variable.
3. mglaunch becomes a command string, with the path to mglaunch, a space, double quote (in case there is a space in what follows, the automation tool executable path), the automation executable's path, and another double quote.
4. We execute the command line string, then kill the shell.
This is essentially equivalent to opening a command window and typing the path to mglaunch and the path to the automation executable, which will open the automation tool from inside the mglaunch wrapper.
So now your automation tool is running, and doing so under the care and protection of mglaunch.
At this point, the only other thing needed is the COM version to be used in the automation tool to start the CreateObject commands. So how is that done?
Again, we use the Windows registry. In my vb.net project, I have a module with all of the following in it.
1. An imports statement with
Imports Microsoft.Win32
This is there so that we can interface with the registry.
2. Global variables used to hold the COM version and an error-checking boolean.
Public proceed AsBoolean
Public prog_id AsInteger
prog_id is the COM version.
3. A subroutine that reads the COM version from the registry with error checking and reporting via the proceed boolean variable.
PublicSub get_ver()
Dim regkey As RegistryKey
Dim tmp AsString
regkey = Registry.LocalMachine.OpenSubKey("SOFTWARE\Classes\MGCPCB.ExpeditionPCBApplication\CurVer", False)
If regKey IsNothingThen
tmp = "Critical registry keys are missing. This most likely means that the Mentor Graphics "
tmp = tmp & "tools have not been installed properly." & vbCrLf & vbCrLf
tmp = tmp & "Try to correct that then start over. "
MsgBox(tmp)
proceed = false
exitsub
EndIf
tmp = regkey.GetValue("")
tmp = tmp.Substring(InStrRev(tmp, "."))
prog_id = CInt(tmp)
regKey.Close()
EndSub
4. You see here that the tmp variable is used to get the regkey value. It is then parsed to get only the part after the last dot in the string. This number is the COM version, and is stored in the prog_id global variable. I run this subroutine prior to running the routine that includes the CreateObject command, and use the proceed boolean to make sure it all works properly. Here is an example of how that is done:
proceed = True
get_ver()
if proceed = falsethen
MsgBox("Unable to find registry keys needed for automation access to EXpedition.")
me.close
endif
5. After get_ver has successfully run, we know the COM version.
6. I have a subroutine that starts the Part Editor, or the Cell Editor. Here is an example of starting the PartEditor
PublicSub Get_Part_Editor()
'Creates a handle to the Parts Editor in Library Manager
Try
part_ed_dlg = CreateObject("MGCPCBLibraries.PartsEditorDlg" & "." & prog_id.ToString)
Catch ex As Exception
Debug.Print("failing to create part editor session with this error: " & ex.Message)
proceed = False
ExitSub
EndTry
pdb_db = part_ed_dlg.OpenDatabaseEx(job, False)
'job is the path to the central library .lmc file
If part_ed_dlg.LockServer() Then
'do nothing
else
msgbox("Could not lock database for writing")
EndIf
EndSub
7. The important line is the one right after the Try command.
part_ed_dlg = CreateObject("MGCPCBLibraries.PartsEditorDlg" & "." & prog_id.ToString)
You see that it uses the CreateObject function, identifies the tool that it's going to create, then adds the COM version to the end.
I have verified that this works successfully in VX.1. I have not yet tried it in VX.1.1 or VX.1.2, because of other problems with both of those releases.
8. For CellEditor, there's a similar subroutine:
PublicSub GetCellLib()
'there are some other globally declared variables in here.
Try
celldlg = CreateObject("CellEditorAddin.CellEditorDlg" & "." & prog_id.ToString)
Catch ex As Exception
Debug.Print("failing to create cell editor session with this error: " & ex.Message)
proceed = False
ExitSub
EndTry
celldb = celldlg.OpenDatabase(job, false)
'job is the path to the central library .lmc file
celldlg.visible = False
EndSub
Again, I've verified that this works. I assume you are using the Windows Task Scheduler or some equivalent tool to run your scrips after hours. I set up a simple task in Task Scheduler to run my library editor tool with the .vbs startup script. It works, and I can extract data from the PartEditor and the CellEditor. or execute functions on the parts and cells.
To start automation hooks into already-running tools, just use GetObject instead of CreateObject, and don't bother with the .vbs script that starts the executable with mglaunch. However, sometimes it's a mixed bag. You may be hooking into a running session of Xpedition with the GetObject command, but also running one of the PCB Engines. PCB Engines require the CreateObject statement, so in that case you would need to use the mglaunch wrapper for the entire executable.
Here's an example of starting a hook into Xpedition with GetObject:
app = GetObject(, "MGCPCB.ExpeditionPCBApplication" & "." & prog_id.ToString)
(note the comma in the above statement right after the opening parentheses. I forget why it is needed, but it is. And different than the CreateObject statement, which does not need it)
And starting a Mask Engine instance with CreateObject. (mglaunch needed in this case):
mskeng = CreateObject("MGCPCBEngines.MaskEngine" & "." & prog_id.ToString)
I think this includes everything, but it's late and I may have forgotten something. Go over it and then get in touch, and we'll hammer out any issues.
Best wishes getting it all to work