Más Bugs? El "Abogado del Diablo" de Embarcadero
 

Hola, Sufridores de Delphi para Android.
Aquí estoy de nuevo con mis problemas, que pueden ser los vuestros.
No sé si es que le "pido peras al olmo" , pero me encuentro muchos problemas con Delphi para Android.

No soy nuevo en esto. Pero tampoco soy un maestro. En la foto número 1 veréis algunos libros de Borland Turbo pascal 7 y de Borland Pascal With Objects (Por no remontarme a Pascal para DOS).
Foto
http://www.clubdelphi.com/foros/images/attach/jpg.gif

Bueno, no se ve la foto, me tendréis que creer.

Como no soy profesional en esto. Hasta ahora me había apañado con Delphi7 para windows.
Con la moda de los móviles, he querido actualizarme a Delphi 10 (DX) para entretenerme pasando algunos proyectos de VCL Windows a Android.

Con la experiencia que tenia sobre Pascal y Delphi, que han funcionado de maravilla para Windows, esperaba mucho más de DX.

A medida que quiero avanzar, me voy encontrando "dificultades" que no debería encontrar en los programas de desarrollo de aplicaciones de Embarcadero.

He encontrado otros dos ¿Bugs?

El primero consiste en que si en un TStringGrid le intentas ocultar las líneas de la rejilla, no te permite ni editar ni asignar strings en tiempo de ejecución.

El otro caso consiste en que si tienes un array de TStringGrids declarado y otro TStringGrid declarado fuera del array, si creas un evento OnClick del TStringGrid declarado fuera del array y le asignas el evento a otro TStringGrid perteneciente al array, el compilador te permite la asignación y te pasa los valores correctamente.

Pero no sucede igual con el evento OnDrawColumnCell. Te da un error al compilar informando de que no tienen los mismos parámetros. Aparentemente son los mismos, pero el parámetro State: TGridDrawStates, no es el mismo. En el evento OnDrawColumnCell del TStringGrid que no está dentro del array, (si posas el cursor sobre él) podrás ver que pertenece a FMX.Grid.TGridDrawStates. Pero si posas el cursor sobre el mismo evento de uno de los elementos del array, podrás ver que el TGridDrawStates pertenece a
la clase FMX.Grid.TStringGrid.TDrawColumnCellEvent.TGridDrawStates.

Y NO LO COMPILA.

Código Delphi [-]
ArrayDeStringGrid[X,Yl].OnDrawColumnCell := StringGridFueraDelArrayDrawColumnCell;

Esto es una faena, si tienes varios TStringGrids en el array y quieres que se comporten de la misma manera.

Me vais a llamar "quisquilloso", "pejiguero", "meticuloso", "exigente"... lo que queráis, PERO ESTO EN UN ENTORNO DE DESARROLLO CARO y de Embarcadero, me parece, (cuanto menos), "imperfecto".

¡Seguiremos peleando...!

No sé si me he explicado lo suficientemente claro. Si quedan dudas, me lo decís.

Perdón por el rollazo.

Saludos a todos/as.

En este punto estoy de acuerdo con vos

Es una estupidez lo de los Scoped Enums

Basicamente, en VCL escribes esto:

Código Delphi [-]
  Align := alClient;
  MessageDlg('bla', mtInformation, [mbOk, mbCancel], 0);

En FMX no compila, ya que se traduce asi

Código Delphi [-]
  Align := TAlignLayout.Client;
  MessageDlg('bla', TMsgDlgType.mtWarning, [TMsgDlgBtn.mbYes, TMsgDlgBtn.mbNo], 0);

Y no podes cambiarlo, eso es porque FMX fue compilado con la directiva Scoped Enums en ON

El codigo es mas largo y molesto de escribir :mad:

Hola Agustín.
Tienes "más razón que un santo", (como se dice por aquí).
Me recuerda la tediosa notación de Java. ("System.out.Println()" o bien "java.awt.event.ActionEvent evento".
¡¡¡Con lo bonito y lo fácilmente legible que era el código Delphi!!! "PrintLn()" y ya. Añoranzas...
Ya podía Embarcadero haberse esforzado un poquito, y (respetando la notación de toda la vida) haber "traducido" internamente la notación a la hora de compilar el código.
Un saludo.

Si bien parece que hubo por ahí alguna pifia de parte de Embarcadero, les sugiero que se tomen muy en serio los unit scopes, los namespaces la erradicación del With (a menos que por fin sea blindado) y procuren evitar toda referencia en código que se preste a ambigüedad o genere duda de procedencia.

Los identificadores calificados es probablemente una de las mejores prácticas que debemos adoptar. El mundo ya no es pequeño, las bibliotecas son muchas y muy vastas, los nombres tienden a colisionar.

Con el with estoy de acuerdo, sin pensarlo; la unica excepcion para el with es este caso: The Either Type en el cual comparto con Stefan

Pero con el tema de los Scoped Enum no. Y es que el problema esta en que en la VCL seguimos "de la manera vieja" y en FMX esta "la manera nueva" y esto genera mucha confusion. Yo creo que Embarcadero deberia haber hecho el mismo cambio en sus dos framework, no solamente en uno

Por otro lado, el tema "ambiguedad", no estoy de acuerdo

Código Delphi [-]
uses
  System.SysUtils,
  Unit1 in 'Unit1.pas';

type
  TNumeros = (Uno, Dos, Tres);

  // declarado en seccion interface de Unit1, sino obtendria un Identifier redeclared: 'Uno'
//  TPalabras = (Uno, Delphi);

var
  Numero: TNumeros;
  Palabra: TPalabras;
begin
  Numero := Uno; // TNumeros.Uno
  Numero := Dos; // TNumeros.Dos
  Palabra := Uno; // E2010 Incompatible types: 'TPalabras' and 'TNumeros'
  Readln;
end.

Este codigo no compila, lo cual es algo bueno

Si hay colisiones de enumerativos, o bien se usan calificadores completos, o bien se usa otro prefijo. Pero no se puede decir que hay posibilidad de codigo ambiguo como en el caso del with que ya todos sabemos que puede desencadenar en un desastre :)

https://twitter.com/algonzalez74/sta...35658950909953

https://twitter.com/algonzalez74/sta...36471987408896

Un saludo sin ánimo de debate. :)

Bueno.
No quería yo levantar tanta polémica.
Pero estoy de acuerdo con Al, el código debe ser lo más fácilmente inteligible por los humanos, aunque por parte de la máquina tenga que esforzarse un poquito más por traducir las expresiones.
Saludos.

Yo me sigo inclinando por la variante #1 de las 2 que escribi en el mensaje #2

Soy un fanatico de escribir poco codigo, es decir, esto no me gusta para nada:

Código Delphi [-]
  Writeln(ExtractFileName(ParamStr(0))); // v\||/
  Writeln(AppBinName); //^\||/ ^\||/

De hecho, el escribir las distintas versiones de MessageDlg me terminaron resultando muy molestas, ademas no tienen opcion para enviar argumentos para aplicar Format (como si existe una ShowMessageFmt)

Y por eso me escribi unos propios metodos que invocan a MessageDlg pero apenas envio parametros:

Código Delphi [-]
  InfoMsg(const AMessage: string); // MessageDlg(AMessage, mtInformation, [mbOk], 0);
  InfoMsgFmt(const AMessage: string; Args: array of const); // MessageDlg(Format(AMessage, Args), mtInformation, [mbOk], 0);
  PromptMsg(const AMessage: string): Boolean; // MessageDlg(AMessage, mtConfirmation, mbOkCancel, 0);
  ...

No es mas facil y rapido de escribir, amigable, legible, el propio metodo intenta indicar su proposito (InfoMsg esta claro que va a mostrar un cuadro de dialogo con informacion, les dejo para adivinar: que haran los metodos ErrorMsg y WarningMsg? :D)

No entiendo porque el uso de enumerativos sin calificadores completos pueda llevar a ambiguedad, Al si puedes poner un ejemplo te lo agradeceria, porque no me doy cuenta ^\||/

Yo ando perdido porque no conozco las versiones recientes de delphi. Había escuchado que tenían ya (por fin) espacios de nombres, pero veo que eso de los unit scopes es diferente. ¿Que no bastan los espacios de nombres? ¿No es agregar más confusión? ¿O de que se tratan que no entiendo? :o

LineComment Saludos