Qbasicnews.com

I've run into a problem. Recently at work I've been writing a bunch of programs that do an assortment of tasks with XLS, CSV, and tab-delimited text files. Mostly conversion, removing duplicate records, etc.

Anyways, my problem is that I like to make the programs such that you can drag-and-drop files onto the compiled executable. I've been doing this by using the "COMMAND$" function, looking through the string to parse by spaces, and saving the filenames to an array, then working with those filenames.

My problem is that the COMMAND$ function will only take maybe three or four files before it becomes too long. In otherwords, if I select two file and drag-and-drop them onto an executable, it works just fine. But if I drag and drop FIVE files onto the executable, it gives an error message.

Is there any way of increasing the allowed length of this function so that more files could be dropped onto the exe file? If not, does anybody know of a different approach to allow for the ease of drag-and-drop capabilities for an exe file?

I've noticed that one reason the command line gets so long is because it includes the files' full paths, e.g.

"M:\CLIENTS\DATA\CUSTOMER\SPREADSHEETS\09242003\blahblah.xls"

If I'm running this program IN the M:\clients\....\09242003\ folder, is there any way to make it just pass the filename instead of the full path?

I figure somebody'll have some great advice on this.

*peace*

Meg.

I assume it would be impossible to just run the program in a shorter directory?

it's not the program that's in a long directory, it's the path of the files that are gettin' passed to it. They're almost always on the server, all laid out in their folders inside folders.

*peace*

Meg.

The command-line length is a limit of DOS. You could use a batch file. With Windows 9x you can get the command line parameters using %1 to %9. With NT/2K/XP, you can use %1 to %9 also, or you can use %* for the whole thing. You could then stuff these in a file and read them from there.

If you don't want to use batch files, the other option would be to make a simple VB program to get the command line and then pass it to your QB program somehow. (Either split it up or use a temp file...)

so you're saying that I should make the exe file, then also make a batch file, and have them do the following:

1. drag-and-drop all the .xls files onto the BAT file
2. have the BAT file put %1 - %9 (or whatever) into a file called "FILENAME.LST"
3. have the BAT file call the EXE file
4. have the EXE file open up and use the contents of FILENAME.LST

could you give me some hints on the contents of the BAT file?

*peace*

Meg.

Instead of using %1 through %9, I could use %* and break it up somehow, but I'm not sure what the BAT file should look like.

*peace*

Meg.

meg,

I just looked in my !!!Original 1990 vintage QB users manual!!! and find on page 338 that the maximum length of COMMAND$ is 124 characters.

Hope this helps.

Mango

This may not be a practical solution, depending on the situation, but...

Maybe you can write a program that shells:


Then searches through out.dat for *.xxx and feeds those to your program.

if your program processes each file separately:

if you need a list of files:

also generates a list (with nt/2k/xp):


Note that the first two will give error messages (but they're not really errors), because you need to check if the file exists with quotes and without quotes to suppot both long and short filenames.

Plasma: Thank you so much. That's what I'm looking for. The third solution should work beautifully. Is there a length restriction on the number of files that can be dragged-dropped onto a BAT file?

*peace*

Meg.