Mensajes

[Advance / USB Configuration / USB /Legacy USB support = enable]

Cheká en la Bios los siguientes items

Advance /  USB Configuration / USB  /Controller = enable
Advance /  USB Configuration / USB  /2.0 support = enable
Advance /  USB Configuration / USB  /Legacy USB support = enable

probá asi :  List2.ListIndex = List1.ListIndex
´

Código [Seleccionar] Expandir



Private Sub List1_Click()
  If List2.ListCount >= List1.ListIndex + 1 Then
    List2.ListIndex = List1.ListIndex
  End If
End Sub



Me referia a una pausa en el code hasta que se termine de Ejecutar el llamado a CMD, pero si ya lo habias probado lo descartas, S2

Como alternativa (hasta que encuentres el error) puedes crear una segunda aplicacion que encargue de registrar y luego ejecute tu aplicacion principal.

1) ejecutas tu aplicacion principal

2) cuando esta llega a la linea  que te tira el error entonces
   A) si te tiró el error y antes de cerrarla llamas al tu segunda aplicion, esta segunda aplicacion registra la DLL y tambien antes de cerrarla vuelve a ejecutar desde la misma tu aplicacion principal.

  B) si  tu aplicacion principal no te tira el error sigue adelante sin llamar a la segunda aplicion


PD: en cuanto al error en sí, no necesitarás una pausa entre el registro de la DLL y el llamado a la funcion que te tira el error ?

[Digamos que los semaforos o mutex son alternativas mas "globales"]

Muy bueno Karcrack =D

@Hasseds, todo eso que pusiste se puede "saltar" por ejemplo copiando la app a otra unidad, mismo nombre etc y va a correr. Digamos que los semaforos o mutex son alternativas mas "globales"

Por supusto, eso esta fuera de discucion, ya felicité a KK por el code en un post anterior, pero con las dos App que cité mas app.path en el mismo if se puede lograr una sola instancia.

[Proyecto2]

Como que no sirve, si renombras (en la misma carpeta o ya está corriendo  no hay segunda instancia
PD: y app.path en el caso que se renombre en otra carpeta

1- No es buena idea 'hardcodear' un nombre (de carpeta o fichero, da igual), ya que eso es facilmente modificable...
2- Prueba a usar el metodo de app.PrevInstance haciendo esto:
Compila el ejecutable como "Proyecto1.exe" ejecutalo, ira sin problemas... copia el "Proyecto1.exe" a "Proyecto2.exe" y abrelo... veras que hay dos instancias de la misma aplicacion...

If App.PrevInstance = True Or App.EXEName <> "Proyecto1" Then End

como va a abrir Proyecto2 si no es = a Proyecto1

Jajaja XD...

Karcrack como dice cobein... Sos un capo...! Me gustó este code...! :

+1 , tambien me gustó el code

Si se renombra el fichero y se vuelve a ejecutar el proceso eso no sirve para nada

Como que no sirve, si renombras (en la misma carpeta o ya está corriendo  no hay segunda instancia
PD: y app.path en el caso que se renombre en otra carpeta

If App.PrevInstance = True Or App.EXEName <> "Project1" Then End

[se tiene razón con buscar por la clase de form]

1. KarCrack ya te respondió por mi.
2. Me reservo gran parte {Drinky no hace mucho que inicio con el uso de las APIS tengo entendido}, aun que se tiene razón con buscar por la clase de form, solo que es la segunda vez que lo veo de tu parte {la 1era fue en un off en un tema nada q ver}.

Si, "se tiene razon" con buscar por la clase de form" y Tambien que HWnd es long
Si,  "es la segunda vez que lo vez de mi parte", es porque nuevamente no se usó la clase (SciCalc)
Si, "la 1era fue en un off en un tema nada q ver"...  tal vez para mi si tenia sentido (no tengo que pedirte permiso para meter un comentario off o in)

No me quedó claro si a lo que te referis en el primer parrafo de mi anterior post es lo que respondio KarCrack sobre checar el cero o fue la "sentencia" de : "no debe pasarse una api que devuelve cosas inestables directamente en otra "  

No tengo ganas de sueguir gastando energia en esto

[no debe pasarse una api que devuelve cosas inestables directamente en otra]

Ese código esta mal, en primera] no debe pasarse una api que devuelve cosas inestables  directamente en otra   en este caso findwindow dentro de Enablewindow

Si te referis a esto

Private Sub Command1_Click()
 Call EnableWindow(FindWindow("SciCalc", vbNullString), 1)
End Sub

Es solo una puerta de escape para que no tenga que usar el administrador de tareas para cerrar la calculadora,  y si vamos a hilar fino que nay que usar de hwnd en Enablewindow ?, una variable como devuelve FindWindows  en este caso ? ... si no es asi entonces estas diciendo que en hwnd de Enablewindow o de cualquier API van Constantes  ? ...  bueno, si es así no lo sabia, me estoy enterando en este momente que la variable hwnd as Long es una constante.

NI TAMPOCO directamente pasar el handle devuelto, directamente a procesar en la siguiente linea.
En pocas palabras debe verificarse que se a obtenido lo deseado y evitar jaladas de pelos posteriores.

 handle = FindWindow("SciCalc", vbNullString)
 Call SendMessage(handle, &HC, 0, ByVal "CLAUSURADO")
 Call EnableWindow(handle, 0)

En esta si,  estamos de acuerdo , falta el "if handle <> 0 Then"

No es necesario que Drinky use a huevo findwindow pero con la clase de ventana,,,

creo que te referis a esto :

handle = FindWindow (vbNullString, "Calculadora")' solo para un windows en castellano
handle = FindWindow("SciCalc", vbNullString) ' para windows con cualquier idioma

Para mi es logico, no tengo dudas. No es a huevo porque en este caso se ejecuta  la calculadora en la linea anterior y el Hwnd es el correcto (aunque haya mas calculadoras abiertas) .


PD: En este post hice solo dos acotaciones a Drinky, una que el valor de Hwnd es Long y no String y  la otra acotacion fue el uso de FindWindows. Ninguna de las dos con "mala leche"