El motor de interpretación ActiveX Script, tiene que implementar la interfaz IActiveScript. Cuando el hospedero crea una instancia del motor de interpretación, llama a la función SetScriptSite de esta interfaz, para establecer el puente de interacción hospedero-motor de interpretación.

A continuación veamos una breve descripción de cada uno de los miembros de la interfaz IActiveScript

El motor de interpretación permite controlar la funcionalidad básica de la ejecucion del guion; pero si soporta guiones textuales y evaluación de expresiones textuales compatibles con el lenguaje, entonces tiene que implementar la interfaz IActiveScriptParse.

La interfaz IActiveScriptParse constituye el analizador sintáctico del lenguaje interpretado y el ejecutor de las instrucciones del guión del motor de interpretación. El puntero a esta interfaz se obtiene llamando el metodo QueryInterface de IActiveScript. Los miembros fundamentales de la misma son:

La función ParseScriptText ejecuta el analisis sintáctico de acuerdo a las banderas de control que se establezcan en su llamada. Esta función tiene la siguiente sinopsis:

El parámetro dwFlags, determina el procesamiento y puede ser cualquiera o una combinacion de las siguientes constantes:

El parámetro pexcepinfo apunta a una estructura para recibir la informacion de excepcion, que llenada si la funcion ParseScriptText retorna el valor DISP_E_EXCEPTION.

Se puede construir una aplicación rudimentaria que actúe de hospedero de los motores de interpretación. El código que acompaña este artículo, tienen las fuentes completas del ejemplo que explicamos a continuación. Para crear el hospedero, creemos una nueva aplicacion en Delphi. Incorporemos un componente Memo1 del tipo TMemo, para la edición de los guiones. Adicionemos un componente TMenu con al menos un elemento TMenuItem para ejecutar el guión editado asociado al siguiente codigo:

El código ha sido abundantemente comentado para permitir identificar claramente los pasos explicados para la implementación de la tecnología ActiveX Script en una aplicación.

ir al índice

Microsoft(r) Windows(r) Scripting Host es un hospedero de guiones de ejecución independiente del lenguaje para motores de interpretación ActiveX™ en plataformas Windows de 32 bits.

Las plataformas de Microsoft Windows(r) 98, Windows NT(r) Workstation versión 5.0 y Windows NT Server versión 5.0 soportan este hospedero de guiones de ejecución. La propia compañía ya ha incluído los motores Microsoft(r) Visual Basic(r) Scripting Edition (VBScript) y Microsoft(r) JScript™. Otras compañías de proporcionarán otros motores ActiveX™ para lenguajes como Perl, TCL, REXX, Python y otros.

Este hospedero presenta baja ocupación de memoria durante la ejecución directa de los guiones, las secuencias de comandos no necesitan estar incrustadas en un documento HTML y es ideal para implementar comandos no interactivos que realicen tareas administrativas y de inicio de sesiones.

Windows Scripting Host utiliza la extensión del archivo de comandos para determinar qué motor de secuencias de comandos debe utilizar. Como resultado, quien escribe secuencias de comandos no necesita obtener el ID de motor de secuencias de comandos. El hospedero mantiene por sí solo, una asignación de extensiones de secuencias de comandos con ID de los motores y utiliza el modelo de asociación de Windows para iniciar el motor apropiado para la secuencia de comandos dada.

Windows Scripting Host expone nueve objetos globales de los cuales sólo tres están disponibles para los guiones de ejecución. Estos son WScript, WshArguments y WshShell. Las propiedades y metodos de los mismos quedan fuera del alcance de este articulo. El lector interesado, puede encontrar la documentacion de referencia en la ayuda del Personal Web Server de Windows 98.

En Windows 98 puede correrse desde la consola un guión de ejecución con el utilitario CSCRIPT.EXE. En la carpeta SAMPLES\WHS dentro del directorio de instalación de Windows 98, encontrará el archivo SHOWVAR.VBS, que es un guión de ejecucion en VBScript. Revise su contenido con el utilitario NOTEPAD.EXE. Para correrlo, haga doble CLICK sobre el mismo o ejecute desde la opcion EJECUTAR del menú de inicio la siguiente linea de comando,

CSCRIPT SHOWVAR.VBS

ir al índice

El ambiente de Delphi, está concebido fundamentalmente para desarrollar aplicaciones que soportan el ambiente gráfico de Windows de forma rápida, sin embargo, existe un conjunto de aplicaciones que no requieren de una interfaz gráfica que Delphi construye muy eficientemente también. En este artículo, vamos a examinar las aplicaciones de tipo consola, que son programas que se caracterizan por ser rápidos y el tamaño del ejecutable es pequeño.

Las generalidades

Las aplicaciones de consola, son programas escritos sin hacer uso de una interfaz gráfica de usuario.

En Windows, las aplicaciones de consola se ejecutan en una ventana especial basada en texto, conocida como la ventana de consola, a través de la cual se realiza la interacción con la aplicación. Los dispositivos estandares de entrada y salida de texto, están automáticamente asociados a esta ventana de consola.

Delphi no crea una nueva forma cuando crea una aplicación de tipo consola. Los controles visuales de la VCL no son generalmente empleados en una aplicacion de tipo consola, sin embargo, pueden ser usados.

El progama más simple de una aplicación de tipo consola que usted puede compilar en Delphi y correr desde la línea de comando es el siguiente:

Program Consola

{$APPTYPE CONSOLE}

Begin
  Write( 'Hola a todos' );
End.

La primera línea, declara el nombre del programa, que tiene que ser igual nombre del fichero en que se guarda la aplicación con extensión PAS. La directiva {$APPTYPE CONSOLE} instruye al compilador que construya una aplicación del tipo consola. Esta directiva, tiene sólo sentido para un programa y no debe se usada en una librería, package o unit. Debemos resaltar, que las aplicaciones de consola, son programas de 32 bits dentro del ambiente de Delphi.

El contenido de lo que hay que ejecutar dentro del programa, se enmarca entre el begin y end. En este ejemplo, el programa simplemente escribe una cadena al dispositivo estandard de salida (ie. el monitor de la computadora).

El procedimiento Write, está definido en la unidad SYSTEM y es implícitamente importada en todos los programas. En Delphi 4, el ejecutable de este programa compilado tendrá un tamaño de fichero de 15.5 Kb. Compárelo contra el tamaño del programa más simple que puede construirse, usando una interfaz gráfica.

Las aplicaciones de consola, pueden dividirse en varios ficheros. En este caso, utilizaremos la claúsula Uses para indicar los ficheros que se incluyen en la aplicación. También, podemos incorporar recursos, en particular, es útil adicionar recursos de versión. Esto se realiza adicionando la directiva {$R *.RES}.

Una forma alternativa y equivalente de indicar, dentro del ambiente de Delphi, que estamos compilando una aplicación de tipo consola, es con la opción Generate Console Application del LINKER. Personalmente preferimos, hacerlo explícitamente con la directiva antes señalada.

Las particularidades

En la unidad SYSTEM, está declarada una variable lógica, IsConsole, que puede ser usada para examinar en tiempo de ejecución, si el programa que está corriendo es una consola o tiene interfaz gráfica y tomar las acciones correspondientes.

El tamaño pequeño de las aplicaciones consola, está vinculado a no usar la unidad Forms. Si en el ejemplo inicial, adicionaramos la línea,

Uses Forms;

el tamaño del ejecutable generado, cambiaría a 271 Kb. O sea, la aplicación incrementa el tamaño del ejecutable en más de 17 veces. El único argumento, por el cual desearíamos adicionar la unit Forms a una aplicación de consola, sería para proporcionar acceso a la variable Application, que es una instancia del objeto TApplication. Así que, no incluya la unit Forms en sus aplicaciones de tipo consola.

Para acceder a la cola del comando, cuando se invoca una aplicación, podemos hacer uso de las funciones ParamCount y ParamStr.

La ParamCount, retorna el número de parámetros pasados a la aplicación en la cola del comando. Por su parte, ParamStr(n) retorna la n-ésima cadena de la cola del comando. ParamStr(0) siempre retorna el nombre de la aplicación con el camino completo desde la carpeta en que reside. Si el valor de n que se suministra es mayor que el valor retornado por ParamCount, entonces tendremos una cadena vacía.

Adicionalmente, la unidad System, suministra un conjunto de variables públicas muy útiles, que son inicializadas cuando se carga la misma y el conjunto de funciones básicas requeridas en cualquier aplicación: manipulación de cadenas, acceso a ficheros, operaciones con variants y manejo de memoria. Recomendamos que eche un vistazo a esta unidad.

Algo avanzado

Vamos a ver ahora, a través de un ejemplo sensillo, cómo una aplicación con interfaz grafica de windows interactúa con una aplicación de consola.

La aplicacion con interfaz gráfica MiGUI

Esta aplicación muestra en su interfaz un botón para lanzar la aplicación de consola, una caja de edición para establecer los parámetros del comando de consola que se va a invocar y un control MEMO para mostrar el resultado.

La aplicacion de consola MiCon1

La aplicación de consola es muy sencilla. Simplemente realiza la suma de dos números suministrados en la cola de comando y escribe el resultado.

El esquema funcional de interacción de ambas aplicaciones es el siguiente:

• La aplicación de Windows, MiGUI, lanza la aplicación de consola MiCon1, pasándole por la cola de comando los parámetros funcionales (dos números que se van a sumar).
• La aplicación de consola, MiCon1, ejecuta su trabajo y escribe al dispositivo de salida estandard, el resultado.
• La aplicación MiGUI, captura la salida de la aplicación de consola y la muestra en su interfaz.

Asociado al botón de lanzar de la aplicación MiGUI se tiene el siguiente código, que ha sido abundantemente comentado para facilitar su comprensión:

procedure TForm2.Button1Click(Sender: TObject);
const
  BufSize = $4000;
var
  si : TStartupInfo;
  pi : TProcessInformation;
  ec, attr, BytesRead : DWORD;
  WriteHandle, ReadHandle : THandle;
  ConsoleOut : string;

      procedure TerminarConsola;
      begin
        Button1.Enabled := True;
        CloseHandle( ReadHandle ); // Cerrar los handles del pipe
        CloseHandle( WriteHandle );
      end;
begin
  // Creamos un pipe anonimo cuyo extremo de escritura vamos a
  // utilizar como dispositivo de salida del proceso de consola
  // que se va a lanzar. El buffer del pipe tiene que ser suficientemente
  // grande como contener la salida del proceso de consola.
  if not CreatePipe(ReadHandle, WriteHandle, nil, BufSize) then Exit;

  // Inicializar la estructura de informacion de arranque del proceso
  FillChar(si, SizeOf( TStartupInfo ), 0);
  si.cb := SizeOf( TStartupInfo );

  // Establecemos los dispositivos de salida y error de proceso de consola
  si.hStdOutput  := WriteHandle;
  si.hStdError   := WriteHandle;

  // Establecer la prioridad del hilo de ejecucion de la aplicacion de consola
  // Variantes: IDLE_PRIORITY_CLASS, HIGH_PRIORITY_CLASS, REALTIME_PRIORITY_CLASS
  attr := DETACHED_PROCESS or NORMAL_PRIORITY_CLASS;

  // Indicar que se atienda los valores pasados en el miembro wShowWindow y
  // los handles suministrados en la estructura
  si.dwFlags     := STARTF_USESHOWWINDOW or STARTF_USESTDHANDLES;
  // Indicar la forma en que se muestra la aplicacion lanzada
  // Variantes: SW_SHOWNORMAL, SW_MAXIMIZE, SW_MINIMIZE
  si.wShowWindow := SW_HIDE;

  // La funcion CreateProcess, crea un nuevo proceso donde ejecuta el fichero
  // ejecutable especificado.
  ConsoleOut := Edit1.Text; // Ejecutable a lanzar
  try
    if not CreateProcess(nil,	// lpApplicationName (nil para consolas)
             PChar(ConsoleOut),  // Ejecutable de consola y cola de comando
             nil,		// LPSECURITY_ATTRIBUTES
             nil,		// LPSECURITY_ATTRIBUTES
             FALSE,	// bInheritHandles
             attr,         // dwCreationFlags
             nil,	   	// lpEnvironment
             nil,		// lpCurrentDirectory
             si,		// lpStartupInfo
             pi )		// lpProcessInformation

    then // Si la aplicacion de consola no es lanzada, retornar
    begin
      TerminarConsola;
      Exit;
    end;
  except
    TerminarConsola;
    Exit;
  end;

  // Evitar recurrencia al lanzar la aplicacion de consola
  Button1.Enabled := False;

  // Ciclo para esperar que la aplicacion de consola termine su trabajo
  Repeat
    if not GetExitCodeProcess(pi.hProcess, ec) then
    begin
      TerminarConsola;
      Exit;
    end;
    Application.ProcessMessages;
  Until (ec <> STILL_ACTIVE);

  try
    // Leer del pipe, la informacion escrita por la aplicacion de consola
    SetLength(ConsoleOut, BufSize);
    ReadFile( ReadHandle, ConsoleOut[1], BufSize, BytesRead, nil );
    SetLength(ConsoleOut, BytesRead);

    // Copiar al memo, el texto retornado por la aplicacion de consola
    Memo1.Lines.Text := ConsoleOut;
  finally
    TerminarConsola;
  end;
end;

El ejemplo es muy sencillo; pero permite imaginar su alcance. En primer lugar, la aplicación que sostiene la interfaz gráfica y la aplicación de consola, se ejecutan automáticamente en dos hilos de ejecución diferentes. En un ambiente multitarea y multihilo como Win32, se pueden establecer prioridades diferentes para cada aplicación. La aplicación de consola se ejecuta sin ser mostrada. Si ésta cae en un ciclo de ejecución prolongado, desde la aplicación con interfaz puede cancelarse la misma o inclusive ejecutar otras cosas.

Construya la aplicación MiGUI (las fuentes están construidas con Delphi 4) suministrada con este artículo y ejecute a través de ella, el siguiente ejemplo de aplicación de consola, que es parte del sistema operativo:

mem /c

Interesante, ¿ Verdad ?

   ir al índice

En el Explorador de Windows, cuando pinchamos con el botón derecho del ratón sobre un fichero con extensión BMP, automáticamente emerge un menú, en una de cuyas opciones encontraremos Abrir. Si seleccionamos esta opción, se abre la aplicación Paint mostrando la imagen contenida en el fichero para ser editada. Esta funcionalidad, se logra con la asociación de tipos de ficheros a las aplicaciones que son capaces de cargarlos para ejecutar algún trabajo con él.

La asociación de ficheros a una aplicación es conocida desde Windows 3.1, donde bastaba adicionar en la sección Extensions del fichero del sistema WIN.INI, la siguiente línea:

BMP=C:\WINDOWS\PAINT.EXE   ^.BMP

Pero, en la plataforma Win32, el soporte de WIN.INI solamente es mantenido por compatibilidad con las versiones anteriores. En Windows 95, Windows 98, Windows 2000 y Windows NT, el registro de Windows es el repositorio donde se almacena la información de asociación de ficheros con una aplicación, ahora extendida con un modificador llamado verbo (verb), que califica la acción a ejecutar sobre el mismo. 

El verbo indica la acción que la aplicación asociada debe realizar sobre el documento contenido en un fichero. Existen tres verbos clásicos: Open, utilizado para abrir y visualizar el documento, Edit utilizado para abrir el documento en modo de edición y Print, utilizada para mandar el documento a la impresora predeterminada en el sistema.

El procedimiento de asociar un tipo de fichero a una aplicación se realiza en dos pasos:

1. Inscribir el tipo de documento utilizando la extensión del fichero que lo contiene en el Registro de Windows, con la clase de una aplicación, que implicitamente lo va a manipular.
2. Registrar la clase de la aplicación que es capaz de abrir un documento y los verbos para el Shell de Windows, con los cuales es capaz de actuar sobre el documento.

En lo adelante, supondremos que las operaciones con el registro de Windows, se realizan bajo al llave HKEY_CLASSES_ROOT

Para realizar el primer punto, debemos añadir una llave con el nombre de la extensión del fichero (incluyendo el punto precedente de la extensión), bajo la cual estableceremos una llave con el nombre default a la que asociaremos como valor el nombre de la clase de la aplicación. Usualmente, se utiliza como nombre de clase de una aplicación, el nombre de la misma, seguida de un punto y la palabra Document. Así, en el editor del registro de Windows, se vería:

HKEY_CLASSES_ROOT\ 

.ext\ 

Default = "MiApp.Document"

Para registrar la clase de la aplicación, hay que crear una llave con MiApp.Document. Bajo esta llave, se especifican las acciones que se ejecutan desde el Shell de Windows, donde cada acción visible es una clave cuyo valor es la cadena del comando para ejecutar dicha acción. En el registro de Windows, debe quedar algo como esto,

HKEY_CLASSES_ROOT\

MiApp.Document\

Shell\

Open\Command\Default="MiAppPath\MiApp.exe %1"

Edit\Command\Default="MiAppPath\MiApp.exe %1"

Print\Command\Default="MiAppPath\MiApp.exe /p %1"

En el ejemplo a continuación se muestra el código completo de una unit, que contiene el procedimiento RegisterAssociation, que le permite asociar un tipo de fichero a su aplicación, que adicionalmente incorpora el icono principal de la aplicación a las metáforas gráficas que son mostradas en el Explorador. Simplemente, incorpore la llamada a este procedimiento con cuanto tipo de fichero usted quiera asociar a su aplicación dentro del evento de CreateForm de la forma principal de su aplicación.

Muchas veces puede suceder que a varios nos parezca demasiado grande el .EXE generado por Delphi, y realmente lo es. ¿Por qué ? ¿Cómo evitarlo ? Estas son algunas de las cosas que debemos tener en cuenta al desarrollar una aplicacion hecha en Delphi y queremos que funcionen con el máximo de optimización y eficiencia posibles.

Desde los antiguos programas de MS-DOS generados en Turbo Pascal ó C, a muchos de nosotros nos gustaban usar las famosas librerías TVision ó Turbo Power para darle belleza y colorido a nuestras aplicaciones. Esto por supuesto tenía el inconveniente de mientras más unidades (units) usábamos, mas grande se nos hacia el .EXE resultante.

Con la llegada de Windows al mercado, la programacion tradicional de MS-DOs quedó obsoleta y entró un nuevo modo de programar el cual abstraía mucho más a los usuarios de sus aplicaciones en general, se trataba del Sistema de manipulación de Mesjaes de Windows, en el que Windows es el que manda un mensaje a la aplicacion, la aplicación espera por ese mensaje y si lo conoce y tiene un manipulador de este mensaje, sencillamente le da respuesta. Con esta gran ventaja surgió adjunto el desarrollo de la Programación visual Orientado a Objetos que ya venía desde el Ms-DOS y surgieron las librerias de Windows llamadas API. Pero la API no era POO y tenía muchas dificultades al expresar cosas evidentes y muy sencillas, además del tiempo que el usuario gastaba en realizar una sencilla aplicación. Surgieron las MFC (Microsoft Fundation Class) que no son más que las mismas funciones de la API creadas por Microsoft pero ahora con POO y de Borland la VCL (Visual Component Library).

Por supuesto que a partir de ese momento todos los productos de Microsoft soportaban la API que era la librería que ya venía implicita en Windows. Por eso si se desarrolla una aplicacion con un producto de Microsoft, el EXE generado es relativamente más pequeño que si se hace con un producto Borland con la VCL, porque ya las DLLs de MFC están en Windows, mientras que la VCL no y hay que distribuirlas.

Como todos conocemos, Dephi es un compilador de código nativo, o sea, no nesesita ninguna DLL acompañada del .EXE para ejecutarse en una PC sacada de la caja.

Cuando instalamos Delphi, la primera vez que lo corremos el introduce dentro del .EXE las DLLs según las vaya usando. Usted toma ese .EXE y se va para cualquier lugar, lo corre y listo. Pero esto tiene el inconveniente que según se usen mas BPLs (Borland Package Library - Las DLLs de Borland) asi será mas grande el EXE resultante. La solución está en ir al menú Projects/Options/Packages, y poner el Check Box Build whot runtime Packages en TRUE. Esto hará que dentro del .EXE no se metan las BPLs, solo el código nesesario de nuestra aplicación. Los BPLs se distribuyen mediante una utilidad llamada Install shield que viene con Delphi y donde se le dice que BPL usará. Para saber las PBLs que usa nuestro proyecto basta con ir al menú Project/Information y allí veremos todas las BPLs que hay que poner en el Install Shield. Esto es una muy buena opción ya que si Ud. desarrolla varias aplicaciones en una misma PC, todas las aplicaciones usan una misma copia de las BPLs, ahorrando memoria, tiempo de instalación de Install Shield, porque el no sobreescribe la copia del BPL a menos que Ud diga lo contrario. De esta forma es más efectivo y beneficioso porque Build Whit runtime pachkages, como lo trae Delphi por defecto mete los BPLs dentro de nuestro EXE, cosa que no nos satisface.

Pero hay algo que quizás puede pasar inadvertido para algunos usuarios, sobre todo principiantes (a mi me pasó). Como todos sabemos, los componentes de la paleta de compoenetes de Delphi se agrupan en Páginas, c/u de estas páginas está asociada a un BPL en específico, por Ej: Standard - VCL40.BPL, adicional - VCLX40.BPL, Data Access y DataControls VCLDB40 y VCLDBX40.BPL respectivamente, QReport a QRP40.BPL y asi sucesivamente. Que quiere decir esto ?? Sencillo. Si usted usa un componente en Delphi, el le adciona a la clausula uses de la forma la unit a que pertenece el componente, por tanto si agrega un TTable agregará al uses DBTables si agrega un Navigator agregará un DB y usted estrá usando el VCLDB40 y VCLDBX40.BPL en su programa, porque el compilador se guia en as BPLs que uses por la unit en la cláusula uses. Pero cuando eliminamos un componete de nuestra forma, Delphi no le quita la unit de la cláusula uses, y entonces, aunque no tengamos una sola Tabla ó navigator en nuestra forma, si sus respectivas units están reflejadas en la forma, entonces el seguirá pidiendole las BPLs asociadas a estos compoenetes. Por tanto, es recomendable, cuando borremos algún componente si estamos seguros de que no usamos más esa unit para nada (Por eso Dephi no la borra del uses cuando borras un componente) que la ELIMINEMOS de la cláusula uses de nuestra forma. De cualquier manera, existe un componente en la Forma y usted borra su unit, el vuelve a agregarla al compilar. (Cada vez que compila chequea los componentes y las units de c/u de ellos).

Concluyendo:

Este es una de las posibles soluciones, hay para tratar de hacer nuestras aplicaciones eficientes y optimas, minimizando el tiempo de carga ejecucion y usando los recursos del sistema de forma más racional, ahorrando memoria (recuerden que al ejecutar un .EXE todo está en memoria), etc. También debemos optimizar internamente nuestro código y usar las facilidades que nos da el lenguaje Object - Pascal internamente y la POO.

Suerte...

ir al índice

(Nota: Los textos e ideas originales de esta exposición no son míos. En cada caso, se cita la fuente de donde extraje la información, que por curiosa, me pareció interesante hacerselas llegar)

Cuando se ejecuta un gran proyecto de software en un equipo, los programadores, gustan de dejar en el paquete alguna huella que revele su participación. Después de mostrar algunos ejemplos, vamos a relatar una técnica para lograr esto en nuestros proyectos en Delphi.

En el sitio www.ethek.com, podemos encontrar un reseña debida a Jesús Manuel Rodríguez, que nos explica la forma de ver los créditos del equipo de Windows 98.  

1. Menú de Inicio -> Panel de control -> Fecha y hora, o también hacer doble click sobre la hora en la barra de tareas.
2. Seleccionar temporalmente la zona horaria GMT +01:00 Bruselas, Conpenhague, Madrid, París, Vilnius
3. En la imagen del mapa mundi que está mostrada, poner el cursor en el punto 1, pinchar el ratón y  manteniendo oprimida la tecla Ctrl, arrastrarlo hasta el punto 2.
4. Soltar la tecla Ctrl .
5. Con el cursor sobre el punto 2, pinchar el ratón y  manteniendo oprimida la tecla Ctrl, arrastrarlo hasta el punto 3.
6. Soltar la tecla Ctrl .

Entonces, se abre la ventana que mientras carga otros recursos, muestra unos números en azul y luego los nombres y fotos del equipo de programación de Windows 98.

No es fácil lograr que se muestren los créditos del equipo de programación de Windows 98. Tendrá que intertarlo varias veces. Yo generalmente lo consigo a la tercera oportunidad. Bueno, lo que se muestra es una página WEB, que se abre temporalmente en el siguiente camino:

    Directorio de Windows\Application Data\Microsoft\Welcome

En el directorio SYSTEM, se encuentra una librería, MEMBG.DLL, que contiene los recursos mostrados en la página WEB, dinámicamente construida.

Otra forma alternativa de ver los nombres de los participantes en el proyecto Windows 98 es la siguiente.

1. Menú de Inicio -> Panel de control ->Pantalla, o también hacer click con el botón derecho sobre la pantall y seleccionar Propiedades
2. Seleccionar la pestaña "Protector de Pantalla".
3. Seleccionar el protector de pantalla "Texto 3D" y en activar la configuración. Escribir el texto "Volcano", aceptar y después hacer una vista previa.
4. Los nombres de las personas participantes en el equipo, irán alternandose uno a uno.

Veamos ahora una propuesta de hacer algo como esto. Bajo el título "Implementing an Easter Egg", por colaboracion de Michael Burton, en el número 38 (Abril de 1999) de la páginas de UNDU, se suministra un código que al ocurrir una combinación de teclas poco usuales, se activa un diálogo que puede servir para mostrar los créditos de los participantes en la construcción de un proyecto en Delphi.

Aquí reproducimos el código suministrado en el artículo (traducción mediante).

1. En la forma en que se desee activar los créditos del equipo, establezca la propiedad KeyPreview en True. Esto permite a la forma tener la entrada de teclado antes que el control activo en la misma. 

2. Crear dos variables privadas en la forma:

  eeCount: integer;
  sEgg: string;

La variable eeCount, cuenta los golpes de tecla para procesar la activación de los creditos de equipo. La variable sEgg contiene la secuencia de teclas entradas.

3. Crear dos constantes en la forma:

const
  EE_CONTROL: TShiftState = [ssCtrl, ssAlt];
  EASTER_EGG = 'RIMROCK';

EE_CONTROL contiene las teclas de control que deben estar oprimidas cuando el usuario quiere activar los créditos del equipo de programación. Pueden ser cualquier combinacion de ssCtrl, ssShift y ssALt, pero se debe usar cualquier combinacion que no interfiera con los controles en la forma.

4. En el evento OnCreate de la forma, hacer la siguiente inicialización:

eeCount := 1;
sEgg    := EASTER_EGG;

5. En el evento OnKeyDown de la forma implemente el siguiente código:

procedure TForm.FormKeyDown(Sender: TObject; var Key: Word; Shift: TShiftState);
begin
  {are the proper control keys down?}
  if Shift = EE_CONTROL then begin
    {was the proper key pressed?}
    if Key = Ord(sEGG[eeCount]) then begin
      {was this the last keystroke in the sequence?}
      if eeCount = Length(sEGG) then begin
        {Easter egg activation code goes here, e.g.,}
         ShowMessage('This is an easter egg');
          eeCount := 1; {failure - reset the count}
      end else begin
        Inc(eeCount); {success - increment the count}
      end;
    end else begin
      eeCount := 1; {failure - reset the count}
    end;
  end;
end;

Puede reemplazar la llamada a ShowMessage con lo que usted desee. Compile y pruebe.

Los programadores de Delphi, también han dejado sus huellas en los programas. Por ejemplo, en Delphi 1, si usted muestra la ventana de créditos (About box) y sosteniendo oprimidas las teclas Shift y Alt, teclea la palabra TEAM, veremos entonces los créditos de los programadores.

¿ Estará implementada esta curiosidad en las versiones posteriores, digamos en Delphi 3 o 4 ? Si usted lo conoce, hágamelo saber y muchas gracias por anticipado. 

ir al índice

Microsoft ha incorporado en su plataforma Windows, un nuevo tipo de ayuda, más en correspondencia con los desarrollos de Internet y nuevas formas de presentación y búsqueda de la información, que es la ayuda HTML compilada (HTML Help compiled). 

Hay 2 razones por la que los desarrolladores tenemos que prestar atención a la ayuda HTML compilada.

1. Es parte integrante de las nuevas versiones de Windows.
2. Suministra mayor funcionalidad y es más fácil de construir y mantener que la ayuda basada en ficheros HLP.

Para ver los ficheros de ayuda HTML compilada, se requiere tener instalado los siguientes componentes:

Si ha instalado Microsoft Internet Explorer 4 o superior, automáticamente estos componentes se habrán instalados. En Windows 98 y NT 5, ya se suministran como parte del sistema operativo.

En esta parte, queremos mostrar como se accede a los ficheros de ayuda compilada, desde una aplicación de Delphi. Primeramente abordaremos, de una forma muy general, el API de la ayuda compilada, explicaremos la forma en que se especifica una URL en un fichero de ayuda compilada y mediante ejemplos, mostraremos como desde un programa de Delphi se accede a la tabla de contenido, el índice, las búsquedas, y obtener ayuda sensible al contexto. Usted puede apoyarse, durante la lectura de este artículo, descargando la fuentes del programa de ejemplo suministrado.

Para construir la ayuda compilada, debemos usar el paquete MS HTML Help Workshop, que puede ser obtenido gratuitamente, descargandolo en Internet desde el sitio de Microsoft.

El API del HTML Help

El API de HTML Help, permite a los programas de Windows crear ventanas de ayuda y mostrar los tópicos de la ayuda, con un control completo sobre el tipo, estilo y posición de la ventana de ayuda.

También, la ventana de ayuda, puede emerger en un programa Windows sin uso de la tecnología OLE. Además, está implementado la ayuda sensible al contexto, búsqueda por palabras claves, interacción con los programas de Windows y control del panel de navegación en el visor de ayuda.

El API de HTMP Help tiene una sola función que muestra la ventana de la ayuda. A través de esta función usted puede especificar que tópico mostrar en la ventana de la ayuda, si es mostrado en una ventana emergente (popup), si el tópico es accesado a través de su ID, una palabra clave, un salto URL, etc.

Dependiendo del valor de uCommand especificado, esta funcion retorna:

• El handle a la ventana de ayuda.
• 0 (NULL). En algunos casos, esto indica fallo y en otros indica que la ventana de ayuda no ha sido creada.

Un listado de los comandos disponibles (parámetro uCommand de la función HtmlHelp) por categorías, es el siguiente:

El comando más importante es HH_DISPLAY_TOPIC, que permite abrir un fichero de ayuda compilada (CHM) en una ventana de ayuda y mostrar el tópico especificado dentro de este fichero. 

Para acceder al API de la ayuda compilada, hemos traducido al PASCAL el fichero HtmlHelp.h suministrado con el paquete de Microsoft. Usted encontrará este fichero con el nombre HHelp.pas en el archivo compactado que acompaña este artículo. En cada unidad en que haga acceso a la ayuda compilada, deberá incluir el mismo en la claúsula uses.

Las URL de ayuda compilada

En un fichero de ayuda HTML compilada, una URL especifica un fichero o un tópico y opcionalmente el tipo de ventana para mostrar la parte referenciada por la URL.

Para especificar una URL a un fichero de ayuda compilada, se hace como sigue:

          FicheroAyuda.chm[>nombre de Window] 

donde FicheroAyuda.chm es el nombre del fichero de la ayuda HTML compilada y nombre de Window, es el nombre de la ventana de ayuda donde se desea que aparezcan los tópicos.

Para especificar un tópico dentro de un fichero de ayuda compilada, se escribe:

          FicheroAyuda.chm::Topico.htm[>nombre de Window] 

donde Topico.htm, es el nombre del fichero HTML que se quiere mostrar en la ventana de la ayuda.

Si la ayuda compilada ha sido construida, preservando el camino de acceso a los ficheros HTML, entonces una URL a un fichero con estas características, se escribe:

          FicheroAyuda.chm::/Camino/Topico.htm[>nombre de Window] 

donde Camino, es la cadena de carpetas anidadas por la que se llega al fichero.

También es usual, anteceder estas URL con la partícula "ms-its:". Esta partícula, identifica un protocolo, registrado en Windows, similar a cuando en un navegador de internet escribimos "http://".

Así que en general, desde una página HTML, al referirnos a otra página HTML almacenada en un fichero de ayuda compilada, debemos escribir:

          ms-it:FicheroAyuda.chm::/Camino/Topico.htm[>nombre de Window] 

El visor de ayuda HTML compilada

La forma más inmediata y sencilla de ver un fichero de ayuda HTML compilada, es hacer doble CLICK sobre el nombre del mismo (extensión CHM) en el Explorador de Windows.

Desde nuestras aplicaciones, podemos ejecutar la siguiente línea de código, para obtener el mismo resultado:

El visor de la ayuda HTML compilada, es una ventana de tres paneles, como usted puede ver mientras lee los artículos del Taller de Delphi. 

Cada panel del visor, puede ser manipulado a través de la estructura HH_WINTYPE y el API de la ayuda HTML compilada; pero esto no presenta interés en esta exposición. 

Tabla de contenido e índice de la ayuda HTML compilada

En lo adelante, supondremos que en la propiedad HelpFile de nuestra aplicación, hemos establecido el nombre del fichero de ayuda HTML compilada.

Para obtener la tabla de contenido de la ayuda, ejecutamos el siguiente comando:

De la misma manera, para obtener el índice de la ayuda, ejecutamos el siguiente comando:

Búsquedas por palabras

Para comenzar una búsqueda podemos usar el siguiente procedimiento:

Si en la estructura HH_FTS_QUERY, establecemos el miembro fExecute en True, entonces al invocar la función HtmlHelp, se realiza la búsqueda solicitada. Si el miembro fTitleOnly se establece en True, la búsqueda se realiza solamente sobre los títulos de los tópicos de ayuda.

Obteniendo ayuda sobre un tópico

En la ayuda HTML compilada, un tópico se identifica con una página HTML. Si esto es conocido, se puede mostrar un tópico, suministrando al siguiente procedimiento, el nombre de la página donde está contenido. 

 

{Procedimiento para activar la ayuda contenida en una página determinada.} procedure MostrarTopico(Topico : string); begin   HtmlHelp(Handle,            PChar(Application.HelpFile + '::/' + Topico),            HH_DISPLAY_TOPIC,            0); end;

 

En Delphi, cada componente descendiente de TWinControl, tiene la propiedad HelpContext, que puede contener cualquier valor entero. Nuestro objetivo es mostrar la página que es referenciada por el valor de la propiedad HelpContext. Básicamente, un tópico de la ayuda se invoca, a modo de ejemplo, de la siguiente manera:

 

{ Al invocar la ayuda contextual, es requisito que el fichero de ayuda HTML compilada, haya sido construido llenando en la seccion MAP la asociacion de las cadenas contextuales con las páginas de la ayuda. En el fichero de cabecera tienen estar referidas igualmente las cadenas contextuales con los valores numericos de la ayuda contextual que usamos en el campo HelpContext de los controles.}    HtmlHelp(Handle,            PChar(Application.HelpFile),            HH_HELP_CONTEXT,            HelpContext);

 

Para que esto funcione correctamente, tenemos que seguir algunos pasos adicionales durante la construcción de la ayuda HTML compilada:

1. Construir el fichero asociación de las constantes simbólicas de la ayuda contextual y los valores numéricos de las mismas (fichero de inclusión). 
2. Adicionar en la sección MAP del proyecto de ayuda compilada, el nombre del fichero de inclusión.
3. Adicionar en la sección ALIAS del proyecto de ayuda compilada, la correspondencia entre las constantes simbólicas de la ayuda contextual y las páginas HTML contenedoras del texto del tópico de contexto. 

El fichero de inclusión, se construye incorporando para cada valor de contexto una línea, como se muestra en el siguiente ejemplo:

 

// Constantes para los tópicos de ayuda contextual #define IDH_MAIN        10000 #define IDH_PAGINA1  11000 #define IDH_PAGINA2  12000 #define IDH_POPUP      20000

 

Se acostumbra a llamar a este fichero de inclusión con el nombre CTXHelp.h y a que las constantes simbólicas comiencen con la partícula IDH_.

Para adicionar en la sección MAP, el nombre de fichero de inclusión, abrir con un editor de texto, ie. NOTEPAD.EXE, buscar la sección MAP y si no existe crear y poner el nombre del fichero. Esto quedará como se muestra a continuación:

El nombre del fichero de inclusión debe estar contenido, además, en el listado de ficheros de la ayuda HTML compilada, que se encuentra en la sección FILES del proyecto de ayuda.

Finalmente, la sección ALIAS debe ser constuída o de existir ya, adicionar una línea para cada constante simbólica asociada a una página de ayuda contextual, como se muestra en el siguiente ejemplo:

Dedicaremos otro artículo a la construcción de la ayuda HTML compilada y abundaremos más sobre en contenido del proyecto de ayuda. Por el momento, aceptemos esto como necesario para lograr el funcionamiento de la ayuda HTML en nuestros programas.