Continuamos con el tema de las 2 últimas entradas. Visto el esqueleto del proyecto y probado que funciona (la carga, descarga y registro de la DLL) ahora nos queda generar una previsualización funcional. Hasta ahora hemos visto que podemos mostrar un formulario «vacío», ahora nos toca programar realmente la carga del fichero (según su tipo).
Os adjunto los links de todas las entradas de esta serie, que iré completando a medida que avance:
Con la estructura que tenemos del proyecto anterior, lo único que tenemos que hacer ahora es programar la carga y visualización de la información del fichero en el formato que queramos ofrecerla al usuario.
Para este primer ejemplo vamos a empezar con algo sencillo.
Realizaremos una previsualización de ficheros de log (*.LOG) que vamos a tratar como ficheros de texto plano.
Embarcadero MVP.
Analista y Programador de Sistemas Informáticos.
Estudios de Informática (Ingeniería Técnica Superior) en la UPC (Universidad Politécnica de Barcelona).
Llevo utilizando Delphi desde su versión 3. Especialista en diseño de componentes, Bases de Datos, Frameworks de Persistencia, Integración Continua, Desarrollo móvil,…
Continuando el tema de «Crear una Previsualización de ficheros en Windows», vamos a seguir completando esta serie, haciendo referencia al tema del registro que nos quedó pendiente en la anterior entrada.
Os adjunto los links de todas las entradas de esta serie, que iré completando a medida que avance:
Hablo de «registros» en el título de esta entrada, porque vamos a abordar por un lado, los cambios en el «registro de Windows» que debemos realizar para que nuestra DLL quede «inscrita» en el sistema (con esto le decimos al sistema, que cuando quiera visualizar un determinado fichero de extensión AAA, debe cargar nuestra DLL para mostrar ese contenido). Y en segundo lugar, veremos cómo registrar nuestra DLL en Windows a través de regsrv32.
.
CLAVES DE REGISTRO
Cuando registramos nuestra DLL (regsvr32) necesitamos modificar algunos valores en el registro de Windows para indicar al sistema que tiene una DLL disponible para utilizar cuando se le solicite una vista previa de un archivo con extensión AAA.
Para ello tenemos disponible esta documentación que explica los diferentes cambios a crear/borrar cuando realizamos el register/unregister.
Lo primero que debemos tener en cuenta, es que si nuestro controlador de Vista previa (de 32 bits) se está registrando en un sistema de 64 bits, tal y como se describe aquí, debe usar un IdApp diferente;
Embarcadero MVP.
Analista y Programador de Sistemas Informáticos.
Estudios de Informática (Ingeniería Técnica Superior) en la UPC (Universidad Politécnica de Barcelona).
Llevo utilizando Delphi desde su versión 3. Especialista en diseño de componentes, Bases de Datos, Frameworks de Persistencia, Integración Continua, Desarrollo móvil,…
La idea de esta serie de entradas es ver todos los pasos necesarios para generar desde cero una DLL de Previsualización para Windows, de un determinado tipo de ficheros.
Antes de continuar os adjunto los links de las entradas de esta serie, que iré ampliando a medida que las vaya publicando:
Si abrimos el Explorador de Windows, para algunos tipos de ficheros que existen en nuestro equipo, el sistema operativo dispone de vista una previa desde el propio explorador. Nos permite ver el contenido del fichero de forma rápida, sin necesidad de abrir el programa asociado.
Al seleccionar una imagen o un fichero .INI en el explorador de Windows, si tenemos la previsualización activada, veremos directamente una «vista previa» de ese archivo sin necesidad de abrir otro programa.
Si por el contrario, el fichero no tiene vista previa definida, veremos un mensaje de Windows indicándolo. Algo similar a esto (varía dependiendo de la versión):
Embarcadero MVP.
Analista y Programador de Sistemas Informáticos.
Estudios de Informática (Ingeniería Técnica Superior) en la UPC (Universidad Politécnica de Barcelona).
Llevo utilizando Delphi desde su versión 3. Especialista en diseño de componentes, Bases de Datos, Frameworks de Persistencia, Integración Continua, Desarrollo móvil,…
Continuando con la entrada anterior del blog, donde hablaba de cómo acceder a las propiedades de audio de un dispositivo Android; La idea de esta entrada es avanzar un poco más en el tema y generar una aplicación que nos permita gestionar varios perfiles de audio en nuestro dispositivo.
Una vez que vimos cómo acceder a la información del volumen actual, lo siguiente que nos interesa es poder almacenar diferentes perfiles, de forma que podamos seleccionar uno de los perfiles y configurar todos los parámetros de audio de forma rápida y automática.
Además debemos poder editar los perfiles existentes, borrar os que no nos interesen y tener la posibilidad de crear nuevos.
Contaremos con una serie de perfiles predefinidos, que podrían ser similares a estos:
Embarcadero MVP.
Analista y Programador de Sistemas Informáticos.
Estudios de Informática (Ingeniería Técnica Superior) en la UPC (Universidad Politécnica de Barcelona).
Llevo utilizando Delphi desde su versión 3. Especialista en diseño de componentes, Bases de Datos, Frameworks de Persistencia, Integración Continua, Desarrollo móvil,…
Hace unos días se planteaba en el clubdelphi una cuestión acerca de la gestión de volúmenes en los dispositivos Android. Me llamó la atención porque días atrás me había planteado la cuestión de poder disponer de «perfiles de audio» en mi propio teléfono Android. Se trata de un Xiaomi con versión KitKat instalada y una ROM personalizada.
¿Cómo podemos desde Delphi acceder a los volúmenes del dispositivo para las diferentes características (música, alarmas, llamadas,…)?
¿Cómo podemos cambiarlos?
Esta estrada, al final la he dividido en dos. Os adjunto los links a las dos partes; Est a primera más itroductoria y la segunda más práctica y donde generamos una aplicación de ejemplo funcional.
Lo primero es saber cómo podemos acceder a esta información utilizando las clases de Android. Si revisamos la API de Android llegamos a la clase AudioManager, que es la que se encarga de estos menesteres (y algunos más).
La descripción de la clase dice lo siguiente:
«AudioManager provides access to volume and ringer mode control.»
Embarcadero MVP.
Analista y Programador de Sistemas Informáticos.
Estudios de Informática (Ingeniería Técnica Superior) en la UPC (Universidad Politécnica de Barcelona).
Llevo utilizando Delphi desde su versión 3. Especialista en diseño de componentes, Bases de Datos, Frameworks de Persistencia, Integración Continua, Desarrollo móvil,…
Ya he hablado anteriormente de varios sistemas y paquetes de componentes para internacionalizar aplicaciones en el blog. Por ejemplo, aquí y aquí. A raiz de un comentario de otro usuario, esta vez, por necesidad en este proyecto (IBCC) he decidido probar los componentes DKLang.
A primera vista me han sorprendido, pues cuenta con versión para XE5 incluyendo aplicaciones móviles (Android/iPhone) así como para VCL y FMX. Más adelante hablaré de la versión para XE5 (versión 5), aunque en esta entrada y para este proyecto he usado la versión 3, que es la que soporta Delphi 6.
Para la compilación del componente, al menos en esta versión (Delphi 6), hacen falta los componentes TNT para unicode. Gratuítos y con código fuente que podéis bajar desde esta misma web o desde internet sin problemas.
La compilación e instalación de los packages se hace sin problemas. Basta con añadir un par de directorios al path para que encuentre los ficheros necesarios. Una vez instalado el package de diseño, ya me aparece el componente DKLanguageController en la pestaña de System.
He echado en falta algún manual sencillo para poder seguir a la hora de empezar con un proyecto nuevo. En la web y en la ayuda no hay nada que de una guía rápida de funcionamiento. Aun así, no lleva más de 10 minutos ver cómo se maneja el componente.
Todos los ejemplos que se incluyen están realizados utilizando los componentes TNT, aunque es fácil sustituirlos en el DFM por componentes estándar y el funcionamiento es correcto.
Embarcadero MVP.
Analista y Programador de Sistemas Informáticos.
Estudios de Informática (Ingeniería Técnica Superior) en la UPC (Universidad Politécnica de Barcelona).
Llevo utilizando Delphi desde su versión 3. Especialista en diseño de componentes, Bases de Datos, Frameworks de Persistencia, Integración Continua, Desarrollo móvil,…
La mayoría de dispositivos Android (teléfonos y tablets) actuales cuentan con un gran número de sensores, de diferentes tipos y de variada funcionalidad. Algunos más conocidos que otros y algunos más útiles que otros.
La idea de esta entrada y de las siguientes es mostrar cómo funcionan y cómo acceder a la información que nos proporcionan los diferentes sensores presentes.
Los sensores presentes en el dispositivo se gestionan utilizando la clase TSensorManager, que se encuentra en la unit System.Sensors. Además podemos encontrar otras units que completan las definiciones para cada una de las plataformas destino (System.IOS.Sensors, System.Win.Sensors, System.Mac.Sensors,…)
Embarcadero MVP.
Analista y Programador de Sistemas Informáticos.
Estudios de Informática (Ingeniería Técnica Superior) en la UPC (Universidad Politécnica de Barcelona).
Llevo utilizando Delphi desde su versión 3. Especialista en diseño de componentes, Bases de Datos, Frameworks de Persistencia, Integración Continua, Desarrollo móvil,…
He actualizado el contenido de la web en DropBox para que estén en todo momento accesibles los ejemplos, artículos, documentación,… Más detalles de todo ello en esta entrada.
He incluido los últimos ficheros añadidos a las entradas, la última versión de las librerías GLibWMI y los últimos ficheros de otras secciones como la de las rxLib en este blog.
Si os vais a dar de alta os agradecería que usarais esta invitación, de esta forma a ambos nos ofrecen un poco más de espacio, que nunca va mal… ;-)
Embarcadero MVP.
Analista y Programador de Sistemas Informáticos.
Estudios de Informática (Ingeniería Técnica Superior) en la UPC (Universidad Politécnica de Barcelona).
Llevo utilizando Delphi desde su versión 3. Especialista en diseño de componentes, Bases de Datos, Frameworks de Persistencia, Integración Continua, Desarrollo móvil,…
Ya he hablado en otras ocasiones de cómo generar un aplicación multiidioma en Delphi y de paquetes tanto comerciales, como los componentes siComponents, como de código abierto como GNU GetText. En esta entrada hablaba de ambos y explicaba cómo acometer este proceso.
Hace tiempo había revisado el sistema de internacionalizar aplicaciones de Delphi (en este caso en la versión 6) y no me pareció muy intuitivo, tal vez también por falta de algo de documentación. Por lo que he visto en las versiones nuevas, pocas cosas han variado en el proceso y en las herramientas que trae el IDE.
En este caso me he visto obligado por las circunstancias a utilizarlo, y aunque a priori me ha resultado un poco “confuso”, como en su momento, una vez puesto en marcha, el sistema la verdad es que no es complejo y funciona de forma bastante sencilla. Se echa en falta que determinados aspectos sean un poco más potentes, como el editor de traducciones o el repositorio y la forma en que funcionan. Estos dos elementos realizan su función pero son bastante básicos en comparación con otros paquetes que hay en el mercado.
El sistema de traducción de Delphi, se basa en añadir todos los recursos traducidos a una DLL; Una para cada idioma que necesitamos añadir a nuestra aplicación.
EL PROYECTO
Para ver el proceso completo de internacionalización crearemos un proyecto sencillo, con dos formularios y veremos que es relativamente rápido montar toda la estructura para que funcione en varios idiomas.
Algunas etiquetas, un memo con algunos strings, unos botones y un segundo formulario para comprobar un ejemplo con más de uno y un TComboBox que nos permitirá modificar el idioma en tiempo de ejecución.
Una vez que tenemos nuestro proyecto funcionando, comencemos el proceso para añadirle dos nuevos idiomas, en este caso el catalán y el inglés, al que ya tiene por defecto (español o castellano).
INTERNACIONALIZACIÓN
Para ello lo primero que debemos hacer es añadir los 2 nuevos idiomas desde el menú de Project.
en la imagen inferior podéis ver las pantallas del asistente, aunque no tiene ninguna complicación y lo que hacemos con él es añadir los idiomas (tantos como necesitemos) a la aplicación.
Una vez finalizado el asistente, veremos que el IDE ha generado dos proyectos más (en nuestro caso) correspondientes a los idiomas que hemos seleccionado.
Podemos probar a compilar y grabar todos los proyectos.
Lo siguiente es comenzar a traducir las cadenas para poder utilizar múltiples idiomas en la aplicación. El editor de cadenas es similar a muchas otros aplicaciones que hay para esta función. Se trata de una pantalla que nos muestra las cadenas actuales y donde debemos introducir las cadena introducidas.
Para acceder al “Translation Manager” podemos hacerlo desde el menú en: “Project / Languages / Update resource DLLs”.
En esta pantalla vemos a la izquierda la estructura del proyecto y los diferentes formularios que lo componen. A la derecha la zona que nos permite traducir las diferentes cadenas. Hay columnas que identifican el elemento (ID), la que contiene las cadenas en el lenguaje original de la aplicación y la que contendrá las cadenas traducidas, en este caso con el título de “Inglés (estados Unidos)”.
He marcado en rojo una cadena que ya aparece traducida automáticamente (&Cerrar – &Close). Este es debido a que esta cadena ya está traducida en el repositorio.
EL REPOSITORIO
El “Transation Repository” o “Repositorio” es como un diccionario de traducciones que podemos ir ampliando a medida que traducimos aplicaciones. De esta forma, podemos reutilizar las cadenas que ya hemos traducido anteriormente (en la misma aplicación o en otras). En el ejemplo que estamos viendo, mi repositorio ya tiene incluida la traducción desde el Español (internacional) al Inglés (Estados unidos) de la palabra &Cerrar. Por eso al acceder a las traducciones, esta palabra ya aparece traducida.
El repositorio nos permite acelerar la traducción de términos. Además posee opciones para importar y exportar traducciones, con lo que podemos compartirlos o incluso utilizar herramientas de traducción automáticas externas e importar las traducciones a él.
Una vez que las cadenas están traducidas para los formularios podemos añadirlas al repositorio desde el “Translation Manager” , para tenerlas disponibles más adelante.
EJECUCIÓN
Una vez traducidas y añadidas al repositorio todas las cadenas de los diferentes idiomas, compilamos los proyectos, tanto el original, como los de los diferentes idiomas.
Para probar la ejecución, podemos seleccionar desde el menú de “Project” cual es el idioma que queremos por defecto. Si probamos con alguno de los 2 idiomas y ejecutamos, veremos que efectivamente la aplicación, como era de esperar.
Por último, nos quedaría ver cómo modificar el idioma durante la ejecución de la aplicación. Es bastante simple y para ello hay una sección en la ayuda del propio Delphi a la que podéis acceder; Dentro de la «internacionalización de aplicaciones» hay un tema concreto llamado «Dynamic switching of resource DLLs». Allí se puede leer que basta con añadir la unit Reinit en el uses, y utilizar una línea como la siguiente para cambiar el idioma.
// Cargar los recursos y releer los formsif(LoadNewResourceModule(lang) < >0)thenbegin
ReinitializeForms;end;
// Cargar los recursos y releer los forms
if (LoadNewResourceModule(lang) < > 0) then begin
ReinitializeForms;
end;
Comentar que si en alguna versión de Delphi, no encontráis la unit ReInit, podéis buscar dentro del directorio de Demos.
Al final el código que hay más arriba va a ser el único que vamos a necesitar en la aplicación.
Embarcadero MVP.
Analista y Programador de Sistemas Informáticos.
Estudios de Informática (Ingeniería Técnica Superior) en la UPC (Universidad Politécnica de Barcelona).
Llevo utilizando Delphi desde su versión 3. Especialista en diseño de componentes, Bases de Datos, Frameworks de Persistencia, Integración Continua, Desarrollo móvil,…
Esta es otra de las nuevas características que se anuncian en el nuevo Delphi XE2. A priori con el nombre me hago una idea de lo que puede ser y se que hay otros lenguajes que poseen características similares (si es lo que yo me pienso).
De todas formas, como no lo tengo claro, me he puesto a buscar qué hay sobre esta palabra…
______________________________________________
“…permite conectar cualquier elemento visual a cualquier tipo de datos utilizando LiveBindings ™”
______________________________________________
“LIBÉRATE DE LAS REJILLAS | VISUALIZA DATOS VIVOS
El nuevo LiveBindings de Delphi te permite conectar cualquier fuente de datos a cualquier interfaz de usuario o elemento gráfico VCL o FireMonkey.
LiveBindings te da la potencia y libertad creativa para presentar datos a usuarios en las formas más intuitivas e interactivas.
LiveBindings también incluye expresiones, dándote la increíble potencia y flexibilidad para construir “dinámicamente” enlaces a datos calculados y actualizados.”
______________________________________________
“¡Nuevo! Conecta cualquier elemento visual a cualquier tipo de dato con LiveBindings”
______________________________________________
Bueno, no se si con eso os he aclarado algo más. Al menos una idea sí parece que nos da de los que pueden ser.
Los LiveBindings permiten completar y ampliar las posibilidades de visualizar datos que nos provee la VCL (y sobre todo los componentes de Base de Datos). Hace unos años, arrastrar un componente DBEdit sobre un formulario, asignarle un DataSource y desde ahí “engancharlo” a un campo de una tabla/consulta era lo más. Ha pasado el tiempo y las tecnologías van cambiando (y también las necesidades).
No es que este modelo ya no sirva, pero sí que en algunas ocasiones queda un poco “corto” o un poco “cuadriculado” (pensemos en desarrollos por capas). La solución en estos casos pasaba por utilizar código para salvar esas limitaciones. Ahora esa parte puede quedar mucho más simplificada.
Podemos dividir los LiveBindings (LB) en tres varios tipos, dependiendo de los tipos de elementos que vayan a relacionar.
TIPOS DE LIVEBINDINGS
TBindScopeDB
Nos permite “conectar” componentes con DataSets; Utilizando el Inspector de objetos o el asistente, podemos definir como “proveedor de datos” los elementos de un Dataset y como “destino” cualquier componente.
Un ejemplo pasa a paso de utilización de TBindScopeDB podría ser el de un formulario con componentes DB (pero sin ellos –vamos a utilizar los estándar-).
Para ellos crearemos una nueva aplicación FireMonkey y colocaremos los componentes normales para realizar una conexión a Base de Datos (en mi caso he utilizado ADO). Para mostrar los Datos utilizaremos un TStringGrid.
Para mostrar los datos utilizaremos un TBindScopeDB, aunque no hace falta arrastrar el componente desde la paleta (aunque se puede hacer) porque podemos hacerlo utilizando las opciones del menú utilizando el asistente.
Si seleccionamos en Grid, tanto en el menú contextual, como en la parte inferior del “Object Instector” aparece la opción “Link to DB DataSource”. El propio wizard ya nos muestra las fuentes de datos disponibles para poder seleccionar la que queramos.
Una vez hecho esto, veremos que el asistente ha hecho todo trabajo por nosotros.
Por un lado ha creado 2 componentes nuevos:
BindingScopeDB1: El comentado que nos permite “linkar” una fuente de datos con componentes de edición estándar (en nuestro caso).
BindingsList1: Es el componente que almacena toda la lista de “Bindings” que vamos a ir creando para este formulario. En este momento sólo posee uno, pero añadiremos más (más adelante los veremos en detalle).
Vamos ahora a utilizar componentes de edición estándar para mostrar los datos que aparecen en el grid; En este caso 2 TLabel y dos TEdit (TEdit y TCalendar) para los campos de código de empleado y fecha. Los labels los utilizaremos para visualizar el título de los campos (propiedad DisplayLabel –no sólo los podemos utilizar con los datos, sino con cualquier otra propiedad-) de cada campo.
Para el Label, lo que necesitamos hacer es “linkar” la propiedad Text del Label, con la propiedad DisplayLabel del campo EmpNo de la Base de Datos (cuya propiedad DisplayLabel tiene el valor “Código”, como se puede ver en la imagen del Grid).
Para esto utilizaremos un TBindExpression.
Desde el propio “Object Inspector” podemos configurar cómo queremos que funcione. Por un lado El TLabel y su propiedad Text y por otro lado el TFieldEmpNo y su propiedad DisplayLabel, tal y como se ve en la imagen siguiente.
Una vez configuradas las opciones, ya vemos que automáticamente el cambio se ve reflejado en el Label. Si modificamos la propiedad del TField (por ejemplo para mostrarla en otro idioma), automáticamente se modificará el texto del Label.
Para el campo de Edición podemos seguir los mismos pasos que hemos realizado para el Grid, seleccionando el campo que queremos mostrar; Y de la misma forma para el segundo Label y para el TCalendarEdit que mostrará la fecha.
Una vez concluido esto, podemos revisar qué contiene nuestro componente BindingsList1.
Como era de esperar, contiene los 5 “Links” que hemos realizado en nuestro formulario. Podemos ver el nombre del componente y a la derecha una pequeña descripción de cada unos de ellos; Si accedemos (para ver más detalles) por ejemplo, al “binding” del componente de Fecha, veremos la siguiente pantalla (corresponde a lo que hemos configurado en el Inspector de objetos).
Nos dice que el control CalendarEdit1, en su propiedad Text, recibe notificaciones (assign to control -operation-) desde BindScopeDB1,HireDate en su propiedad DisplayText.
El resultado es bastante simple y en este caso no os puedo poner código de ejemplo, Al menos aquí pegado, porque todo se hace sin teclear nada (eso es bueno ¿no? ;-))
Todo el proyecto posee las siguientes líneas:
procedure TForm1.Button1Click(Sender:TObject);begin// cerrarSelf.Close;end;procedure TForm1.Edit3Click(Sender:TObject);begin// Abrir una web
ShellExecute(Handle,'open',PChar(Edit3.Text),nil,nil,0);end;procedure TForm1.Image1Click(Sender:TObject);begin// Animación del titulo
Layer3D1.AnimateFloat('RotationAngle.Y',360,6);end;
procedure TForm1.Button1Click(Sender: TObject);
begin
// cerrar
Self.Close;
end;
procedure TForm1.Edit3Click(Sender: TObject);
begin
// Abrir una web
ShellExecute(Handle, 'open', PChar(Edit3.Text), nil, nil, 0);
end;
procedure TForm1.Image1Click(Sender: TObject);
begin
// Animación del titulo
Layer3D1.AnimateFloat('RotationAngle.Y', 360, 6);
end;
Os animo a que reviséis el proyecto y hagáis vuestras pruebas. Al principio es todo nuevo y cuesta un poco, pero a medida que uno se acostumbra el procedimiento se vuelve bastante ágil.
Embarcadero MVP.
Analista y Programador de Sistemas Informáticos.
Estudios de Informática (Ingeniería Técnica Superior) en la UPC (Universidad Politécnica de Barcelona).
Llevo utilizando Delphi desde su versión 3. Especialista en diseño de componentes, Bases de Datos, Frameworks de Persistencia, Integración Continua, Desarrollo móvil,…
Usamos cookies para asegurar que te damos la mejor experiencia en nuestra web. Si continúas usando este sitio, asumiremos que estás de acuerdo con ello.Aceptar
INTRODUCCIÓN
Cuando registramos nuestra DLL (regsvr32) necesitamos modificar algunos valores en el registro de Windows para indicar al sistema que tiene una DLL disponible para utilizar cuando se le solicite una vista previa de un archivo con extensión AAA.
La idea de esta serie de entradas es ver todos los pasos necesarios para generar desde cero una DLL de Previsualización para Windows, de un determinado tipo de ficheros.
Para el Label, lo que necesitamos hacer es “linkar” la propiedad Text del Label, con la propiedad DisplayLabel del campo EmpNo de la Base de Datos (cuya propiedad DisplayLabel tiene el valor “Código”, como se puede ver en la imagen del Grid).
