elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.


 


Tema destacado: [Aporte] Mejores practicas en Java


  Mostrar Mensajes
Páginas: 1 2 3 4 5 [6] 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 ... 1017
51  Programación / .NET / Re: Ayuda con DotNet en: 9 Septiembre 2017, 05:39
Hola.

Asegúrate de seguir las instruccioenes de instalación específica para distribuiciones Debian:


Saludos.
52  Programación / Programación General / MOVIDO: Como funciona el mod(%) en c# en: 9 Septiembre 2017, 05:26
El tema ha sido movido a .NET.

http://foro.elhacker.net/index.php?topic=474277.0
53  Programación / .NET / Re: Como funciona el mod(%) en c# en: 9 Septiembre 2017, 05:23
Hola.

Primero de todo: las preguntas sobre C# van en el subforo de programación .NET Framework.

Todo lo que necesitas saber y aprender está en la MSDN...
...deberías revisarla en el futuro para aclararte tus dudas.



si (n % 2 != 0) significa que el número no es par verdad

Efectivamente. El operador de módulo devolverá el resto después de dividir 'n' por '2', que siempre será Cero si 'n' es divisible por '2', o dicho de otra forma: 0 si 'n' es par.

Saludos.
54  Programación / .NET / Re: [Duda]Winform o WPF al momento de desarrollar una Aplicacion en: 6 Septiembre 2017, 20:17
Hola.

¿Segun ustedes cual creen que es mejor?

No es cuestión de creencias, estamos hablando de un hecho indiscutible: WPF es mejor, puesto que es la evolución directa de WindowsForms. En otras palabras: Winforms = pasado (y con pseudo-obsolescencia programada), WPF = presente y futuro (largo futuro por delante, sin fecha determinada de muerte).

Con respecto a temas de "diseño", WindowsForms se basa en la utilización de la API de Windows para renderizar con GDI+ (DirectShow), mientras que WPF lo hace con la API de DirectX (Direct3D), y éste puede aprovecharse de ciertas ventajas como la aceleración de hardware por GPU al renderizar, entre otros muchos beneficios destacables que afectan positivamente al rendimiento de WPF en comparación con la lenta tortuga de WinForms y su imperfección.

Respecto al rendimiento de tu aplicación, bueno, éste será proporcionál a la calidad de tus algoritmos, ni más, ni menos. No importa si WinForms o WPF, aunque en lo referente al instrumental interno de renderización ya hemos explicado que si, hay una gran diferencia donde WPF es más óptimo que WindowsForms, así que es posible que la velocidad de respuesta de la interfáz de usuario pueda ser algo mejor en WPF si lo comparásemos en igualdad de condiciones con WinForms.

Y respecto a la personalización, todo depende de como lo mires y lo que necesites. WPF es mucho más completo en todos los sentidos (y cada día lo es más, puesto que es una tecnología en continuo desarrollo, a diferencia de WinForms), y eso también incluye que la cantidad de parámetros relacionados con el aspecto y el comportamiento de un control (léase: sus propiedades) sea mucho más amplio en comparación con WinForms. Además en WPF se pueden usar plantillas (templates) para modificar sencillamente el aspecto de un elemento, pero en WinForms también se puede modificar el aspecto de los controles... solo que para hacer grandes cambios en la mayoría de ocasiones se requieren metodologías más tediosas (léase: Platform Invoke).

De todas formas, la respuesta a "¿que tecnología es mejor o más completa?" no debería ser un factor decisivo, me refiero, sin saber que es lo que realmente quieres lograr con la programación, para hacer cosas simples WinForms te servirá perfectamente y te resultará más sencillo. La sofisticación o el perfeccionismo de WPF implica un nivel bastante más elevado de dificultad al programar en comparación con WinForms (empezando por el simple hecho de que tienes que compaginar dos lenguajes al mismo tiempo C#\VB.NET + Xaml ), ten eso presente en tu decisión. Por otro lado, ir a por la tecnología más reciente y sofisticada (WPF) siempre será una buena decisión para todo.

Saludos.
55  Programación / Programación Visual Basic / MOVIDO: Optimizar busqueda en un datagridview en: 5 Septiembre 2017, 05:06
El tema ha sido movido a .NET.

http://foro.elhacker.net/index.php?topic=473994.0
56  Programación / .NET / Re: Optimizar busqueda en un datagridview en: 5 Septiembre 2017, 04:41
Hola.

como realizo tal operación que me indicas?

( Me tomo la libertad de responderte yo, que hace tiempo que no respondo nada en el foro, y el compañero NEBIRE parece estar un poco ausente a este thread. )

Al decir "deshabilitar un control" yo al menos me estoy refiriendo a deshabilitar las peticiones de redibujado del control. ¿Y cómo se hace esto?... pues depende del escenario...

Si es un control que realice un layout automático, por lo general un contenedor de controles como: TableLayoutPanel, FlowLayoutPanel, o Panel, podemos utilizar el método Control.SuspendLayout(), esto es útil sobre todo al añadir muchos controles al contenedor de controles, ahí queremos suprimir el layout para que el control no se redibuje hasta que hayamos terminado de insertar todos los controles. La supresión del layout afecta a propiedades tales como: Control.AutoSize, Control.Anchor y Control.Dock. Podemos ignorar llamar a SuspendLayout claro está, pero de hacerlo solo conseguiremos que el proceso de inserción /interacción con el control sea lento y feo, produciendo flickering...

Si por lo contrario hablamos de un un control de usuario entonces es mucho más facil "deshabilitar" el control ya que evidentemente tendriamos toda la capacidad de controlar el dibujado del control a nivel interno digamos. Por decir algo: podría ser tan simple como anular (override) la propiedad Control.Enabled e ignorar todo el dibujado del control mientras su valor sea False, por ejemplo.

Para un control de tipo lista, es decir: ListView, ListBox o ComboBox, lo que debemos hacer es llamar al método Control.Beginpdate. Los pasos a seguir serian los siguientes:

...Las operaciones de interacción con la colección (Control.Items) del control aquí...

Con el método Control.BeginUpdate() lo que conseguimos hacer es suprimir cualquier petición de redibujado durante las modificaciones que le hagamos a la colección del control. Cada vez que añadimos un elemento a la colección, se dispara un evento para que el control se redibuje, esto por cada 1 de los elementos que añadamos en el control, por lo tanto resulta evidente que pretender añadir varios elementos a la colección sin preocuparnos del redibujado... provocará una considerable disminuición en el rendimiento del control.

Sin embargo el control DataGridView no expone dicho miembro, pero en su lugar... (sigue leyendo aquí abajo)

Hay que reconocer que el sistema es un poco tonto, porque si se añade al final y el elemento no cabe en la vista, no hace falta en realidad actualizar la vista.... pero...

Así es, pero precisamente para solventar ese problema de raíz es que está la propiedad DataGridView.VirtualMode (con su posterior y tediosa implementación personal):


Ese es el modo más óptimo de administrar la respuesta o "responsividad" de un control DataGridView con exceso de elementos (como los +14.000 en este caso).



De todas formas, para mantener una velocidad de respuesta estable en un DataGridView en la carga de varios elementos, para evitar el redibujado constante y mantener un rendimiento decente, vaya, tampoco es tan dificil, por lo general no debería ser necesario recurrir a implementar el modo virtual, sino que simplemente debemos utilizar un DataSource en lugar de administrar manualmente la cantidad de columnas y filas, y la inserción o eliminación manual de elementos. Que de eso se encargue la lógica del control por si solo mediante el DataSource bindeado. Pero lo cierto es que no he trabajo en escenarios con +14.000 elementos de carga, así que no puedo hablar mucho de lo que no he experimentado...

Eso sí, si por el motivo que sea nos vemos obligados a tener que administrar de forma manual la inserción de elementos en el DataGridView (como parece ser tu caso), entonces para aumentar el rendimiento se debe utilizar el método DataGridView.Rows.AddRange en lugar de DataGridView.Rows.Add (recuerda que por cada elemento añadido el control se redibujará... y no quieres que eso ocurra, así que debes añadir todos los elementos de una sola vez, llamando a AddRange).



Para el tema de las búsquedas... una solución sería dejar un margen de tiempo de inactividad, un "timeout" por así decirlo. En lugar de buscar cada vez que presionas una tecla, lo que debes hacer es determinar (mediante un objeto Timer o StopWatch) cuanto tiempo hace que se pulsó una tecla por última vez (digamos 500 milisegundos, es un buen valor de inactividad), y entonces empezar a realizar la búsqueda en los elementos de la colección. O más sencillo: realizar la búsqueda solamente cuando se presione la tecla ENTER, o al presionar un botón que diga "Buscar".

Saludos.
57  Programación / .NET / Re: Ayuda para hacer facturas en visual 2017 en: 5 Septiembre 2017, 04:13
no se si revisaste un poco mas abajo el tema, ya detalle todo...

-_-

Mi comentario lo escribí ayer (antes de que tú escribieras ese comentario con la factura) pero lo he publicado hace un rato. Lo siento. De odas formas eso no cambia las cosas... es importante dar la información necesaria lo primero de todo al formular una duda sobre programación :-/

Es bastante tarde aquí, mañana veré si puedo ayudar en algo. Un saludo.
58  Programación / .NET / Re: Calcular porcentaje en: 5 Septiembre 2017, 04:08
Código
  1. progressBar_barrra_progreso.Value = 0; // Resetear progressBar a 0.

Lo correcto, tanto por estética del código fuente, como por rendimiento y seguridad del producto final, sería utilizar el método ProgressBar.Increment:

Código
  1. progressBar1.Increment(1);

De esta forma evitarías futuros posibles errores humanos como sería por ejemplo:
Código
  1. progressBar1.Maximum = 100;
  2. progressBar1.Value = 101;
...Este código de arriba provocaría una excepción de tipo ArgumentOutOfRangeException, mientras que si usases el método ProgressBar.Increment podrías rebasar el valor máximo por accidente sin provocar ninguna excepción.

Ejemplo demostrativo:
Código
  1. progressBar1.Maximum = 100;
  2. for (int x = 0; x <= 999; x++) {
  3. progressBar1.Increment(1);
  4. }



Código
  1. Application.DoEvents();

No sé si habrás tenido la oportunidad de leer lo que programadores profesionales siempre han opinado sobre el método Application.DoEvents, pero todas las opiniones escritas en la World Wide Web se podrian resumir brevemente en las siguientes palabras: "Application.DoEvents() is EVIL, do not use it." - y quien dijo eso tuvo mucha razón. No debes utilizar dicho método a menos que seas consciente de lo que hace y como lo hace intérnamente, sé que es una via de escape facil para solventar la respuesta o responsiveness de la interfáz de usuario, pero es que esa metodología conlleva muchas desventajas, y a día de hoy es prehistórica. Lo único que te debería importar es lo siguiente: al lo único que consigues llamando a ese método de forma continua dentro de un búcle, es disminuir el rendimiento (la velocidad) de tu programa y el algoritmo de copiado, y no lo estás disminuyendo un poco, sino MUCHO ( puedes hacer la prueba por ti mismo con y sin llamar a Application.DoEvents() ).

( Aquí te dejo una opinión del gran gurú Hans Passant: https://stackoverflow.com/a/5183623/1248295 )

En lugar de utilizar el método Application.DoEvents(), puedes utilizar esto otro método:
...De esta manera, las llamadas continuas a Application.DoEvents() se disminuirán en consideración, y con ello aumentará bastante el rendimiento de tus algoritmos donde tengas que llamar a Application.DoEvents(). Y por supuesto al usar esta alternativa/mejora, la interfáz de usuario seguirá siendo responsiva a los eventos de notificación de Click.

...Pero mucho mejor y más correcto que utilizar Application.DoEvents(), que como ya dije ES UNA METODOLOGÍA PREHISTÓRICA (aparte de peligrosa), sería recurrir a los instrumentos que .NET Framework nos proporciona hoy en día, me refiero a la programación asincrónica, ni más, ni menos. Si necesitamos interactuar con los elementos de control de una UI, entonces lo más adecuado sería utilizar el componente BackgroundWorker, puesto que está precisamente diseñado para llevar a cabo la interactuactuación con la UI, pero podemos utilizar la classe Task, o Thread. También es importante utilizar los métodos Control.BeginInvoke / Control.Invoke según las circunstancias. Hay varias maneras de llevarlo a cabo, depende del escenario / circunstancias.

Por último, te muestro un pequeño ejemplo gráfico:

       

PD: Ahora que lo pienso mejor, debería haber escrito "responive UI" en lugar de "app" en la imagen, pero bueh. Si, ya sé que me preocupo por tonterías, soy así de exquisito o perfeccionista... según se mire xD.

Saludos.
59  Programación / .NET / Re: HTML to PDF/TIFF en: 5 Septiembre 2017, 04:04
Hola. Open-Source no conozco ninguna, pero las librerías comerciales de SautinSoft funcionan muy bien:

HTML > PDF:
PDF Metamorphosis .Net

PDF > TIFF
PDF Focus .Net

PD: ...Siempre puedes tratar de buscar la "medicina" por la World Wide Web.

Saludos.
60  Programación / .NET / Re: Como puedo obtener datos x dato de php a .net en: 5 Septiembre 2017, 04:03
como podría evitar que salieran los <tr y td que solo me estableciera los numeros.

Hola.

Lee:

Un ejemplo que podrías adaptar a tus necesidades:
Código
  1. Dim html As XElement =
  2.    <html>
  3.        <body>
  4.            <table>
  5.                <tr>
  6.                    <th>Column</th>
  7.                </tr>
  8.                <tr>
  9.                    <td>17788481</td>
  10.                    <td>5955996</td>
  11.                    <td>58585</td>
  12.                </tr>
  13.            </table>
  14.        </body>
  15.    </html>
  16.  
  17. Using wb As New WebBrowser
  18.  
  19.    wb.ScriptErrorsSuppressed = True
  20.    wb.DocumentText = ""
  21.    wb.Document.OpenNew(replaceInHistory:=True)
  22.    wb.Document.Write(html.ToString())
  23.  
  24.    Dim elements As HtmlElementCollection = wb.Document.GetElementsByTagName("TD")
  25.    For Each el As HtmlElement In elements
  26.        Debug.WriteLine(el.InnerText)
  27.    Next
  28.  
  29. End Using

PD: Para parsear documentos HTML en .NET, conviene utilizar la librería de terceros (y gratuita) HtmlAgilityPack.

Saludos
Páginas: 1 2 3 4 5 [6] 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 ... 1017
Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines