No voy a hacerlo demasiado largo, ya que es un tanto tarde (madrugada del lunes en España) y como todo hijo de vecino tengo que levantarme temprano para trabajar, pero tenía pendiente comentar con vosotros que ya han confirmado la fecha del evento “Delphi Developer Day IV”, que va especialemente dirigido a la comunidad hispana: viernes, 26 de Febrero (2010).
En lo que respecta a la hora de inicio, según el formulario de respuesta que se lanza al registrarte al evento, figura las 7:00 AM (PST), que si no me equivoco y de acuerdo al último que pude asistir, vendrán a ser sobre las 4 pm (en España).
Recordad que en http://dn.embarcadero.com/article/40336 disponéis de mas información tanto del contenido del seminario web como de los expertos que van a participar. Os adelanto simplemente que serán 8 presentaciones, a la cual mas interesante :-)
No deberías de perdértelo.
Por cierto: esta tarde no he podido dedicar tiempo al blog ya que estoy bastante absorbido con el aprendizaje de punto net y mi toma de contacto con Delphi Prism. Y al final, tienes que combinar lo mejor que se puede el tiempo de forma que en este caso, desgraciadamente el blog ha sido el sacrificado. No obstante, no quería acabar el día sin al menos dejar estas letras.
Ha sido una tarde tranquila, recreandome y “jugando” con el entorno, e intentando poner en práctica el ejemplo de desarrollo que propone Marco Antonio Santín en su video del “Curso de Desarrollo de aplicaciones de escritorio y acceso a datos con Delphi Prism”. A medida que voy siguiendo los pasos, comparo mentalmente con las estructuras que uso habitualmente desde mis desarrollos y amplío las ideas comentadas, intentando encontrar puntos similares, que me sirvan de referencia.
Así por ejemplo, he intentado encontrar mis clases Ancestro y Browser como base de las propuestas del curso y he acabado traduciendo la llamada principal “Mostrar” a punto net, para ver que tal quedaba. (Mostrar era un método de clase de la clase base TAncestro).
Tras un buen rato, el método original
class function TAncestro.Instancia: TAncestro;
var
I: Integer;
begin
for I := Screen.FormCount - 1 downto 0 do
begin
TForm(Result) := Screen.Forms[I];
if Result.ClassType = Self then Exit;
end;
Result := nil;
end;
class function TAncestro.Mostrar: TAncestro;
begin
Result := Instancia;
if Assigned(Result) then
begin
if Result.WindowState = wsMinimized then
ShowWindow(Result.Handle, SW_RESTORE);
Result.BringToFront;
end
else
begin
Result := Create(Application.MainForm);
Result.RegistroLeer;
Result.Show;
end;
end;
quedaba reescrito como:
class method TAncestro.Instancia(FormType: System.Type): TAncestro;
begin
Result:= Nil;
for each f: Form in Application.OpenForms do
begin
if (f.GetType() = FormType) then
begin
Result:= TAncestro(f);
Exit;
end;
end;
end;
class method TAncestro.Mostrar(FormType: System.Type): TAncestro;
begin
Result:= Instancia(FormType);
if Assigned(Result) then
begin
if Result.WindowState = FormWindowState.Minimized then Result.Show;
Result.BringToFront;
end
else begin
var Prototipo: Object := Activator.CreateInstance(FormType);
Result:= TAncestro(Prototipo);
Result.MdiParent:= ActiveForm;
Result.Show;
end;
end;
Y la llamada desde el menu principal había cambiado también. Inicalmente escribía:
TModelos.Mostrar;
y ahora, tenía que añadir algunas lineas mas (aunque no demasiadas más). En la primer aproximación hacia algo como:
var fModelo: TModelos := New TModelos();
var Prototipo: System.Type;
Prototipo := fModelo.GetType();
TModelos.Mostrar(Prototipo);
Luego me he dado cuenta de que no tenia demasiado sentido instaciar dos veces el objeto por lo que tras otro buen rato, escribo finalmente:
var Prototipo: System.Type;
Prototipo := System.Type.GetType("Empresa12.TModelos");
TModelos.Mostrar(Prototipo);
Lo cual parece mas razonable y ademas funci0na… :-)
Como primer punto de encuentro está bien (imagino que en próximos días encontraré formas de simplificar esas llamadas) y doy por bien empleada la tarde. Pero es difícil evitar sentirse extraño y no hacer algunas comparaciones, de cosas que he podido echar en falta. Por ejemplo en el editor de código: Es imposible no darse cuenta de que el editor no es mas cómodo ni usable por tener una pestaña adicional (una para el código y otra para el diseñador del formulario). Así pues, mientras Delphi trabajaba entre bastidores, me he encontrado con sorpresa que algunos cambios manuales en el nombre de la clase o del ascendente en el tipo, ocasionaba errores de lectura en la carga del formulario en tiempo de diseño, fruto de que no se habian modificado los modulos que llevan la referencia “XXX.designer.pas”. Y he tenido que ir repetidamente a ese modulo de diseño de formulario y abrirlo con un editor de texto plano y modificar manualmente los nombres para que fueran correctos y se solucionara el error. 
¡Cosas un tanto extrañas que te hacen el trabajo mas farragoso!
Tampoco entiendo el por qué no han puesto un filtro en la paleta de componentes de forma que puedan ser fácilmente encontrados a la hora de buscar uno en concreto. Delphi lo resolvió en las ultimas versiones, tanto a nivel de la paleta de componentes como de busquedas mas generales a nivel de ide y opciones de configuración.
Existen algunos detalles mas pero parece aconsejable dejarlos para otro día dada la hora que es… :-)
Mañana será otro día. Por hoy yo tengo bastante…
http://www.danysoft.com/
http://www.embarcadero.com
Delphi Access
Comentarios recientes