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)
Seven x64 estoy ahora. Pero lo programe en PC virtual de XP x 32.
miren el video.
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
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..
Te soy honesto, ya lo tengo puesto y andando, es lo primero que hice. El tema, es que particularmente en mi pc creo q (no se como hice en su momento con mi Win7) De default corre todo como admin, como WIndows XP). Asi que.. realmente no sé cuando algo me lo ejecuta o no como admin.. si ese es el codigo, lo tengo, pero no puedo probarlo :S necestaria una PC con una instalacion basica y bien bloqueada, o en algun lado dice o te podes dar cuenta? La 2da opcion era. No sé si estaba dormido o algo anoche, pero tal vez no vi esa, vi varias de vbforums y no las probe todas. pero esta si anda, me di cuenta que anda. Saludos y mil gracias broly
Código:
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 'donde se va a ejecutar la accion: ShellExecute 0, "runas", App.Path & "\MyExe.exe", requireAdministrator, vbNullString, 3
Yo imagino que tengo la predeterminada que viene con Windows, cuando el Atube Catcher me reemplazó la DLL, me cagó. Tendria q ser la original de Windows. ahora me fijo lo que dices y te digo.
Si no es cuestión de bajarse 500 versiones y probar al azar "...a ver si canta el pájaro".
En programación es cuestión de saber o no saber, no tanto de probar... (que es la opción pobre cuando uno no sabe).
Abre el fichero del proyecto (*.vbp) con un visor de texto, copia el contenido y vuélcalo, y así sabremos que versiones de componentes usas (que exijan referencia, los que vienen embebidos en el runtime, ya lo contienen dichas librerías)... más aún, viene el GUID para cada componente y al final la versión, por lo que con dicho dato se puede ver de localizar si está instalado buscándolo en el registro de win2...
Creo que es bastante obvio lo que necesito. Ahora pruebo y te cuento
Object={86CF1D34-0C5F-11D2-A9FC-0000F8754DA1}#2.0#0; mscomct2.ocx Object={C1A8AF28-1257-101B-8FB0-0020AF039CA3}#1.1#0; mci32.ocx Object={C932BA88-4374-101B-A56C-00AA003668DC}#1.1#0; msmask32.ocx Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.2#0; mscomctl.ocx Object={F9043C88-F6F2-101A-A3C9-08002B2F49FB}#1.2#0; comdlg32.ocx Bueno, al fin! gracias. Despues de 2 meses de sufrimiento. Lo que hice fue lo que dijo NEBIRE, abrir con el notepad el proyecto vbp, ver Justo las DDL q son, y bajar y poner esas. Primero entre al proyecto, anoté las que necesitaba y estaban mal, luego las bajé, las registre con el regsvr, y luego las activé en el proyecto, y andubo. Lo unico que tenia un calendario mal que no hubo forma de arreglarlo con la OCX, pero ya sabia q era ese componente asi que lo elimine y lo puse de nuevo con el nombre original del componente y listo. Al fin podrñe volver a controlar mi eocnomia jaja.
Y lo que dijo broly no me andubo para este caso, pero usar una maquina virtual.. quiero implementar eso en un proyecto que tengo, me puede ser excesiamente util para una Pc virtual con Windor xp
MOD: No hacer doble post. Usa el botón modificar. (Por 3era vez...)
Básicamente, mi programa tiene que ejecutar programas, pero como sabemos eso de "ejecutarlo y listo" murió con Windows XP. Desde Vista en adelante está el UAC y toda esa basura. Que no es problema, si el usuario tiene que confirmar abrir el .exe que yo mando la orden con el Shell de VB6 no es drama, el drama es que si el .exe no tiene tildado el "Ejecutar como administrador" el programa o no abre, o abre y no hace lo que tiene que hacer. La pregunta es, como hago para que el Shell ejecute programas como adminsitrador?
es que ya baje como 300 versiones :S baje varias, las registre con el svr, niguna va. por que es mas alla del 5.0 y del 6.0 no? hay una subversion que no se cual es. Todo empezo x q me hizo conflicto con el atube catcher
No, no hay caso. No levanta de ninguna forma. Ni ajustando lo que dice NEBIRE
Ni con la pc virtual de XP que dijo el moderador, no hay forma de levantar ese puto proyecto. Tendre que rehacer toda la interfaz e ir copipasteando el codigo de a poco, se me hizo *****, q *****
Mostrar Mensajes
