Not unless you have the file format specification of the .PRG files, no.
Your app would need to be able to open the .PRG and parse it to fetch the dimension data. I have asked for this specification long ago, but was turned down, which is understandable because competitors could use that specification in order to open PC-DMIS programs in "their" software.
Having nothing to do at the moment (I'm retired) I spotted this question from some time ago. The answer given is correct but I thought I would add some further info on the topic. Disclaimer: The following is based on personal observation of the behavior PC-Dmis while writing PC-Dmis programs and PC-Dmis automation code. I do not have access nor have I seen the base code source for PC-Dmis Application so the following is entirely conjecture based on experience.
As a programmer in C++, C# and Java, the .PRG files looks to me to be an Object serialization file. When you create a Pc-Dmis program you're not really creating a script or list of programming commands in the traditional sense like in a source code for C++, C, Java, C# etc. It appears that when creating a PC-Dmis program you're actually sequentially linking various PC-Dmis objects such as the DimensionCommand etc. Either one of the views that you can use to look at your program is simply a view of the PC-Dmis Objects that the underlying PC-Dmis application allows you to see. It appears to me that during PC-Dmis program execution, each object in the "program" is accessed sequentially and its "DoYourThing" method is invoked. Notice that when writing the "program" that you can insert a Hit command object, then multiple lines later add a Dimension command object, link the Hit command object with the Dimension command object and it knows instantly the current values of the Hit command, without program execution.
Object Application programmers use what is called a Class as a template which describes everything about the object, its properties (X value, Y value etc.) and methods (things it can do). Using Visual Studio, you can see all the Classes of objects used by PC-Dmis, its properties and methods. When you insert an PC-Dmis command object into the "program" PC-Dmis creates an instance (makes it real) from the template and inserts it into the sequential list of objects that represent your program. When you save a "program", each object in sequence writes itself, and all the data necessary to reconstruct itself. into binary file (not man readable). To read the data from the file, you would need the EXACT class template for each object in the file. If the data in the file has been changed or corrupted, opening the file to reconstruct all of its objects will fail. I'm sure many of you have seen this when a PC-Dmis file fails to open. As a programmer, the method for serializing objects to a file is a method already written for me in a system library file. As such, I have no idea the order in which class information is written, nor do I care. To enable someone else to read in the program file I would have to give them all my class templates source code.
Having described how I think PC-Dmis "program" files are created, we come to the "so what".
Knowing the above info is only relevant if you're having performance issues during PC-Dmis program execution. Specifically, if your program is getting data, such as hit locations or part dimension values, from an external file during execution.
Case 1: Programmer wrote a loop to read and hit the hit location according to the data from an external man readable file created by Design office. In this case the CMM literally sat for more than a few seconds while waiting to read the next hit location data from the file.
Case 2: Programmer wrote a PC-Dmis subroutine to read each hit location from a file, creating an array of hit locations. This array of hit locations was then used in a loop. This solved the problem of the delay after each hit in the loop. But the subroutine to read in the hit locations and create the array created a considerable pause each time the program was executed.
Case 3: Taking advantage of the info above, a PC-Dmis automation program was written to read the Hit location data file and create a new PC-Dmis Subprogram (.PRG) file. The file, constructed with the proper PC-Dmis subprogram start and end commands, was populated with variable array assignments using the hit data from the data file. The subroutine name was always the same name so that the main PC-Dmis program calling the subroutine did not have to be modified. After the subprogram was created, The main PC-Dmis program file was opened. Here's where things get interesting. While the main program is being read in and each object being recreated, it comes to the call subroutine object. It is at that moment, the subroutine is actually read in and constructed. When the main program is executed, the call to the subroutine is nearly instantaneous because the subroutine and the variable arrays were created during the opening of the program. Repeated execution of the already opened program has no delays.
Side note: Case 3 is one method of creating "Parametric" PC-Dmis programs written to measure part families of basically the same shape but differ in size and the absence or presence of features.
Having nothing to do at the moment (I'm retired) I spotted this question from some time ago. The answer given is correct but I thought I would add some further info on the topic.
Thanks for sharing that knowledge. Very interesting observations. I could see how those different approaches of reading measuring routine data from an external file could result in very different execution performances. I bet it was quite a surprise to have a several second time delay between each hit when implanting Case 1. I'm sure there would be some delay, but that's huge! I like your clever workarounds. I didn't realize that all the subroutines would load when a program is opened like that. Good thing to keep in mind.
Getting off topic now... How's retired life treating you? Do you still tinker with computer programming for fun?
