Mensajes

No existe ningún miembro para llevar a cabo esa finalidad. Los comandos FIND y FINDSTR se limitan a mostrar la linea completa de la coincidencia del patrón de búsqueda o expresión regular, no extrae la porción que coincide.

Tampoco existe un búcle de tipo for-each capaz de iterar cada caracter de un string, puedes usar un For corriente que es lo más parecido, pero primero tendrías que tokenizar el texto de entrada, es decir, modificar manualmente el archivo de texto para darle un formato compatible partiendolo en tokens legibles por dicho For, por ejemplo añadiendo un espacio en blanco entre cada caracter ...manualmente, lo cual no es una solución viable al no ser automatizable (en Batch).

¿Por qué la necesidad de hacerlo en Batch si ya sabes como llevar a cabo la misma tarea en otros lenguajes?, Batch es una herramienta extremadamente limitada.

Saludos.

[Dir]

Se puede hacer con un simple búcle For evitando el uso del comando Dir para aumentar el rendimiento general del script disminuyendo el tiempo total necesario de ejecución (al evitar el inicio de dicho comando, esperar la señal de salida, y filtrar la salida en al variabe de For).
Dependiendo de las circunstancias (la cantidad de archivos) la diferencia puede ser ínfima, o considerable, pero sea como sea hay que seguir buenas prácticas de uso evitando instrucciones innecesarias:

Código (DOS) [Seleccionar] Expandir

@Echo OFF

Call :MakeNullFiles "C:\Directory" "png"
Pause&Exit /B 0

:MakeNullFiles :: %1=Directory path; %2=File extension.
If Not Exist "%~1" (
GoTo:EOF
) Else (
PushD "%~1"
(For %%# In ("*.%~2") Do (
Copy /Y Nul "%%~f#")
)1>Nul
PopD
GoTo:EOF
)

Saludos.

[[SOURCE] File 2 startup v1.1]

Puedes hacerlo de forma guiada con mi aplicación:

• [SOURCE] File 2 startup v1.1

O tambien puedes hacerlo así:

• http://lmgtfy.com/?q=How+to+add+program+to+windows+startup

Saludos.

Me alegro de que en tu caso lo hayas podido solucionar de esa manera, pero te aseguro que no se soluciona así al menos para proyectos nuevos.

Dicha opción ya viene activada por defecto cuando se genera un nuevo proyecto de WindowsForms:


Siendo este el renderizado por defecto (en Windows 10 con un theme visual oscuro):


Saludos!

En realidad no existe ningún problema con tu proyecto/aplicación, no es por que tu proyecto sea antiguo ni haya incompatibilidad ni nada parecido, simplemente estás describiendo el comportamiento natural de Visual Studio 2015, esa es la manera en la que el designer de WindowsForms renderiza un Form, pero al compilar la aplicación Windows 10 renderizará la ventana Win32 aplicando el estilo de ventana correspondiente.

Es algo que a mi y a muchos otros usuarios no nos gusta en absoluto, pero tecnicamente hablando no creo que se pueda considerar como "problema", puesto que Microsoft lo ha desarrollado con esa intención y eso significa que existe alguna razón para ello (razón que yo desconozco).

PD: Cuando me instalé VS2015 a mi también me pareció extraño y quise investigar un poco al respecto, creeme si te digo que ni los gurús más sabios (en StackOverflow.net) conocen el por qué de este cambio.

Saludos

[Timer]

Tengo un programa que recibe datos una y otra vez por el puerto serie. A 0.1 segundos

¿Quieres decir que tienes declarado un Timer que tickea/marca en un intervalo de 10 ms, o por lo contrario a 100 ms?, en el primer caso estás cometiendo un grave error de diseño que en el peor de los casos generará un elevado consumo innecesario de operaciones I/O (de CPU), así que deberías incrementar el intervalor a 100 ms, eso como mínimo (como está establecido por defecto), ya que para controlar un estado de progreso no necesitas más eficiencia, los intervalos más cortos que 100 ms se usan para cosas muy específicas que generalmente requieran mayor precisión de actividad computacional, con las consecuencias negativas y asumibles que eso conlleva.

al cerrar el programa...El programa se cuelga.

¿Alguna solución?

Lo primero de todo es que jamás debes establecer la propiedad CheckForIllegalCrossThreadCalls (a menos que sea para realizar algún tipo de test de colisiones de hilos), asi que lo primero de todo que te aconsejo, es que para corregir el código actual, empieza por evitar el uso de esa propiedad para conservar su valor por defecto (False).

Bien, el motivo por el cual no puedes cerrar el Form puede deberse por varios factores en combinación, sin ver el código es imposible averiguarlo, pero es causa de un algoritmo expensivo como por ejemplo un For continuo (o infinito) que no finaliza su bloque de instrucciones, el problema es que cuando el usuario demanda el cierre de la aplicación, el evento no se puede procesar hasta que el algoritmo expensivo termine de finalizar su ejecución, puesto que todas las operacioens las estás llevando a cabo de forma sincrónica en un mismo hilo, el hilo de la UI.

El problema se puede solucionar de varias maneras, te indicaré los pasos de la que considero la más sencilla:

1. Declara una variable booleana que servirá para detectar (y más tarde controlar) la petición del cierre de aplicación por parte del usuario, llamemos a esa variable por ejemplo: userRequestedAppClose.

2. Declara un controlador de eventos (event-handler) para el evento Form.Closing, y en el bloque de dicho event-handler controlas el valor de la propiedad e.Closereason delos datos del evento, para asignarle un valor a nuestra variable userRequestedAppClose en caso de CloseReason.UserClosing.

3. Mueve la lógica del algoritmo que se encarga de leer el puerto serie y actualizar la barra de progreso, a un método individual.
   Y añade las correspondientes evaluaciones para evitar excepciones de colisiones entre threads, lee acerca de Control.Invoke
https://msdn.microsoft.com/en-us/library/system.windows.forms.control.invokerequired%28v=vs.100%29.aspx
+
https://msdn.microsoft.com/en-us/library/system.windows.forms.control.invoke%28v=vs.110%29.aspx

4. Declara una tarea (System.Threading.Tasks.Task) y declara e instancia un token de cancelación (System.Threading.CancellationToken), con la tarea podrás ejecutar el método individual del punto nº3 de forma asíncrona, asegúrate de utilizar la sobrecarga (u overload) del constructor que toma como parámetro un token de cancelación:
https://msdn.microsoft.com/es-es/library/dd783029(v=vs.110).aspx  
o también puedes usar este otro overload:
https://msdn.microsoft.com/es-es/library/dd783257(v=vs.110).aspx + TaskCreationOptions.LongRunning

El token de cancelación servirá para interrumpir la ejecución de la tarea cuando el usuario demande el cierre de la app, y así poder salir.

5. Por último, debes modificar la lógica del método individual del punto nº3 para cancelar la tarea evaluando el valor de la propiedad IsCancellationRequested según el valor actual de nuestra variable userRequestedAppClose:
https://msdn.microsoft.com/en-us/library/system.threading.cancellationtoken.iscancellationrequested(v=vs.110).aspx

Un ejemplo parcial y en pseudo-codigo:

Código [Seleccionar] Expandir

declaración t As Task
declaración ct As CancellationToken
declaración cts As CancellationTokenSource

Método(...) {
   If this.userRequestedAppClose = True, entonces:
      cts.Cancel()
      continuar el bloque.
   de lo contrario:
      continuar el bloque.

   If ct.IsCancellationRequested = False, entonces:
      Recoger nuevos datos del SerialPort.
      Actualizar +n la posición de la barra de progreso.
   de lo contrario:
      Terminar ejecución del bloque.
}

Es mucho más sencillo y comprensible de lo que parece, en apenas unas 20-30 lineas de código puedes desarrollar la solución (sin sumar tu algoritmo del serialport/progressbar), simplemente he escrito explicaciones bastante largas para lo que es, ya que como te habrás dado cuenta quiero evitar mostrarte un código ya hecho, aunque de todas formas en MSDN y Google puedes encontrar cientos de ejemplos sobre tareas y cancelaciones de tarea, eres libre de escoger el camino que prefieras (es decir, copiar el código, o aprender a hacerlo por ti mismo).

Otra solución sería utilizar la class BackgroundWorker o la class Thread para llevar a cabo practicamente lo mismo, ya que son sencillamente lo mismo ...classes para representar un hilo de .NET, lo que las diferencia son su modo de empleo con niveles distintos de abstracción (siendo la class Thread el low-level del threading). La class Task tiene el nivel de abstracción más alto, por lo que en términos de comprensión y tamién implementación o elaboración, eso lo convierte en la solución más sencilla y rápida de aplicar, al menos, en mi opinión.

Saludos.

Vaya, entro al foro libre despues de un mesecito o dos, y me encuentro con uno de tus típicos y geniales aportes...

Yo vi la "noticia" en este otro video:
[youtube=640,360]https://www.youtube.com/watch?v=v-aq4aHI0JA[/youtube]

La gente no se cree mucho estas cosas, pero no se dan cuenta de que es más irracional no creerlas, ¿por qué?, por la cantidad de evidencias que existen que hacen que la Navaja de Ockham se decante hacia un lado, por que las retransmisiones de NASA no son en vivo, bueno, se supone que lo son, pero tecnicamente hablando no, por que se emite con unos segundos de retraso para poder controlar lo que el "espectador" visualiza en la pantalla, y entonces ellos pueden hacer (y lo hacen) cortes en la emisión si existe algo que no debamos ver (como en las retransmisiones de futbol, que también tienen o al menos tenían un tiempo de retraso para cortar la emisión en caso de fanáticos que se desnudan en el campo y etc), y, vaya, que "casualidad" que NASA se dedique a cortar la emisión SIEMPRE que sucede algo extraño (sin excepciones), no es que sea una o dos veces, es SIEMPRE, y yo lo se a ciencia cierta por que hace tiempo desarrollé un simple algoritmo para grabar su webcam y guardar los cortes de emisión y unos momentos antes, para así poder sacar mis propias conclusioens sobre el tema (puesto que por mucho que alguien diga que algo es así o asá, lo mejor es comprobarlo por uno mismo, aunque existen canales en youtube dedicados a hacer exactamente lo mismo, grabando y registrando todos los cortes de emisión de NASA).

La pregunta sería, ¿por qué NASA siempre corta la emisión cuando aparece un OVNI? (y entendamos por OVNI objeto volador no identificado, no una nave alienígena).

Es evidente que debe existir una política de empresa al respecto, y por ello los empleados de NASA siempre cortan la emisión al ver un OVNI, es su trabajo hacerlo, ¿pero por que existe esa política?, la gente podría pensar "lo cortan para intentar evitar que los conspiranoicos digan que son alienígenas y crear una polémica innecesaria a NASA", pero eso es IRRACIONAL, por que para empezar si no es una nave alienígena entonces no hay motivo para cortar la emisión, es absurdo, por que en nuestras vidas cada día vemos cosas que no comprendemos que significado tienen, y nadie nos las censura ni nos las tratan de ocultar ...¿se entiende lo que digo?, si hubiera motivos para pensar que es una mota de polvo, o liquido, o cosas comprensibles, ¿entonces por que cojones iban a pretender cortar la maldita emisión?, y segundo, lo que crea polémica, desconfianza y mala fama hacia NASA es precisamente que SIEMPRE que aparece un objeto volador no identificado en la pantalla, lo corten, eso si que crea polémica al respecto.

El que quiera seguir pensando que esto es casualidad, o que cortan la emisión con la intención de evitar polémica, entonces que lo siga pensando, por que hay que estar ciego, pero de verdad, para no ver como nos intentan ocultar la existencia de vida y tecnología extraterrestre, y no lo digo solo por este asunto de las webcams de NASA (que llevan haciendo esto desde siempre), sino por las ciento mil y una otras cosas extrañas que se suman a la lista de cosas que sospechar sobre NASA, junto a la lista de evidencias de vida extraterrestre, pero bueno, yo es que en realidad no necesito basar mi afirmación en evidencias para demostrarme a mi mismo nada, por que tengo pruebas visuales, pero claro, nadie me creería.

Saludos.

[String.TrimEnd(Char[]) | MSDN]

Es un problema con facil solución:

• String.TrimEnd(Char[]) | MSDN

PD: No uses el método por defecto sin parametizar, debes especificar los caracteres adecuados en el array, creo que serían los respectivos códigos Unicode de las constantes Microsoft.VisualBasic.ControlChars.CrLf (o ControlChars.Cr + ControlChars.NewLine):

• Character literals - C# | MSDN

Saludos

[CreateProcess]

Hola

Lo primero de todo, nativamente hablando no existe ningún miembro en la API de Windows para bloquear la ejecución de un proceso de forma guiada, y un Antivirus es un producto programado por grupos de varios desarrolladores profesionales, lo que pretendo decir es que el algoritmo de bloqueo se elabora e implementa con el sudor y el esfuerzo de uno mismo, otra cosa es que tal vez pueda existir una API de terceros ya desarrollada para tal propósito (una API gratuita, o de pago), podría ser, pero al menos yo jamás la he visto.

Para impedir la ejecución de un executable tienes que llevar a cabo un api-hook (si o si) de la función CreateProcess y adjuntarlo a las instancias del explorer,
y entonces, al interceptar el precall de dicha función, podrás leer sus parámetros y así detectar la petición de creación del proceso a bloquear, notificar mediante eventos lo que quieras notificar, e ignorar el precall para no crear el proceso (si hookeas otras funciones, es posible que tambén debas interceptar el postcall, y modificar el valor correspondiente que debe ser devuelto, depende de como funcione cada función, valga la redundancia).

• CreateProcess function | MSDN

(luego también están las funciones ShellExecute y ShellExecuteEx, pero son unos wrappers de la función CreateProcess, y también está WinExec, de la que no estoy seguro si es un wrapper pero creo que no, aunque de todas formas no hay que darle mucha importancia a WinExec ya que es una función en deshuso que solo existe por motivos de compatibilidad con aplicaciones de 16-Bit)

Tienes al menos tres librerías populares para poner en práctica el api-hooking en .Net, Nektra Deviare, EasyHook, y Detours (C/C++);
Te las he nombrado por orden de preferencia personal y de complejidad, siendo Microsoft Detours la peor opción tratándose de .Net (para eso mejor desarrollar la app en C++), EasyHook es gratuita pero muy inestable y con una infinidad de bugs reportados sin corregir, y Nektra Deviare es una librería de pago (si uno no sabe encontrar...) mucho más eficiente que EasyHook y mucho más sencilla de utilizar ...dentro de lo que cabe en esta temática de la ingeniería inversa.

Sinceramente, este tipo de trabajo es de cosecha propia, puesto que hay que invertir bastante tiempo en investigar y documentarse en general sobre el comportamiento y el tipo de valores contenidos en los parámetros de "X" función que desees hookear, de todas formas, no me cuesta nada compartir este antiguo código que desarrollé y lo guardé, el cual precisamente sirve para prohibir/evitar la ejecución de un proceso (notepad.exe) utilizando la liberría de Nektra Deviare:

Código (vbnet) [Seleccionar] Expandir

Imports Nektra.Deviare2
Imports System.IO

Public NotInheritable Class Form1

   Public WithEvents SpyMgr As NktSpyMgr
   Public Hook As NktHook

   ' CreateProcess API reference:
   ' http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx
   ReadOnly libName As String = "kernel32.dll"
   ReadOnly funcName As String = "CreateProcessW" ' Unicode
   ReadOnly hookFlags As eNktHookFlags = eNktHookFlags.flgOnlyPreCall Or
                                         eNktHookFlags.flgAutoHookChildProcess

   ' Processes to attach the hook.
   ReadOnly processesToAttach As IEnumerable(Of Process) =
       Process.GetProcessesByName("explorer") '.Concat(Process.GetProcessesByName("cmd"))

   Private Sub Test() Handles MyBase.Load

       Me.SpyMgr = New NktSpyMgr()
       Me.SpyMgr.Initialize()

       Me.Hook = SpyMgr.CreateHook(String.Format("{0}!{1}", libName, funcName), hookFlags)
       Me.Hook.Hook(sync:=True)

       ' It could exist more than one explorer.exe instance so...
       For Each proc As Process In processesToAttach
           Me.Hook.Attach(procOrId:=proc.Id, sync:=True)
       Next proc

   End Sub

   <MTAThread>
   Private Sub OnCreateProcess_Called(ByVal hook As NktHook,
                                      ByVal proc As NktProcess,
                                      ByVal callInfo As NktHookCallInfo) Handles SpyMgr.OnFunctionCalled

       ' Process that the hook should intercept.
       Dim processToIntercept As String = "notepad.exe"

       ' CreateProcess function params.
       Dim lpApplicationNameParam As NktParam = DirectCast(callInfo.Params(0), NktParam)
       Dim lpCommandLineParam As NktParam = DirectCast(callInfo.Params(1), NktParam)

       If Path.GetFileName(lpApplicationNameParam.Value.ToString).Equals(processToIntercept, StringComparison.OrdinalIgnoreCase) Then

           With callInfo
               If .IsPreCall Then ' Skip precall to avoid process creation/initialization.
                   .Result.Value = 1
                   .SkipCall()
               End If
           End With

       End If

   End Sub

End Class

PD: El algoritmo cumple su función dentro de lo esperado, pero yo no soy ningún experto de la ingeniería inversa, quiero decir, que no se si el procedimiento controla todas las posibilidades en las que podría crearse un proceso, así que no lo tomes como un "código perfecto" en absoluto, sino más bien como un "algo por donde empezar".

PD2: En ese código que he mostrado existe una vulnerabilidad que se puede explotar facilmente (salta a la vista), y es que puedes cambiarle el nombre al notepad.exe por loquesea.exe para poder ejecutarlo (o al revés, para bloquearlo), esto está justificado, pues es solo un ejemplo demostrativo de técnicas de api-hooking, no de protección antiviral xD, pero si quieres un nivel de seguridad más eficiente, entonces se me ocurre que podrías realizar una comparación byte a byte entre los bytes del proceso seleccionado a bloquear, y los bytes del proceso que intenta ser creado para determinar si se trata del mismo archivo indiferentemente del nombre del archivo, y así decidir si el proceso debe ser creado o no.

Saludos

[SendKeys.Send Method | MSDN]

Hola

1.
Como indica la documentacion en la MSDN, las teclas especiales Fn se deben cerrar entre brackets:

Código (vbnet) [Seleccionar] Expandir

SendKeys.SendWait("{F6}")

• SendKeys.Send Method | MSDN

2.
Si no he entendido mal, un programa de terceros crea un acceso directo, le asigna la combinación de teclas "F6", y tu quieres enviar la pulsación de esa tecla para abrir el acceso directo... el cual imagino que estará ubicado en el escritorio.

Bien, en ese caso otro problema adicional sería que le estás enviando las pulsaciones del telcado a la ventana activa (tu form).

Saludos