Just spent some time figuring this out. It might be useful to others...
Code:
' needed for API call
#define SPI_GETWORKAREA 48
' used to define main form's width/height
#define GAMESKEL_WIDTH 640
#define GAMESKEL_HEIGHT 480
' subroutine called when form needs to be centered
sub CenterForm()
dim screenbounds as rect
dim formtop as long
dim formleft as long
' Get the boundaries of our current screen
SystemParametersInfo( SPI_GETWORKAREA, 0, screenbounds, 0 )
' calculate the top/left corner of the form
formleft = (screenbounds.nleft + screenbounds.nright - GAMESKEL_WIDTH) \ 2
formtop = (screenbounds.ntop + screenbounds.nbottom - GAMESKEL_HEIGHT) \ 2
' ensure top/left corner is actually onscreen
If formleft < 0 then formleft = 0
If formtop < 0 then formtop = 0
' Move the form
SetWindowPos hWnd, 0, formleft, formtop, 0, 0, SWP_NOSIZE Or SWP_NOZORDER Or SWP_NOACTIVATE
end sub
Awesome to see other people doing raw GUI stuff in FB at last.
I am really impressed with the qbasic compatibility on the graphics, etc., but I really want to get the API figured out for the gui and general purpose apps.
It really doesn't make sense to make a highly (or not so highly, but still) graphical app that requires sdl/directx and really doesn't do much.
I have a tendency to write a lot of file conversion routines. Many of which have no gui at all, but just a few command line messages.
steven_basic, right now, 1000101 and I are working on some GUI stuffs. We've got a whole mess of stuff nailed down, including many of the controls, and even menus. Maybe you could join our little mission to perfect a native GUI library for Windows?
@adosorken
Are you gals/guys doing STANDARD or OOP style functions ?
Will it be a complete FRAMEWORK or GUI only ?
GPL/LGPL or Closed Source ?
Windows only, or will it be possible through changing inc or lib files to compile for another OS ?
LIFE IS FULL OF QUESTIONS
The framework is procedural. It will be implemented into the GUI Compiler, which has been codenamed POOP (I'm not kidding). Open source once released, and fuck other OS's as far as I'm concerned. FB doesn't support the level of OOP required to make it like VB does it, so the GUI Compiler fills in where FB leaves off.
Say you've got something like this:
Code:
Button1.Visible = False
the GUI compiler changes that line of code to:
Code:
lresult = ShowWindow(frmMain_Button1.hwnd, SW_HIDE)
or if you have something like this:
Code:
Button1.Caption = "This Button Sucks!"
the GUI compiler changes that line of code to:
Code:
gc_int_tstring = "This Button Sucks!"
lresult = SetWindowText(frmMain_Button1.hwnd, Sadd(gc_int_tstring))
So the user would have a 'mygui.poop' file and the poop gui compiler would translate oop style code into 'normal' win api code and generate a 'mygui.bas' file.
Sounds like a lot of work... 8)
Quote:which has been codenamed POOP (I'm not kidding)
Hehe... You said "poop".
I would like to help, but currently I have very little time for personal projects. ( I am actually in the middle of a vendor show) I could attempt to help as much as I can if you would like to give me some info on what I would need to do.
Quote:So the user would have a 'mygui.poop' file and the poop gui compiler would translate oop style code into 'normal' win api code and generate a 'mygui.bas' file.
Sounds like a lot of work... 8)
It is a lot of work, but not difficult to accomplish. Eric's already working on the WndProc optimizations, and I'm still decking out the various controls.
POOP = Practically OOP.
steven_basic: basically what we need (no pun intended, hehe) is some examples of the more advanced controls in use (for example, ListView looks like a real nightmare, it's hard enough in normal VB let alone through the API). We're trying to duplicate much of the functionality of VB6, so anything that could further the cause is what we're researching. Something simple as a form-centering routine is great.
Also, have you any idea how to determine the size of non-client areas of a window? For example: a window set to 600 pixels tall in XP with styles is going to have a different client area size than the same window in Windows 98...that's a major issue right now.
Quote:Also, have you any idea how to determine the size of non-client areas of a window? For example: a window set to 600 pixels tall in XP with styles is going to have a different client area size than the same window in Windows 98...that's a major issue right now.
I'm not the one who was asked but I can't keep myself shut... :wink:
Code:
BOOL GetClientRect(
HWND hWnd, // handle of window
LPRECT lpRect // address of structure for client coordinates
);
hWnd:
Identifies the window whose client coordinates are to be retrieved.
lpRect:
Points to a RECT structure that receives the client coordinates. The left and top members are zero. The right and bottom members contain the width and height of the window.
this should be one way of getting this info...
If you need more let me know.