cual es la mejor forma de llamar a un formulario de modificación de datos

[[oscarac]]

si qjuieres usar pestañas podrias usar componentes de Delphi que te permiten hacerlo tipo PageControl

[novato_erick]

hola oscarac

Estaba leyendo respecto al componente PageControl antes de iniciar el proyecto, y lo utilize ciertamente sin embargo al cargar el programa te abre las pestañas y ese no es el comportamiento que tengo entendido que se requiere busque por todos lados para ver si era posible abrir y cerrar las pestañas del PageControl a medida que uno lo necesitara pero no encontré nada.

Actualmente lo utilizo en un formulario como por ejemplo:
frmArticulos que tiene un PageControl con varias pestañas que me desplazo para asi agregar mas información requerida al articulo.

Saludos;

[[oscarac]]

no tengo delphi a la mano en este momento... pero tengo entendido que puedes ocultarlas y colocarlas visibles segun tus necesidades

[ecfisa]

Hola novato_erick.

Haciéndo la creación desde el mismo form podes mostrarlo:

Código Delphi [-]
class function TfrmSecundario.Mostrar: Boolean;
begin
  with Self.Create(nil) do
  try
    Result:= ShowModal = mrOk
  finally
    Free
  end
end;

Para llamarlo:

Código Delphi [-]
procedure TfrmPrincipal.ShowSecundario(Sender: TObject);
begin
  TFrmSecundario.Mostrar
end;

Saludos.

[[oscarac]]

creo que se oculta asi

Código Delphi [-]
 
tsDatos.tabVisible := False;

[ecfisa]

Empezado por oscarac

creo que se oculta asi

Código Delphi [-]
 
tsDatos.tabVisible := False;

Correcto oscarac, así es.

Para ocultar/mostrar todos los TabSheets por ejemplo:

Código Delphi [-]
procedure TForm1.btnTabsOnOffClick(Sender: TObject);
var
  i: Integer;
begin
  for i:= 0 to PageControl1.PageCount -1  do
    with PageControl1.Pages[i] do
      TabVisible:= not TabVisible
end;

Saludos.

[[maeyanes]]

Hola...

novato_erick, las pestañas las puedes crear y eliminar en tiempo de ejecución sin grandes problemas.

Código Delphi [-]
var
  Page: TTabSheet;

begin
  // Crear una página:
  Page := TTabSheet.Create(PageControl1);
  Page.PageControl := PageControl1;
  Page.Caption := 'Página 1';
  // ...
  // Eliminar la página:
  Page.Free;
end;

Saludos...

[[Caral]]

Hola
A ver si asi le queda algo mas claro a novato_erick
Dale Click al DBgrid.
Saludos
Variaciones sobre el mismo tema.

[novato_erick]

Ya llevamos tres días con este tema a todos ustedes gracias. Ya pude solucionar los problemas de los form tomando en cuenta sugerencia de diversos participante en este tema por ejemplo:

roman dijo:

No soy yo quien para juzgar tu diseño, pero nunca he sido fan de encajar formularios dentro de otra ventana.

Tenia razon esta tecnica en diseño no es mala pero me trae muchos comportamientos extraños que al final tendria que tener mas practica.

oscarac

si quieres usar pestañas podrias usar componentes de Delphi que te permiten hacerlo tipo PageControl

y

ecfisa

Haciéndo la creación desde el mismo form podes mostrarlo:


maeyanes

novato_erick, las pestañas las puedes crear y eliminar en tiempo de ejecución sin grandes problemas.

estas tres recomendaciones las realize y me funcionó

Chris

Declaro dos contructores en la clase (los llamo "visores de registro", para diferenciarlos de los "exploradores de registro").

Chris este es a otro nivel... bueno cuando lo haga se de quien lo tome...

y caral

Hola
A ver si asi le queda algo mas claro a novato_erick
Dale Click al DBgrid.
Saludos
Variaciones sobre el mismo tema.

Ejemplo Form.zip

Gracias me servio mucho tu ejemplo...

Gracias Sres...

[novato_erick]

Caral

me di cuenta leyendo tu código que debiste de tomar tu tiempo para hacerlo y darme mejor explicación mandándome ese miniproyecto... oye gracia por ese tiempo.


Saludos

[[Caral]]

Hola
De nada amigo, pero la verdad lo hice en un ratito, no es nada perfecto, es solo una muestra sencilla para tomar notas.
Me alegro que le saques algo de provecho.
Siempre he sido de la opinion de que un ejemplo, aunque sea sencillo, es mejor que codigo al alzar, los novatos lo entendemos mejor.
Saludos

[[Chris]]

Empezado por roman

No veo por qué. Se requiere una sóla línea de código para poner en modo de edición o de inserción al dataset.

Román, no me quedaba claro porque insistías en que para el visor de registro le debería dar igual si está editando o creando un nuevo registro. Igual, no se necesitaba mucho código. Ahora me doy cuenta que desde tu punto de vista tenías toda la razón de pensar así. Pero en mi caso, no es conveniente hacerlo y sí se requieren de los dos constructores. Ahora te explico:

Había pecado en no mencionarte que los visores no trabajaban con el mismo TDataset que utilizan los exploradores. Por ejemplo un explorador de clientes trabaja con un Dataset que mediante SQL solo descarga los campos absolutamente necesarios (los mostrados en la regilla y uno que otro). Talvez solo utilicen 4 ó 5 campos de un total de 20 que puede tener la tabla. Los visores son ya otra cosa. Ellos sí necesitan todos o casi todos los campos de la tabla. Es por eso que necesitan de otro TDataset que trabaja con SQL.

El código de los constructores no es simplemente "Dataset.Edit;" o "Dataset.Insert;". Su código es un poco más sofisticado -por decirlo de cierta manera-. Inclusive, una de las primeras cosas que hacen es determinar los privilegios del usuario. También adaptan el SQL para solamente descargar del servidor el campo que se va a modificar, o abrir el TDataset sin descargar ningún dato si es que se creará un nuevo registro.

Esa es la razón por la que existen dos constructores. Códigos completamente aislados para dos própositos distintos que requieren de una lógica especial para cada caso. Talvez ahora me puedas entender en el por qué he insistido en la necesidad de tener dos constructores según la operación que se valla a realizar.

Por último, no me quiero despedir sin antes darte las gracias por tan buen agradecimiento que has hecho Erick a los que hemos participado en este hilo. Uno sería más feliz si todos los que aquí consultan tuvieran semejante don del agradecimiento a cómo lo tienes. Te lo digo porque me he topado con personas que ni siquiera te dicen un "gracias" al final. Pero bueno, uno también al final lo hace por "amor al arte"

Saludos,
Chris

[roman]

Hola Chris,

Yo sigo sin ver del todo la necesidad de los dos constructores. Bueno, entiendo que tengas razones para hacerlo y seguramente tienes razón, pero tu argumento de los distintos dataset no me convence .

Yo también uso datasets distintos según si son para mostrar una lista de registros o si son para editar un registro. Aquí un ejemplo extraido de un caso real:

Inserción:

Código Delphi [-]
begin
    with TSolicitanteEditorForm.Create(Self) do
    begin
        SolicitudesDm.QSolicitante.Open;
        SolicitudesDm.QSolicitante.Append;

        if ShowModal = idOk then
        begin
            Self.txtRfc.Text := SolicitudesDm.QSolicitante['rfc'];
            Self.txtApellidos.Text := SolicitudesDm.QSolicitante['apellidos'];
            Self.txtNombre.Text := SolicitudesDm.QSolicitante['nombre'];
        end;
    end;
end;

Edición:

Código Delphi [-]
var
    SolicitanteId: Integer;

begin
    SolicitanteId := QSolicitantesSesion['solicitante_id'];

    SolicitudesDm.QSolicitante.Close;
    SolicitudesDm.QSolicitante.ParamByName('id').AsInteger := SolicitanteId;
    SolicitudesDm.QSolicitante.Open;

    with TSolicitanteEditorForm.Create(Self) do
    begin
        SolicitudesDm.QSolicitante.Edit;

        if ShowModal = idOk then
        begin
            QSolicitantesSesion.Refresh;
            QSolicitantesSesion.Locate('id', SolicitanteId, []);
        end;
    end;
end;

En ambos casos se usa una dataset específico (QSolicitante) para editar los datos que se pone en modo de inserción o edición según la operación, y esto lo hace quien llama, no el editor en sí.

En el evento Show del formulario de edición se hace una ligera distinción entre edición e inserción:

Código Delphi [-]
procedure TSolicitanteEditorForm.FormShow(Sender: TObject);
begin
    if dsSolicitantes.DataSet.State = dsInsert then
        Caption := 'Nuevo solicitante'
    else if dsSolicitantes.State = dsEdit then
        Caption := 'Datos del solicitante';
end;

pero el resto del formulario funciona igual tanto en uno como en otro caso. Aun suponiendo que tuviera muchas distinciones entre inserción y edición (que, insisto, no veo porqué habría de ser así) haría algo como esto:

Código Delphi [-]
procedure TSolicitanteEditorForm.FormShow(Sender: TObject);
begin
    if dsSolicitantes.DataSet.State = dsInsert then
        InicializaInserción()
    else if dsSolicitantes.State = dsEdit then
        InicializaEdicion();
end;

// Saludos

[roman]

Empezado por novato_erick

Chris este es a otro nivel... bueno cuando lo haga se de quien lo tome...

Bueno, yo no estoy de acuerdo para nada con el argumento de que, como se está empezando, hay que hacer las cosas como mejor podamos sin meternos en "otro nivel".

Es entendible, claro, que al principio no dominemos algunas cosas y tiempo después lo hagamos de otra manera. Pero si desde el principio hay técnicas que son adecuadas y alguien nos las enseña, pues, ¿por qué no usarlas y evitarnos quebraderos de cabeza en un futuro?

// Saludos

[[Chris]]

Empezado por roman

Hola Chris,

Yo sigo sin ver del todo la necesidad de los dos constructores. Bueno, entiendo que tengas razones para hacerlo y seguramente tienes razón, pero tu argumento de los distintos dataset no me convence .

Hola Román!

Aparte de los Datasets separados también hubieron otras razones por la que tomé este diseño. Uno de ellos era independizar al máximo el visor del explorador y viceversa. Es así porque necesitaba que cualquier parte de la aplicación pudiera, con la mayor simplicidad posible, llamar al visor en modo de inserción/edición o simplemente vista. No solamente los exploradores.

Otra de las razones es que en mi aplicación, los visores no se muestran en forma modal (requerimiento auto impuesto por usabilidad). Esto ocaciona que el explorador no pueda "quedarse esperando" a que un usuario ingrese o modifique un nuevo cliente por ejemplo. Cuando los visores hacen un cambio a la base de datos, lo notificacan a toda la aplicación por medio de Mensajes de Windows. Así el resto de módulos pueden decidir si procesar o no la notificación. Algo muy similar a cómo funcionan ciertas partes de la API de Windows.

Este diseño me ha dado mucha independencia y agilidad para desarrollar nuevo módulos. Ya que los exploradores y visores descienden de una clase base que implementa lo básico para cada uno, los herederos simplemente solo implementan lo que es específico para el tipo de dato con el que trabajan.

Saludos,
Chris