Summary: 4 people replied.
One person suggested I look at the examples. I always start at the
examples and only post to the Pro/Gurus if I can't get the examples to
work. Same with threads.
Two people suggested it had something to do with argv parameters passed to
the app. I don't pass any parameters to it. I start up the asynchronous
.exe file by typing it's name at a dos prompt with no parameters.
Many thanks to Alan Hild who had the winning suggestion. Turns out to be
two problems. Pro/Toolkit apparently doesn't like paths. Made it a
single word and then it worked. (Almost). Now it does start wildfire but
doesn't return control to the program immediately on startup. Still sits
around for 5 minutes and finally returns error code of -1,
"PRO_TK_GENERAL_ERROR" (Real helpful PTC)
Here are a few of the many commands I tried:
//err = ProEngineerStart("D:\ent\appl\prod\ptc\proewf\bin\proe.exe
D:\ent\appl\prod\ptc\proewf\bin\proewildfire_tk.psf",NULL);
//err =
ProEngineerStart("D:\\data\\prowork\\ProToolkit\\ModifyAssyDims2\\Debug\\proe_tk","D:\\ent\\appl\\prod\\ptc\\proewf\\protoolkit\\protk_appls\\pt_userguide\\text");
//err =
ProEngineerStart("D:\\data\\prowork\\ProToolkit\\ModifyAssyDims2\\Debug\\proe_tk",NULL);
//err =
ProEngineerStart("D:\\data\\prowork\\ProToolkit\\ModifyAssyDims2\\Debug\\proe_tk",".");
//err =
ProEngineerStart("D:\\data\\prowork\\ProToolkit\\ModifyAssyDims2\\Debug\\proe_tk","bat");
//err =
ProEngineerStart("D:\ent\appl\prod\ptc\proewf\bin\proewildfire_tk.psf",NULL);
//err =
ProEngineerStart("D:\\ent\\appl\\prod\ptc\\proewf\\bin\\proewildfire_tk.psf",".");
//err =
ProEngineerStart("D:\ent\appl\prod\ptc\proewf\bin\proewildfire_tk.psf",".");
//err = ProEngineerStart("proewildfire_tk.psf",".");
//err = ProEngineerStart("proe_tk",".");
err = ProEngineerStart("proewildfire",".");
Only two of them worked:
1) err = ProEngineerStart("proewildfire_tk.psf",".");
2) err = ProEngineerStart("proewildfire",".");
proewildfire.bat is our company's batch program for starting up wildfire
without any Pro/Toolkit access. (Yes you can do a few minimal things in
Pro/Toolkit even if you don't have a license for it)
proewildfire_tk.psf is a PTC Startup File created by our sysadmin which
includes environment variables which are supposed to give access to
licensed parts of the Pro/Toolkit. Apparently it also does something else
that I don't understand. (File types in my Windows Explorer are set to
open .psf files with proe.exe which is why it will work with a single
word.)
1)The following command starts wildfire but then sits around for 5
minutes, eventually returning error code -1. I commented out the return
-1; so it could continue on. It then continues on but fails at
err = ProMdlRetrieve(wname, PRO_MDL_ASSEMBLY, &mdl);
2)The following command starts wildfire and then immediately continues on.
It then also fails at
err = ProMdlRetrieve(wname, PRO_MDL_ASSEMBLY, &mdl);
So why does 1 pause while 2 continues on immediately? Something about
that proewildfire_tk.psf file. Here are it's contents:
// PTC - PSF file: proe
//
PRODUCT=Pro/ENGINEER
DESC=proewidfire_tk
ENV=INTRALINK_DIR=
ENV=ILINK_CMD_NAME=
ENV=INTRALINK_CMD=%INTRALINK_DIR%\bin\%ILINK_CMD_NAME%
ENV=MECH_LP=__MECH_DIR__
ENV=MECH_HOME=%MECH_LP%\%PRO_MACHINE_TYPE%
ENV=PRO_MECH_COMMAND="%PRO_DIRECTORY%\bin\proe.exe"
"%PRO_DIRECTORY%\bin\proewildfire_tk.psf"
ENV=PATH+=%PRO_DIRECTORY%\%PRO_MACHINE_TYPE%\deflib
ENV=PATH-=%PRO_DIRECTORY%\%PRO_MACHINE_TYPE%\lib
ENV=PATH-=%INTRALINK_DIR%\%PRO_MACHINE_TYPE%\illib
ENV=PTCNMSPORT=1239
ENV=NMSD_TIMEOUT=300
ENV=PRO_COMM_MSG_EXE=%PRO_DIRECTORY%\%PRO_MACHINE_TYPE%\obj\pro_comm_msg.exe
ENV=PROE_START=%PRO_DIRECTORY%\bin\proe.exe
ENV=CDRS_DATA=%PRO_DIRECTORY%
ENV=PRO_IMAGE_CONVERTER=%PRO_DIRECTORY%\%PRO_MACHINE_TYPE%\obj\convert_image.exe
ENV=PRO_PHOTORENDER=%PRO_DIRECTORY%\%PRO_MACHINE_TYPE%\obj\PhotoRender.exe
ENV=GALAXYHOME=%PRO_DIRECTORY%\%PRO_MACHINE_TYPE%
ENV=PROGUIDE_DIRECTORY=%PRO_DIRECTORY%\uifdoc
ENV=SPG_DIRECTORY=%PRO_DIRECTORY%
ENV=PRO_USRMAIN=%PRO_DIRECTORY%\usrprog\umain\usrmain.c
ENV=PROTABLE_DIRECTORY=%PRO_DIRECTORY%\protable
ENV=PROTAB=%PRO_DIRECTORY%\%PRO_MACHINE_TYPE%\obj\protab.exe
ENV=ZIP_EXEC=%PRO_DIRECTORY%\%PRO_MACHINE_TYPE%\obj\zip.exe
ENV=CLHOME=%PRO_DIRECTORY%\text\pcldata
ENV=PVIEW_PVEXPORT_HOME=%PRO_DIRECTORY%\apps\prodview
ENV=CV_ENV_HOME=%PRO_DIRECTORY%\%PRO_MACHINE_TYPE%\CV102
ENV=VC_VCONF_START=%PRO_DIRECTORY%\%PRO_MACHINE_TYPE%\obj\ptcvconf.exe
ENV=PTC_D_LICENSE_FILE+="our license server names here"
ENV=PROE_FEATURE_NAME=PROE_1384822 ()
RUN="%PRO_DIRECTORY%\%PRO_MACHINE_TYPE%\nms\nmsd.exe" -noservice -timeout
%NMSD_TIMEOUT% &
RUN="%PRO_DIRECTORY%\%PRO_MACHINE_TYPE%\obj\xtop.exe"
// USER - PSF
// Add User specific environment or run applications below here
A ha! You say (as I did). There is the 5 minute delay.
ENV=NMSD_TIMEOUT=300
So I set it to 60 and re-ran in a new dos window but it still delayed for
5 minutes. Maybe I need to reboot for it to go into effect? Great. I
don't want to waste a half hour to get back to where I'm at.
I also tried commenting out this line:
RUN="%PRO_DIRECTORY%\%PRO_MACHINE_TYPE%\nms\nmsd.exe" -noservice -timeout
%NMSD_TIMEOUT% &
but had no effect
Q1. What the heck is in this file that prevents control from being
returned immediately on Proe startup, and why?
Q2: Why does ProMdlRetrieve fail? I moved the assembly and part to the
executable directory (and renamed them to remove the version number just
in case. It came up ok manually.) so I could test it without a path but
it still failed.
Q3: How do you'all handle paths?
TIA
Greg
