Is there a way to extract the file names saved a .pset file?

I am trying to create a vba code that extracts the name of files saved into a .pset. Is there anyway to open a .pset with out opening microstation. When i open with notepad its all in garbled coding language that i can not utilize the information.

Thanks!

  • Emily,

    PSETs are compressed XML like files. If you rename a .pset to .zip you can extract it and see what's inside. I'm not sure how you'd get into this using VBA.
    There's a a way to do it programmatically, because Bentley has a utility rebasepset that will find and replace strings in .psets. I came across this after we upgraded our ProjectWise server and has to update the serve name in hundreds of psets.


    Tom F.

  • Hi Emily (and Tom F),
    Here is the procedure (sorry for the formatting). To piggyback off what Tom said:

    1. Export the PSET onto your C drive.
    2. Change the file extension from .PSET to .ZIP (this requires the display of file extensions in Windows). “Yup folks, a PSET is merely a group of XML files disguised as a Zip file—how about that?”
    3. Create a new folder, name is irrelevant.
    4. Open the Zip file.
    5. Select all the .XML files that are in the 8-4-4-12 character format (0ba53d02-4f49-4266-b8b7-e680b0b0fd1f.xml, for example) and copy them.
    6. Open the new folder, paste them.
    7. From the address bar, highlight and copy the path.
    8. Open the Command Prompt.
    9. Type CD followed by a space, then paste in the path from Step 7, press Enter. (This should now reflect the path from Step 7.)
    10. Type find /i ".dgn" *.xml > output.txt
      1. Note that the files will be searched alphabetically, not in the order they were listed in the PSET.
    11. Open Output.txt in a robust text editor.
    12. Select all the lines, and sort alphabetically.
    13. Delete the short lines in the top-half of the list:

    14. Select the remaining lines and copy them:

    15. Open a blank spreadsheet and paste them into Cell A11 on the tab. While Column A is (still) highlighted, open the Data tab and click Text to Columns. On Step 2, use the less-than character as the (only) delimiter:

    16. When done, the (unfitted) columns should look like this:

    17. Find the column with the file names and paths; in this example it’s Column K:

    From here the rest is up to you. I like to paste this column into the spreadsheet I used to create the PSET; this allows me to check where the missing file(s) from the PSET are.

     

    Enjoy,

    LOR

  • LOR,

    Man, that is some impressive reverse engineering. That's going into the toolbox.

    Thanks!

    Tom F.

  • Thanks! The original intent of doing this was to build PSETs offline, since that would avoid the triple-whammy of copying out files (with ProjectWise):

    1. When the files are added,
    2. When the Print Style is applied, and...
    3. When the PSET is printed.

    I get No. 3, but 1 and 2 are just huge time-sucks from the user's POV, regardless of the technology behind it.

    Anyway, I went deep down this rabbit-hole, copying and editing XML files, then carefully reassembling them back into the ZIP (PSET), but what I discovered was the GUIDs inside the XMLs are not the GUIDs in ProjectWise. There is an extra layer of on-purpose obscurement, as if the GUIDs are re-hashed for some odd reason. Maybe there is a lookup table somewhere, or a Magical PSET GUID Decoder Ring, but that's where it dead-ended for me.

    To bad, though, it would have been super-slick--or super normal--to write out (or copy/edit) a bunch of XML files--could probably do the whole thing from Excel--and build a PSET in minutes, instead of hours and hours and hours... I mean, a PSET is just a series of text files, so why all the gyrations??? Outside of PW I can print 500 drawings, in index order, in about 3 hours. In PW, this is a 2-day adventure... :-)

    (And Renditions is no prize either, in case anyone suggests that.)

    OK, OK, I'm preaching to the choir, sorry...

    LOR

  • Shoot--I forgot one thing:

    I explored, and maybe continue to explore, creating ONE pset for EACH dgn, with the hopes--according to a CR filed a few years ago--that a tool to stitch PSETs together would exist by now (it doesn't, AFAIK). This sort-of solves The Problem by off-loading the PSETs to the individual user(s) (since they need to make check-prints).

    Why ONE pset for EACH dgn?

    • All drawings need to be printed, but usually not all at the same time (voided drawings, retired drawings, garbage drawings, etc.) Having 500 tiny PSETs is more valuable to me than being able to create one (or two or three or four...) PSETs in < 1 day.
    • I can easily connect "which PSETs" with the index (which also comes from PW), providing a super-PSET that prints in index order, at will.

    Aside from the missing stitching tool, the biggest problem here is:

    • creating a single PSET and printing it to a PDF takes about a minute (using MVBA), but
    • creating a PDF directly (also using MVBA) takes 10 seconds.

    This is tough to swallow for most project teams. Well, I guess Milton Friedman was right: there are no free lunches...

    LOR