Autor
|
Tema: (SOLUCIONADO) Duda sobre los elementos que trabajan en segundo plano (Leído 1,189 veces)
|
|
|
spiritdead
Desconectado
Mensajes: 295
|
Hola,
¿Cuales de estos elementos trabajan en segundo plano al llamarlos, y cuales NO (osea cuales congelan la class)?
Sub Function Module Una class distinta a la actual (No se me ocurren más elementos que preguntar...)
Por ejemplo un thread , all llamarlo trabaja en segundo plano sin congelar la app, pues a eso me refiero, ¿hay otros elementos que trabajen en segundo plano?
Muchas gracias
sub es un subrutina por decirle asi donde puedes enviarle parametros functions son funciones de las cuales envias parametros y casi siempre obtienes un unico resultado y modulos son espacios donde puedes crear subrutinas-funciones diciendolo de manera sencilla  para no irme al tecnicismo y todo corre tanto en main como segundo plano cuando hablas de threads estas hablando de hilos tu aplicacion corre en el hilo principal o llamado Hilo Padre, del cual esta tu appDomain principal, en el cual esta todo lo relacionado a tu programa al crear hilos, ellos utilizan informacion del appdomain, y generan un hilo HIJO del cual puedes realizar tareas es bien sabido que al utilizar hilos TU NO puedes acceder al hilo padre desde el, y para ello entra al tema los llamados "DELEGADOS" y bueno ahi sigue en extenso la larga trama de threads-delegates
|
|
|
|
« Última modificación: 17 Diciembre 2012, 10:52 por spiritdead »
|
En línea
|
|
|
|
EleKtro H@cker
Desconectado
Mensajes: 3.293
|
es bien sabido que al utilizar hilos TU NO puedes acceder al hilo padre desde el, y para ello entra al tema los llamados "DELEGADOS" es bien sabido y bien sufrido  , pero eso no es del todo cierto, se puede acceder al hilo principal usando Checkforillegalcrossthreadcall = false (Ya, sé que no es correcto usarlo y da muchos problemas, lo he sufrido mucho  ) Dices que todo corre en main y en segundo plano, pero no entiendo el concepto, si las sub-rutinas corrieran en segundo plano entonces no congelarían el main, ¿no?... Lo que tengo claro es que un thread corre en segundo plano (osea en un subproceso del proceso principal) Yo lo que pretendo saber es: si por ejemplo desde el form principal tengo que llamar a un sub el cual usa un for, que obviamente congelará la app hasta finalizar el for... ¿el único elemento al que puedo recurrir para evitar el congelamiento es crear un nuevo thread (hilo) y llamar a ese thread en lugar del sub? ¿O puedo usar algún otro elemento que trabaje "en segundo plano" como el thread?Gracias por la explicación.
|
|
|
|
|
En línea
|
Como insertar corréctamente un código en el foro para que los moderadores no se acuerden de tus familiares: 
|
|
|
Novlucker
Ninja y
Moderador Global
 
Desconectado
Mensajes: 10.572
Yo que tu lo pienso dos veces
|
Si, todo eso que mencionas bloquea la app si no son llamados desde otro thread, o desde un BackgroundWorker por ejemplo.
Saludos
|
|
|
|
|
En línea
|
Contribuye con la limpieza del foro, reporta los "casos perdidos" a un MOD XD http://twitter.com/novlucker "Hay dos cosas infinitas: el Universo y la estupidez humana. Y de la primera no estoy muy seguro." Albert Einstein
|
|
|
kub0x
Desconectado
Mensajes: 516
K!ll d4 l4mm3r n0w
|
Advertencia - mientras estabas escribiendo, una nueva respuesta fue publicada. Probablemente desees revisar tu mensaje.
Si estoy en lo cierto tienes -> BackGroundWorker, ThreadPool, Delegados(métodos asíncronos) ... Como ves no estás obligado a trabajar únicamente con la clase Thread(), existen alternativas y seguramente me olvido de alguna xD. Si el subproceso lo quieres pausar para lanzar otro subproceso dentro de éste, pues con las clases Mutex() o Semaphore() consigues ese resultado.
|
|
|
|
|
En línea
|
|
|
|
spiritdead
Desconectado
Mensajes: 295
|
es bien sabido y bien sufrido  , pero eso no es del todo cierto, se puede acceder al hilo principal usando Checkforillegalcrossthreadcall = false (Ya, sé que no es correcto usarlo y da muchos problemas, lo he sufrido mucho  ) Dices que todo corre en main y en segundo plano, pero no entiendo el concepto, si las sub-rutinas corrieran en segundo plano entonces no congelarían el main, ¿no?... Lo que tengo claro es que un thread corre en segundo plano (osea en un subproceso del proceso principal) Yo lo que pretendo saber es: si por ejemplo desde el form principal tengo que llamar a un sub el cual usa un for, que obviamente congelará la app hasta finalizar el for... ¿el único elemento al que puedo recurrir para evitar el congelamiento es crear un nuevo thread (hilo) y llamar a ese thread en lugar del sub? ¿O puedo usar algún otro elemento que trabaje "en segundo plano" como el thread?Gracias por la explicación. usar el Checkforillegalcrossthreadcall = false es un error muy fuerte si o si, si usaras threads debes aprender a manejar delegados para acceder a los controles del hilo padre de forma SEGURA  xD evitate dolores de cabeza y olvidate del Checkforillegalcrossthreadcall = false y enfocate en threads despues q aprendes a usarlos, y dominarlos el mundo lo vez de color de rosa y si tienes buen dominio podrias hacer 1 buena combinacion de (threads-delegados-eventos-thread.sleep(X)) dando 1 plus a tus aplicaciones en temas de rendimiento 1 muestra es el Filezilla para la subida-descarga el soft usa multi-hilo y nota lo liso q va  o como en mi software implemente esa metodologia, y puedo realizar cientos de tareas a la vez con consumos del cpu menores al 5% siempre 
|
|
|
|
|
En línea
|
|
|
|
EleKtro H@cker
Desconectado
Mensajes: 3.293
|
¿Y que me dicen de esto? ' Usage: ' InvokeControl(RichTextBox1, Sub(x) x.AppendText("a")) #Region " Invoke Controls " Public Sub InvokeControl(Of T As Control)(ByVal Control As T, ByVal Action As Action(Of T)) If Control.InvokeRequired Then Control.Invoke(New Action(Of T, Action(Of T))(AddressOf InvokeControl), New Object() {Control, Action}) Else Action(Control) End If End Sub #End Region
Lo he testeado a fondo creando varios threads que modifican propiedades de varios controles al mismo tiempo, e incluso modifican el mismo control del form principal todos los threads al mismo tiempo, y no me ha saltado ninguna excepción, es decir, lo he podido usar sin escribir delegados... ¿Esa técnica la consideran buena o la idea de usar delegados sigue siendo mejor?
|
|
|
|
|
En línea
|
Como insertar corréctamente un código en el foro para que los moderadores no se acuerden de tus familiares: 
|
|
|
Novlucker
Ninja y
Moderador Global
 
Desconectado
Mensajes: 10.572
Yo que tu lo pienso dos veces
|
[...] lo he podido usar sin escribir delegados [...] No has declarado un delegado, has utilizado uno predefinido, ¿que crees que es Action?  Saludos
|
|
|
|
|
En línea
|
Contribuye con la limpieza del foro, reporta los "casos perdidos" a un MOD XD http://twitter.com/novlucker "Hay dos cosas infinitas: el Universo y la estupidez humana. Y de la primera no estoy muy seguro." Albert Einstein
|
|
|
EleKtro H@cker
Desconectado
Mensajes: 3.293
|
No has declarado un delegado, has utilizado uno predefinido, ¿que crees que es Action?  Vaya, eso lo explica todo XD, estuve buscando un buen rato sobre lo que es "Action" porque en todos los snippets relacionados con multi-threading lo veo, pero no encontré nada, si pudieras pasarme algún link... xD Gracias
|
|
|
|
|
En línea
|
Como insertar corréctamente un código en el foro para que los moderadores no se acuerden de tus familiares: 
|
|
|
|
|
EleKtro H@cker
Desconectado
Mensajes: 3.293
|
'Declaration Public Delegate Sub Action(Of In T1, In T2, In T3, In T4, In T5, In T6, In T7, In T8, In T9, In T10, In T11, In T12, In T13, In T14, In T15, In T16) ( _ arg1 As T1, _ arg2 As T2, _ arg3 As T3, _ arg4 As T4, _ arg5 As T5, _ arg6 As T6, _ arg7 As T7, _ arg8 As T8, _ arg9 As T9, _ arg10 As T10, _ arg11 As T11, _ arg12 As T12, _ arg13 As T13, _ arg14 As T14, _ arg15 As T15, _ arg16 As T16 _ )
Eso ya pinta dificil. PREGUNTA: ¿Action tiene un límite de 16 argumentos? (Quizás no llegue a saber hacer eso en toda mi vida xD, pero estaría bien saberlo si se da el caso.) De todas formas con toda esta info doy por solucionado el tema xD, Gracias por vuestras respuestas.
Bonito snippet: Simple Delegate Example Imports System Namespace DelegateTest Public Delegate Sub TestDelegate(ByVal message As String) Class Program Public Shared Sub Display(ByVal message As String) Console.WriteLine("") Console.WriteLine("The string entered is : " + message) End Sub Shared Sub Main(ByVal args As String()) '-- Instantiate the delegate Dim t As New TestDelegate(AddressOf Display) '-- Input some text Console.WriteLine("Please enter a string:") Dim message As String = Console.ReadLine() '-- Invoke the delegate t(message) Console.ReadLine() End Sub End Class End Namespace
|
|
|
|
|
En línea
|
Como insertar corréctamente un código en el foro para que los moderadores no se acuerden de tus familiares: 
|
|
|
Novlucker
Ninja y
Moderador Global
 
Desconectado
Mensajes: 10.572
Yo que tu lo pienso dos veces
|
PREGUNTA: ¿Action tiene un límite de 16 argumentos? (Quizás no llegue a saber hacer eso en toda mi vida xD, pero estaría bien saberlo si se da el caso.) Exacto, de hecho, la cantidad de parámetros depende de la versión del framework  . Si necesitas más que eso deberías de declarar tu propio delegado. Saludso
|
|
|
|
|
En línea
|
Contribuye con la limpieza del foro, reporta los "casos perdidos" a un MOD XD http://twitter.com/novlucker "Hay dos cosas infinitas: el Universo y la estupidez humana. Y de la primera no estoy muy seguro." Albert Einstein
|
|
|
spiritdead
Desconectado
Mensajes: 295
|
¿Y que me dicen de esto? ' Usage: ' InvokeControl(RichTextBox1, Sub(x) x.AppendText("a")) #Region " Invoke Controls " Public Sub InvokeControl(Of T As Control)(ByVal Control As T, ByVal Action As Action(Of T)) If Control.InvokeRequired Then Control.Invoke(New Action(Of T, Action(Of T))(AddressOf InvokeControl), New Object() {Control, Action}) Else Action(Control) End If End Sub #End Region
Lo he testeado a fondo creando varios threads que modifican propiedades de varios controles al mismo tiempo, e incluso modifican el mismo control del form principal todos los threads al mismo tiempo, y no me ha saltado ninguna excepción, es decir, lo he podido usar sin escribir delegados... ¿Esa técnica la consideran buena o la idea de usar delegados sigue siendo mejor? te lo resumo de 1 manera mas bonita Delegate Sub SetValue(ByVal value As Single, ByVal status As String) Public Sub SetValueObjects1(ByVal value As Single, ByVal status As String) If KryptonProgressBar2.InvokeRequired Then Dim d As New SetValue(AddressOf SetValueObjects1) Me.Invoke(d, New Object() {value, status}) Else KryptonLabel42.Text = ("(" & Math.Round(value, 1) & ")%") KryptonProgressBar2.Value = value End If End Sub
esa es 1 manera bonita de usar delegados y bastante optimizada en cuanto a uso de sintaxis por decirlo asi el codigo q puse es uno de los delegados mios q tome para darte 1 ejemplo
|
|
|
|
« Última modificación: 19 Diciembre 2012, 04:11 por spiritdead »
|
En línea
|
|
|
|
|
|
spiritdead
Desconectado
Mensajes: 295
|
Gracias
cuando hagas un Invokerequired enfocate en el objeto directo, no lo envies parametrizado trabajando esa parte dinamicamente porque a veces al trabajar con forms dinamicos, te salen errores bastante peculiares  mi recomendacion es 1 delegado por cada control q necesites usar desde otro hilo =) asegurandote q asi tengas multiples instancias de forms con controles repetidos, no genere NI un error 
|
|
|
|
|
En línea
|
|
|
|
|
|