[[Al González]]

Empezado por ElMug

[...] Que haya o no otros metodos es irrelevante, especialmente si no ahorran una columna, y te forzan a descifrar [...] el metodo que les comparto, considero, le puede ser bastante util al que desee tratarlo, por su simpleza, eficacia, y robustidad.

Antes que nada, gracias por compartir tu código, ese digno y ejemplar acto es algo de lo más apreciado en cualquier foro de programación.

Ahora viene la crítica, con lo cual espero edificar algo sobre esta pequeña Damasco en que se ha convertido el hilo.

Forzar es precisamente lo que hace tu código: Le pides a un objeto TJPEGImage que intente asimilar cierto flujo de bytes, el cual puede o no puede ser una imagen de ese formato, por tanto se corre el riesgo (controlado) de que se le atragante la tostada y eleve una excepción.

En cuanto a que es simple (guardando las subjetividades a las que se presta esa palabra), por lo menos habría que eliminar sus partes innecesarias (asignación de Nil a Image1.Picture.Graphic) o repetidas ("BlobField := ...", y "BS := ..."), ya que ahorrar código es mucho más importante para la CPU que ahorrar campos para una base de datos. No tiene sentido volver a asignar el mismo valor a la variable BlobField, ni volver a llamar al método CreateBlobStream (en todo caso sólo reposicionar el flujo BS en su primer byte).

eficaz .- Que tiene eficacia. eficacia .- Capacidad de lograr el efecto que se desea o se espera.

Sí es eficaz, aunque con el desafortunado precio de nunca destruir los objetos TJPEGImage y TBitMap que asignas (copias) a Image1.Picture.Graphic. Con cada ejecución de ese código, tu programa estará ocupando más y más memoria; mira lo que hace TPicture:

Código Delphi [-]
procedure TPicture.SetGraphic(Value: TGraphic);
var
  NewGraphic: TGraphic;
begin
  NewGraphic := nil;
  if Value <> nil then
  begin
    NewGraphic := TGraphicClass(Value.ClassType).Create;
    NewGraphic.Assign(Value);
    NewGraphic.OnChange := Changed;
    NewGraphic.OnProgress := Progress;
  end;
  try
    FGraphic.Free;
    FGraphic := NewGraphic;
    Changed(Self);
  except
    NewGraphic.Free;
    raise;
  end;
end;

En cuanto a la robustidad, que en informática se considera libre de defectos o fallas de funcionamiento, hay que decir que ese código no es del todo robusto. Algunas de las razones son:

1. Asumes que "Image1.Picture.Graphic:= TJpegImage.Create" no va a causar ningún problema, por lo que BS podría quedar sin destruirse nunca.

2. Asumes que si falla el primer LoadFromStream, es definitivamente por no tratarse de una imagen JPEG. ¿Será la única razón por la cual pueda elevarse una excepción al ejecutar esa sentencia?

3. No hay ninguna garantía de que el objeto BS sea destruido si falla el segundo LoadFromStream. OK, todos hacemos pequeñas asunciones en nuestro código de cuando en cuando, ¿pero qué tal si aun siendo una imagen BMP, LoadFromStream tuviera dificultades para leerla?

4. La no liberación de los objetos TGraphic que creas.

Es lo que se puede notar en tu solución a simple vista. Es una mala práctica emplear "excepciones controladas" para determinar el flujo del programa; para tomar decisiones están los Ifs no los Excepts. ¿Que te ahorras campos? Muy bien, PERO siempre que no dejes tu aplicación llena de pequeñas trampas.

En cuanto al empleo de objetos auxiliares dentro de las rutinas, ya sabes la regla:

1. Apertura (creación)

Try
  2. Uso
Finally
  3. Cierre (destrucción)

Reitero, que bueno que has compartido tu código. Si tienes a bien hacerle las correcciones y mejoras pertinentes, de igual manera muchos te estaremos agradecidos por publicar la nueva versión.

Saludos a todos.