Como implementar un Procedimiento Compartido

[[escafandra]]

No siempre ocurre ese caso y siempre se puede colocar más de una llamada a ProcessMessages. En algún caso puede ser útil.

Evidentemente, es secuencial, por lo que es preferible usar hilos para aquellas tareas que van a demorar el procesamiento mensajes Windows y que provocarán la falta de respuesta de la aplicación. Estamos de acuerdo, pero puesto que existe no se puede dejar de mencionar, si bien subrayando sus carencias.

Saludos.

[[escafandra]]

En cuanto al uso exclusivo de clases discrepo. Una librería de funciones generales es tan útil como una librería de clases. Todo depende de la función.

Una función general es mucho más portable entre distintas app que la perteneciente a una librería de clases. Mi forma de programar es saltar de alto a bajo nivel sin complejos, en aquellas tareas que lo requieran. POO no es dogma de fe. En ocasiones es excelente elección. En otras un engorro.

VCL está orientado a objetos, es lógico que sus eventos requieran una clase, pero nada te impide crear eventos con una función calback tradicional. La API de Windows es un ejemplo.

La programación, bajo mi punto de vista, debe ser plástica y adaptarse a cada necesidad. La rigidez muchas veces complica lo sencillo.

No estoy ni a favor ni encontra de POO simplemente uso ambas, según la necesidad. Y aunque discrepen muchos, me gusta más la POO de C++ que delphi.

Saludos

[Toni]

Los dos teneis vuestra parte de razon. Como en todo hay que buscar un equilibrio. Yo tambien soy pro POO pero en ocasiones te puede complicar la vida, tanto como en otras es la mejor solucion. We water my friend!

[[escafandra]]

Empezado por Toni

Los dos teneis vuestra parte de razon. Como en todo hay que buscar un equilibrio. Yo tambien soy pro POO pero en ocasiones te puede complicar la vida, tanto como en otras es la mejor solucion. We water my friend!

Pues eso mismo trato de explicar...

Saludos.

[[Al González]]

Concuerdo con la mayor parte de lo dicho por escafandra, a quien me da gusto tener ocasión de saludarlo, por cierto.

Sin quitar demasiado valor a las motivaciones de AgustinOrtu.

Debo confesar que yo mismo me encuentro en esa encrucijada, que se pone delante de todo programador bibliotecario surgido antes de la POO: Habiendo ya creado un considerable número de clases me pregunto si valdría la pena convertir mis cientos de funciones sueltas en métodos de una o varias clases de utilidad.

Perdón si con esto me sumo al desvío del tema, de un asunto doméstico de C++Builder hacia un tema algo más general —pero demasiado importante como para no ser debatido—.

Saludos.

[[escafandra]]

Encantado de volver a leerte, Al González . Es cierto que muchas veces surgen dudas de ese tipo. Soy de los que piensan que si las ventajas son dudosas ¿por que hacerlo?. En realidad todo depende...

No creo que el tema esté desvirtuado, pues es la duda que se plantea NEG1414 y que tantas veces nos planteamos todos. Como bien dices, es lo suficientemente importante como no dejarla pasar por alto. Todas las opiniones cuentan y seguro que a NEG1414 le aportan mucho.

Saludos

[NEG1414]

Gracias a todos por participar en el hilo que he abierto...

Desde el punto de vista de un programador autodidacta y relativamente novato en la POO creo entender la postura ortodoxa de AgustinOrto respecto a los "procedimientos libres" que considera males necesarios (o no) que distorsionan la estructura "armonica" de la progrmacion orientada a objetos, refuerza esta opinion cuando escribe "El ProcessMessages esta prohibido".

Personalmente senti la misma "aprension" cuando surgio la programacion visual a la que consideraba ideada para "niños , acostumbrado como estaba a escribir linea tras linea sobre una pantalla totalmente negra teniendo como unica referencia un punto parpadeante.... el tiempo como en todo en la vida te hace ver lo equivocado que estabas..

Creo que lo fundamental en una aplicacion es que funcione... el como es importante pero hay que ser flexible (lo dice alguien que en una epoca estaba obsesionaba con llegar al mismo fin con el minimo de numero de lineas de codigo) , muchas veces seguir caminos menos "higienicos" producen un resultado optimo, que nos ahorra tiempo y trabajo (al fin y alcabo el "pecado" queda entre tu y tu conciencia).

Respecto a la cuestion inicial voy a optar por la opcion del "Procedimiento Libre" me parece sencilla y efectiva, respecto al segundo punto, el de mensajes, en el problema que me atañe le doy la razon a AgustinOrto, no me vale y lo explico..

Tengo un Form padre en el que tengo una barra de progreso y una serie de botones tengo un form hijo, tambien con una serie de botones, en los dos capturo mensaje raton y si lo deseo hago que los botones del raton esten anulados de la forma (gracias Leo)

Código PHP:

 void __fastcall AppMessage(MSG &Msg,bool &Handled);  

_fastcall TFHijo::TFHijo(......,TProgressBar *PB,.......): TForm(Owner)
  {

    //Leer Mensajes
    Application->OnMessage = AppMessage;  

  }

 void __fastcall TFFiltros::AppMessage(MSG &Msg, bool &Handled)
 {   
   if((WM_LBUTTONDBLCLK == Msg.message || WM_LBUTTONDOWN == Msg.message)  && !BotRatonAct)
    { 
      Handled = true;
     }
 } 


desde el padre accedo al hijo de dos formas: modal (visualizandolo) o llamando directamente a un constructor, pasndole como uno de sus parametros la barra de progreso.
Accediendo de la segunda forma en el form hijo (sin visualizarse) se realizan una serie de procesos y a medida que estos se realizan la barra de progreso en el form padre avanza (hasta aqui todo correcto), el problema surge cuando hago click con el raton, la teoria era que al estar procesando datos en el forn Hijo, cualquier accion con el raton sobre componentes del form Padre fuera nula, ya que el formHijo recebiria el mensaje y lo anularia(BotRatonAct = false), el caso es que para mi sorpresa al hacer click con el raton sobre cualquiera de los botones del FOrm Padre estos se accionan... No Vale...

Gracias a todos o tra vez y recuerden...

La ignorancia es un mal que se cura preguntando.