forum.vdsworld.com

[steeld]

My script uses RUN to kick off a command-line app. I have tried it on a range of PCs. On some it works fine and on others it fails. I haven't yet nailed down what the problem is but is seems to be a combination of memory and/or the fact that the command-line app accesses networked drives. In all cases, the command-line itself, when copied and pasted into a command window, works fine. It's only when it's fired from a RUN command that I see problems on some machines.

Anybody seen anything similar?

[WidgetCoder]

Check the file paths and or parameters for spaces. The run command parses the path string and interprets each white space as a parameter. You can either use escape characters "@chr(34)" or use the @shortname() function to overcome this problem.

e.g.:

%%FilePath = C:\Program Files\Internet Explorer\some.exe

Run @shortname(%%FilePath) /Param1 /Param2

OR better yet (in case 8.3 filename support is disabled):

Run @chr(34)%%FilePath@chr(34) /Param1 /Param2

[steeld]

I've checked all that dozens of times.

However, I've narrowed it down and it's a strange one.

This is what I do. I have a dialog with a File menu and an Open.. option that calls @filedlg so the user can select what file to send to the command-line app. Now if I bypass the @filedlg and hardcode the filename, the RUN command works fine. The selected filename and path are EXACTLY the same as the hardcoded one - I've been through all that.

I even changed the variable name, file description strings and everything but it's the fact that I am calling @filedlg that causes RUN to fail later in the script. What's worse is that RUN fails in a somewhat random manner - on some machines and not others and/or when retrieving files from a network file server. My only solution for my script appears to be to forget the @filedlg call and simply implement a drag'n'drop for file selection - that's my next step. I'll report back on progress but this is really curious.

[WidgetCoder]

If you post some example code I can test it on my end or perhaps someone up here will spot the problem. I feel your frustration... been there and done that a lot...

[steeld]

May be tricky as I perhaps need to supply the command-line app as well unless I can construct another which reports exactly what RUN is passing to it with, and without, @filedlg being executed.

Another quirk, is that if I hardcode everything I pass to the command-line app and still leave @filedlg in to be executed, the RUN fails to pass the parameters correctly even though it is not using anything returned by the @filedlg. If I comment out the @filedlg, it runs fine.

My priority first off is to make my app usable. Then, I'll see if I have time to delve a little further to provide a demonstrable and simple code sample here.

Thanks for your help.

[Aslan]

Maybe you could just post the "RUN" line as it is in your script for us to look at.

I had a similar issue several years ago and it turned out to be that I used a double quote ( " ) where I should have used @chr(34).

A good way to test this in the dialog editor is replace "Run" with "Info" to see exactly what the command line being passed looks like.

Here's a good template for what seems to have worked reliably for me.