The GUI library for Aurora has two flavors. One for Linux and one for Windows. The goal is to keep functions and classes as identical as possible on both platforms.
There will be differences that can be accounted for by using the preprocessor so that one code base can be maintained, and subsequently compiled on both OS's.
The GUI library is designed as a heirarchy of derived classes providing the basic set of functionality needed to work with windows, menus, controls, etc. Extensions to the classes are easily provided by deriving your own class from one of the built in base classes.
Besides the built in classes there is nothing preventing you from using the Windows API directly, of course doing so means your program will only compile and run on a Windows machine.
Paul.
I sense some GUI stuff is close then :P
Lewis
Working on the base classes as we speak. The compiler is now far enough along to create fully working, useful classes.
Great news Paul.
Kepp up the good work
Lewis
Now that things are settled down at my outside job you'll see faster updates now. Having a lot of fun now.
Using classes alliviates the need to use alternative names for standard structs, and aliasing API functions. For example in my other language I had to call RECT WINRECT because of the conflict with the command. Class methods don't conflict with the outside world so you can name them whatever you want.
Here is some example code I am working on.
window mywindow;
mywindow.Create(10,10,100,100,AWS_SIZE | AWS_MAXBOX, 0, "Test window",NULL);
mywindow.DrawRect(20,20,50,50, RGB(0,0,0));
PumpMessages();
To handle messages you can derive a class from 'window' and through the magic of virtual functions override only the message handlers your window needs.
class canvas : window
{
declare virtual OnMouseMove(int x, int y, int flags),int;
declare virtual OnLButtonDown(int x, int y, int flags),int;
}
canvas :: OnMouseMove(int x, int y, int flags),int
{
//handle mouse move messages
if(flags & 1) //left button is down
SetPixel(x, y);
return true;
}
canvas :: OnLButtonDown(int x, int y, int flags),int
{
//handle left button down
return true;
}
global sub main()
{
canvas mywindow;
mywindow.Create(10,10,100,100,AWS_SIZE | AWS_MAXBOX, 0, "Test window",NULL);
mywindow.DrawRect(20,20,50,50, RGB(0,0,0));
PumpMessages();
return;
}
Using 'window' as the base class of 'canvas' gives it all of the functionality of the base and allows you to extend the window class. That is the elegance of OOP. You don't need to know how the window class does its job in order to derive a new class from it. When the 'mywindow' class is destroyed, automatically at the end of the subroutine, or when using DELETE on an instance created with NEW, it calls the class destructor. Which closes the window and cleans up. The 'window' class has a Destory member that can also be used to close the window.
mywindow.Destroy();
Enough jabbering for now...back to work.
Paul.
Will there be a way to write my own Destroy() to prompt for saving files, etc, and then call base.Destroy(); ?
Wow this is so cool. I cant wait to get stuck into this. Ive never done any other programming other than IBasic so this is all very exciting for me.
Lewis
What is PumpMessages() ? i guess it has something to do with handling window messages.
Thanks
Lewis
Okay, Paul, I know you'll shoot me for this but... any chance of supporting ActiveX controls? ;D
I'd assume PumpMessages() is the GetMessage, TranslateMessage, DispatchMessage part you see in plain API programs. Will there be support for the ::MyMethod syntax, so if I have a method outside called Create taking the same parameters as the window one, I can distinguish between them with ::Create() vs Create().
Questions, questions ;)
-Destroy is virtual but you would want to prompt for saving files in OnClose. Then you can chose to continue or close the window.
-PumpMessages is just a temporary function to process messages and wait for a WM_QUIT message.
-ActiveX and COM are extensions of OOP. So anything is possible.
-Haven't decided on the scope resolution operator yet. C++ uses the double colon to specify either class scope or global scope. Might use a single character.
Paul.
There will be an update this weekend with the first GUI code available.
After a couple of redesignes I have decided to leave most of the decision making to the programmer, and not Aurora. There were cases where IBasic did a little too much for you regarding messages, window creation, etc.
Here is a simple window example of deriving a class from the base 'window' object and handling the close button.
class mywindow : window
{
declare virtual OnClose(),int;
}
mywindow::OnClose(),int
{
Destroy();
return TRUE;
}
global sub main()
{
mywindow w;
w.Create(0,0,300,300,AWS_CAPTION|AWS_VISIBLE|AWS_BORDER|AWS_SYSMENU|AWS_AUTODRAW,0,"test window",NULL);
do {
wait();
}until w.m_hwnd = 0;
return;
}
Window styles are mapped to the particular OS they are meant for. You'll notice I use positive logic now in regards to styles. Meaning you won't get a caption, border, etc. unless you ask for it. Autodraw windows work and instead of turning them on by default you need to specify the AWS_AUTODRAW style.
This will make converting code found on the net a wee bit easier.
We still need more testers. If you have been holding off buying the alpha until the GUI library was working then now is the time. So far there are only 8 of us testing the code, with lewis catching the most bugs ;)
Paul.
Oh great, this weekend. Ive been getting quite excited about this.
Does aurora use the same Window UDT as in IBasic? I ask this because i saw the until w.hwnd = 0.
Thanks
Lewis
It's a window class, not a struct. But classes are derived from structs so you could sy it has many of the same variables. ;)
m_hwnd is a member variable of that class.
Paul.
Sorry Paul, thats what i mean, did it have the same member variables as the IBasic Winow UDT.
Lewis