GeneXus Extension: Open Command Prompt

Algo que siempre pensé que le falta a GeneXus, es una opción para abrir una línea de comandos en el directorio de la base de conocimientos.

Ahora con GeneXus Rocha, tenemos la posibilidad de hacer nuestras propias extensiones, así que decidí implementarlo...

Las extensiones se desarrollan en Visual Studio 2005 (o con Visual C# 2005 Express a partir del build que subieron hoy), y se desarrolla en C#. El SDK cuenta con un wizard que crea una primer instancia del proyecto, lo cual facilita bastante el proceso.

En la versión actual del wizard hay una forma de agregar una opción de menú, que no estaba en la primer versión, por lo que ahora debería ser más fácil hacer esto. De todas formas, siempre es bueno saber como hacer las cosas "a mano".

El proyecto para VS2005 se puede descargar de GXOpen. Si alguien quiere solo incorporar la extensión a GeneXus, lo puede hacer copiando el archivo GXCmdPrompt.dll (que está en GXCmdPrompt\GXCmdPrompt\bin\Debug) a la carpeta Packages debajo de la instalación de GX Rocha, y reiniciar GeneXus.

Para agregar esta funcionalidad, fue necesario modificar varios archivos:

  • un archivo XML donde se definen los componentes de la extensión (GXCmdPrompt.xml),
  • un archivo .resx de recursos (GXCmdPrompt.resx),
  • dos clases para que la opción de menú pueda realizar acciones (CommandKey y CommandManager),
  • y una clase para el paquete (Package).

Veamos en más detalle como implementar esta extensión.

GXCmdPrompt.xml

Lo primero que debemos hacer es crear el archivo GXCmdPrompt.xml, que tiene lo siguiente:

<?xml version="1.0" encoding="utf-8" ?>
<Package xmlns:gx='http://schemas.genexus.com/addin/v1.0'
id="f0c16daa-a732-43a9-b3eb-2a40824975cf"
name="GXCmdPrompt" >
<Resources>
<Resource type="strings" name="MCrispino.Packages.GXCmdPrompt.GXCmdPrompt"/>
</Resources>

<Commands>
<CommandDefinition id="OpenCommandPrompt" />
</Commands>
<Menues>
<Menu type="menubar">
<Popup name="Extensions" insertBefore="Help" >
<Command refid="OpenCommandPrompt" insertBefore="CopyModel" />
</Popup>
</Menu>
</Menues>
</Package>

El tag Package tiene un atributo id, que debe ser (obligatoriamente) el GUID de la clase Package, que se genera automáticamente cuando creamos la extensión con el wizard. Además tiene un atributo name, que indica el nombre del paquete.

Dentro de Resources, deben ir todos los archivos de recursos, en este caso el único era GXCmdPrompt.resx, que está en el namespace MCrispino.Packages.GXCmdPrompt.

Dentro de Commands deben ir los comandos, en este caso solo tenemos OpenCommandPrompt.

Dentro de Menues se define la estructura de los menues que vamos a tener, en este caso en la barra de menues aparece la opción Extensions (<Popup name="Extensions") antes de la opción Help (insertBefore="Help"). Dentro de este menú aparece el comando OpenCommandPrompt.

Dos comentarios importantes con respecto a este archivo:

  • La propiedad Build Action debe decir Embedded Resource, para que el archivo quede dentro del assembly.
  • Es conveniente configurar el Schema, poniendo la ruta completa al archivo GXPackageDeclaration.xsd, para tener intellitips en la edición.

GXCmdPrompt.resx

En el archivo de recursos lo único que se definió fue el texto que debe aparecer en el menú. Es un archivo que tiene pares de (nombre, valor), en este caso la única entrada es name=OpenCommandPrompt (igual que el comando), value=Open Command Prompt.

Package.cs

La clase Package se crea por defecto cuando se genera el paquete con el wizard. No voy a mostrar el código completo, para que funcione es necesario crear dos métodos:

private void LoadCommandTargets()
{
AddCommandTarget(new CommandManager());
}

public override Artech.Packages.Definition.Package GetPackageDeclarations()
{
try
{
return GetPackageDeclarationsFromResource("MCrispino.Packages.GXCmdPrompt.GXCmdPrompt.xml");
}
catch (System.Exception e)
{
System.Windows.Forms.MessageBox.Show("Error loading package GXCmdPrompt:\n" + e.ToString());
return null;
}
}

Además hay que invocar al método LoadCommandTargets en el método Initialize. Este método es el que agrega la funcionalidad al paquete, creando la clase CommandManager y agregándola como Command target.

El método GetPackageDeclarations, carga las definiciones del archivo XML que se describió más arriba.

CommandKeys.cs

Aún no me queda muy claro para que se necesita esta clase, pero así funciona :). Lo que se definen acá son los comandos, que luego se usan en la clase CommandManager. Pienso que no es necesaria, y que se podría usar new CommandKey(Package.guid, "OpenCommandPrompt") donde se usa CommandKeys.OpenCommandPrompt...

En todo caso, el código es:

public class CommandKeys

{

private static CommandKey cmdPrompt = new CommandKey(Package.guid, "OpenCommandPrompt");

public static CommandKey OpenCommandPrompt { get { return cmdPrompt; } }

}

CommandManager.cs

Esta es la clase que hace la mágia, es la que le da vida a la opción de menú que agregamos.

El nombre de la clase en sí no es importante, lo que debemos tener en cuenta es que debe heredar de la clase CommandDelegator.

En el constructor tenemos:

public CommandManager()
{
AddCommand(CommandKeys.OpenCommandPrompt, new ExecHandler(ExecOpenCommandPrompt), new QueryHandler(QueryOpenCommandPrompt));
}

donde:

  • tenemos una llamada al método AddCommand, que es el que registra el comando
  • el primer parámetro es CommandKeys.OpenCommandPrompt, que es el comando que definimos en la clase CommandKeys
  • el segundo parámetro es el método que se va a invocar cuando se haga click en la opción, en este caso ExecOpenCommandPrompt
  • el tercer parámetro es el método que se va a invocar para determinar si la opción debe estar habilitada o no, en este caso QueryOpenCommandPrompt

El método ExecOpenCommandPrompt está definido como

public bool ExecOpenCommandPrompt(object[] parameters)
{
IKBService kbserv = UIServices.KB;
if (kbserv != null && kbserv.CurrentKB != null)
{
string kbDirectory = kbserv.CurrentKB.Location;

Process p = new Process();
p.StartInfo.FileName = System.Environment.GetEnvironmentVariable("comspec");
p.StartInfo.Arguments = "/K cd /D " + kbDirectory;
p.Start();
}

return true;
}

Lo que hace es fijarse el directorio de la KB (primero verifica que haya una KB abierta), y luego invocar al cmd.exe (obtiene la ruta con System.Environment.GetEnvironmentVariable("comspec");) pasandole el comando necesario para posicionarse en el directorio de la KB. Por último devuelve true, para indicar que el evento fue procesado.

El método QueryOpenCommandPrompt está definido como

private bool QueryOpenCommandPrompt(ICommandAdapter adap, ref CommandStatus status)
{
status.State = CommandState.Disabled;

IKBService kbserv = UIServices.KB;
if (kbserv != null && kbserv.CurrentKB != null)
{
status.State = CommandState.Enabled;
}

return true;
}

Es decir, por defecto el estado (variable por referencia status) lo pone como deshabilitado, y solo si la KB está abierta lo habilita.

Conclusiones

La experiencia de construir esta extensión fue muy positiva, no solo por haber logrado desarrollar la extensión, sino también por el aprendizaje que queda.

Creo que es muy bueno tener un mecanismo para extender GeneXus. Si bien desarrollar estas extensiones no es trivial, es algo que se puede hacer sin demasiado esfuerzo (después que uno averigua donde tocar).

De aquí en más queda mucho por hacer. Para Artech, escribir lo más que puedan de documentación, implementar más wizards con los escenarios más comunes, y proveer ejemplos. Para la comunidad, desarrollar las extensiones que consideremos necesarias, que sin duda van a ser muchas.

Comentarios

  1. Enrique Almeida28/9/06 19:22

    Bien metida!.
    Esperemos que sea la primera de varias extensiones por venir!.

    ResponderBorrar

Publicar un comentario

Entradas más populares de este blog

Literales de tipo Date y DateTime en GeneXus

Imagen
Cuando programamos, ya sea en GeneXus o en cualquier otro lenguaje, es muy común usar literales en el código, para valores conocidos o especiales de la aplicación. Por ejemplo, si voy a hacer una suma de varios registros, inicializo la variable en cero: &suma = 0 O si estoy por ejemplo en una transacción y quiero saber si estoy en modo Insert, puedo preguntar if &Mode = 'INS'     ... endif (nota: es un ejemplo... lo recomendable en este caso es usar el dominio enumerado TrnMode) En GeneXus hay unos cuantos tipos de datos, pero podríamos decir que los principales son cuatro: números, strings, booleanos y fechas (o fecha-hora para ser más precisos). Para los tres primeros, es bien sabido como expresar literales, ¿pero para las fechas? Esta funcionalidad creo que no es muy conocida, pero en GeneXus también se pueden escribir literales de fechas, utilizando el caracter # como delimitador (así como usamos las comillas simples o dobles para los strings).
Leer más

Comando "do case" en GeneXus

El comando do case de GeneXus tiene una sintaxis que no me termina de convencer... El problema es que las condiciones de cada case pueden ir sobre variables distintas. Más que un do case , la sintaxis permite usarlo como un if-elseif . En Java y C#, el comando equivalente es el switch , que discrimina según los valores que toma una variable dada. Por ejemplo: switch (variable) {     case 1:         // hago algo para el valor 1         break;     case 2:         // hago algo para el valor 2         break;     default:         // hago algo para los demás valores         break; } En GeneXus, el do case me permite hacer cosas como do case {     case &variable = 1 :         // hago algo para el valor 1 de &variable     case &otra_variable = 2 :         // hago algo para el valor 2 de &otra_variable     otherwise:         // hago algo para los demás valores endcase Me gustaría más tener un comando if-elseif que me permitiera hacer: if &va
Leer más

Subversion vs. Git

Cuando se habla de control de versiones, hay dos grandes formas de encarar el tema: centralizado o distribuido. Durante un año estuve usando Git (un sistema de control de versiones distribuido), y ahora hace un mes y medio que estoy usando Subversion  (que es centralizado). Lo que sigue es un intento de comparar ambas herramientas, desde mi punto de vista personal, sin intención de hacer una comparación exhaustiva ni del todo objetiva. Lo primero que hay que aclarar es que ni Git es del todo "distribuido" (ya que se suele mantener un repositorio centralizado), ni Subversion es totalmente centralizado (porque se trabaja sobre una copia local). La diferencia en realidad es donde ocurren las operaciones (branch, commit, etc.). En el caso de Git (y los demás que son distribuidos como Mercurial), las operaciones son locales, mientras que en Subversion ocurren en el servidor. Esto quiere decir que en Git puedo hacer N commits antes de mandar los cambios al servidor, mientr
Leer más