[[Delphius]]

Empezado por kbaby

Bueno recien me hago un hueco de estudiar integrales y estadistica para poder ver un poco el ejemplo y tu post. Pues como te dije, yo no aprendí nada de eso. A mi me enseñan las cosas pero de modo lento... porque no todos los de mi aula tenemos la experiencia de tener un ordenador en casa para poder ensayar y a otros se le da mal el aprnedizaje del codigo. Entonces tenemos un nivel muy bajo, pero estas "llamadas" yo las hago de otra manera o lo que me enseñaron a mi por llamadas es cuando estas en un código y necesitas que actue otro button, entonces pones ButtonX.Click;

De todas formas me voy a poner ahora un ratito con el delphi a ver si saco algo. Muchas gracias, a ver si acabo examenes y me pongo a "delphilar".

Me estaba temiendo de que tu no tienes equipo en casa, por como muchas veces me decías que anotabas cosas en tu libreta y te llevas los apuntes a casa.

Bueno no importa, lo importante es que continues y no te dejes vencer.
Lamento si te ha resultado duro que yo haya elejido ese modo de mostarte las cosas, pero me parece de que ese modo se consiguen mejores cosas.

Lo del "llamar" al bottonClick es una opción. Y es algo parecido a lo que hago yo... la diferencia es que tu pones el código a ejecutar en botones, mientras que yo hago que los botones llamen a ciertos procedimientos y son éstos quienes se encargan de hacer el trabajo.

Básicamente yo hago que el botón de la orden al procedimiento. Mientras que tu haces que todo el trabajo lo hagan botones. Esto no siempre es deseado. A medida que avancen tus conocimientos sobre el tema comprenderás las diferencias.

Um... lo que me dices sobre la enseñanza, pues... yo soy de opinar de que si se van a dar clases que se den bien. En otro caso que se vayan.

La enseñanza sea la que sea, debe darse correctamente y por más lenta que sea, es preferible explicar bien las cosas básicas antes que estar meses a medias.

¡Tu metele ganas!

Empezado por kbaby

Y bien aquí estoy. Estuve dándole vueltas a tu código hasta me dieron ganar de copiarlo pero nada que no encuentro que "cosa" haces para que se modifique. Así que me creé este:

Código Delphi [-]procedure TForm1.Button10Click(Sender: TObject);
var y: integer;
begin l.Items.clear; // limpio el listbox
for y:= 1 to t.rowcount-1 do begin //antes de iniciar esto, mi rejilla
// ya le volqué todas las personas
edit1.text:=t.cells[1,y];
edit2.text:=t.cells[2,y];
edit4.text:=t.cells[3,y];
edit5.text:=t.cells[4,y];
button1.click; // ejecuta el boton de añadir
end;
end;


Cosas buenas:
- Hace lo que quiero que haga (cuando una persona esta en la rejilla y le modifico o sin modificar) guarda todos los datos de la rejilla en el listbox (limpiándolo previamente).

Cosas malas:
- Las personas no estan ordenadas por ningún criterio, así que cágate (perdon xD) cuando mi "hospital" tenga 1239123947823984905 usuarios y la muchacha de recepción le de por buscar al paciente Pepito Gomez (se muere ).

Jajaja que te parece tio voy a seguir echándole un ojo a eso de hacer llamadas a tu forma que me gusto!

Pue eso... sigue dandole ganas. Un truco más: Copia el código de los procedimientos y funciones que se llaman para un botón dentro del botón y notarás que igualmente funciona. Por ejemplo si yo tengo algo como esto:

Código Delphi [-]
procedure TForm1.Button1Click(Sender: TObject);
var Se_puede: boolean;
begin
  Llamar_a_A;
  Se_puede = Se_puede_hacer_B;
  if Se_puede
     then Llamar_a_B;
end;

Lo que hace Delphi, como para que entiendas, es hacer eso:

Código Delphi [-]
procedure TForm1.Button1Click(Sender: TObject);
var Se_puede: boolean;
begin
  // aqui comienza el código de Llamar_a_A;
  // ....
 // aqui termina el código de llamar_a_A;
 Se_puede = // aquí el código de Se_puede_hacer_B
 if Se_puede
   then begin
            // aqui comienza el código de Llamar_a_B
            // ...
            // aqui termina el código de Llamar_a_B
          end;
end;

¿Se entiende? Es como tener un código enorme al cual parto en pedacitos mas chicos. Cada parte hace algo... y lo lindo de esto es que puede que esas partes sean más o menos independientes una de otra lo cual favorece a que se evita tener que estar repitiendo código. Si justo una de esas partes me sirve aqui y hallá... en ves de copiar su código la "llamo" y solita hara su trabajo (Si recibe parámetros, quien la llama le pasa los parámetros).

Más o menos lo podemos ver como un "díalogo". Formalmente se los puede llamar como el cliente y el subordinado. O en ocasiones el maestro y el subordinado.
A ver... te voy a dar un ejemplo con algo cotidiano. Supongamos que quiero comprar dólares. ¿Quien es el cliente? Nosotros. Puesto que somos los interesados en hacer algo. ¿Quién es nuetro subordinado? El cajero puesto que cedemos algo de nuestra actividad en alguien más. Podríamos decir "Para que hacerlo yo... si hay alguien que lo sabe hacer y lo hace bien?"

Entonces quedamos en que necesitamos comprar dolares (lo que deseamos hacer). Cuando llega nuestro turno de ser atendidos soltamos una frase como la siguiente "Buenos días, quiero comprar dólares" El subordinado nos dice: "Buenos dias. Muy bien, ¿Cuanto desea?". Le informamos el monto, y el nos responde con un "Son xxx pesos. ¿Le parece bien?" Si respondemos afirmativamente, nos solicita nuestro DNI. Se lo decimos, el confirma la transacción y al minuto nos entrega los dolares correspondientes y el vuelto en caso de ser necesario.

Si te fijas, alguien para hacer si trabajo ha necesitado saber algo por parte del cliente. En este caso, el cajero necesitaba conocer de nosotros la cantidad a comprar y nuestro DNI. En programación esto se suele hacer con el paso de parámetros.

¿Te parece raro lo que te he dicho?
Pues veamoslo como podríamos resolverlo esto en forma de código:

Código Delphi [-]
procedure TForm1.ComprarDolaresClick(Sender: TObejct);
var pesos, dolares, vuelto: real;
     DNI: integer;
     confirmar: boolean;
begin
    dolares := 0.0;
    pesos := StrToFloat(CantidadAComprar.Text); // es un TEdit
    DNI := StrToInt(DNI.Text);
    confirmar := Confirmar.Checked; // es un TCheckBox
    if Confirmar
       then begin
                dolares := pesos div 3.15 // 3.15 es la tasa de cambio
                vuelto := pesos - (dolares x 3.15);
                ButtonGuardarTransaccion.Click // asi lo harías tu...
              end;

Se que es un ejemplo... no pretende ser totalmente gráfico y real. ¿Como se puede resolver esto?

Una alternativa que yo utilizaría es esta:

Código Delphi [-]
procedure TForm1.ComprarDolares(AComprar: real; var TasaCambio: real);
var Confirmar: boolean;
begin
   PedirTasaCambio(TasaCambio);
   Confirmar = AnalizarCompra(TasaCambio);
   if Confirmar
     then Comprar(AComprar);
end;

De ese modo yo hago algo como esto para llamar a ese procedimiento:

Código Delphi [-]
procedure TForm1.ButtonComprarDolaresClick(Sender: TObject);
begin
   ComprarDolares(StrToFloat(Cantidad.Text), tasa);
   //Nota como primero paso convertiendo el texto de un TEdit en float,
   // tasa posiblemente sea una variable global
end;

¿Eso es todo? ¿Y aquel emborroso código inicial? ¿Donde ha quedado aquello del DNI, devolver el vuelto, darle el dinero... y demás...? Pues de eso se encarga el procedimiento Comprar.

Analicemos...
ComprarDolares es un procedimiento, no es un Button... es algo que se va a ejecutar cuando se presione el botón. Para que ComprarDolares funcione, necesita saber dos cosas:
1. La cantidad a comprar (parámetro AComprar)
2. Una tasa de cambio (parámetro por valor, TasaCambio).

¿De donde sale esa tasa de cambio? Para que la necesitamos? En realidad, cuando uno compra dolares uno va y se informa de la tasa de cambio y en base a ello decide... quien en realidad sabe de la tasa es el cajero...
Si te fijas, antes de TasaCambio: real, hay una palabra var. Esto hace que el parámetro sea por valor. Viene a ser como un parámetro de salida (que puede ser de utilidad para después).

Entonces, estamos frente a un díalogo entre los procesos y funciones y la forma de hacerlos hablar es a través de parámetros. Hay ocasiones en que no son necesarios los parámetros, otras en que si.

Nuestro botón se comunica con ComprarDolares, y éste a su vez con PedirTasaCambio, AnalizarCompra, y Comprar.

¿Quien es cliente y subordinado? Pues se trata de una cadena...
1. Primero: el procedimiento ComprarDolares es subordinado del Botón ComprarDolares. Por tanto el cliente (interesado) es el Botón.
2. Segundo: a su vez, el procedimiento ComprarDolares es cliente puesto que subordina parte del trabajo a Comprar, PedirTasaCambio, etc...
3. Posiblemente, y es de esperar que PedirTasaCambio, Comprar hagan otras cosas.... cosas que ha nosotros no nos interese saber, pero que le son necesarias para hacer su trabajo.

Por ejemplo: PedirTasaCambio, por dentro haga cosas como "VerificarConBancoCentral", "VerificarSiHayDolares", o cosas por el estilo...

El asunto es que a un problema grande, lo partimos en pedacitos chicos, que juntos hacen las cosas más grandes. Esto se conoce como el principio divide y vencerás. Esto lo verás más adelante en tu cursado.

Se que posiblemente te sientas mareado por todo lo que te he dicho... es normal, al comienzo cuesta entender las cosas.

Lo más sorprendente es que tu lo aplicas, y ni siquieras te haz dado cuenta... ¿O acaso el haber hecho un Button2.Click no es parte de esa filosofía?

Saludos, kbaby... Piensa en frio.