Thursday, September 16, 2004

GUI

It stands for Graphic User Interfaces. When Windows was first released in 1985, C was the main programming language and C++ was a new tool. Although OOP was an old concept, for Windows and Microsoft C was the "lingua franca". So, the WIN32S API was conceived as a layer sitting at the top of DOS and Screen controllers boards.

Maybe there was a low level C code to write a pixel to the screen, by using an Assembly routine that lighted on the particular pixel with a particular color. Suppose this can be encapsulated in a simple routine :

void itWillLightAColorOnTheScreen( struct color c , int* x , int* y );

How could this function be implemented? The processor sends a signal to the screen board, we will name it a message. "Hey dear board, check if the pixel is on or off. If not, light on a pixel there with this color." Next, pulses are sent, the microprocessor at the screen board recieves the message (acknowledge it) and puts it in its stack of tasks. Next responds "Dear microprocessor, now I can put that pixel on the screen!". Next it will try and when it gets it responds "I got it bro!". So we have a pixel in the screen. I have no clues of how many lines of Assembly code this would require (I can check at my book at home if you need ;-)) , but assuming WIN32S coders arguments would make us thinking that "true coders" would only write GUIs in Assembly, as it sits at the top of the C WIN32S layer.

Well, let's assume we have that particular function. A code to write a simple line goes below:

#include

struct color {
char* colorname;
int colornumber;
};

void itWillLightAColorOnTheScreen( struct color c , int* x , int* y );

int main() {
struct color c;
int i = 0;
int j = 0;
int InitX = 234;
int InitY = 234;
int FinalX = 500;
int FinalY = 500;
c.colorname = "Blue";
c.colornumber = 234;/*234 is a number picked up randomly ;-)*/
/*Now we are going to create a line*/
for ( i = InitX ; i < FinalY ; i++ ) {
for ( j = InitY ; j < FinalY ; j++ ) {
itWillLightAColorOnTheScreen( c , &i , &j );
}
}
return 0;
}

void itWillLightAColorOnTheScreen( struct color c , int* x , int* y ){
/*Do the thing*/
printf("Good man, I have written that color to the screen!");
}


Now, how do I create a window? Write four lines and connect them. Easy ? Maybe. Next, one should write code to map the serial port where we have a serial mouse. This mouse simply sends a signal to the processor to indicate where the user would enjoy to place the mouse in the screen. Or:

Input( Xuser, Yuser)------> function that maps these coords to the screen and informs the
processor.

If the user presses the button, we assume its state changes to "1", so that the processor might consider that the user wants to launch an event. Next the program should associate the event to the graphical representation and launch the desired event. Thus, it is huge and complex task when we add mulithreading issues, or, the processor simply has lots of other things to handle.

Suppose a programmer shoudl rely on Assembly code and low level design, one would take decades to create a simple program. So the C WIN32S API comes at hand. But then, it is also very complex and it generates large code.

Well, Microsoft encapsulated it in a library, an OOP library named MFC. Microsoft Foundation Classes, which puts WIN32S code (structs, functions, properties, macros) into the OOP standard, so that C++ can come and make it simpler to read. But then, MFC sits at the top of the WIN32S layer and frankly man, it still has some bizarre things like resources , macros and typedefs.

If you want to dig deeper how to create OOP code from C code, I recommend this site:

http://www.relisoft.com

SUN just encapsulates the WIN32S API in an API named Swing, which is an OOP library. However, it loses in terms of performance. However, it is an excellent enviroment for GUI. I can say the same for the other OOP APIs I know, that are Python's Thinker and C# graphic APIs. However they sit at the top of the WIN32S and that low level Assembly code I mentioned.

As an Engineer, I find the solutions that are easy for me and have better results. So, I don't feel like knowing WIN32S or MFC. Charles Petzold, who's known as the WIN32S GUI guru simply says "I prefer C# APIs". Who Am I to disagree? For microcontroller tasks, non GUI and fast calculations C is still the top one. But come on dude, C for GUI development is too much :-) I like RAD tools, especially Borland ones like C# Builder or J Builder. But coding at hand it is funnier. But slower than doing it via RAD ways.

No comments: