INTRODUCCION A LA PROGRAMACION BAJO WINDOWS (parte 2)

FUNCIONES, PARAMETROS Y MENSAJES

En el tutorial anterior dejamos en el aire el significado de los parámetros de las funciones del programa de ejemplo, así como el contenido de algunas estructuras utilizadas en el código. A continuación se va a tratar de ver todas estas cosas mas otro sencillo ejemplo que introduzca nuevos conceptos. Por supuesto, hoy vamos a tratar la parte mas tediosa de Windows, su cantidad de funciones, parámetros y tipos de datos, aunque aquí se tratara de simplificar su comprensión todo lo posible.

TIPOS DE DATOS MAS FRECUENTES EN WINDOWS

Los tipos de datos mas frecuentes son:

• HWND: Es un handle a una ventana, como a la ventana principal. • HDC: Es un handle a un contexto de dispositivo (para trazar gráficos mediante el, usando la interfaz de

Windows). • UINT: Es un typedef de un entero de 32 bits sin signo, muy común para devolver datos. • WPARAM/LPARAM: Enteros de 32 bits. Son parámetros de WndProc(). • BOOL: Es un entero de 32 bits booleano. • BYTE: Dato de 8 bits. • DWORD: Entero de 32 bits sin signo. • LONG: Es un entero de 32 bits. • LPSTR, LPCSTR: Un puntero a una cadena de caracteres o a una constante de cadena. • HICON, HCURSOR, HBRUSH: Handle a un icono, cursor o brochas. • HBITMAP: Referente a un bitmap (grafico). • RECT: Se usa para determinar rectángulos dentro de un area grafica. Es una estructura que contiene 4

campos, que son las coordenadas (x1, y1, x2, y2) de un rectángulo. • POINT: Estructura que permite identificar puntos. Contiene dos campos que son las coordenadas (x,y) de

un punto (en pixels desde la esquina de la ventana (0, 0)).

LAS FUNCIONES REGISTERCLASSEX()

Como vimos en el tutorial anterior, esta función registra una ventana a través de una clase de ventana WNDCLASSEX previamente inicializada:

//definimos la estructura de la ventanaWNDCLASSEX wcx; // estructura de la ventana

//determinamos los valores de los camposwcx.style = CS_HREDRAW | CS_VREDRAW; // valores más usuales

//registramos la clase de la ventana ya registradaif( !RegisterClassEx( &wcx ) )

return( FALSE ); // en caso de error, salir

La variable que se le pasa a RegisterClassEx() es una estructura de tipo WNDCLASSEX, la cual tiene la siguiente forma en los archivos de cabecera de Windows:

typedef struct _WNDCLASSEX { UINT cbSize; UINT style; WNDPROC lpfnWndProc; int cbClsExtra; int cbWndExtra; HANDLE hInstance; HICON hIcon; HCURSOR hCursor; HBRUSH hbrBackground; LPCTSTR lpszMenuName;

LPCTSTR lpszClassName; HICON hIconSm; } WNDCLASSEX;

LOAICON(), LOADCURSOR(), Y GETSTOCKOBJECT()

A la hora de rellenar los diferentes campos de la estructura WNDCLASSEX se usan las funciones LoadIcon(), LoadCursor() y GetStockObject():

LoadIcon(): Sirve para cargar un icono, devolviendo un handle tipo HICON del mismo. En el código de inicialización lo usamos para cargar un icono del stock de Windows y asignárselo a la ventana que se esta creando. Sus parámetro de llamada son los siguientes:

HICON LoadIcon( HINSTANCE hInstance, // handle de la instancia LPCTSTR lpIconName // puntero a la cadena con un nombre // o un identificador de recursos);

El parámetro lpIconName constituye un identificador de recursos, de los cuales los mas habituales son los que pueden verse a continuacion:

IDI_APPLICATION Default application icon. IDI_ASTERISK Same as IDI_INFORMATION. IDI_ERROR Hand-shaped icon. IDI_EXCLAMATION Same as IDI_WARNING. IDI_HAND Same as IDI_ERROR. IDI_INFORMATION Asterisk icon. IDI_QUESTION Question mark icon. IDI_WARNING Exclamation point icon. IDI_WINLOGO Windows logo icon

LoadCursor(): Sirve para cargar un cursor para el ratón, devolviendo el handle identificador del mismo. De la misma manera lo usamos en WNDCLASSEX para definir el aspecto del cursor cuando nuestra aplicación se este ejecutando (aunque tambien podemos cambiarlo en cualquier momento):

HCURSOR LoadCursor( HINSTANCE hInstance, // handle de la instancia LPCTSTR lpCursorName // puntero a la cadena con un nombre);

los valores mas habituales de IpCursorName son los siguientes:

IDC_APPSTARTING Standard arrow and small hourglass IDC_ARROW Standard arrow IDC_CROSS Crosshair IDC_HAND Windows NT 5.0 and later: Hand IDC_HELP Arrow and question mark IDC_IBEAM I-beam IDC_ICON Obsolete for applications marked version 4.0 or later. IDC_NO Slashed circle IDC_SIZE Obsolete for applications marked version 4.0 or later. Use IDC_SIZEALL. IDC_SIZEALL Four-pointed arrow pointing north, south, east, and west IDC_SIZENESW Double-pointed arrow pointing northeast and southwest IDC_SIZENS Double-pointed arrow pointing north and south IDC_SIZENWSE Double-pointed arrow pointing northwest and southeast IDC_SIZEWE Double-pointed arrow pointing west and east IDC_UPARROW Vertical arrow IDC_WAIT Hourglass

GetStockObject(): Es utilizado para extraer un objeto grafico del stock predefinido del GDI de Windows, permitiéndonos utilizar recursos incluidos dentro del propio Windows, como la brocha(brush), paleta (palette), fuentes(font), plumas(pen), etc.

HGDIOBJ GetStockObject( int fnObject // entero con el valor del objeto);

En nuestro caso la hemos utilizado para extraer la brocha blanca con la que rellenar el fondo de nuestra ventana (indicándola en wcx.hbrBackGround()).

LA FUNCION CREATEWINDOWEX()

La función CreateWindowEx(), como se comento en el tutorial anterior, crea la ventana tras registrarla. Su prototipo es el siguiente:

HWND CreateWindowEx( DWORD dwExStyle, // estilo extendido de la ventana LPCTSTR lpClassName, // puntero al nombre de la clase LPCTSTR lpWindowName, // puntero al titulo de la ventana DWORD dwStyle, // estilo de la ventana int x, // posicion orizontal de la ventana int y, // posicion vertical de la ventana int nWidth, // ancho de la ventana int nHeight, // alto de la ventana HWND hWndParent, // handle a la ventana padre HMENU hMenu, // handle al menu (NULL=no menu) HINSTANCE hInstance, // handle a la instancia LPVOID lpParam // puntero a los datos de creacion);

De esta declaración podemos deducir fácilmente el significado de (x, y) y (nWidth, nHeight) como la posición y el tamaño de la ventana en pixels (referido a la esquina (0, 0) del escritorio (o pantalla)). El parámetro lpClassname es el nombre de la clase con la que registramos la ventana y hInstance es un handle a la instancia actual de la aplicación (cuando ejecutamos varias veces un mismo programa, cada ventana es una nueva instancia del mismo). Mucho de esos parámetros se ponen a NULL, como por ejemplo al no disponer de ventana padre.Por otra parte, dwExStyle y dwStyle nos va a permitir elegir el aspecto de nuestra ventana.

CUADROS DE DIALOGO

Una de las funciones de ventana mas útiles de Windows es la posibilidad de mostrar y gestionar cuadros de dialogo del estilo Si/No. Aceptar/Cancelar, etc, muy útiles para mostrar información, resultado de errores, para pedir confirmaciones al usuario, permitiendo un rápido y sencillo control del flujo del programa.En el tutorial anterior pudimos ver en el Listado 1 un ejemplo de cuadro de dialogo de información, que esperaba la pulsación del botón Aceptar para continuar la ejecución. La creación de uno de estos cuadros de dialogo es muy sencilla gracias a MessageBox() y MessageBoxEx() (como siempre el prefijo Ex significa Extendido), funciones de la API de Windows para la gestión de los mismos. Los cuadros de dialogo pueden ser "modales" y "modales de sistema". La diferencia entre ambos radica en que los primeros no permiten acceder a otra ventana del programa hasta que la respuesta del usuario se produzca aunque permite el acceso a otros programas distintos del mismo (estos son los cuadros por defecto) Por otra parte, los segundos no permiten el acceso a ninguna otra aplicación (incluida la nuestra) hasta que son respondidos. Veamos el prototipo de la función MessageBox():

int MessageBox( HWND hWnd, // handle ventana LPCTSTR lpText, // frase informacion LPCTSTR lpCaption, // titulo UINT uType // estilo del cuadro);

De los cuatro parámetros, el primero es el handle a la ventana padre (que puede ser NULL si no queremos que pertenezca a ninguna ventana en concreto), el segundo (lpText) un puntero al texto que queremos que aparezca en el (Windows partirá la línea si es necesario) pudiendo además incluir secuencias de escape como \n, etc. El tercero constituye el titulo de la ventana y el ultimo (y mas importante) el estilo del dialogo, es decir, los botones y el tipo de dialogo deseado. Podemos usar usar varios de estos indicadores simultáneamente empleando el operador OR Como resultado, MessageBox nos devuelve el botón que haya sido pulsado (ya sea como ratón o

teclado) , o cero en caso de error.Un ejemplo del uso de MessageBox se han implementado en el Listado 1.

//Listado 1

#include <windows.h>

int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow )

{ int opcion;

opcion = MessageBox( NULL, "Texto de información.", "Título del MessageBox.",

MB_OKCANCEL | MB_ICONASTERISK );

if( opcion == IDOK )MessageBox(NULL, "Ha pulsado ACEPTAR",

"Salir", MB_OK ); else

MessageBox(NULL, "Ha pulsado CANCELAR", "Salir", MB_OK );

return(0);}

LAS MACROS LOWORD E HWORD

LOWORD e HWORD son dos funciones de tipo macro predefinido para Windows que nos permiten extraer el WORD bajo y alto, respectivamente de cualquier variable de 32 bits que se le especifique. Esto resulta muy útil muchas veces para obtener parámetros pasados a la función de procedimientos de ventana. Veamos como ejemplo una opción de código que nos permite saber sobre el tamaño de nuestra ventana cuando cambia su tamaño (mensaje WM_SIZE, recibimos en IPamam el nuevo ancho y alto):

int Anchi, Alto;// ... codigo ...case WM_SIZE

Ancho=LOWORD(lParam);Alto=HWORD(lParam);

Cuando el mensaje recibido es WM_SIZE , IParam se obtiene el nuevo tamaño del área cliente de la ventana , estando en la parte alta de IParam la anchura y en el WORD bajo, la altura.

LA FUNCIÓN TEXTOUT(): TEXTO EN NUESTRA APLICACIÓN

Una de las funciones mas importantes para hacer nuestras pruebas y programas es la salida de texto en la pantalla, muy útil para debbugear la aplicación y obtener mensajes en la ventana de la misma . Para ello se dispone de la función TextOut ( aparte de la DrawText vista en el ejemplo anterior):

BOOL TextOut( HDC hdc, // handle al DC int nXStart, // coordenada x int nYStart, // coordenada y LPCTSTR lpString, // puntero al texto int cbString // longitud de la cadena);

Los parámetros a pasarle a la función son un handle de contexto de dispositivo (que podemos obtener mediante BeginPaint() y bien, como veremos en el próximo tutorial mediante GedDC), las coordenadas (en pixels) donde imprimir la cadena , la propia cadena, y la longitud en caracteres pues esta función no busca el carácter END OF STRING (0) al final de la misma.Por supuesto necesitamos saber la anchura en pixels de la fuente para poder escribir las líneas unas debajo de las

otras ( o caracteres en posiciones concretas de la ventana, haciendo una "posición actual" a modo de cursor donde escribir, como en MS-DOS Para ello necesitamos saber la altura y la anchura de cada carácter para la fuente que este seleccionada para nuestra aplicación (la System Font, por defecto). El mejor momento de hacer esto es durante la creación de la aplicación , tomando la altura y la anchura de cada carácter mediante la función GetTextMetrics(), como puede verse en el listado 2 , donde se utilizan unas variables del tipo static (no desaparece su valor al salir de la función) llamadas cxChar y cyChar , que contiene el ancho y alto medio de cada carácter para la sytem font.

//-----------// Listado 2//-----------#include <windows.h>

//--- Declaración de funciones del programa -----------int WINAPI WinMain( HINSTANCE, HINSTANCE, LPSTR, int );LRESULT CALLBACK WndProc( HWND, UINT, WPARAM, LPARAM );void MenuProc( HWND, UINT, WPARAM, LPARAM );

//--- Declaración de variables del programa -----------char WindowName[] = "Default Window";char WindowTitle[] = "Windows95 application";

//=== Función principal WinMain() =====================int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance,

LPSTR lpCmdLine, int nCmdShow ){ HWND hwnd; MSG msg; WNDCLASSEX wcx;

// Definimos la estructura de clase: wcx.cbSize = sizeof( WNDCLASSEX ); wcx.style = CS_HREDRAW | CS_VREDRAW; wcx.lpfnWndProc = WndProc; wcx.cbClsExtra = 0; wcx.cbWndExtra = 0; wcx.hInstance = hInstance;

// icono, cursor, fondo e icono pequeño: wcx.hIcon = LoadIcon(NULL, IDI_WINLOGO); wcx.hCursor = LoadCursor(NULL, IDC_ARROW); wcx.hbrBackground = (HBRUSH) GetStockObject( WHITE_BRUSH ); wcx.hIconSm = LoadIcon(NULL, IDI_WINLOGO); wcx.lpszClassName = WindowName; wcx.lpszMenuName = NULL;

// Registramos la clase de ventana ya preparada: if( !RegisterClassEx( &wcx ) ) return( FALSE );

// Creamos la ventana con CreateWindowEx(): hwnd = CreateWindowEx( WS_EX_OVERLAPPEDWINDOW, WindowName, WindowTitle, WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 400, 300, NULL, NULL, hInstance, NULL );

// Comprobamos la creación de la ventana: if( !hwnd ) return( FALSE );

// Hacemos visible la ventana y la actualizamos:

ShowWindow( hwnd, nCmdShow ); UpdateWindow( hwnd );

// Bucle de mensajes, env¡a los mensajes hacia WndProc while( GetMessage( &msg, NULL, 0, 0 ) ) { TranslateMessage( &msg ); DispatchMessage( &msg ); }

// devolvemos el valor recibido por PostQuitMessage(). return( msg.wParam );}

//=== Función del procedimiento de ventana WndProc() ====LRESULT CALLBACK WndProc( HWND hwnd, UINT message,

WPARAM wParam, LPARAM lParam ){ HDC hdc; PAINTSTRUCT ps; TEXTMETRIC tm; RECT rect; int loop; static long cxChar, cyChar;

switch( message ) { // mensaje producido en la creación de la ventana case WM_CREATE: hdc = GetDC( hwnd ); GetTextMetrics( hdc, &tm ); cxChar = tm.tmAveCharWidth; cyChar = tm.tmHeight + tm.tmExternalLeading; ReleaseDC( hwnd, hdc ); break;

case WM_PAINT: hdc = BeginPaint( hwnd, &ps ); GetClientRect( hwnd, &rect ); for( loop=0; loop<10; loop++ ) TextOut( hdc, 0, loop*cyChar, "ESTO ES UNA PRUEBA", 18 ); EndPaint( hwnd, &ps ); break;

// mensaje producido al aumentar el tamaño de la ventana case WM_SIZE: // aqui habriamos de coger de nuevo el tamaño. break;

// mensaje producido al cerrar la ventana case WM_DESTROY: PostQuitMessage( 0 ); break;

// resto de mensajes, dar una respuesta estándar.default:

return( DefWindowProc( hwnd, message, wParam, lParam ) );}

return(0);}

TEXTOUT Y WSPRINTF

La forma mas sencilla de utilizar TextOut() es conjuntamente con la función wsprintf(). Esta función introduce cadenas y variables (admitiendo especificadores de formato) dentro de un buffer de texto (los concatena), devolviendo la longitud , a titulo de ejemplo:

char cadena[80];int longitud;//... codigo ...longitud=wsprintf(cadena, "El resultado es %d", total);TextOut(hdc, 100, 100, cadena, longitud);

De esta manera , en nuestra aplicación podemos imprimir tanto cadenas de texto puro como valores numéricos de cualquier tipo, aprovechando además que wsprintf() nos devuelve el tamaño de la cadena creada.

EL BUCLE DE MENSAJES

El bucle de mensajes es sin duda uno de los puntos vitales de nuestro programa, ya que en el se recogen y traducen todos los mensajes de Windows a los parámetros que finalmente reciben la función callback de procedimientos de ventana:

// Bucle de mensajes, envía los mensajes hacia WndProcwhile( GetMessage( &msg, NULL, 0, 0 ) ){

TranslateMessage( &msg ); // convertimos el mensajeDispatchMessage( &msg ); // devolvemos el control a w95

}

// devolvemos el valor recibido por PostQuitMessage().return( msg.wParam );

Este es un bucle que se repetirá hasta que el usuario salga de la aplicación momento en el que recibiremos un cero y el while será FALSE En casi de recibir un valor distinto de 0 (TRUE) , el bucle continua Hay que decir que Windows tiene una cola de mensajes , existiendo una continua llegada y traducción de los mismos.

BOOL GetMessage( LPMSG lpMsg, // puntero a la estructura que contiene el mensaje recibido HWND hWnd, // handle a la ventana que lo recibe UINT wMsgFilterMin, // identificador del primer mensaje UINT wMsgFilterMax // identificador del ultimo mensaje);

El tipo de datos LPMSG es (vayámonos acostumbrándonos a la terminología "húngara" de Windows) un puntero largo a MSG (LP=Long Pointer):

typedef struct tagMSG { // msg HWND hwnd; // handle a la ventana destinataria UINT message; //identificador del mensaje WPARAM wParam; // informacion adicional LPARAM lParam; // informacion adicional DWORD time; // hora del envio del mensaje POINT pt; // coordenadas del raton} MSG;

WPARAM es el mismo tipo que UINT y LPARAM es un typedef para LONG , la estructura tipo POINT contiene las coordenadas del ratón en el momento de recibir el mensaje y esta definida como:

typedef struct tagPOINT{

LONG x; // coordenada xLONG y: // coordenada y

}POINT;

Como puede verse en la línea GetMessage(&msg, NULL, 0, 0) handle a la ventana puede especificarse como NULL, ylparam/wparam a cero con el fin de obtener todos los mensajes para nuestra aplicación, no solo par una determinada ventana ( si hubiesemos creado diferentes ventanas hijas). Continuando con el comentario del bucle del mensajes, mediante TransalateMessage() traducimos algunos de estos mensajes, y mediante DispatchMessage() los enviamos a la función de procedimientos de ventana para que realice su proceso.

OTRA MANERA DE RECOGER LOS MENSAJES

Bajo Windows tenemos otra posibilidad en ves de esperar a que Windows nos envie un mensaje, continuar trabajando (aunque no nos envié mensajes) recogiendo nosotros mismos todos los mensajes que se envíen en Windows y contestando tan solo a los que nos atañen. Para ello puede usarse la función PeekMessage(), lo cual nos permitirá realizar otras acciones (como actualizar nuestro programa) una vez por cada mensaje que sea enviado a Windows.

while(1){ HacerAlgo(); if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) {

if (msg.message==WN_QUIT)return (msg.wParam);

TranslateMessage(&msg);DispatchMessage(&msg);}

}

Mediante el bucle anterior hacemos que nuestra función vaya en busca de los mensajes al mismo tiempo que ejecutamos código propio de nuestra aplicación (llamando en el ejemplo anterior de manera ilustrativa HacerAlgo()), que podría, en el caso de un juego redibujar la pantalla, mover los sprites a distintas posiciones , con esto le estamos robando tiempo a otras aplicaciones.

Interfaz gráfica de usuario

De Wikipedia, la enciclopedia libre

Saltar a navegación, búsqueda

En el contexto del proceso de interacción persona-ordenador, la interfaz gráfica de usuario, es el artefacto tecnológico de un sistema interactivo que posibilita, a través del uso y la representación del lenguaje visual, una interacción amigable con un sistema informático.

La interfaz gráfica de usuario (en Idioma inglés|inglés Graphical User Interface, 'GUI') es un tipo de interfaz de usuario que utiliza un conjunto de imágenes y objetos gráficos para representar la información y acciones disponibles en la interfaz. Habitualmente las acciones se realizan mediante manipulación directa para facilitar la interacción del usuario con la computadora.

Surge como evolución de la línea de comandos de los primeros sistemas operativos y es pieza fundamental en un entorno gráfico.

Como ejemplo de interfaz gráfica de usuario podemos citar el escritorio o desktop del sistema operativo Windows y el entorno X-Window de Linux y también Finder de Mac OS X.

Tabla de contenidos

[ocultar]• 1 Introducción

• 2 Precursores • 3 Xerox Alto • 4 Xerox Star 8010 • 5 GEOS • 6 Apple Lisa, Macintosh, Apple II GS • 7 GEM • 8 Workbench • 9 Apple y Windows • 10 Tipos de interfaces gráficas de usuario

o 10.1 PUI's y Zooming user interface o 10.2 "Touchscreen user interface"

• 11 Véase también • 12 Bibliografía

• 13 Enlaces externos

Introducción [editar]

La historia reciente de la informática está indisolublemente unida a las interfaces gráficas, puesto que los sistemas operativos gráficos han ocasionado grandes consecuencias en la industria del software y del hardware.

Las interfaces gráficas surgen de la necesidad de hacer los ordenadores más accesibles para el uso de los usuarios comunes. La mayoría de ordenadores domésticos requerían conocimientos de BASIC (el 95% de ellos mostraban el intérprete BASIC al encenderse) u ofrecían una interfaz de línea de órdenes (como los sistemas operativos CP/M o los diferentes OS del Apple II), lo que requería conocimientos por encima de la media si se deseaba hacer algo más que usarlo como consola de videojuegos.

Esta limitación fue salvada gracias al desarrollo de los entornos gráficos, que permitieron que las personas pudieran acceder a un ordenador sin tener que pasar por el tortuoso proceso de tener que aprender a manejar un entorno bajo línea de órdenes.

Precursores [editar]

Los investigadores del Stanford Research Institute liderados por Douglas Engelbart, desarrollaron una interfaz de hipervínculos en modo texto gobernado por un mouse, que también inventaron. Este concepto fue ampliado y trasladado al entorno gráfico por los investigadores del Xerox PARC en EE.UU.. El entorno se denominó PARC User Interface y en él se definieron los conceptos de ventanas, checkbox, botones de radio, menús y puntero del mouse. Fue implementado comercialmente en el Xerox Star 8010

Xerox Alto [editar]

El Xerox Alto, desarrollado en el Xerox PARC en 1973, fue el primer ordenador personal, así como el primero que utilizó la metáfora de escritorio y una interfaz gráfica de usuario.

Xerox Star 8010 [editar]

La estación de trabajo Xerox Star, conocida oficialmente como el "8010 Star Information System" (Sistema de Información Estrella 8010) fue introducida por Xerox Corporation en 1981. Fue el primer sistema comercial en incorporar varias tecnologías que han llegado a ser hoy en día corrientes en computadores personales, incluyendo la pantalla con bitmaps en lugar de solo texto, una interfaz gráfica de usuario basada en ventanas, iconos, carpetas, mouse, red Ethernet, servidores de archivos, servidores de impresoras y e-mail.

GEOS [editar]

Para el Commodore 64 y su sucesor el Commodore 128 se desarrolló el entorno gráfico GEOS en 1986. Este entorno se portó al IBM PC, fue utilizado en varias PDA y Nokia lo usó como base de su actual sistema operativo.

Apple Lisa, Macintosh, Apple II GS [editar]

Tras una visita al Xerox PARC en 1979, el equipo de Apple encabezado por Jef Raskin se concentra en diseñar un entorno gráfico para su nueva generación de 16 bits, que se verá plasmado en el Apple Lisa en 1983. Ese sistema gráfico es portado al sucesor del Apple II, el Apple II GS. Un segundo equipo trabaja en el Apple Macintosh que verá la luz en 1984 con una versión mejorada del entorno gráfico del Lisa (pretendimos hacer un ordenador tan simple de manejar como una tostadora). Desde ese momento el Mac reinará como paradigma de usabilidad de un entorno gráfico; pese a que por debajo el sistema operativo sufra cambios radicales, los usuarios no avanzados no son conscientes de ello y no sufren los problemas de otras plataformas.

GEM [editar]

GEM es un GUI diseñado por Digital Research para ejecutarse sobre varios sistemas operativos de línea de comandos del IBM PC y compatibles: funciona tanto sobre IBM DOS /MS-DOS como sobre CP/M 86. Su máxima popularidad en el PC llega de la mano del Amstrad 1512 y del Amstrad 1640, los clónicos que rompieron en Europa la barrera del precio popularizando el PC, hasta ese momento relegado mayoritariamente a oficinas. Aunque se incopora en su primera generación de portátiles y en el Sinclair PC 200, será sustituido en la siguiente generación de PCs Amstrad por Microsoft Windows 2.xx. En el PC vivirá una segunda juventud al venir de serie con DR-DOS como TaskMax.

Pero será en los Atari ST y sucesores donde se convertirá en el entorno gráfico oficial de la plataforma, alcanzando gran popularidad, tanto por ser en principio una alternativa barata al MAC en autoedición, como por hacerse con el nicho de mercado de la música profesional.

Workbench [editar]

Es el nombre dado por Commodore a la interfaz gráfica del AmigaOS, el sistema operativo del Commodore Amiga lanzado en 1985. A diferencia de los sitemas más populares (GEM, Mac OS, MS Windows...) es un verdadero entorno multitarea sólo rivalizado por la interfaz X Window System de los diferentes sabores de Unix. La frase más repetida por un "amiguero" es: "para masacrar marcianos, formatear un diskette y enviar o recibir un Fax todo a la vez y sin colgarse, necesitas un 386 con disco duro, 16 MB de RAM y OS/2; un Amiga 500 con disquete y sólo su memoria base (512 KB de RAM y 512 KB de ROM) es capaz de todo eso". Aunque muy popular por los espectaculares (para entoces) gráficos de la máquina y su gran plantel de videojuegos, será la negligencia de sus sucesivos propietarios la principal causa de que acabe restringido a sólo la plataforma Amiga.

Apple y Windows [editar]

A principios de los años ochenta (en 1982) Apple, que había comenzado como una micro-empresa formada por dos empleados (Steve Jobs y Steve Wozniak) había crecido hasta convertirse en una empresa de 300 millones de dólares.

En el año 1983 Apple ya se había convertido en una empresa de 1000 millones de dólares, el mismo valor que IBM.

En 1987 IBM se vio obligada a entrar en el mercado de los ordenadores personales con entorno gráfico con su modelo PS/2, aliándose con Bill Gates (Microsoft), que había desarrollado el OS/2. La interfaz gráfica de este sistema operativo era muy similar a la de Apple.

Pero el OS/2 no se convirtió en el nuevo estándar del sector, debido fundamentalmente al conflicto de intereses entre IBM y Microsoft.

En el año 1985, Microsoft saca al mercado Windows 1.0, entorno gráfico para ordenadores PC IBM compatibles, con un parecido asombroso al Mac OS.

La respuesta de Apple a la introducción del sistema operativo Windows fue la interposición de una demanda de varios miles de millones de dólares contra Microsoft, por violación de copyright.

La aparición de ordenadores IBM clónicos hizo que el sistema Windows se popularizara, lo que restó mercado a Apple. Ésta se recuperó a finales de 1990 lanzando nuevos productos.

Una señal inequívoca del éxito de Apple fue la aparición de productos similares: una pequeña compañía llamada Nutek Computers Inc. anunció que estaba desarrollando un ordenador compatible con el Macintosh.

En 1991, John Sculley, director de Apple, reveló que la compañía estaba considerando competir contra Microsoft en el campo del software vendiendo su sistema operativo a terceros.

Apple reveló que estaba manteniendo conversaciones con su antiguo rival, IBM, destinadas a compartir tecnologías. Decidieron crear una joint venture para desarrollar un sistema operativo avanzado que ambas utilizarían en sus nuevas máquinas y licenciarían a terceros. Este plan presentaba un desafío directo a Microsoft.

Microsoft consigue convertir a Windows en el sistema operativo más utilizado en el mundo, dejando a Apple en un segundo lugar.

Tipos de interfaces gráficas de usuario [editar]

PUI's y Zooming user interface [editar]

Interfaz gráfica tridimensional de Compiz en GNU/Linux

Los GUIs que no son PUIs son encontrados en juegos de computadora, y los GUIs avanzados basados en realidad virtual ahora son usados con más frecuencia en las investigaciones. Muchos grupos de investigación en Norteamérica y Europa están trabajando actualmente en el interfaz de enfoque del usuario o ZUI (Zooming User Interface), que es un adelanto lógico en los GUI, mezclando 3D con 2.o ó "2D y medio objetos vectoriales de una D".

"Touchscreen user interface" [editar]

Algunos GUIs son diseñados para cumplir con los rigurosos requisitos de los mercados verticales. Éstos se conocen como "GUIs de uso específico." Un ejemplo de un GUI de uso específico es el ahora familiar Touchscreen o Pantalla Táctil (pantalla que al ser tocada efectúa los comandos del mouse en el software. Es encontrado en muchos restaurantes alrededor del mundo y en tiendas de autoservicio. Primero iniciado por Gene Mosher en la computadora del ST de Atari en 1986, el uso que el específico GUI en el Touchscreen ha encabezado una revolución mundial en el uso de las computadoras a través de las industrias alimenticias y de bebidas, y en venta al por menor.

Otros ejemplos de GUIs de uso específico, relacionados con el Touchscreen son los cajeros automáticos, los kioscos de información y las pantallas de monitoreo y control en los usos industriales, que emplean un sistema operativo de tiempo real (RTOS). Los teléfonos móviles y los sistemas o consolas de juego también emplean el Touchscreen. Además la domótica no es posible sin una buena interfaz de usuario, o GUI.

Con la idea de simplificar el uso de los ordenadores para usuarios de todo tipo y no sólo para los expertos, se ha convertido en una práctica habitual utilizar metáforas visuales por medio de la llamada interfaz gráfica de usuario (IGU ó GUI en inglés) para que el usuario interactúe y establezca un contacto más fácil e intuitivo con el ordenador. Si, como afirma Neal Stephenson: "en el principio fue la línea de comandos..." tal como los hackers siguen hoy reivindicando no sólo con nostalgia, sino también como una forma de tener control real sobre las máquinas, en la actualidad prima la cultura de la interfaz "amigable" y vistosa. En estos casos, un simple clic de ratón sobre algún gráfico (imagen) que aparece en la pantalla, sustituye a la tediosa tarea de escribir código fuente para que el ordenador interprete que debe realizar alguna acción. En 1981 aparecieron los primeros ordenadores personales, los llamados Pcs, pero hasta 1993 no se generalizaron las

interfaces gráficas de usuario. El escritorio del sistema operativo Windows de Microsoft y su sistema de ventanas sobre la pantalla se ha estandarizado y universalizado, pero fueron los ordenadores Macintosh de la compañía Apple los primeros que introdujeron las interfaces gráficas de usuario.

Una interfaz es un dispositivo que permite comunicar dos sistemas que no hablan el mismo lenguaje. Restringido a aspectos técnicos, se emplea el término interfaz para definir el juego de conexiones y dispositivos que hacen posible la comunicación entre dos sistemas. Sin embargo, cuando aquí hablamos de interfaz nos referimos a la cara visible de los programas tal y como se presenta a los usuarios para que interactúen con la máquina. La interfaz gráfica implica la presencia de un monitor de ordenador o pantalla constituida por una serie de menús

e iconos que representan las opciones que el usuario puede tomar dentro del sistema.

En el caso del hipertexto, la interfaz hipertextual consistiría en el diseño navegacional y el conjunto de herramientas y utilidades que permiten al usuario-lector interactuar con los contenidos. La interfaz proporcionará al usuario el conjunto de posibilidades que podrá seguir durante todo el tiempo que se relacione con el programa, detallando lo que verá y escuchará en cada momento, y las acciones que puede realizar, así como las respuestas que puede ofrecer el sistema. El usuario, además de entender el mensaje, ha de comprender la mecánica operativa que se le ofrece (sintaxis, órdenes, códigos, abreviaturas, iconos, etc.). Una buena interfaz requiere poco esfuerzo por parte del usuario, simplicidad y funcionalidad.

Las características básicas de una buena interfaz podrían sintetizarse en:

• Facilidad de comprensión, aprendizaje y uso• Representación fija y permanente de un determinado contexto de acción (fondo)

• El objeto de interés ha de ser de fácil identificación

• Diseño ergonómico mediante el establecimiento de menús, barras de acciones e iconos de fácil acceso

• Las interacciones se basarán en acciones físicas sobre elementos de código visual o auditivo (iconos, botones, imágenes, mensajes de texto o sonoros, barras de desplazamiento y navegación...) y en selecciones de tipo menú con sintaxis y órdenes

• Las operaciones serán rápidas, incrementales y reversibles, con efectos inmediatos

• Existencia de herramientas de Ayuda y Consulta

• Tratamiento del error bien cuidado y adecuado al nivel de usuario

La tipografía y el tratamiento del color son dos elementos a los que hay que prestar especial importancia a la hora de establecer una buena interfaz, poniendo especial cuidado en el diseño de las formas y la coherencia interna entre ellas.

Al igual que cualquier otro tipo de documento textual o gráfico creado por un programa de ordenador, la lectura o navegación de un hipertexto se realiza a través de la pantalla, y, en el caso de un documento web, por medio de un programa de lectura y visualización llamado navegador. El diseño del hipertexto se realiza para que el usuario vea en pantalla toda la información necesaria y para que opere e interactúe en ella a través del ratón, el teclado y las opciones del menú. Así, se insertan códigos que no están visibles si así se prefiere, pero que ofrecen la apariencia deseada para ser vistos en pantalla. Aquí la palabra clave es WYSIWYG ("What you see is what you get"), es decir, lo que tu ves es lo que obtienes.

Para diseñar una buena interfaz enfocada hacia el usuario es necesario tener claros los objetivos del hipertexto, teniendo en cuenta no sólo lo que se persigue ofreciendo información, sino las necesidades que van a tener los usuarios a la hora de consultarlo. También es clave determinar el contenido y la funcionalidad, especificar la estructura organizativa, la navegación, las secciones y los sistemas de búsqueda. Hay que tener en cuenta que cada usuario puede tener diferentes necesidades y un buen sistema de navegación debe contar con las herramientas adecuadas para diferentes funciones. Como cada usuario pude tener diferentes necesidades, es importante ofrecer diferentes formas de acceso y búsqueda, desde búsquedas precisas, hasta exploraciones guiadas o a elección del lector.

Interfaz del programa "Obras de Gustavo Adolfo Bécquer". Ejemplo extraído de:http://www.terra.es/personal/webbecquer/imagenes.htm

La interfaz es el elemento que permite al usuario interactuar con los contenidos, no sólo se precisa una interfaz atractiva, sino funcional. El diseño de interfaz de un hipertexto es, pues, fundamental para que el usuario pueda interactuar con los contenidos de dicho hipertexto. La pantalla del ordenador se convierte en una ventana a través de la cual el usuario accede al espacio hipertextual. Xavier Berenguer afirma que "el éxito de un programa depende directamente de la calidad de su interfaz", así podríamos decir, que el éxito de un hipertexto depende de su interfaz.

Figura: Xavier Berenguer http://www.iua.upf.es/formats/formats1/a01et.htm

El diseñador de interfaces debe facilitar y simplificar el acceso y los recorridos de los usuarios. A menudo se usa la metáfora del viaje o del camino a recorrer y se presentan iconos o símbolos de interfaz y otros dispositivos que tienen que ver con las señales utilizadas en mapas, urbanismo o arquitectura. Los contextos navegacionales organizan el espacio de navegación, ayudando al usuario a recorrer los contenidos y ofreciéndole herramientas que guíen o faciliten los recorridos o las búsquedas y la recuperación de información y que le ofrezcan la posibilidad de realizar una serie de acciones estableciendo mecanismos de vuelta atrás, el etiquetado y la vista previa de enlaces y otros procesos automatizados a modo de servicios interactivos. La interfaz de navegación no debe limitarse a la parte visible de la información en un momento dado, sino que debe ser capaz de ofrecer al usuario el acceso a la parte del documento que le interesa y en la forma que desea. Aun tratándose de un entorno navegacional complejo, éste se debe presentar al usuario de una forma sumamente sencilla y que sea lo más normalizada posible.

Algunos ejemplos de interfaz se pueden ver en: Merlos Network, My Websites

http://usuarios.lycos.es/natasab/webs/ de donde se ha extraído este ejemplo.

Un buen hipertexto debe suministrar herramientas de uso sencillo y fácil para que el usuario sepa en todo momento en dónde se encuentra y hacia dónde puede ir, y herramientas para que pueda realizar una serie de acciones como búsquedas, ponerse en contacto con otros usuarios, participar en un foro de debate, etc. Algunas de estas herramientas útiles para la navegación y que deben mostrarse en la interfaz de usuario son las siguientes:

• Herramientas de representación de la estructura de la información documental: Se trata de representar la estructura de los nodos más amplios o genéricos que contienen las diferentes partes o nodos específicos, de forma similar a las secciones, capítulos, etc. de un texto.

• Herramientas de navegación: es necesario representar de forma visual y gráfica (esquemática, iconográfica, etc.) el conjunto de la red hipertextual. Para ello, son muy útiles los mapas de navegación que funcionan a modo de brújula para ayudar al usuario a moverse por el hipertexto. Los diagramas de representación permiten no sólo anticipar las características de la navegación del hipertexto, sino que también facilitan el diseño para la creación del hipertexto. Los navegadores o visualizadores de páginas web, a diferencia de la mayoría de las aplicaciones informáticas actuales, no han recurrido a la manida metáfora del escritorio de trabajo y sus carpetas para organizar la información, sino que han querido emular la forma de conocimiento humano reflejado en el hipertexto: la información se presenta como nodos

dentro de una red en la que una idea lleva a otra y esta a otra diferente. Sin embargo, el sistema sería un caos si no existieran formas de organizar la información en una forma lógica y con posibilidad de conocer en todo momento dónde se está y cómo se ha llegado hasta ahí.

• Herramientas que posibiliten guardar y almacenar la dirección y localización de los documentos a los que se ha accedido, mediante el registro de marcas, favoritos o bookmarks, para su posterior acceso directo.

• Herramientas que permitan definir los enlaces con indicación del punto de destino (ancla): el usuario debe poder visualizar el destino o destinos posibles de cualquier enlace para saber hacia dónde se desplazará en caso de optar por esa conexión.

• Herramientas que permitan la creación de un histórico de navegación: para que el usuario pueda tener constancia del camino recorrido tanto sobre la red de documentos como sobre la red semántica, y poder así volver en cualquier momento, sobre algún paso del camino recorrido.

• Herramientas para la recuperación de la Información: se pueden incluir buscadores y otras herramientas de búsqueda y consulta tanto dentro de la propia red hipertextual como en el resto de la web. Estas herramientas permiten la construcción de documentos dinámicos creados a partir de las propias acciones del usuario, que pueden contar con la ayuda de agentes inteligentes.

• Herramientas que permitan que el usuario participe en la creación del conocimiento en un entorno colaborativo. Estas herramientas permitirán la interacción entre el autor del hipertexto y el usuario o entre varios usuarios, o incluso, que el usuario contribuya al contenido del hipertexto directamente. El usuario puede participar en el contenido del hipertexto haciendo comentarios y anotaciones ya sea en línea o por correo electrónico, es posible iniciar una discusión, es posible añadir contenidos o añadir enlaces mientras se lee, individualmente o en colaboración.

Ejemplo de distintos elementos que pueden formar parte de la interfaz de usuario de un hipertexto

Identificador

De Wikipedia, la enciclopedia libre

Saltar a navegación, búsqueda

Los identificadores (IDs) son símbolos léxicos que nombran entidades. El concepto es análogo al de "nombre". Los identificadores se usan ampliamente en prácticamente todos los sistemas de procesamiento de la información. Nombrar las entidades hace posible referirse a las mismas, lo cual es esencial para cualquier tipo de procesamiento simbólico.

Identificadores en lenguajes informáticos [editar]

En los lenguajes informáticos, los identificadores son elementos textuales (también llamados símbolos) que nombran entidades del lenguaje. Algunas de las de entidades que un identificador puede denotar son las variables, las constantes, los tipos de dato, las etiquetas, las subrutinas, los paquetes y las subrutinas (procedimientos y funciones).

En muchos lenguajes algunas secuencias tienen la forma léxica de un identificador pero son conocidos como palabras clave (o palabras reservadas). Lo habitual es que si un identificador se corresponde con una palabra clave o reservada, éste ya no pueda utilizarse para referirse a otro tipo de entidades como variables o constantes (en unos pocos lenguajes, como PL/1, esta distinción no está del todo clara).

Los lenguajes informáticos normalmente ponen restricciones en qué caracteres pueden aparecer en un identificador. Por ejemplo, en las primeras versiones de C y C++, los identificadores están restringidos para que sean una secuencia de una o más letras ASCII, dígitos numéricos (que en ningún caso deben aparecer como primer carácter) y barras bajas. Las versiones posteriores de estos lenguajes, así como otros muchos más lenguajes modernos soportan casi todos los caracteres Unicode en un identificador. Una restricción común es que no está permitido el uso de espacios en blanco ni operadores del lenguaje.

En lenguajes de programación compilados, los identificadores generalmente son entidades en tiempo de compilación. Es decir, en tiempo de ejecución el programa compilado contiene referencias a direcciones de memoria y offsets más que identificadores textuales (estas direcciones de memoria u offsets, han sido asignadas por el compilador a cada identificador).

En lenguajes interpretados los identificadores están frecuentemente en tiempo de ejecución, a veces incluso como objetos de primera clase que pueden ser manipulados y evaluados libremente. En Lisp, éstos se llaman símbolos.

Los compiladores e intérpretes normalmente no asignan ningún significado semántico a un identificados basado en la secuencia de caracteres actual. Sin embargo, hay excepciones. Por ejemplo:

• En Perl una variable se indica utilizando un prefijo llamado sigil, que especifica aspectos de cómo se interpreta la variable en las expresiones.

• En Ruby una variable se considera automáticamente como inmutable si su identificador empieza con una letra mayúscula.

• En Fortran, la primera letra de una variable indica si por defecto es creada como entero o como flotante.

Referencia del lenguaje Visual Basic

Handles

Declara que un procedimiento controla un evento especificado.

proceduredeclaration Handles eventlist

Partes

proceduredeclaration

La declaración del procedimiento Sub del procedimiento que controlará el evento.

eventlist

La lista de los eventos para proceduredeclaration que se deben controlar. Los eventos los debe provocar la

clase base de la clase actual o un objeto declarado mediante la palabra clave WithEvents.

Comentarios

Use la palabra clave Handles al final de una declaración de procedimiento para hacer que controle eventos

provocados por una variable de objeto declarada con la palabra clave WithEvents. La palabra clave Handles

también puede utilizarse en una clase derivada para controlar eventos de una clase base.

La firma del procedimiento debe coincidir con las firmas de cada evento contenido en eventlist.

Tanto la palabra clave Handles como la instrucción AddHandler permiten especificar que determinados

procedimientos controlan eventos concretos, pero hay diferencias. Utilice la palabra clave Handles al definir un

procedimiento para especificar que controla un determinado evento. La instrucción AddHandler conecta en tiempo

de ejecución los procedimientos a los eventos. Para obtener más información, vea AddHandler (Instrucción)

[ http://msdn.microsoft.com/es-es/library/7taxzxka(VS.80,printer).aspx ] .

Para los eventos personalizados, la aplicación invoca el descriptor de acceso AddHandler del evento cuando

agrega el procedimiento como un controlador de eventos. Para obtener más información sobre eventos

personalizados, vea Event (Instrucción) [ http://msdn.microsoft.com/es-es/library/6hwhs172(VS.80,printer).aspx ] .

Ejemplo

Visual Basic

Copiar código

Public Class ContainerClass

' Module or class level declaration.

WithEvents Obj As New Class1

Public Class Class1

' Declare an event.

Public Event Ev_Event()

Sub CauseSomeEvent()

' Raise an event.

RaiseEvent Ev_Event()

End Sub

End Class

Sub EventHandler() Handles Obj.Ev_Event

' Handle the event.

MsgBox("EventHandler caught event.")

End Sub

' Call the TestEvents procedure from an instance of the ContainerClass

' class to test the Ev_Event event and the event handler.

Public Sub TestEvents()

Obj.CauseSomeEvent()

End Sub

End Class

En el siguiente ejemplo se muestra cómo una clase derivada puede utilizar la instrucción Handles para controlar un

evento desde una clase base.

Visual Basic

Copiar código

Public Class BaseClass

' Declare an event.

Event Ev1()

End Class

Class DerivedClass

Inherits BaseClass

Sub TestEvents() Handles MyBase.Ev1

' Add code to handle this event.

End Sub

End Class

Component Object Model

De Wikipedia, la enciclopedia libre

Saltar a navegación, búsqueda

Component Object Model (COM) es una plataforma de Microsoft para componentes de software introducida por dicha empresa en 1993. Esta plataforma es utilizada para permitir la comunicación entre procesos y la creación dinámica de objetos, en cualquier lenguaje de programación que soporte dicha tecnología. El término COM es a menudo usado en el mundo del desarrollo de software como un término que abarca las tecnologías OLE, OLE Automation, ActiveX, COM+ y DCOM. Si bien COM fue introducido en 1993, Microsoft no hizo énfasis en el nombre COM hasta 1997.

Esencialmente COM es una manera de implementar objetos neutral con respecto al lenguaje, de manera que pueden ser usados en entornos distintos de aquel en que fueron creados, a través de fronteras entre máquinas. Para componentes bien creados, COM permite la reutilización de objetos sin conocimiento de su representación interna, porque fuerza a los implementadores de componentes a proveer interfaces bien definidos que son separados de la implementación. Las diferentes semánticas de reserva de memoria son acomodadas haciendo a los objetos responsables por su propia creación y destrucción por medio de la cuenta de referencias. Se puede hacer casting entre distintos interfaces de un objeto por medio de la función QueryInterface(). El método preferido de herencia en COM es la creación de subobjetos a los que se delegan las llamadas a métodos ( llamado agregación ).

Aunque estas tecnologías han sido implementadas en muchas plataformas, son principalmente usadas con Microsoft Windows. Se espera que COM sea sustituido, al menos en un cierto grado, por Microsoft.NET, y soporte para Web Services a través de Windows Communication Foundation (WCF). DCOM en red usa formatos binarios propietarios, mientras que WCF usa mensages SOAP basados en XML. COM también compite con CORBA y Java Beans como sistema de componentes de software.

Tabla de contenidos

[ocultar]• 1 Detalles técnicos

o 1.1 Interfaces o 1.2 Clases o 1.3 Lenguaje de definición de interfaces y librerias de tipos o 1.4 Conteo de referencias o 1.5 Instanciación o 1.6 Programación o 1.7 Transparencia de aplicaciones y red

• 2 Críticas o 2.1 Mensaje de bombeo o 2.2 Conteo de referencias o 2.3 DLL hell

• 3 Referencias • 4 Véase también

• 5 Enlaces externos

Detalles técnicos

Los programadores COM construyen software usando componentes de software COM-aware. Diferentes tipos de componentes son identificados por tipo de IDs (CLSIDs), los cuales son identificadores globales únicos, o GUIDs. Cada componente COM revela su funcionalidad por medio de uno o más interfaces. Los diferentes interfaces soportados por un componente son distinguidos los unos de los otros usando interfaces IDs (IIDs), que son también GUIDs.

Los Interfaces COM tienen implementaciones en varios idiomas, tales como C, C + +, Visual Basic, y varios de los lenguajes de script implementados en la plataforma Windows. Todo acceso a los componentes se realiza a través de los métodos de las interfaces. Esto permite que técnicas como inter-proceso, incluso programación entre ordenadores (este último mediante el apoyo de DCOM).

Interfaces [editar]

Todos los componentes COM deben (al menos) implementar el interface estándar IUnknown, y así todo los interfaces COM son derivado de IUnknown. El interface IUnkown consta de tres métodos: AddRef() y Release(), que implementan conteo de referencias y control del ciclo de vida de los interfaces; y QueryInterface(), que por especificar un IID permite a una llamada recuperar las referencias a los diferentes interfaces que el componente implementa. El efecto de QueryInterface () es similar a dynamic_cast <> en C + + o casting en C # y Java.

Los interfaces de un componente COM es necesario que muestren propiedades reflexiva, simétrica y transitiva. La propiedad reflexiva se refiere a la capacidad para que la llamada al QueryInterface() dado un interfaz con el ID del interfaz devuelva la misma instancia del interfaz. La propiedad simétrica que cuando el interfaz B es recuperado del interfaz A por el QueryInterface(), el interfaz A es recuperable del interfaz B también. La propiedad transitiva es similar a la propiedad simétrica, pero requiere que si el interfaz B se puede conseguir del interfaz A y el interfaz C se puede conseguir del interfaz B, entonces el intefaz C deberia poder conseguirse del interfaz A.

Un interfaz consta de un puntero a una función virtual que contiene una lista de punteros a las funciones que implementa la función declarada en el interfaz, en el mismo orden que fueron declaradas en el interfaz. Esta técnica de paso de punteros de función de estructuras es muy parecida a la utilizada por OLE 1.0 para comunicar con su sistema de librerías.

COM especifica muchos otros interfaces estándar usado para permitir comunicación entre componentes. Por ejemplo, uno de esos es IStream, que esta puesto para los componentes que tiene semántica de flujo de datos (un componente FileStream usado para leer y escribir archivos). Tiene los esperados métodos Read y Write para realizar las lecturas y escrituras de flujo. Otro interfaz estándar es IOleObject, que esta puesto para componente que esperan ser enlazados o empotrados en un contenedor. IOleObject contiene métodos que permite a los interesados determinar el tamaño de los límites de un componente rectángulo, si el componente soporta operaciones como ‘Open’, ‘Save’ y así sucesivamente.

Clases [editar]

Una clase en COM se denomina coclass, que es la forma contraida de Component Object class. Una coclass es la forma de COM de definir una clase en el sentido orientado a objetos independiente del lenguaje. Una coclass suministra una implementación concreta de uno o más interfaces. En COM, tales implementaciones concretas pueden ser escritas en cualquier lenguaje de programación que soporte desarrollo de componentes COM, como C++, Visual Basic, etc.

Uno de las mayores contribuciones de COM al mundo de desarrollo Windows es la toma de conciencia del concepto de separacion de interfaz de implementación. Esta toma de conciencia ha influido, sin duda, en el camino programadores al construir los sistemas de hoy. Una extensión de este concepto fundamental es el concepto de una interfaz, múltiples implementaciones. Esto significa que en tiempo de ejecución, una aplicación puede elegir la instanciación de un interfaz de uno de las diferentes implementaciones concretas.

Lenguaje de definición de interfaces y librerias de tipos [editar]

Las librerias de tipos contiene metadatos que representan los tipos COM. Sin embargo, esto tipos deben ser primero descritos usando el Microsoft Interface Defnition Language. Esto es la práctica común en el desarrollo de un componente COM, por ejemplo al empezar con la definición de tipos usando IDL. Un archivo IDL es lo que proporciona COM que permite a los desarrolladores definir las clases orientadas a objetos, interfaces, estructuras, enumeraciones y otros tipos definidos por el usuario en un lenguaje de forma independiente. COM IDL es similar en apariencia a las declaraciones de C / C + + con la adición de palabras clave como "interface" y "library" para la definición de interfaces y de las colecciones de las clases, respectivamente. IDL también requiere el uso de los atributos entre corchetes antes de las declaraciones para proporcionar información adicional, como el GUID de las interfaces y la relación entre los parámetros de puntero y longitud de los campos.

El archivo IDL es compilado por el compilador MIDL en un par de formas para utilizarlos en varios lenguajes. Para C/C++, el compilador MIDL genera una cabecera independiente del compilador que contiene definiciones de estructuras que emparejan las funciones virtuales de la declaración de interfaces y un archivo C que contiene declaraciones de la interfaz GUIDs. El código fuente C++ para un modulo Proxy puede también ser generado por el compilador MIDL. Este Proxy contiene métodos stubs para convertir llamadas COM en RPC, esto permitido por el DCOM.

Un archivo IDL puede también ser compilado por el compilador MIDL en una libería de tipos (archivo .TLB). Los metadatos binarios contenidos dentro de la librería tiene significado para ser procesados por los compiladores del lenguaje y entornos de tiempo de ejecución (VB, Delphi, el .NET CLR, etc.). El resultado final de tal procesado TLB es que la construcción específica de cada lenguaje estan producidas a lo que representa la clase COM definida en la .TLB (y en defnitiva el que se defnió en el archivo de origen IDL).

Conteo de referencias [editar]

El más importante de todos los interfaz COM, es decir, IUnknown (de la que todas las interfaces COM debe ser derivados), admite dos conceptos principales: la exploración características a través del método QueryInterface, y la gestión del ciclo de vida del objeto mediante la inclusión de AddRef () y Release (). Conteo de referencias y exploración de característica que se aplican a los objetos (no a cada interfaz de un objeto) y, por tanto, debe tener una implementación centralizada.

Las especificaciones COM requieren de una técnica llamada conteo de referencias para garantizar que los distintos objetos están vivos mientras haya clientes que han adquirido el acceso a uno o más de sus interfaces y, por el contrario, que el mismo objeto esté correctamente eliminados cuando todo código que usa el objeto haya terminado con el y ya no lo requiere. Un objeto COM es el responsable de la liberación de su propia memoria una vez que su contador de referencias se reduce a cero.

Para su ejecución, un objeto COM generalmente mantiene un valor que se utiliza de referencia para el conteo. Cuando es llamado AddRef () a través de cualquiera de las interfaces del objeto, este valor se incrementa. Cuando se llama a Relaease(), este número entero se decrementa. AddRef () y Release () son los únicos medios por los que un cliente de un objeto COM es capaz de influir en su ciclo de vida. El valor interno sigue siendo un miembro de la privado del objeto COM y nunca será accesible directamente.

Instanciación [editar]

COM normaliza el proceso de instanciación (es decir, la creación) de objetos COM, al exigir la utilización de la clase Factories. Para cada objeto COM que se creó, dos parametros asociados deben existir:

• Una clase ID. • Una clase Factory.

Cada clase o CoClass COM debe estar asociado con una única ID de clase (un GUID). También debe ser asociada con su propia clase Factory (que se logra mediante el uso de un registro centralizado). Una clase Factory es en sí mismo un objeto COM. Es un objeto que debe exponer la IClassFactory o IClassFactory2 (este último con la soporte licencias de apoyo) interfaz. La responsabilidad de dicho objeto es la creación de otros objetos.

Una clase Factory suele estar contenida en el mismo código ejecutable (es decir, el servidor de código) como el propio objeto COM. Cuando una clase Factory está llamada a crear un objeto objetivo, este objetivo del objeto es el id de clase que debe ser proporcionado. Así es como la clase Factory sabe qué clase de objeto instancia.

Una sola clase Factory objeto puede crear objetos de más de una clase. Es decir, dos objetos de diferente ids de clase pueden ser creadas por la misma clase de Factory objeto. Sin embargo, esto es transparente para el sistema de COM.

Delegando la responsabilidad de creación de un objeto en objeto separado, se consigue un mayor nivel de abstracción y el desarrollador tiene una mayor flexibilidad.

A fin de que las aplicaciones cliente puedan adquirir las clases de objetos Factory, los servidores COM debe exponerlos adecuadamente. Una clase Factory está expuesta de forma diferente, en función de la naturaleza del código del servidor. Un servidor que está basado en DLL debe exportar un función global DllGetClassObject (). Un servidor EXE que está basado en los registros de clases Factory en tiempo de ejecución a través de la función de la API de Windows de CoRegisterClassObject ().

Programación [editar]

COM es un estándar binario y puede ser desarrollado en cualquier lenguaje de programación capaz de comprender e implementar de sus tipos de datos binarios definidos e interfaces.

Bibliotecas en tiempo de ejecución (en situaciones extremas, los programadores) son los responsables de que entren y salgan del entorno COM, instanciación y conteo de referencias de objetos COM, objetos para consultar información sobre la versión, la codificación de aprovechar las avanzadas versiones de objetos.

Transparencia de aplicaciones y red [editar]

Los Objetos COM pueden ser instanciados y referenciados en un proceso, a través de las fronteras de un proceso dentro de equipo y, a través de una red, usando la tecnología DCOM. Salir del proceso y de los objetos remotos puede utilizar serialización para enviar las llamadas a los métodos y valores de retorno hacia atrás y hacia delante. La serialización es invisible para el objeto y el código usando el objeto.

Críticas

Mensaje de bombeo [editar]

Cuando un STA se inicializa que crea una ventana oculta que se utiliza para la inter-apartamento y entre procesos de enrutamiento de mensajes. Esta ventana debe tener su cola de mensajes regularmente bombeado. Esta construcción se conoce como un mensaje bomba. En versiones anteriores de Windows no hacerlo podría causar en todo el sistema bloqueos. Este problema es especialmente desagradable porque algunas APIs de Windows inicializa COM como parte de su aplicación, lo que provoca una fuga de los detalles de implementación.

Conteo de referencias [editar]

El conteo de referencias dentro de COM puede causar problemas si dos o más objetos están referenciados circularmente. El diseño de una aplicación debe tener esto en cuenta para que los objetos no se queden huérfanos.

Los objetos pueden también dejar activa la cuenta referencias si el COM "caso sumidero" es el modelo utilizado. Dado que el objeto que dispara el evento necesita una referencia al objeto para reaccionar al evento, el conteo de referencias a objeto nunca llega a cero.

DLL hell [editar]

Debido a la ubicación de cada uno de los componentes se almacenan en una ubicación de todo el sistema (el registro de Windows), puede haber una sola versión de un cierto componente instalado. Por lo tanto, COM sufre seriamente del DLL hell, en que dos o más aplicaciones requieren diferentes versiones de un mismo componente.

Windows XP introduce un nuevo modo de registro de objetos COM "Registro libre de COM". Este servicio hace posible que las aplicaciones que necesiten para instalar los objetos COM almacenaran toda la información de registro necesaria para COM registro en la solicitud del directorio, en lugar de en el registro global, en donde, en rigor sólo una única solicitud se utilizan. DLL hell, se pueden evitar mediante Registro-COM libre, la única limitación que se requiere, al menos, Windows XP o posteriores versiones de Windows y que no debe utilizarse para EXE, COM o servidores en todo el sistema de componentes, tales como MDAC, MSXML, DirectX o Internet Explorer.