Foro de elhacker.net

Jamas di con un problema tan extraño, trataré de resumir. El problema es con un bat

Estoy haciendo un programa que simplemente con un commonddialog selecciono un archivo, el path y la extension queda en un txt, y con un boton se ejecuta lo que haya quedado en el path, o sea seleccono un archivo y lo ejecuto... solo eso.

Que sucede, cuando lo selecciono por primera vez y le doy ejecuitar a ese boton lo abre correctamente.

Luego el sistema mio tiene la opcion de guardar registros de todo eso, asi que mediante los record set guardo en la base de datos cada registro, luego cuando el usuario quiere restarua eso (a modo de preset)

Resulta que carga todo correctamente, cuando lo devulevo el path del programa al mismo txt original, en el textbox se puede apreciar que se lee exactamente IDENTICO a como fuera si el usuario lo hubiera seleccionado recien en lugar de restaurar la preset.

Ahora que pasa... cuando le doy ejecutar, no se ejecuta...

pero si selecciono de nuevo el archivo y una vez vuelto a seleccionar  (obviamente la ruta no cambia ni se modifica a la vista, es exactamente la misma) si anda el ejecutador de mi programa... con solo volver a seleccionar lo mismo

El tema es que lo que selecciono es un bat, entonces en realidad el shell si lo ejecuta, pero se cierra rapidamente, como si fallara algo interno del bat, pero lo tan extraño que destaco, es que simplemente volviendo a cargar manualmente (con mi boton examinar) el archiv bat, si anda. Y la ruta no se modifica.

Es mas, en la linea anterior a ejecutar el shellejecute, puse un msgbox para que muestre al path del programa, y en ambos casos (cuando restauro el preset desde la base de datos, o seleccionado ahi mismo sin usar el recorset) el path es exactamente el mismo y no hay una / de menos o de mas o : o esas cosas..

que podrá ser?

Todo apunta a magia negra.  :rolleyes:  estás seguro que es el mismo path? :xD

te dire algo, si no muestras el codigo , nunca te podriamos ayudar a ver donde esta el error.

- Cierto, al menos una muestra funcional que de el problema + la versión de tu sistema operativo.

Seven x64 estoy ahora. Pero lo programe en PC virtual de XP x 32.

miren el video.

yuzCEsWALaE

donde dice el nombre del acceso directo en el txtbox (el la mitad arriba) ahi va el .exe original, por que eso lo usa para cerrarlo. El programa abre y cierra cada X minutos, Todo funcioa de 10, los registros los relojes, todo, absolutamente todo de 10. SOlo ese maldito coso que ven sin explicacion. El codigo es largo para pasarlo todo, q parte necesitarian ver exactamnte?

NOTA: Por las dudas le meti un msgbox cuando lo programaba con la cantidad de caracteres del txtpath y me daba la misma cantidad de caracters

Como te dije antes, Tu como Programador debes revisar el codigo Parte por parte en busca del bug.
Claro esta q si cargas el Present (k.aaa) y no funciona , debes verificar exactamente los valores que carga dicho archivo. y que hace. puede q el error este alli...

Tu pusiste "Brujeria china" cuando no te cargo por medio del (k.aaa) , y despues que cargaste de nuevo el "gg.lnk" pusiste "No cambio nada" quiero hacer enfacis ahi, ya que no puedes afirmar que eso, hay variables en el codigo que no sabes si cambiaron.

(lo que trato decir , es que el error que tienes puede estar en cuando cargas el archivo (k.aaa), que no carga lo que deberia ser. )

---

No muestras codigo, asi que tendre que "Teorizar / Suponer" donde esta la falla.

Bien, por lo que veo el Programa lo q hace :

1) Abre el gg.lnk (un acceso directo a "Start Todo.bat")

2) se seleccionara en un combobox el Programa de minero.

3) basicamente el programa controla el tiempo del minado y/o guarda el estado donde quedo en un Present (k.aaa) .

---------------------------------------------------------------------------------------------------------------

No has puesto el codigo del Start TODO.bat no podemos saber si es un error en el Script.


No sabemos que Informacion se guarda/carga el archivo de Precencia (k.aaa)

Incluso Podria ser el PhoenixMiner.exe que no se cierra a la Primera vez, tendrias q revisar. y si ese fuera el caso debes Matar el Proceso cuando terminas el minado.

noo, es muchísimo mas simple que es, el guardar preset, lo unico que hace es guradar en una base de datos, mediante adodb.recordset, el contenido de 5 text box, el q tiene el path, los 2 para poner minutos, y alguinas opciones mas.

Entonces cuando el usuario carga eso que guardó antes, simplemente va a la base de datos, toma los datos tal cual se guardarony  los vuelve a poner en los casilleros originales. SOlo eos eso.

Entonces la bruejeria china es,

si cuando el usuario cargó el .bat del acceso directo, en el txtpath se puede ver la ruta (el txt q termina en Start Todo.bat) Entonces el bton verde no hace mas que un shellexecute de ese bat, h ejecuta el scrip del bat y anda (ahora, cuando lo hace por primra vez) si carga el preset (o sea, el recorset pone en el txtpath exactamente el mismo sin espacios ni nada de mas ni menos), ejecuto el shellexecute y no anda. Pero la direccion que se le pasó al ShellExecute.. es exactamente la misma que si lo hubiera cargado con el bton de examinar, o la hubiera escrito manual o lo que sea... el problema está o en el bat, o en el shellexecute, mas bien diria en algo raro entre ambas cosas, por que el shellExecute ejecuta perfecamente lo que sea sacando los bat, cualquier cosa sea cargada con preset o en el mismo boton examinar, anda siempre. Es solo con los bats. Realmente creo que es alguna configuracion externa tal vez :/

Tal vez sea alguna limpieza de variables, o algun parámetro del ShellExecute, por que lo de "Usar Presets" no es mas que guardar y restaurar los mismos datos que el usuario puso en una base de acces, y restaurar eso tal cual a donde estaba.

REsumen nivel 5:

1)Boton examinar da => c:/hola.bat  El usuario usa el ShelExecute (el boton verde) >> Anda bien
2)Boton guardar preset. c:/hola.bat se guarda en la base de datos
3)Boton restaurar: Restaura en txtpath c:/hola.bat exacctamente igual que en el 1 queda en el txtpath
4) El boton verde ejecuta el shellexecute > no anda.
5) Hago el paso 1 y anda.

ShellExecute actua sobre el path del txtpath, no una variable. Y ademas lo mas extraño, es que de entrada anda, luego no.  Creo que desistiré, no parec problema del programa, debe ser algo del entorno de windows o de los bat en si, o algo en el parámetro del ShellExecute, uso el ShellExecute mas comun y corriente:

Private Declare Function ShellExecute Lib "shell32.dll" Alias _
    "ShellExecuteA" (ByVal hwnd As Long, ByVal lpOperation As String, _
    ByVal lpFile As String, ByVal lpParameters As String, _
    ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long

Private Sub btnEjecutar_Click()
    ' Ejecutar un acceso directo
dim ret
ret = ShellExecute(Me.hWnd, "Open", txtpath.text, "", "", 1)

End Sub

No sé si aún te sirva, pero es bastante obvio que algo sí que es diferente en ambos casos, y es un error muy común cuando uno tiene poca experiencia. Siempre que uses cuadros de diálogo para abrir o guardar archivos, ten presente que te pueden cambiar el directorio actual (working directory).

Puedes ver que eso está ocurriendo en tu programa. Fíjate en tu video, en las ventanas de consola, desde dónde se están ejecutando los comandos del bat. Seguro alguno de esos comandos depende de la ruta, y por eso el error.

Hola. No creo, sigo pensando que es brujeria china. Desde el dia que dejé esto es por que me llené de odio luego de reever el codigo de las formas que sean, y no le encontré la vuelta. Hoy luego de?? 1 mes? decidí retomarlo, para intentar nuevamente y sigo sin encontrar respuesta. Me enfermé a tal punto que iba a directamente a rehacer el proyecto, pero me calmé y pensé un poco:

Situacion: No hay forma, sólo anda de esa forma. ¿Que hago? busco la solucion? ya no, la busque demasiadoy  no la encontré. Entonces buscaré la solución más elegante.

Lo solucioné, creando un acceso directo.

Seré extenso pero repetiré el problema.


Tu primera cita



tendría argumento lógico y real si fallara luego de cargar una preset con cualquier tipo de archivo. O sea si yo guardo una preset, salgo de programa, lo inicio de nuevo, cargo una preset, le doy Play y falla con todos los archivos, claramente es lo que dices: un error en el directorio actual.

Pero no es el caso, ya que cualquier archivo que exista (excepto los bat) Funciona bien. Inicio el programa > Cargo la preset, le doy play al programa, y el programa o archivo se ejcuta sin problema y sigue la función de mi original de mi programa.


Pero no, sólo falla con los BAT (y no sé si todos, al menos los que uso).

Resumen del problema:

Si inicio el programa, seleccciono el bat, le doy play.. anda
Si inicio el programa, selecciono cualquier programa u archivo, le doy play... anda
Si Inicio el programa, guardo una preset del bat, Lo cierro, cargo la preset y le doy play, NO ANDA. Es decir, abre el CMD rápido y se cierra.
Si inicio el programa, guardo una preset con cualquier archivo, y le doy play, Anda...

 Lo que hace mi programa cuando selecciona el archivo, es simplemente abrir el commonDialog, el FileName (ruta completa con archivo y extensión incluidos) queda guardado en la caja de text "txtpath" luego el boton preset guarda eso en una base de datos. Cuando se carga la preset desde otro boton, se trae la info desde la base de datos al casillero de origen. Fin, eso es el 50% del programa.

Al levantar es  recordset. el botón de "iniciar" manda el ShellExecute al TXTpath, y obviamente anda, con todo y todas las preset, menos el jodido bat... (sólo si es cargado desde un preset preset, pero cualquier otro archivo si anda cargando preset :/).


Brujería del Tío Bill.. para mi algun error interno desconcido entre el CMD y las API de ShellExecute, Shell, o el WinExec. Con ninguna de las 3 andubo,
tal vez al final del recordset en el levante de los datos a la base de datos al sistema tenga algo... O tal vez en el option explicit para abajo.. En fin, para mi absolutamente todo queda descartado por que anda con todo lo que existe en entorno windows, con o sin carga de presets, menos con los bat luego de ser levantados desde la base de datos.

En fin, cual es la solución? La única y comentada al principio del post, volver a seleccionar el archivo Bat, o el acceso directo a dicho bat, desde el boton que abre el common dialog. Solamente hacer eso, y darle play, ya anda, sino se cierra al toque la ventana del CMD


Cual es la solcucion elegante? Simplemente cuando guardo la preset, en secreto sin decirle al usuario le borro la carpeta system32 y todas sus fotos guardo en el path del programa un acceso directo a esa ***** que haya seleccionado al principio.

Cuando inicia el programa, pregunta si es un bat, si pone que no, ejecuta normalmente algo que no sea bat y obviamente anda. Si pone que si, abre de nuevo el commonDialog en la carpeta interna del programa, y hace doble click en el acceso directo, ya con eso sigue la funcion correcta de todo el sistema y anda perfectamente. Digamos unos 4 clicks de más.

No se me ocurrió otra cosa, probé demasiadas cosas y jamás quiso andar.



Ni lei eso que me pedias el codigo del bat... a ver si era eso.

Por cierto si, es la función principal del programa y por eso se pide aparte (escrito manualmente x el user) el nombre del .exe. Cierra el .exe en un momento.

El bat tiene esto


setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
EthDcrMiner64.exe -epool us2.ethermine.org:4444 -ewal 0x8cce0e45e0fe85f3f70380825c23975b2235.MineraHanlRX570 -epsw x -mport 0 -showdiff 1 -showpower 1 -dbg -1 -rxboost 0

Fail sorry. Arriba ultima

Hablas de un modo inconcreto. No se puede adivinar que falla en un programa que falla, así, sin más.

Luego pones un vídeo (que no voy a ver), en vez de simplemente hacer un copypaste de texto, con el contenido del bat... y el contenido del código que hace la llamada al bat. Es rápido, es fácilmente consultable y se puede repasar cuantas veces sea preciso de forma rápida (un vídeo exige volver a verlo todo de nuevo y se pierde mucho tiempo con ello).

Si haces esto último marcado en negrita, pués se le podrá echar un vistazo rápido...

Esto pone el Path del archivo en el TXT Path:

Dim cadenita
 Dialogo.ShowOpen
txtPath.Text = Dialogo.FileName
txtSucia.Text = Dialogo.FileTitle
cadenita = Len(txtPath.Text)
If cadenita > 255 Then
MsgBox "La ruta de este programa es demasiado lejana, debe seleccionar una ruta más corta de destino", vbCritical
txtPath.Text = ""
Exit Sub
End If
c_var = 0

Cadenita es un simple método para que el cliente no me selecicone algo en la ultima subcarpeta del nucleo de system32 con 3000 subcarpetas previas.

txtsucia guarda el EXE, por que se usa para otra funcion del programa que no tiene problemas.

Si yo ahi le doy Play anda, anda con el ShellExecute:

Private Declare Function ShellExecute Lib "shell32.dll" Alias _
    "ShellExecuteA" (ByVal hwnd As Long, ByVal lpOperation As String, _
    ByVal lpFile As String, ByVal lpParameters As String, _
    ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long
    
'---------- El boton Play:

ret = ShellExecute(Me.hwnd, "Open", txtPath, "", "", 3)

Ya ahi anda, sin problemas, el bat y lo que sea.

Luego este boton, Guarda los TXT en una base de datos:

Private Sub EntradaPreset()
    Dim rs As ADODB.Recordset
        If Not Conectar() Then Exit Sub
        Set rs = New ADODB.Recordset
            rs.Open ("Preset"), cn, adOpenKeyset, adLockOptimistic
            rs.AddNew
            rs!codigo = lblCodigoPreset
            rs!nombre = txtPreset
            rs!Path = txtPath
            rs!exenames = txtSucia
            rs.Update
            Set rs = Nothing
            Call contadorPreset
            Desconectar
End Sub

ContadorPreset es un bucle que guarda en otro registro un numero de codigo para no mezclar los registros de la BD


Luego, cargas esa preset desde el otro boton:

Private Sub LlamadaDeDatos()
Dim rs As ADODB.Recordset
Dim sql As String
If Not Conectar() Then Exit Sub
Set rs = New ADODB.Recordset
sql = "Select * FROM Preset WHERE nombre = '" + cboPreset.List(cboPreset.ListIndex) + "'"
rs.Open (sql), cn, adOpenKeyset, adLockOptimistic ' abre rs
txtPath.Text = ""
txtPath.Text = rs!Path
txtSucia.Text = rs!exenames
End If
Set rs = Nothing
Desconectar
end sub


Y le das play, con el primer ShellExecute, y anda con todos los archivos, excepto con el Bat Con el bat se cierra la ventana DOS al cargar los datos del Bat. El bat tiene esto:

setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
EthDcrMiner64.exe -epool us2.ethermine.org:4444 -ewal 0x8cce0e45e02439fe85f35b2235.MineraHanswellRX5epsw x -mport 0 -showdiff 1 -showpower 1 -dbg -1 -rxboost 0



Ahora, si desde el Examinar primero de todos que abre el CommonDialog, vuelves a seleccionar el archivo.bat (ya cargada la preset y con la falla) ... anda y no falla
, empieza a usar el bat sin problemas.

Tiene un par de cosas extrañas en los recordesets, pero si se consdidera que el ShellExecute toma la ruta completa y sin espacios ni carcateres ni barras de mas ni de menos, idénticos y funciona... pero no quiere funcionar con el bat... creo que el problma es algo del bat. Pero tampoco cuadara por que si se hace ese remedio casero si funciona... What Te FuAkckk

Bueno, solo he mirado (de momento) el primer parrafo.
Contienes un grave error...

Aunque revisas que el usuario no haya elegido un path inaccesible, no revisas que haya cancelado.
Si cancela, txtPath.Text, Dialogo.FileName, txtSucia.Text y Dialogo.FileTitle quedan con valor "".

Se puede preguntar por si están vacíos, pero es más cómodo tratarlo como un error.
Te pongo ese párrafo para solucionar ese caso, cuando revises que a pesar de ello te siguiere dando error, pués se revisa el resto del código.

Private Function SeleccionaFile() As Boolean
    Dim cadenita
 
    With Dialogo
        .DialogTitle = "Elija un fichero ejecutable..."
        .Filter = "Ejecutables (.exe .com .vbs)|*.exe;*.com;*.vbs|Exe (.exe)|*.exe|Com (.com )|*.com|VB Script (.vbs)|*.vbs" ' ...etc...
        .CancelError = True
        On Error GoTo Cancelado
        .ShowOpen
 
        txtPath.Text = .FileName
        txtSucia.Text = .FileTitle
    End With
 
    cadenita = Len(txtPath.Text)
    If cadenita > 255 Then
        MsgBox "La ruta de este programa es demasiado lejana, debe seleccionar una ruta más corta de destino", vbCritical
        txtPath.Text = ""
        Exit Function
    End If
 
    SeleccionaFile = True
    Exit Function
Cancelado:
    If (Err.Number = 32755) Then
        MsgBox "el usuario ha cancelado la eleccion de fichero..."
        ' hacer lo que corresponda a este caso... tipicamente no hacer nada al devolver.
    Else
        Call MsgBox("Ocurrio un error inesperado..." & CStr(Err.Number), , "Dialogo de seleccion de fichero")  ' no se espera que esto suceda... pero si alguna vez ocurre, al reportar el mensaje, hay por donde indagar...
    End If
End Function
 
 
 
' ... despues... en la llamada
 
if (SeleccionaFile = TRUE) then
  '... se invoca lo que sea que haces... 
else
  ' pero si devuelve false, es lo mismo que si el usuaro no hubiera realizado ninguna accion
end if
 
 

Por cierto, como dices que invocas un ejecutable, imagino que el control 'Commondialog' tiene filtrado para elegir solo ficheros ejecutables, no???. Que has establecido algún valor en las propiedades 'Filter'. Sino el usuario podría elegir cualquier cosa... he puesto un filter de ejemplo...

Amigo perdon que te responda asi, pero creo que no me comprendes.No uso el CommonDialog para cargar la preset, El shellExecute lee desde un TXT, que está ahí, legible, y si copias y pegas manualmente y lo abres, peus abre el bat, pero el shellexecute no lo hace. En el momento que falla, es completamente independiente del CommonDialog.

Lo mas triste es que cuando si uso el commond dialog  si anda.

El único problema que tiene es que cuando cargas la preset, y le das play ahi no lee los bat. Solo los bat. En primera instancia desde el commond dialog (y sin tener la modificacion que me diste) tampoco tira error y anda bien- (Seguramente lo haga si el usuario pone cancelar... Aunque tampoco quedaria texto en el txtpath, por lo cual ya salteria con mi cartel de error propio al dar play al programa...

No entiendo que relación puede tener el ShellExecute con el CommonDialog, ya que el ShellEjexute usa un txt para cargar la referencia y usar el programa, no el CommonDialog, y la direccion traida por el CommondDialog al TXtpath esta correcta.

Y no no hay filtro, el programa trae y ejecuta cualquier cosa. Ya probe fotos musica, lo que sea, y lo abre con el programa asociado predetermiandamente.

De hecho trae y ejecuta todo correctamente

Ok, te entiendo.

Si cuentas que el programa funciona correctamente de un modo pero no cuando tomas el mismo path, y lo pasas al shellexecute, las dos posibilidades más inmediatas son:
A - Problema con la redefinición del string pasado al shell execute.
B - Problemas de permisos sea del usuario o de la carpeta donde yace el fichero. Esto último e smás dependiente del S.O. que del programa, si el usuario toma los permisos adecuados o ejecuta el programa con permisos de administrador...

Incluso aún siendo esto último, por orden (si fuera el caso) procede examinar primero que el string recibido se pase correctamente a sehllexecute.

Seguiré leyendo tu mensaje previo para ver si aparece el código donde quede recogido dicha llamada y si aparece el contenido de uno de esos txt, donde conste la ruta, para dilucidar el posible problema.

...a la noche saco un ratito, lo reviso y te comento.

El caso es que al final no veo ningún string con las rutas que fallan y con las rutas que funcionan...
El contenido del bat, carece de importancia, lo mismo que carecería de importancia el contenido de un txt, o de una imagen, lo que dices que falla es la apertura.


Aísla la llamada a una función como esta (a fin de ver que rutas recibe y que errores genera).

Private Sub Ejecutar(ByRef Comando As String, ByRef Orden As String)
    Static contador As Long
    Const HANDLE_INSTANCIA As Long = 32
 
    Debug.Print contador ; comando;
    contador  = (contador  + 1)
 
    ret = ShellExecute(Me.hwnd, orden, comando, "", "", 3)
 
    If (ret <= HANDLE_INSTANCIA) Then
        Debug.Print " FALLO: " & ret
    Else
        Debug.Print
    End If
End Sub
 

que se llamaría así:

call ejecutar(txtpath, "Open")

Ejecuta varias veces con los que funcionan y con los que no... haz luego una captura a la ventana debug ( y la subes a alguna web y la pones aquí), con las rutas y los valores de error, podrá determinarse qué sucede.
si además muestras la misma salida cuando dices que las ejecutas llamadas desde el commondialog, mejor que mejor, porque así podrá compararse las diferencias entre ambos paths.

Me dio un poco de pereza leer las respuestas chonchas...

Pero me suena que es tema de primero ubicarte en el path de ejecucion y luego ejecutarlo. por lo que entendi Tu haces esto:

cargas el archivo y ejecutas

y si intentas

cargas el archivo -> te ubicas en el path -> Ejecutas

* Cargar el archivo no es ubicarte en la ruta...

Saludos.

Hola, luego de enfriarme otros 30 dia, retomé esto y ya está la la causa (encontrada).

Resumen: El problema está al ejecutar directamente un archivo Bat (desconzoco si todos o solo ese) desde el ShellExecute. Me di cuenta por que decidí buscar archivos con los controles viejos Drive/Dir/file. Y éstos 3 me dejan en el txtPath literalmente  la ruta seleccionada, que termina en .LNK (yo el bat ese lo abro con un acceso directo). Entonces, tanto al instante de crearlo como al guardar y restaurar la preset, siempre es el LNK y al ejecutar el acceso directo funciona en todos los casos.

Pero el CommonControls, al poner un acceso directo ya me pone el vinculo directo en el txtpath, y de ahi todos los problemas de antes.

Ahora ¿¿por que??

En defnitiva, el problema está en el ShellExecute, o el método que use, al ejecutar directamente el BAT. Incluso ejectuando el accesodirecto que da al bat anda, pero el BAT en sí no... jamas vi algo tan extraño.