Cita de: eferion en 10 Abril 2015, 08:24 AM
Si por "usuario" quieres decir "programador" te tengo que corregir. No es invisible al programador.
Para que tu programa pueda mostrar una interfaz gráfica necesitas que tu código se conecte con la API correspondiente del sistema operativo que se encarga de gestionar la interfaz de usuario del sistema operativo. Lo que sucede es que normalmente no trabajas directamente sobre la API del sistema operativo, sino que haces uso de una librería que alguien se ha molestado en programar, y que te permite crear interfaces gráficas de una forma más sencilla.
En el caso de Delphi, la librería gráfica es la VCL (Visual Component Library). Además, tienes la "suerte" de que esta librería la proporciona Borland por defecto junto con el IDE, pero aunque no tengas que preocuparte por cómo funciona la clase "Button" de la VCL, has de saber que siempre vas a poder crear tus propios controles gráficos... y para poder hacer eso tienes que conocer cómo funciona esta librería.
En el caso de VisualBasic, la librería gráfica es la MFC (Microsoft Foundation Class). Tienes la "suerte" de que esta librería, al igual que la de Delphi, la proporciona Microsoft por defecto junto con su IDE.
En cualquier caso, has de saber que siempre tienes la opción de trabajar directamente con la API... al fin y al cabo cualquier componente gráfico se va a acabar apoyando antes o después en dicha API.
¿Por qué estoy tan seguro de que todo pasa por la API del sistema operativo? Muy sencillo. Si cada aplicación crease su propio gestor de ventanas sería imposible que pudieses visualizar varias aplicaciones a la vez en la pantalla del ordenador. Para que esto sea posible es necesario que exista un gestor común que se encargue de decidir qué ventana está encima de otra, con qué control está interactuando el usuario en cada momento, a qué control le llega el "foco" cuando el usuario manipula el ratón, etc.
En cuanto a cómo lo hacen con el bucle de mensajes... a ver, normalmente cuando se crea una aplicación con interfaz gráfica, se especifica una función que será la encargada de recibir todos los mensajes por parte del SO. En esta función se encapsula una secuencia de "if" para capturar todos los mensajes importantes para la aplicación. Cuando se recibe un mensaje que es reconcido por la aplicación, el código de esta función acaba llamando a un método concreto de la aplicación para que ese mensaje sea correctamente procesado.
Un ejemplo. Tienes una aplicación con dos botones (A y B), y quieres que al presionar el botón A aparezca un texto en pantalla. Entonces en el bucle de mensajes tienes que "escuchar" un mensaje de tipo "BOTON_PRESIONADO"... además, tendrás que asegurarte de que el botón presionado sea el A. Si todo lo anterior se cumple entonces el bucle de mensajes tiene que llamar a la función BotonAPresionado. Esta última función será la que muestre el mensaje por pantalla y, tras esto, la ejecución volverá al bucle de mensajes a la espera del siguiente mensaje.Código (c) [Seleccionar]#define BOTON_PRESIONADO = 0x01
#define A = 0x01
#define B = 0x02
void bucleMensajes( int mensaje, int control )
{
if( mensaje == BOTON_PRESIONADO && control == A )
BotonAPresionado( );
}
void BotonAPresionado( )
{
// Mostrar mensaje en pantalla
}
El problema de trabajar a tan bajo nivel es que mantener ordenado la función del bucle de mensajes puede ser bastante complicado... las librerías gráficas te abstraen de esta parte, ya que ellas solas son capaces de configurar el bucle de mensajes en base a la configuración que tu ventana.
sí, me equivoque , era programador.
Lo de invisible me refería justo a eso , en delphi o vbasic el programador no trabaja directamente con la pi y no necesita saber como funciona internamente los componentes, todo está encapsulado, se apoya en las librerias, solo debe programar en los eventos on_click , on_mousemove y todo funciona de maravilla.
mi duda era como se llevaba a cabo eso de crear los componentes o esa palabrita "encapsular", porque si antes o despues se tienen q apoyar en las apis, entonces los diseñadores de esos controles tambien habran usado las apis , como "meterias" un bucle de mensajes para cada control o ventana dentro de una clase sin "atascarse", si el bucle siempre da vueltas hasta que se cierre una ventana, en que momento se ejecutaria los bucles de las demas ventanas?
Código [Seleccionar]
class ventana
{
private:
void buclemensajes()
public:
};
void ventana::bucleMensajes( int mensaje, int control )
{
BOOL bRet;
//me quedo atascado en este while de la clase y no podre salir de la clase hasta que se cierre esta ventana :P y no podre ejecutar los otros bucles
while( (bRet = GetMessage( &msg, hWnd, 0, 0 )) != 0)
{
if (bRet == -1)
{
//salir
}
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
}
}
