Detect name of the batch file which called my application 1

[colttaylor]

My BP7 application is getting a lot of support calls concerning captured network printers in Win2k. The
capture's get lost under a variety of conditions and
that operating system weakness leads directly to irrate
customer's calling me to fix it.
Recapturing the printer resolves the problem, but a few days later, the capture disappears again and they're calling again.
I discovered a nice way to avoid the re-occurrence of this problem, by adding commands to refresh the capture, directly into the batch files which calls my program. For example if the batch was...

C:
CD\MYDIR
MYPROG.EXE
CD
...I change it to...

C:
CD\MYDIR
NET USE LPT1: /DELETE
NET USE LPT1: \\SERVER1\HPLASERJ
MYPROG.EXE
CD
This works great and for the last several months, I have been manually editing batch files during each support call. Unfortunately, I wasn't very smart when I set up my customer networks, so multiple batch files on multiple local terminal harddrives have to be edited for each customer network. THIS BATCH FILE EDITING IS GETTING OLD!

Enough History, here is my question...
I want to make my program do the batch file editing for me. For this to work, I need to find the name of the batch file which called my program. Once I have the name, I can open the batch file as a text file, look for my NET USE commands and add them if they are needed. HOW DO I FIGURE OUT THE NAME OF THE BATCH FILE WHICH CALLED MY APPLICATION FROM WITHIN MY APPLICATION?

Thanks in advance for any assistance!
Peace,
Colt.
If it's stupid but it works, it isn't stupid

 

[LorenPechtel]

No answer here but a wild guess:

Walk up the PSP chain and see what the command line was for the previous layer. Check the current directory and walk the path looking for a batch file of that name.

Note: If you add lines to a currently-running batch file you can get strange results--when your program exits the batch file will resume where it left off.

Assuming Net use doesn't cause anything to stay resident, why not simply issue the commands at the start of your program?

 

[colttaylor]

Thanks!
Exec'ing a few commands at startup is a great idea! If it's stupid but it works, it isn't stupid