SwpRunCmd
gar...@gmail.com
during the use of SwpRunCmd appear a cmd console,
is possible to reduce to icon or run hide?
Many thanks in advance.
Regards,
Ugo
Enrico Maria Giordano
<gar...@gmail.com> ha scritto nel messaggio
news:4339e2c9-b83d-4419...@i76g2000hsf.googlegroups.com...
> Dear Friends,
>
> during the use of SwpRunCmd appear a cmd console,
> is possible to reduce to icon or run hide?
If your OS is Windows then you can use ShellExecute().
EMG
--
EMAG Software Homepage: http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: http://www.emagsoftware.it/tbosg
The EMG Music page: http://www.emagsoftware.it/emgmusic
Xavi
Yes, a few years before I wrote two functiones .-
nRes := _RunHide( @cOut, cCmd ) and FilterOutCon( @cOut )
but is only tested for BCC, win2k and xHarbour.
If you or someone wants I can revise and posting.
Best regards.
Xavi
gar...@gmail.com escribió:
Robert Campsmith
Here is what I use to replace SwpRunCmd (from Blinker) and
Run (from xHarbour)...
*- from Enrico Maria Giordano via xHarbour newsgroup
#pragma begindump
#include "windows.h"
#include "hbapi.h"
#include "shellapi.h"
HB_FUNC( SHELLEXECUTE )
{
hb_retnl( ( LONG ) ShellExecute( ( HWND ) hb_parnl( 1 ),
hb_parc( 2 ), hb_parc( 3 ), hb_parc( 4 ), hb_parc( 5 ),
hb_parni( 6 ) ) );
}
#pragma enddump
Then I use this function "SwapOut()" wherever I would have
used the Run command or in Clipper/Blinker the SwpRunCmd.
****************************************
FUNCTION SwapOut( cProgram, cParameter )
*
* Purpose: swap out to ShellExecute
* Note: preferred way to call a Windows program
* will also work with DOS
*
SHELLEXECUTE( 0, 0, cProgram, cParameter, 0, 1 )
RETURN( NIL )
*
Good Luck,
-- Robert
gar...@gmail.com
In these solutions is possible to read the system ERRORLEVEL state?
Regards,
Ugo
Mario H. Sabado
I'm interested with your functions.
Thanks,
Mario
Robert Campsmith
The "SHELLEXECUTE" C program that EM Giordano wrote returns
a long numeric. When I tested, it returned the value 42 and
the function worked as expected. I do not know the meaning
of the return value. Enrico?
-- Robert
Enrico Maria Giordano
"Robert Campsmith" <drro...@sturec.com> ha scritto nel messaggio
news:g364o9$d9v$1...@aioe.org...
> The "SHELLEXECUTE" C program that EM Giordano wrote returns a long
> numeric. When I tested, it returned the value 42 and the function worked
> as expected. I do not know the meaning of the return value. Enrico?
A value greater than 32 means success.
Xavi
I need help to do the functions in several S.O. and test them.
And, for me, it's very important to find compatibility with Harbour.
About the name of the file is because I am thinking of Just in Time Compiler! ;)
Procedure Test()
Local nRes, cCmd, cOut := ''
// Important cOut initialize empty beacuse successive calls possible
cCmd := 'cmd /CDir *.*'
nRes := _RunHide( @cOut, cCmd )
if( nRes == 0 )
cCmd := 'C:\xharbour\bin\harbour.exe /q'
nRes := _RunHide( @cOut, cCmd )
// ...
FilterOutCon( @cOut )
endif
? cOut, nRes
return
Best regards.
Xavi
Mario H. Sabado escribió:
dlzc
> Ugo,
>
> The "SHELLEXECUTE" C program that EM Giordano
> wrote returns a long numeric. When I tested, it
> returned the value 42 and the function worked as
> expected. I do not know the meaning of the return
> value.
If in doubt about a WinAPI call, ask Micro$haft...
http://support.microsoft.com/kb/238245
... Win2k, but it gives you the idea...
David A. Smith
Mario H. Sabado
I'll test your function and I hope I can get rid of the popping icon
from windows task bar when calling external exe file (like rrwrun.exe).
Best regards,
Mario
Xavi
Thank to you.
Yes, don't worry about it or about the amount of information that the new process can dump.
For example if you have MySQL installed you can run the client "mysql.exe" with any instructions or script.-
Local cOut, cCmd := [C:\MySQL\bin\mysql -uroot -pxxxxxxxxxxxxxxxx -e"SHOW DATABASES;"]
nRes := _RunHide( @cOut, cCmd )
// ...
? cOut, nRes
Mario H. Sabado
_RunHide() Works fine so far with xHarbour and Harbour environment.
Although, I have "Unable to create process" error when calling 16-bit
application. Is this correct?
Thanks,
Mario
N:dlzc D:aol T:com (dlzc)
"Mario H. Sabado" <mhsa...@gmail.com> wrote in message
news:g39fup$pfn$1...@aioe.org...
> Hi Xavi,
>
> _RunHide() Works fine so far with xHarbour and
> Harbour environment. Although, I have "Unable to
> create process" error when calling 16-bit application.
> Is this correct?
You might try invoking CMD.EXE or COMMAND.COM directly, and see
if they can run the app (command line calls should work). You
may lose the ERRORLEVEL return code of the 16-bit app, however.
David A. Smith
mhsabado
wrote:
> "Mario H. Sabado" <mhsab...@gmail.com> wrote in messagenews:g39fup$pfn$1...@aioe.org...
>
> > Hi Xavi,
>
> > _RunHide() Works fine so far with xHarbour and
> > Harbour environment. Although, I have "Unable to
> > create process" error when calling 16-bit application.
> > Is this correct?
>
> You might try invoking CMD.EXE or COMMAND.COM directly, and see
> if they can run the app (command line calls should work). You
> may lose the ERRORLEVEL return code of the 16-bit app, however.
>
> David A. Smith
David,
Yes, I did try it from command prompt and the 16-bit exe file also
runs with __Run() from code.
Thanks,
Mario
N:dlzc D:aol T:com (dlzc)
"mhsabado" <mhsa...@gmail.com> wrote in message
news:4f3f5915-e4d0-4548...@w4g2000prd.googlegroups.com...
> On Jun 18, 9:17 am, "N:dlzc D:aol T:com \(dlzc\)"
> <dl...@cox.net>
> wrote:
>> "Mario H. Sabado" <mhsab...@gmail.com> wrote in
>> messagenews:g39fup$pfn$1...@aioe.org...
>>
>> > Hi Xavi,
>>
>> > _RunHide() Works fine so far with xHarbour and
>> > Harbour environment. Although, I have "Unable to
>> > create process" error when calling 16-bit application.
>> > Is this correct?
>>
>> You might try invoking CMD.EXE or COMMAND.COM
>> directly, and see if they can run the app (command
>> line calls should work). You may lose the
>> ERRORLEVEL return code of the 16-bit app, however.
>
> Yes, I did try it from command prompt and the
> 16-bit exe file also runs with __Run() from code.
Maybe I was not clear. Let's say the 16-bit apps name is
"AppName".
Did SwpRunCmd( "COMMAND AppName", <appropriate arguments> )
generate the "Unable to create process" error?
David A. Smith
Xavi
Yes, so... What happend?
We need to understand what is D.O.S. "DOS" and their interpreter of commands "command.com".
I think it's very important for the Clipper community.
DOS is an operating system designed to run a flow of instructions in an personal computers.
Based on interruptions, no in cycle distribution process like now known the multitasking that already existed when design.
This means that for you can run a stream of instructions "flow" different from the main flow, you can only catch a interruptions
and then return control (or not) from main flow. This has their limitations like you could imagine. Think about your brand new
desks XWindows, fashionWindows or simply think about how you read this post. Don't you have nothing more in the screen or in the
computer?.
In DOS don't have meaning the pipes, that also existed when design, between several processes or flows of instructions because
simply, these could not exist. When we wrote in command interpreter "Dir *.*|more" in reality we are doing "Dir *.*" in a file
and then, once completed, presenting it by pages "|more".
I lament this but I don't remember any complain about Clipper in CPM (another contemporary operating system). Sincerely I
believe that we must decide what we want about Harbour. A programming language for new applications or just to keep the old.
---------------------
Nosotros necesitamos entender que es D.O.S. "DOS" y su intérprete de comandos "command.com".
Pienso que es muy importante para la comunidad Clipper.
DOS es un sistema operativo diseñado para ejecutar un flujo de instrucciones en ordenadores personales.
Basado en interrupciones, no en distribución de ciclos de proceso como ahora conocemos la multitarea que ya existía cuando se
diseño.
Esto significa que para poder ejecutar un flujo de instrucciones diferentes al flujo principal, sólo puedo capturar una
interrupción para luego devolver el control (o no) al flujo principal. Esto tiene sus limitaciones como podéis imaginar. Pensad
en vuestros flamantes escritorios XWindows, fashionWindows o simplemente pensad en como podéis leer este post. ¿No tenéis nada
más en la pantalla o en el ordenador?.
En DOS no tienen sentido las tuberías "pipes", que también existían, entre diferentes procesos o flujos de instrucciones porque
sencillamente, éstos no pueden existir. Cuando escribimos en su intérprete de comandos "Dir *.*|more" en realidad estamos
haciendo "Dir *.*" sobre un fichero para luego, una vez finalizado, presentarlo paginado "|more".
Siento que esto sea así pero tampoco recuerdo ninguna queja acerca del funcionamiento de Clipper sobre CPM (otro sistema
operativo contemporáneo). Creo sinceramente que debemos decidir lo que queremos de Harbour. Un lenguaje para programar nuevas
aplicaciones o sólo para mantener las viejas.
---------------------
Sorry for my bad English.
Best regards.
Xavi
PS: ¡Dios, estoy escribiendo esto en el 2008! ... Lo siento, no puedo evitar decirlo. :'(
mhsabado escribió:
dlzc
On Jun 18, 9:18 am, Xavi <jarabal_eliminar_no_sp...@gmail.com> wrote:
...
> I lament this but I don't remember any complain
> about Clipper in CPM (another contemporary
> operating system).
CP/M predated MS-DOS and Clipper by 8-bits (and some years). dBase II
ran on 8-bits, but I am not sure Clipper was ever implemented there.
> Sincerely I believe that we must decide what
> we want about Harbour. A programming
> language for new applications or just to keep
> the old.
...
> Sorry for my bad English.
Your English is fine. Your intention is clear.
I don't think that invoking a separate threaded process with a single
integer return value is something that damns the language. I think it
is a feature. Imagine wrapping one of these SwpRunCmd "workarounds"
into a call to a parallel thread, that you can continue operation in
the calling thread, and occasionally check to see if the child process
is complete?
David A. Smith
Xavi
> CP/M predated MS-DOS and Clipper by 8-bits (and some years). dBase II
> ran on 8-bits, but I am not sure Clipper was ever implemented there.
That's going fast as time and forget things.
http://en.wikipedia.org/wiki/Multiuser_DOS
> I don't think that invoking a separate threaded process with a single
> integer return value is something that damns the language. I think it
> is a feature. Imagine wrapping one of these SwpRunCmd "workarounds"
> into a call to a parallel thread, that you can continue operation in
> the calling thread, and occasionally check to see if the child process
> is complete?
That's programming multitasking.
But it is not the objective of my function _RunHide( @cOut...
We have __Run() and you could call _RunHide() with [cmd /C"clipper.exe ..."] you have errorlevel but to capture the output you
need pipes and DOS or windows DOS emulator don't have pipes. I don't know if I have explained.
Best regards.
Xavi
dlzc escribió:
Mario H. Sabado
Just a revisit, using the _RunHide() with xCC/xHBCom Beta-71, I got
"Error BASE/0 CreateProcess". I have no problem though with latest
xHarbour CVS and Harbour SVN. Any idea?
TIA,
Mario
Xavi
> Just a revisit, using the _RunHide() with xCC/xHBCom Beta-71, I got
> "Error BASE/0 CreateProcess". I have no problem though with latest
> xHarbour CVS and Harbour SVN. Any idea?
>
Unfortunately I do not know xHBCom but I think that it works fine with Pelles C.
"Error BASE/0 CreateProcess" is because the command is not an executable win32 valid.
This example create an executable showing the process and run it from our [x]Harbour program.
I use BCC55 and xHarbour release-1-0-0-beta1 but it's easy to adapt to any version.
Procedure Main()
Local cCodePRG
#pragma __cstream|cCodePRG:=%s
*************************************
* CODE PRG cCodePRG for Test.prg
Procedure Main()
? 'Hello World!'
Wait
return
#pragma __endtext
MemoWrit( 'Test.prg', cCodePrg )
? "Builder Test.exe with cCodePRG .-"
? cCodePRG
BuilderHB( cCodePrg )
? "End"
Wait
return
Procedure BuilderHB( cCodePrg )
Local cHbBin, cHbInc, cHbLib
Local cBCBin, cBCInc, cBCLib
Local nRes, cCmd, cOut
cHBBin := 'C:\xHarbour\bin'
cHBInc := 'C:\xHarbour\include'
cHBLib := 'C:\xHarbour\lib'
cBCBin := 'C:\Borland\BCC55\Bin'
cBCInc := 'C:\Borland\BCC55\Include'
cBCLib := 'C:\Borland\BCC55\Lib'
cOut := ''
cCmd := cHBBin + '\harbour /n Test'
? cCmd
Wait
nRes := _RunHide(@cOut, cCmd)
? cOut
if nRes != 0
return
endif
cOut := ''
cCmd := cBCBin + '\bcc32 -tWM -c -v- -O2 -X -I' + cHBInc + ';' + cBCInc + '-oTest.obj Test.c'
? cCmd
Wait
nRes := _RunHide(@cOut, cCmd)
? cOut
if nRes != 0
return
endif
cOut := ''
cCmd := cBCBin + '\ilink32 -Gn -Tpe -x -aa -L' + cHBLib + ';' + cBCLib + ' '
cCmd += 'c0w32.obj Test.obj,' // OBJs
cCmd += 'Test.exe, Test.map,' // EXE MAP and LIBs .-
cCmd += 'cw32 import32 wininet gtwin rtl vm lang macro rdd dbfntx dbffpt hbsix codepage common pp pcrepos'
? cCmd
Wait
nRes := _RunHide(@cOut, cCmd)
? cOut
if nRes != 0
return
endif
? "And Run Test.exe"
Wait
__Run( 'Test.exe' )
return
Best regards,
Xavi
Patrick Mast
> nRes := _RunHide( @cOut, cCmd ) and FilterOutCon( @cOut )
They run fine with xHarbour and/or xHarbour Builder ;-)
But I still see a Dos Box pup up when I use _RunHide(). Should the
cCmnd not be run "Hidden"?
--
Sincerely,
Patrick Mast,
www.xHarbour.com