Interesting approach, but why do you span and connect later, it is for sure tricky to determine which one is first, but I guess you have a tag for the first and second session.
ProEngineerConnectionStart(), here you can spawn and connect in one shot (hope the second does not fire number three 🙂 so I would use some args, or a file lock. I think your machines have different hardware, and the port might not ready, kill pro comm msg is another approach. Again, which one is first is a bit tricky in my point of view.
Or the second will start with
ProEngineerStart( char* proe_path,char* prodev_text_path ),
write the session ID to disk, the first waits for the id, read this and connect, this would be save.
And if you don’t have a process in between, communication between both will be tricky. But I hope this is solved.
extern ProError ProEngineerConnectionStart( char* proe_path,
char* prodev_text_path,
ProProcessHandle *p_handle );
/*
Purpose: Causes the Creo Parametric TOOLKIT program to spawn and connect to a new
Creo Parametric session. ProEngineerDisconnect can be called later
to disconnect from created Creo Parametric session. It is intended
for use in full asynchronous mode.
Input Arguments:
proe_path - The path and file name of the Creo Parametric
executable, or a script that runs it.
prodev_text_path - The path under which the Creo Parametric TOOLKIT message
and menu files are held. This is used in full
asynchronous mode only. Otherwise, pass a null
string.
Output Arguments:
p_handle - A pointer to a process handle to be used in
subsequent calls to Creo Parametric.
Return Values:
PRO_TK_INVALID_PTR - Could not get a valid handle to connect to the
started Creo Parametric.
Other - see returns for ProEngineerStart() and ProEngineerConnect()
