🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
winwraplib
Author
I'm not sure if this is the right place for this, but I was wondering where I can find more information on how to use winwraplib. I'm to write an editor for a game project we're working on, and I don't want to use anything bloated for the UI, and winwraplib seems to be what I need. Any info on how it is intended to be used or, preferably, some samples would be greatly appreciated. Also, if you think there are better alternatives (which are free and not bloated), please let me know. Thanks.
P.S: Hopefully we'll be using AngelScript with both the editor and the game engine, yaaayyy!!
A whole game in AngleScript? I see it's uses as a _scripting_ language but as a whole engine development language? This should be interesting.
Author
Quote: Original post by Anonymous Poster
A whole game in AngleScript? I see it's uses as a _scripting_ language but as a whole engine development language? This should be interesting.
lol - sorry if I was ambiguous, but I thought it was obvious. We'll be using AngelScript for scripting, not developing the engine.
I guess I should have provided an example application with the windows wrapper code. Maybe for my next release I'll be able to do that.
Anyway, it's quite easy to use (if you know Win32). A simple application may look like this (this is not a complete example):
I'm pleased to know that you're considering using AngelScript for your project. Let me know when you have something to show so that I can add it to the users list. :D
Anyway, it's quite easy to use (if you know Win32). A simple application may look like this (this is not a complete example):
int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR cmdLine, int showFlag){ CMainWin *wnd = new CMainWin; wnd->Create(512, 512); while( !acCWindow::CheckMessages(true) ) {} delete wnd; return 0;}==================================class CMainWin : public acCWindow{public: CMainWin(); ~CMainWin(); int Create(int width, int height); void Draw();protected: void OnSize(); void OnInitMenuPopup(HMENU menu, int pos, BOOL isWindowMenu); LRESULT MsgProc(UINT msg, WPARAM wParam, LPARAM lParam);};===================================CMainWin::CMainWin() : acCWindow(){}CMainWin::~CMainWin(){}int CMainWin::Create(int width, int height){ HICON hIcon = (HICON)LoadImage(GetModuleHandle(0), MAKEINTRESOURCE(IDI_ICON1), IMAGE_ICON, LR_DEFAULTSIZE, LR_DEFAULTSIZE, LR_SHARED); HICON hIconSmall = (HICON)LoadImage(GetModuleHandle(0), MAKEINTRESOURCE(IDI_ICON1), IMAGE_ICON, 16, 16, LR_SHARED); int r = RegisterClass("MainWnd", 0, 0, hIcon, hIconSmall, AC_REGDEFCURSOR); if( r < 0 ) return r; r = acCWindow::Create("PUPP", width, height, WS_OVERLAPPEDWINDOW | WS_VISIBLE, 0, 0, "MainWnd"); if( r < 0 ) return r; SetMenu(MAKEINTRESOURCE(IDR_MENU)); SetAccelerator(MAKEINTRESOURCE(IDR_ACCELERATOR)); return 0;}void CMainWin::Draw(){ PAINTSTRUCT ps; HDC dc = BeginPaint(hWnd, &ps); RECT rc; GetClientRect(hWnd, &rc); FillRect(dc, &rc, (HBRUSH)GetStockObject(DKGRAY_BRUSH)); EndPaint(hWnd, &ps);}void CMainWin::OnInitMenuPopup(HMENU menu, int pos, BOOL isWindowMenu){}LRESULT CMainWin::MsgProc(UINT msg, WPARAM wParam, LPARAM lParam){ switch( msg ) { case WM_SIZE: OnSize(); return 0; case WM_CLOSE: DestroyWindow(hWnd); return 0; case WM_DESTROY: PostQuitMessage(0); return 0; case WM_PAINT: Draw(); return 0; case WM_INITMENUPOPUP: OnInitMenuPopup((HMENU)wParam, LOWORD(lParam), HIWORD(lParam)); return 0; case WM_COMMAND: switch( LOWORD(wParam) ) { case ID_APP_EXIT: DestroyWindow(hWnd); return 0; } break; } return DefWndProc(msg, wParam, lParam);}void CMainWin::OnSize(){}I'm pleased to know that you're considering using AngelScript for your project. Let me know when you have something to show so that I can add it to the users list. :D
Author
Thanks for the quick reply. But I think I will bug you some more :)
Let me see if I get this straight. acCWindow::CheckMessages() checks messages for all windows in the application and, since we can get a pointer to the window class from HWND, each window's MsgProc() method is called. To customize a window, we override MsgProc() and because it's virtual, the overridden version is called. When we derive from acCWindow, we can add methods to handle different events, and these methods should be called by the MsgProc() method of our new class.
What I still don't understand is how to use controls (acCButton, for example). Also, what is this DrawItem() method in acCWindow for? What's the Subclass() method for? What steps are necessary to create our own custom controls? I'm not asking for detailed information, and I fully understand that this is just a thin layer above the win32 API (that's why I like it). I just want some headlines describing the design of the library - how the components relate to each other, to win32, and how they fit in the application. In other words, information like the stuff I said in the previous paragraph. Or... you could just throw in another code snippet showing how to put a button on a window and we'll call it a day :D
Thanks again.
Let me see if I get this straight. acCWindow::CheckMessages() checks messages for all windows in the application and, since we can get a pointer to the window class from HWND, each window's MsgProc() method is called. To customize a window, we override MsgProc() and because it's virtual, the overridden version is called. When we derive from acCWindow, we can add methods to handle different events, and these methods should be called by the MsgProc() method of our new class.
What I still don't understand is how to use controls (acCButton, for example). Also, what is this DrawItem() method in acCWindow for? What's the Subclass() method for? What steps are necessary to create our own custom controls? I'm not asking for detailed information, and I fully understand that this is just a thin layer above the win32 API (that's why I like it). I just want some headlines describing the design of the library - how the components relate to each other, to win32, and how they fit in the application. In other words, information like the stuff I said in the previous paragraph. Or... you could just throw in another code snippet showing how to put a button on a window and we'll call it a day :D
Thanks again.
I haven't implemented a Create method for the button class (since I never needed one) so unless you want to modify the code in the library you would do it like this:
I recommend you change the library code to add functions you normally use however, such as the Create method for acCButton. That's what I would do.
I rarely use the acCButton class myself though, as there's almost never anything I want to change about the standard window button.
The DrawItem method is for ownerdrawn controls. It's a way to implement the WM_DRAWITEM message sent to the parent window for the ownerdrawn controls.
You're welcome to ask as many questions you like. I put up the library on the site to get feedback on it, and questions are a form of feedback so I'm grateful for them. :)
Regards,
Andreas
acCButton button; // Declare this as a member of your window// Create the button using normal Win32 codeHWND btn = CreateWindow("BUTTON", "Press me", BS_PUSHBUTTON|WS_VISIBLE|WS_CHILD, 0,0,100,30,hWnd,IDC_BUTTON,0,0);// Subclass the button message procedure. This allows your class to override // the messages you want to processbutton.Subclass(btn);I recommend you change the library code to add functions you normally use however, such as the Create method for acCButton. That's what I would do.
I rarely use the acCButton class myself though, as there's almost never anything I want to change about the standard window button.
The DrawItem method is for ownerdrawn controls. It's a way to implement the WM_DRAWITEM message sent to the parent window for the ownerdrawn controls.
You're welcome to ask as many questions you like. I put up the library on the site to get feedback on it, and questions are a form of feedback so I'm grateful for them. :)
Regards,
Andreas
Author
Hello again. This time I'm going to point out a little problem I've encountered using the library and how to fix it.
The code you posted above for using the acCButton class is not so good. The problem is that you create the button window using ::CreateWindowEx(), and then subclass it (replacing the "BUTTON"'s class window processor with the static acCWindow::WndProc() which practically just forwards the message to acCButton's window proc). The problem with this approach is that acCButton's msg proc will not be used except after the button's window has been created, and so a few messages will get "lost".
The best solution, I think, is to modify the hook procedure's code to Subclass() the passed HWND instead of Attach()ing it. That means replacing the class's msg proc before the window is created instead of after. This is necessary only for window classes which have a message processor other than acCWindow::WndProc(). These include all controls and other classes provided by the system. So the hook procedure should look like this:
What do you think?
The code you posted above for using the acCButton class is not so good. The problem is that you create the button window using ::CreateWindowEx(), and then subclass it (replacing the "BUTTON"'s class window processor with the static acCWindow::WndProc() which practically just forwards the message to acCButton's window proc). The problem with this approach is that acCButton's msg proc will not be used except after the button's window has been created, and so a few messages will get "lost".
The best solution, I think, is to modify the hook procedure's code to Subclass() the passed HWND instead of Attach()ing it. That means replacing the class's msg proc before the window is created instead of after. This is necessary only for window classes which have a message processor other than acCWindow::WndProc(). These include all controls and other classes provided by the system. So the hook procedure should look like this:
// staticLRESULT CALLBACK acCWindow::CreateProc(int nCode, WPARAM wParam, LPARAM lParam){ if( nCode == HCBT_CREATEWND ) { if( wndCreator ) { // If the msg processor of the window class is acCWindow::WndProc already, // then there is no need to subclass it. In fact, subclassing it causes // a stack overflow for some reason (??!!). if( GetWindowLong( (HWND)wParam, GWL_WNDPROC ) == (LONG)acCWindow::WndProc ) wndCreator->Attach( (HWND)wParam ); else wndCreator->Subclass( (HWND)wParam ); } // Unregister the hook procedure here HookCreate(0); // Return 0 to allow continued creation return 0; } return CallNextHookEx(hCreateHook, nCode, wParam, lParam);}What do you think?
That might work. If you really need to process these messages then you need to do it something like what you suggested.
A more common scenario though is that the button is created from a Dialog template, in which case you don't have access to the button until after it has been created in either case. In which case the way I suggested is sufficient.
In most cases you probably never need to subclass the button procedure anyway. I haven't used the acCButton class in many years, the only time I used it was where I wanted to override the looks of it (not it's behaviour).
Regards,
Andreas
A more common scenario though is that the button is created from a Dialog template, in which case you don't have access to the button until after it has been created in either case. In which case the way I suggested is sufficient.
In most cases you probably never need to subclass the button procedure anyway. I haven't used the acCButton class in many years, the only time I used it was where I wanted to override the looks of it (not it's behaviour).
Regards,
Andreas
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
