re utilizacion de Fomr

[vroa74]

Buennos dias :

tengo una duda
estoy usdando BDS 2006, la verdad estoy elaborardo un sistemita pequeño, y la verdad me gustaria poder reutilizar los forms.
por ejemplo
amta de usuario y edicion de usuario
son dos form que usan los mismos datos lo que cambian es la sentencia de los botones.
podria de alguna forma usar el mismo form para ambas aciones con tan solo
pasar un parametro al form que se abre ?????

usando el form como una funcion o procedimiento ????

[Caral]

Hola
Claro que se puede.
lo mas simple es poner un combobox, con los dos tipos, en cuanto se seleccione uno de ellos, cambiaran tanto los caption de los botones como los parametros interiores que desees, por supuesto con el codigo necesario para ese fin.
Saludos

[Delphius]

Hola vroa74,
Hay muchas maneras de conseguir esto... tantas como programadores y gustos de helados hay (no puedo evitar hacer esta comparación... me invade el calor:p)

Una manera de conseguir esto es mantener una variable "bandera" de tres estados. Cada estado representa una acción ABM. Por ejemplo:
0 -> Alta
1 -> Baja
2 -> Modificación

De modo que cuando se crea el form (y/o cuando sea necesario) se ingresa este valor mediante algún parámetro a una función definida que se encargue de habilitar/deshabilitar y/o mostrar/ocultar los controles.
Por ejemplo una procedimiento como este:

procedure HabilitarControles(Opcion: integer);
begin
case Opcion of
0: // sentencias para habilitar los controles de alta
1: // sentencias para habilitar los controles de bajas
2: // sentencias para habilitar los controles de modificación
end;

// Opcional, pero recomendado:
OpcionHabilitada := Opcion; // guardar el valor... en algun lugar
end;

Ahora, si podemos guardar el valor de opción podemos incluso ahorrarnos controles. Sobre todo los botones de Aceptar. ¿Como?

Si hemos guardado el valor de Opcion en alguna variable a la que se pueda tener acceso se puede hacer algo como esto:

procedure ButtonAceptarClick(Sender: TObject);
begin
case OpcionHabilitada of
0: // accion para alta
1: // accion para baja
2: // accion para modificación
end;
end;

Esto es una opción. Y muy usada, debido a su simpleza.
Hay otras maneras, y como dije... dependerá de gustos y/o las necesidades del aplicativo.

Algo a tener en cuenta, lo simple puede llegar incluso a salirte caro. Pues la simpleza de hacer ese empleo deL case puede verse entorpecida con el posible mantenimiento y actualización del sistema. Por ejemplo: ¿Y si en el otro form el 2 es en realidad 1? ¿De donde salen esos números? ¿Y si hay otras "acciones" que agregarse, como una especie de búsqueda o subbúsqueda... le asociamos un nuevo estado... un 4? Estas preguntas pueden darte una pista si la simpleza de este método te resulta.

E incluso puede llegar a ser prospenso como para mezclar la lógica del programa con el aspecto meramente visual. Por ejemplo se puede caer en algo como esto:


procedure ButtonAceptarClick(Sender: TObject);
begin
case Opcion of
0: begin
// Hacemos el alta...
SQL := 'insert...... ';
.....
end;
1: begin
DeshabilitarCombo;
Eliminar;
end;
...
Query1.Open; // Un ejemplo...
end;


¿Al final? ¿Sobrecargamos al botón Aceptar con código y mezclamos las sentencias SQL alli y luego las mandamos? ¿O lo hacemos simple como que se disparen la orden mediante otros procecimientos y/o funciones qur tengan ese código enmarranado?

En fin... dependerá de lo que te resulte cómodo, y/o que tan complejas deban ser las acciones a llevar a cabo en un form como asi también de la cantidad de controles que posea.

No se si te sirva lo que dije. Pero creo que son cosas que uno debe tener en cuenta. Cuando desea llegar a un código simple, bonito, fácil de mantener, y de reutilizar empieza por los forms... pero es muy común, sobre todo cuando uno se inicia en meter todo en un form... llega el momento en que se hace una pregunta como esta: ¿Y ahora... como partir el código en forma correcta para que pueda seguir siendo operable?

Es cuestión de organizarse.

Saludos,

[vroa74]

Creo que no me he sabido explicar con claridad y les expreso mis disculpas.

he pensados algo como


var f : TForm4;
begin
{aqui insertar algun parametro para que la aplicacion entre del modo selecionado}
f:= TForm4.Create(application);
try
f.ShowModal;
finally
f.Release;
end;

[Delphius]

Hola de nuevo.

El planteo que tu deseas aplicar, a mi modo de ver, es un poco errado. No se le puede asignar algo a un form si previamente no ha sido instanciado.

Es decir que primero debe venir el
f := TForm4.Create(Application)

y después la asignación. Como te decía.. una opción es un simple procedimiento. de modo que queda (como ejemplo):

try
f .= TForm4.Create(Application)
f.HabilitarControles(1); // por ejemplo habilitamos la parte de bajas
// O incluso... si puede y es viable hacer algo como:
// HabilitarControles(f,1);
f.ShowModal;
finally
f.Free;
end;

Hay otras opciones un poco mas complejas... Por ejemplo la que ofrece Ian Marrteens en su famoso libro La Cara Oculta de Delphi 4. No recuerdo bien las páginas exactas pero el tema era como mediante simple MostrarModal(1) siendo ese parámetro (en el ejemplo 1) para indicar el modo de baja. Si buscas bajo las palabras clave formas modales y no modales llegarás a buenos resultados. Por ejemplo este:
http://www.clubdelphi.com/foros/showthread.php?t=38285&highlight=mostrar+modales
que fue exactamente el que inicié hace tiempo yo con por el planteo que trata Ian.

No se me ocurre otro modo por el momento... si me das un poquito mas de tiempo... la pienso mejor.

Saludos,

[maeyanes]

Otra forma puede ser, si usas DataSet's, es al momento de crear o mostrar la forma, verificar el estado del DataSet para saber que estás haciendo, por ejemplo:


// Ejemplo de evento OnCreateForm
procedure TEditForm.CreateForm(Sender: TObject);
begin
case DataSource.DataSet.State of
dsBrowse:
// Habilitar solo el botón cerrar...
dsEdit:
// Habilitar los botones aceptar, cancelar
dsInsert:
end
end;

// Formas de llamar la forma:
// Para editar un registo
DataSet.Edit;
with TEditForm.Create(nil) do
try
ShowModal
finally
Free
end;

// Para insertar un nuevo registro
DataSet.Insert;
with TEditForm.Create(nil) do
try
ShowModal
finally
Free
end;

// Solo quiero mostrar los datos del registro activo
with TEditForm.Create(nil) do
try
ShowModal
finally
Free
end;


Espero que esto junto con lo que te han comentado mensajes arriba, te sirva para darte una idea de como puedes implementar tus formas de edición de datos...



Saludos...

[Delphius]

Me gusta la opción de Maeyanes, por lo de los estados del dataSet... no se me ocurrió hacer algo asi. Aunque puede que hay que hacerle algunas observacines, según mi entendimiento...

Por empezar... si hacemos algo como:

DataSet.Edit;
with TEditForm.Create(nil) do
try
ShowModal
finally
Free
end;
Damos por entendido que el DataSet está en algún otro lado. Por ejemplo otra form o un DataModule.
Esto puede llegar a ser contraproducente pues puede que incluso llegue a nublar la comunicación... entre la forma a la que deseamos crear y el DataModule en donde está alojado el DataSet.

Lo digo por esta cuestión:
DataSource.DataSet.State

¿Quien "conoce" a quien? La primera form a la segunda.. y esta segunda al DataModule?

Como dije... es como lo estoy entendiendo... Será que a mi no me gusta ver este tipo de "unión" entre la interfaz y la lógica.
Creo que deben tenerse en cuenta esto... por más simple que sea el sistema.

Si me lo puedes explicar mejor maeyanes te lo agradecería. Ya que estoy intrigado.
Saludos,

[maeyanes]

Bueno... solo era un ejemplo a la ligera para darle una idea de como implementarlo...

El poner el DataSet en edición, inserción, etc... podría hacerse desde cualquier lado... tal vez usando un TDBNavigator...

La forma de edición podría tener un componente TDataSource conectado al TDataSet de los datos a editar...

Así una comparación del tipo case EmpleadosDS.DataSet.State of sería válida...

Entra mucho en juego como tengan diseñadas sus formas de captura y sus módulos de datos...



Saludos...