Mensajes

[Framework Design Guidelines - MSDN]

Ahora mismo estaba leyendo sobre las declaraciones de los eventos y delegados en C#, para entenderlo.. y al menos convertirlo para Vb.Net

Los delegados te va a llevar más tiempo, no lo vas a comprender a la perfección con una lectura, debes practicar.

Actualmente estoy leyendo un curso de Vb.Net, del Guille noc si será el mas indicado, por otro lado estoy en un proyecto que me supera en muchas cosas y ando dando tumbos tratando de entender algunas funciones..

No soy nadie para dar mi opinión sobre los tutoriales de El Guille, pero es un señor muy popular ...por algo será. Recuerdo haber leido un tutorial online que escribió para enseñar VB6, hace muchos años ya, y en algo me ayudó a manejarme por la IDE y cosas muy sencillitas (yo no tenia ni idea de VB), pero no he leido nada suyo de VB.NET.

Puedes explicarme porque lo de las malas costumbre en el codigo que te di.

Simplemente son patrones estándar de diseño, todos los lenguajes imponen sus propios patrones de diseño que el programador debería seguir al pie de la letra, Microsoft sugiere una guía de diseño a la hora de llevar a cabo implementaciones de "X", y es conveniente cumplir con esos patrones de diseño (aunque no sea obligatorio) por que, entre otras cosas, generalmente ofrece ventajas, por ejemplo usar nomenclaturas correctas ayuda al compiler a la VM de .NET a identificar los miembros con mayor rapidez, o también tomar la costumbre de implementar un constructor privado (Private Sub New) imposibilita que el usuario final pueda instanciar una class de manera incorrecta, son muchas las guías de diseño y el por qué de sus ventajas.

Aquí tienes muchas guías de diseño reunidas:

• Framework Design Guidelines - MSDN

En esas guías podemos encontrar la que nos interesa, el patrón de diseño de un Evento:

• Event Design - MSDN

Y nos dice claramente como lo debemos implementar y una de sus ventajas al seguir este patrón de diseño:


El código de C# (o la traducción que hiciste en VB.NET) no está siguiendo la primera regla de diseño mencionada en la imagen, y a raíz de eso tampoco sigue la otra regla.

Saludos

El primer error que me dio es que en Vb.Net la palabra Error es un KeyWord asi que la cambie por ErrorH (la H de handler)

Podrías haber escrito simplemente [Error]:

Código (vbnet) [Seleccionar] Expandir

Public Event [Error] As ...

el ErrorH me dice que es un evento que use el RaiseEvent, para usar esto tengo que primero a ver implementado el AddHandler obligatoriamente ??  esto lo pregunto porque en un proyecto que revise recientemente encontre que hacian uso del RaiseEvent sin el AddHanlder..

Estás confundiendo el significado de las cosas, mira, AddHandler y RaiseEvent no tienen nada que ver, lo primero es para asociar un evento y lo segundo para disparar un evento (desde un invocador de eventos).

El código que has mostrado, el original en C#, hace uso de malas costumbres de programación .NET al implementar un evento mediante el uso de un delegado, y la traducción que has hecho en VB,NET contiene esas malas costumbres y también otras cosas que son incorrectas.

Siguiendo las directrices que aconseja Microsoft, yo lo implementaría así:

Código (vbnet) [Seleccionar] Expandir

Public Class TestClass

   Public Event [Error] As EventHandler(Of ErrorArgs)

   Public sub New()
   End Sub

   Public Sub DoWork()
       ' ...
       Dim args As New ErrorArgs(conn:=valor, ex:=valor)
       Me.OnError(args)
   End Sub

   Protected Sub OnError(ByVal e As ErrorArgs)
       If (Me.ErrorEvent IsNot Nothing) Then
           RaiseEvent [Error](Me, e)
       End If
   End Sub

End Class

Código (vbnet) [Seleccionar] Expandir

Public NotInheritable Class ErrorArgs : Inherits EventArgs

   Public ReadOnly Property Connection As FrostbiteConnection
   Public ReadOnly Property Exception As Exception

   Private Sub New()
   End Sub

   Public Sub New(ByVal conn As FrostbiteConnection, ByVal ex As Exception)
       Me.Connection = conn
       Me.Exception = ex
   End Sub

End Class

Uso:

Código (vbnet) [Seleccionar] Expandir

Public Class TestClass2

   Friend WithEvents Obj As TestClass

   Public Sub New()
       Me.Obj = New TestClass
   End sub

   Private Sub Obj_Error(ByVal sender As Object, ByVal e As ErrorArgs) _
   Handles Obj.Error
       ' ...
   End Sub

End Class

PD: ¿No crees que va siendo hora de que leas los artículos de MSDN y practiques todo lo relacionado con eventos (y delegados) en vez de intentar usarlos o implementarlos sin comprender?, no siempre te lo van a dar todo hecho...

Saludos!

Por experiencia, lo recomendable es "copiarlos" en pequeñas dosis, no todos a la vez, porque puede producirse un error "Lectura demorada", y se escoñó el HDD......

Cada cual que lo haga como quiera, yó solo lo cuento.

Es bien cierto lo que dices Simorg, yo también hago copias (de terabytes) a discos externos, y conviene hacerlo poco a poco, o en su defecto cuando notemos que la valocidad de transferencia disminuye mucho (que lo hará), darle al botoncito de "Pausar" y esperar unos minutos para reanudar la transferencia, es notable que al reanudar la transferencia la velocidad siempre mejora elevando los picos (hasta que vuelva a disminuir xD)

Saludos

[bajo tu responsabilidad]

Quien quiera adquirir un SSD debe conocer sus implicaciones y aceptarlo (o no haberlo comprado), por muchas ventajas que ofrezca lo cierto es que la relación tamaño/precio es absurda, y un tamaño reducido de almacenaje para el sistema operativo trae consecuencias como las que ya has descrito, es decir, que se llena enseguida y es agobiante.

La carpeta de "Archivos de programa" aparte de las instalaciones de software contiene archivos ESENCIALES para el sistema operativo, por ese motivo espero que entiendas el riesgo que supondría separarlos de la partición original de instalación.

Para mover el directorio "Archivos de programa" de forma completa puedes intentar seguir estos pasos que intentaré explicarte que basicamente trata de una redirección de directorio, pero obviamente no me hago responsable de ninguna posible catástrofe, esto es bajo tu responsabilidad:

1. Copia el directorio C:\Program Files a la unidad HDD de destino y también C:\Program Files (x86) si tienes un Windows de 64 bits.
La copia del directorio debe ser completa, si por cualquier motivo (ej. permisos de usuario) no te permite copiar los archivos del sistema entonces puedes llevar a cabo el proceso de copiado desde un live-cd de Windows o Linux, asegúrate de que los archivos ocultos también se copien.

2. Abre el registro de windows con la aplicación Regedit, ve a la siguiente clave de registro: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion y modifica los datos de los siguientes valores para especificar la ruta donde copiaste los directorios:


3. Reinicia el sistema operativo para que los cambios del registro tengan efecto. Inicia sesión de usuario en Windows, y ahora intenta eliminar todo el contenido del directorio C:\Program Files (y C:\Program Files (x86))

En teoría debería permitirte eliminarlo todo, pero puede que algunos valores del registro asociados con archivos del sistema apunten directamente a la letra de unidad "C" (o la letra donde lo hayas instalado) y se encuentren esos archivos en uso y no te permitan borrarlo, en ese caso borra los directorios originales desde un live-cd.

4. Con lo mencionado en teoría ya debería ser suficiente, pero tendrías problemas con valores de registro que apunten directamente a la letra de unidad "C" (o la letra donde lo hayas instalado) y con archivos que hagan lo mismo por ejemplo con los accesos directos, así que conviene que creemos un vínculo de unión de directorios para evitar cualquier conflicto de ese tipo.

Abre la consola de Windows (CMD) y escribe el siguiente comando:

Código [Seleccionar] Expandir

mklink.exe /J "X:\Program Files" "C:\Program Files"
mklink.exe /J "X:\Program Files (x86)" "C:\Program Files (x86)"
Donde "X" sería la letra de unidad de origen (el HDD SATA) y "C" la de destino (el SSD).

Fin.

Saludos

esos 100gb que se han cortado y pegado los habría perdido?

Si cortas (CTRL+X) y pegas obviamente los archivos de origen se irán eliminando de la ubicación de origen según se vayan copiando, si solamente copias (CTRL+C) y pegas entonces los archivos de origen seguirán donde estaban (es decir, no pierdes nada).

Si tienes muchos archivos de diferentes tamaños que en su totalidad ocupan 100 GB y cancelas cuando va por el 50%, habrás perdido aquellos archivos que se hayan conseguido copiar a la ubicación destino durante el proceso de copiado.

Por otro lado, si tu tienes un archivo de 100 GB, lo cortas y lo pegas en otro directorio y cancelas cuando va por el 50%, no pierdes ningún dato del archivo original. ¿por qué?, por que el sistema operativo primero copia el archivo en su totalidad del punto A al punto B y luego lo elimina de la ubicación de origen, dicho de otra forma: cortar significa copiar y luego eliminar.

Si durante un proceso de "cortar" o mover datos de un disco a otro se te cancela por un fallo del sistema o del hardware, en teoría no debería pasar nada grave, recuerda que el archivo de origen se copia (no se mueve al vuelo) así que en teoría estaría intacto, sin embargo el archivo destino quedaría corrupto ya que no se habrian llegado a copiar todos los datos (obviamente).

Saludos

O este otro (si te aburres de usar los típicos símbolos):



Saludos

miremos el caso de  kickass torrents lo cerro e FBI

Ese siempre fue mi buscador favorito de torrents, y un buen dia para mi sorpresa al intentar acceder a la página me encuentro con el típico cartelito del FBI...

...pero por suerte hace tiempo que descubrí este otro dominio que funciona perfectamente :

• http://kickasstorrents.video/

Ahí lo dejo, para quien le sirva.
Saludos!

[Teamviewer]

En caso de que la licencia esté limitada para ser activada en un PC individual, entonces una solución alternativa a lo que te han dicho podría ser utilizando Teamviewer para tomar el control remoto de tu otro PC, no necesitarías copiar "datos", sin embargo para ser honestos el tema de la impresión no se como funcionaría... no se si se podrá "compartir" dispositivos, pruebalo a ver.

Saludos

[%~dp0]

Prueba así:

Código (dos) [Seleccionar] Expandir

@Echo OFF

Set "file=%~dp0programa.exe"

Echo "%~dp0"
If /I Exist "%file%" (
   Start /B "" "%file%"
)

Exit /B 0

Y asegúrate de que el directorio de ejecución del script (%~dp0) sea el correcto.

Saludos!

[Orubatosu]

estás teorizando sobre un campo inexistente atribuyendole unos poderes mágicos sin explicar en absoluto su funcionamiento.

Orubatosu, una cosa es el poder mágico (algo en lo que yo no creo) y otra muy distinta es el poder mental, no los confundas.

Aparte, el ser humano solo puede explicar el funcionamiento de aquello en lo que puede asimilar una (pseudo)comprensión bajo las leyes que nos rodean, no se como esperas que @Senior++ pueda ni deba explicar el funcionamiento de algo que para empezar la mente humana no sería capaz ni tan siquiera de procesar, la creación y sus leyes (las que están por encima de ti, de mi, y de todos los seres que compartimos este mundo).

Entiendo que necesites una explicación de como funciona "X", por que eso es lo que hace la Ciencia con aquello que si que puede explicar, pero es tan sencillo como aceptar que "X" no se puede explicar, sin embargo eso no significa que no se pueda demostrar.

¿Como le explicarías a una persona sorda el sonido del motor de un avión?, ¿o explicarle a un ciego como es el color rojo?, se puede llegar a intentar pero... ¿realmente esa persona será capaz de comprender la descripción?, no, carece del sentido necesario para comprenderlo, y por esta misma regla, ¿como pretendes que alguien le explique a una persona humana qué es eso que llamamos Dios y como funciona?, para poder entenderlo habría que ser lo que conocemos como Dios, estar a su mismo nivel de "capacidad mental".

Es muy facil decir que si no se puede explicar el funcionamiento de algo entonces eso no existe, pero eso es falso con respecto al tema que nos concierne.

PD: Me estoy refiriendo a la existenca del "SER" y a las leyes que le afectan.

Saludos