En correcto lo que dices Román. Lo que sucede es que en mi aplicación existe más de un visor de registro. A cómo dice en un comentario anterior, existe la clase TBaseViewer que es el ancestro de todos lo visores. Dicha clase ya te imaginarás que implementa lo básico y general, dejando algunas cosas como "virtual" para que los herederos puedan personalizar.

Al haber más de un tipo de visor (cada uno con su ligeras diferencias) he preferido utilizar la estructura que os he mostrado. Si hubiese utilizado acciones a cómo mencionas, hubiese terminado repitiendo código para cada uno de los tipos de visores.

Saludos,
Chris

OJO yo hablo de 2 formularios.. 1 donde esta el explorador de registros... osea el grid con los datos y el otro es en que se invoca cuando se ejecutan las "acciones" (agregar, modificar, eliminar).. es en este segundo formulario donde muestro los campos y cuando hablamos de eliminar simplemente desactivos los bdedits y en el boton ejecuto la "accion"

Hola...

Aquí metiendo mi cuchara... :p

oscarac, para eliminar un registro no veo el por que tengas que mostrar el formulario con sus datos si estás realizando la acción desde un explorador de registros. Basta con preguntar si se desea eliminar el registro actual (el que está seleccionado) y dependiendo de la respuesta del usuario, realizas o no la acción de eliminar.


Saludos...

claro claro.. podria hacerse asi, sin mostrar los datos... pero yo me acostumbre a que si voy a borrar algo... le muestro toda la informacion "importante", porque segun mi experiencia ha pasado que el usuario por un error de interpretacion ha borrado lo que no debe, otro motivo es para mantener el estandard.. si agregar y modificar muestro un formulario. entonces en eliminar tambien...

¡Ah! Pero eso es otra cosa. Si tienes varias clases de objetos a editar, desde luego que puede resultar conveniente tener una jerarquía de ellos. Pero aún así, no veo porqué dejar al visor la decisión de escoger entre inserción y edición.

// Saludos

Pues, se supone que el explorador de registros muestra la suficiente información como para que el operador reconozca el registro y sepa si borrarlo o no. Y, en caso de dudas, simplmente entraría a editar el registro para corroborar otros datos, cerraría el editor y oprimiría el botón Borrar.

// Saludos

sucede que mucho antes programaba en FOX, en pantallas de 80x25 y al hacer una grilla, no habia mucho espacio como para mostrar TOOOODaaa la informacion... quiza se me ha quedado esa costumbre

Es que el visor no hace la elección. Es el "caller" al llamar a uno de los constructores previamente descritos. Aunque no sería tan malo dejar al visor hacer la decisión también. Los modelos de Django lo hacen así :)

Saludos,
Chris

jajaja calma chicos mi idea no era llegar a una polémica de técnicas empleadas cada una es interesante.... al fin al cabo el embrollo que he creado se resume en el titulo que presenté al iniciar el hilo.

Hey gracias por compartir sus experiencias...

Me dijo roman

lo hago porque como veras en el codigo

Código Delphi [-]
procedure TFrmPrincipal.AgregarExecute(Sender: TObject);
begin
 FrmCliente := TfrmCliente.create(FrmCliente);
 Try
      FrmCliente.Parent := FrmPrincipal.Panel4; // el formulario que llamo se pega al panel
      FrmCliente.Caption := 'Clientes';// 
      dmacceso.cdsClientes.Active := True;
      dmacceso.cdsClientes.Insert;
      FrmCliente.Show;
 Finally
         If FrmCliente.Caption <> ' ' then
           Begin
              FrmPrincipal.TabSet1.Tabs.add(FrmCliente.Caption);// en el tabset muestra el caption de mi formulario
              FrmPrincipal.TabSet1.TabIndex := FrmPrincipal.TabSet1.Tabs.Count - 1;
           end;
      end;
 //utiles.MuestraVentana('Clientes','Normal');
end;

si lo hago con

Código Delphi [-]
frmClientes.showmodal

, mi formulario se pega en el panel pero no me deja hacer nada en mi aplicación...

Tambien roman

porque si lo dejo en insert me crea otro registro con el mismo nombre y como le tengo evitar duplicidad de datos me manda error...



desanimarme para nada. Ese termino lo utilizo cuando alguien desea algo pero solamente cree que hay una forma de hacerlo. Yo en cambio no me importaría tomar otras opciones para lograrlo al fin al cabo terminar lo que deseo es mi objetivo principal. y ustedes tienen mas experiencia que yo. ténganlo por seguro que los leeré...

Saludos

Ja, ja. Entonces, si el caller hace la distinción, ¿para qué quieres dos constructores? Digo, quizá es que tus visores son muy distintos si se trata de edición o de inserción, y hay que hacer mucha inicialización según el caso. Pero para mi gusto, como dije al pricipio, un tal visor debería actuar prácticamente igual en cualquiera de los dos casos, salvo por algún detalle menor.

// Saludos

Exactamente. Y si no hubiera habido polémica no nos habríamos enterado de las distintas técnicas.

Dicho de otra manera, polemizar no tiene nada de malo. Sirve para aprender nuevas cosas.

// Saludos

Hola
La verdad es que no encuentro el problema por ningun lado.
Lo que se pretende es algo muy sencillo (Usar un form para hacer modificaciones e inserciones).
Donde esta el misterio???
Donde esta lo complicado???.
No lo veo..
Saludos

Realmente las diferencias en cada modo son detalles menores, que bien se podrían expresar en tres o cuatro líneas de código. Pero aunque sean ese poco número de líneas, ya es algo! Y hay que concentrarlas en un solo lugar. Sino habrá que repetir esas cuatro líneas para cada clase de visor. Aparte, no sabes si en un futuro esas cuatro líneas puedan convertirse en 8 y después en 15 y así sucesivamente.

Saludos,
Chris

Bueno, al final, cada quien diseña sus clases lo mejor que puede. ;)

Yo uso un diseño más parecido a lo que comenta roman, los formulario de edición solo saben mostrar los datos, guardar o cancelar la edición del objeto que se le envía y el que los manda a llamar (mayormente un explorador de objetos) es el que decide si es un objeto nuevo o la edición de alguno existente.


Saludos...

Hola...

El misterio, no creo que haya ninguno.

Lo complicado, es la forma en como está haciendo las cosas. Pero claro, muchas cosas las irá afinando mientras más experiencia vaya obteniendo al momento de desarrollar sus aplicaciones.


Saludos...

Caral

El problema es que cada uno tiene su manera y sus tecnicas de llamar formularios para insersion, edicion, eliminacion... yo en realidad he tenido problemas en es cuanto a comportamientos extranos. Cada uno me ah dado aportes interesantes, de igual manera que tu has hecho siempre.

ahora mismo estoy trabajando con algunas sugerencias ya que arriba mostre la nueva manera en que llamo el formulario y porque no uso el showmodal etc.


Saludos

Hola
Yo el problema mas grande lo veo al querer correr antes de caminar.
Si quiero Codigos mas eficientes me voy con Roman, ChackAll, escafandra, Egostar y por supuesto Seoane, Neftali etc. etc...., pero, pero, estare a la altura de entenderlos (como novato)?, lo dudo.
Para mi la mejor manera de llamar a un form (como dice la pregunta) es, la que mejor entienda en ese momento, ya aprendere, ya mejorare.
Quien de vosotros no ha visto un codigo viejo (hecho por vosotros mismos) y ha dicho: '' Que bruto era, si es mucho mejor asi o asa'', estoy seguro que todos.
Moraleja: La mejor manera : La que el depurador no grite.:D;)
Saludos

No soy yo quien para juzgar tu diseño, pero nunca he sido fan de encajar formularios dentro de otra ventana. Por otra parte, ¿realmente deseas hacer otra cosa mientras tienes abierto el formulario de edición de datos?

Claro que quizá tengas una necesidad especial de diseño o requerimiento, pero para mi gusto, un formulario para editar un registro debe ser modal y justamente no permitirte hacer nada más durante la edición.

// Saludos

Ya me estoy dando cuenta a tropezón en los problemas que causa usar formularios encajados en ventana (Se comportan extraño) y me limita a muchas cosas mas.

En cuanto el porque lo requería de esa manera es que el usuario deseaba que trabajara como Los exploradores de Internet, que puedes usar muchas pestañas y hacer varias cosas. solamente trasladándote por pestañas tenia a mano varios formularios (los mas usados).

Ese es el porque se esta trabajando de esa manera.

y tranquilo, siempre las criticas las recibo como algo positivo, y como dijo caral, a base de experiencia llegare a ser como varios de ustedes... :).


lo que hice es que los formularios principales los uso con pestañas, pero si tengo que llamar los formularios de modificación ahí si no lo hago con pestaña... envió un ejemplo de lo que hice:

Código Delphi [-]
class function TfrmCliente.Execute: Boolean;
var
  frmCliente: TfrmCliente;
begin
  frmCliente := TfrmCliente.Create(nil);
  try
    Result := frmCliente.ShowModal = mrOk;
  finally
    frmCliente.Free;
  end;
end;

mas adelante seria agradable poner a funcionar los requerimientos solicitados por mis usuarios.


Saludos;