#DEFINE stdout -11
#DEFINE errout -12
#DEFINE crlf CHR(13)+CHR(10)
*-- Funciones para escribir en StdOut
DECLARE INTEGER 'GetStdHandle' IN WIN32API AS _GetStdHandle INTEGER nHandleType
DECLARE INTEGER 'WriteFile' IN WIN32API AS _WriteFile INTEGER hFile, STRING @ cBuffer, INTEGER nBytes, INTEGER @ nBytes2, INTEGER @ nBytes3
LOCAL loException as Exception, lcOutput, lnOutHandle, lnBytesWritten, lnOverlappedIO
lcOutput = "Hello World!" + crlf
lnOutHandle = _GetStdHandle(-11) && CAPTURAR STDOUT DESDE CONSOLA: FOXBIN2PRG.EXE PARAMS | FIND /V ""
lnBytesWritten = 0
lnOverlappedIO = 0
_WriteFile(lnOutHandle, @lcOutput, LEN(lcOutput), @lnBytesWritten, @lnOverlappedIO)
MESSAGEBOX("BytesWritten: " + STR(lnBytesWritten))
Victor, ¿cómo estás ejecutando exactamente tu EXE desde la consola?
Fijate que en el ejemplo que puse de FoxBin2Prg, al final puse un pipe de DOS y el find "" /v, que es lo que permite obtener la salida de stdout que genera Fox y mandarlo a la consola
Hola Josef:
Cuando metes el código del ejemplo de la clase math en un prg, a este lo pones en un proyecto llamado myproject.pjx y lo compilas como DLL, VFP automáticamente lo compila y registra. Si ese paso de compilación no te da error, entonces quiere decir que deberías poder instanciar tu clase con
ox = CREATEOBJECT("MyProject.Math")
¿Eso te da error?
Juan, hacer un proceso que tenga que hacer archivos de texto para devolver respuestas, es lo más ineficiente que existe si querés una respuesta inmediata.
¿Y del lado que espera la respuesta que haces? ¿Meter un bucle que verifique todo el tiempo si se creó ese archivo, mientras usa el 100% de la CPU?
¿Para llamar a una función que preferís, llamarla con sumar(valores) o dejar archivos de texto por el disco? ¿Qué crees que va más rápido?
No sé para qué tanta migración a VB cuando una DLL Fox puede retornar parámetros con valores por referencia, o incluso un parámetro string con un XML, pero eso si, no como retorno de método.