Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

can not run java cmd

140 views
Skip to first unread message

Roland

unread,
Jun 6, 2007, 6:21:23 AM6/6/07
to
Hi:

I have an application need call cmd file containing java command, tried
using shellexecute and createprocess, both not working.

The processes like this:
delphi application call somecmd.cmd
in somecmd.cmd file, it contains one line: java somejavaclass
then somejavaclass process in DOS environment.

From our customer's document, the somecmd.cmd file can not be use open, it
need run in DOS environment.

If I run somecmd.cmd file in DOS environment, it works, but never work by
calling from my Delphi app.

Could some one give me hand? Thanks.

Roland


Rob Kennedy

unread,
Jun 6, 2007, 1:31:28 PM6/6/07
to
Roland wrote:
> I have an application need call cmd file containing java command, tried
> using shellexecute and createprocess, both not working.

People frequently make mistakes when trying to call those two API
functions. How are you using them?

> The processes like this:
> delphi application call somecmd.cmd
> in somecmd.cmd file, it contains one line: java somejavaclass
> then somejavaclass process in DOS environment.

I'm pretty sure there is no Java virtual machine that runs in DOS. Are
you really talking about the 16-bit operating system of the '80s and '90s?

I suspect you mean to talk about the 32-bit console environment provided
by Windows. (Just because you have a black text window doesn't mean it's
DOS.) Why do you need the command file at all? Can't you just use
CreateProcess to run the Java program directly?

Could the current directory have anything to do with the problem? Can
Java find the file for the requested class?

How do you know that your attempts are "not working"? What do you expect
your program to do, and what is happening instead? Do you get any error
messages? What are the API functions returning?

--
Rob

Roland

unread,
Jun 6, 2007, 8:27:20 PM6/6/07
to
Thanks Rob:

OK. Working environment is WinXP, Delphi 5. I have 3 cmd files need to be
called from my Delphi app. Two of them working fine, and the only one not
working and this one, from java developer's document says: (This cannot be
done by simply opening the file - it should, for example, be run from a DOS
cmd prompt).

These 3 cmd files are used to call java classes and those java stuff then
send xml to the http server and then get respnse from server, transform xml
to html and finally print html label.

I will try call java class directly.

Here are our calling functions:

1. Using CreateProcess:

procedure Pause;
var
Msg: TMsg;
begin
while PeekMessage (Msg, 0, 0, 0, pm_Remove) do
begin
if Msg.Message = WM_QUIT then
begin
PostQuitMessage(msg.wParam);
Exit;
end{Msg.Message};

if not IsDialogMessage (0, Msg) then
with Msg do
begin
TranslateMessage (Msg);
DispatchMessage (Msg);
end{With Msg do};
end {While PeekMessage};
end {Pause};

//{$IFDEF WIN32}
procedure WinExecWait(PFile, PCommand : PChar);
var lpExitCode : DWORD;
lpProcessInformation : TPROCESSINFORMATION;
startupInfo: TStartupInfo;
begin
ZeroMemory(@lpProcessInformation, sizeof(TProcessInformation));
ZeroMemory(@StartupInfo, sizeof(TStartupInfo));
with StartupInfo do
begin
cb := sizeof(TStartupInfo);
dwFlags := STARTF_USESHOWWINDOW;
wShowWindow := SW_SHOWMINIMIZED;
end;
if not CreateProcess(
PFile, // pointer to name of executable module
PCommand, // pointer to command line string
Nil, // pointer to process security attributes
Nil, // pointer to thread security attributes
False, // handle inheritance flag
NORMAL_PRIORITY_CLASS, // creation flags
Nil, // pointer to new environment block
Nil, // pointer to current directory name
StartupInfo, // pointer to STARTUPINFO
lpProcessInformation // pointer to PROCESS_INFORMATION
) then
exit;

while True do
if GetExitCodeProcess(lpProcessInformation.hProcess,lpExitCode) then
begin
if lpExitCode <> STILL_ACTIVE then
break
else
Pause;
end
else
break; { something amiss }

CloseHandle(lpProcessInformation.hProcess);
//{$ENDIF}
End { WinExecWait() };

2. ShellExecute function
ShellExecute(Handle, 'open', PChar(cmdfile]), PChar(CurDir),
PChar(CurDir), SW_Normal);


Any thoughts?

Roland


"Rob Kennedy" <m...@privacy.net> wrote in message
news:4666...@newsgroups.borland.com...

Roland

unread,
Jun 6, 2007, 9:37:24 PM6/6/07
to
The difference for this cmd file is if you double click this cmd file in
windows explore, it doesn't work, while for other cmd files, it works.
That's why the java developer said you need runn this cmd file in DOS cmd
prompt.

I can't figure out why and how to call from Delphi applciation.

Roland


Rob Kennedy

unread,
Jun 6, 2007, 10:56:44 PM6/6/07
to
Roland wrote:
> The difference for this cmd file is if you double click this cmd file in
> windows explore, it doesn't work, while for other cmd files, it works.

What do you mean when you say it "doesn't work"?

> That's why the java developer said you need runn this cmd file in DOS cmd
> prompt.

OK, so what's different about them?

--
Rob

Roland

unread,
Jun 7, 2007, 12:44:39 AM6/7/07
to
> What do you mean when you say it "doesn't work"?
OK. There are 3 cmd files: setClassPath.cmd, runClient.cmd and
generateLabel.cmd.
Before calling runClient.cmd or generateLabel.cmd, it should call
setClassPath.cmd first.
So in Delphi app:
the processes like this:

//send xml request and get response from http server
ShellExecute(handle, 'open', Pchar('setClassPath.cmd'), '', Pchar(curDir),
SW_Normal);
ShellExecute(handle, 'open', Pchar('runClient.cmd'), '', Pchar(curDir),
SW_Normal);
//that's working, the request successfully send to server and get response.

//transform xml to html file
ShellExecute(handle, 'open', Pchar('setClassPath.cmd'), '', Pchar(curDir),
SW_Normal);
ShellExecute(handle, 'open', Pchar('generateLabel.cmd'), '', Pchar(curDir),
SW_Normal);
//that's not working, because no html file generated.
However, if do it in DOS prompt, typing:
setClassPath.cmd
generateLabel.cmd
it's working, and the html file is generated

>
>> That's why the java developer said you need runn this cmd file in DOS cmd
>> prompt.
>
> OK, so what's different about them?
>
> --

Further test in Windows explore
if double click setClassPath.cmd and then double click runClient.cmd, it's
working, xml request was sent and response received.

if double click setClassPath.cmd and then double click generateLabel.cmd, no
html file geenrated.


Now put thess two commands into one batch file generateLabel.bat and having
lines like this:
call setClassPath.cmd
call generateLabel.cmd

And then call generatelabel.bat from Delphi app it's working, the html file
is generated.
ShellExecute(handle, 'open', Pchar('generateLabel.bat'), '', Pchar(curDir),
SW_Normal);

The problem found:
When Delphi app call
ShellExecute(handle, 'open', Pchar('setClassPath.cmd'), '', Pchar(curDir),
SW_Normal);
it execute and no error return
then do
ShellExecute(handle, 'open', Pchar('generateLabel.cmd'), '', Pchar(curDir),
SW_Normal);
it execute and no error return too, but the problem is the java stuff shows
the java library missing, this error is the same as you call
generatelabel.cmd without call setClasspath.cmd.

So somehow the generateLabel.cmd should be called immediately after
setClassPath.cmd and in the same environment. So we combine two cmd into one
batch file, it's working.

BUT I don't know why the other pair java cmd can work and this pair can't
under the same process.

Roland


Rob Kennedy

unread,
Jun 7, 2007, 2:02:14 AM6/7/07
to
Roland wrote:
>> What do you mean when you say it "doesn't work"?
> OK. There are 3 cmd files: setClassPath.cmd, runClient.cmd and
> generateLabel.cmd.
> Before calling runClient.cmd or generateLabel.cmd, it should call
> setClassPath.cmd first.

You don't need those external scripts. Set your own program's
environment variables however the script sets it up, and then run
java.exe or javaw.exe the way the second script runs it.

What's happening now is that you run the first script in a new
command-interpreter process. The script sets the environment variable
*for that process*, and when the script is finished, that process
terminates. Afterward, you run the next script in a *new*
command-interpreter process. That new process inherits its environment
from your program, which still has the same environment it always had.
The first script only modified the environment for its own process, not
your program's.

Modify the environment of your program, or create a new set of
environment strings to pass to CreateProcess when you execute the Java
program.

> So in Delphi app:
> the processes like this:
>
> //send xml request and get response from http server
> ShellExecute(handle, 'open', Pchar('setClassPath.cmd'), '', Pchar(curDir),
> SW_Normal);
> ShellExecute(handle, 'open', Pchar('runClient.cmd'), '', Pchar(curDir),
> SW_Normal);
> //that's working, the request successfully send to server and get response.

If that's working, then the second script doesn't really need the first
script at all.

> //transform xml to html file
> ShellExecute(handle, 'open', Pchar('setClassPath.cmd'), '', Pchar(curDir),
> SW_Normal);
> ShellExecute(handle, 'open', Pchar('generateLabel.cmd'), '', Pchar(curDir),
> SW_Normal);
> //that's not working, because no html file generated.
> However, if do it in DOS prompt, typing:
> setClassPath.cmd
> generateLabel.cmd
> it's working, and the html file is generated

The reason it works is that the command interpreter (which is not DOS)
does not execute scripts by starting new command-interpreter instances.
Instead, what it does is open the script file and execute its lines
one-by-one. Since the commands are being executed internally, changes
made to the environment are *kept* from one line to the next.

> Further test in Windows explore
> if double click setClassPath.cmd and then double click runClient.cmd, it's
> working, xml request was sent and response received.

Once again, you'll find that the first script isn't necessary. You can
run runClient.cmd without running setClassPath.cmd first.

> if double click setClassPath.cmd and then double click generateLabel.cmd, no
> html file geenrated.

Right. That's because Explorer is creating new command-interpreter
instances for each cmd script you run.

--
Rob

Roland

unread,
Jun 7, 2007, 2:29:37 AM6/7/07
to
> What's happening now is that you run the first script in a new
> command-interpreter process. The script sets the environment variable *for
> that process*, and when the script is finished, that process terminates.
> Afterward, you run the next script in a *new* command-interpreter process.
> That new process inherits its environment from your program, which still
> has the same environment it always had. The first script only modified the
> environment for its own process, not your program's.

So how to explain same function calls for those two pairs command file, one
pair is working and one pair is not, that drives me crazy.

Now I put setClassPath.cmd into runClient.cmd and generateLabel.cmd, so my
Delphi app only need call one command. Those java developers totured me.

Roland


Rob Kennedy

unread,
Jun 7, 2007, 11:57:24 AM6/7/07
to
Roland wrote:
>> What's happening now is that you run the first script in a new
>> command-interpreter process. The script sets the environment variable *for
>> that process*, and when the script is finished, that process terminates.
>> Afterward, you run the next script in a *new* command-interpreter process.
>> That new process inherits its environment from your program, which still
>> has the same environment it always had. The first script only modified the
>> environment for its own process, not your program's.
>
> So how to explain same function calls for those two pairs command file, one
> pair is working and one pair is not, that drives me crazy.

The first "pair" isn't really a pair. I told you that you can just run
the second command, _without_ running the first, and it will still work.
In the first pair, the second command is not sensitive to the changed
class path. The class path doesn't need to change, and so the first
command doesn't do anything significant to the success of the second
command.

--
Rob

Roland

unread,
Jun 11, 2007, 10:34:27 PM6/11/07
to
> The first "pair" isn't really a pair. I told you that you can just run the
> second command, _without_ running the first, and it will still work. In
> the first pair, the second command is not sensitive to the changed class
> path. The class path doesn't need to change, and so the first command
> doesn't do anything significant to the success of the second command.
>

You are right. The second command in the first pair can run without first
command. It was misleaded by java developer's document.

Thanks.

Roland


0 new messages