Visual GWin++ Documentation

• Project Home Page
• About This Project
• Project Goals
• GWin Class
• Getting Started – The Visual GWin++ IDE
• To Do
• Known Bugs
• Developer’s Info

About This Project
The aim of this project is to develop an open source Visual Development Environment for the Win32 platform that generates compilable C++ code. It was started in the summer of 2004 as a hobby. It is based on the class ‘GWin’ which handles most of the window functions. To let you know a little of my background in developing this, I started with no first hand experience creating an object oriented program. Before this project I had also never created a Windows program that was more than a couple of files. And my experience with visual development environments was about thirty minutes exposure to Visual Basic when I was 14. I have no background experience in what I am doing and would greatly appreciate any help that I could get. Specifically, I need help developing the overall design of the GWin class so that it will be portable and flexible and allow programmers to use it for what they would normally need every day. Basically, I need help in structuring. This project was developed in Bloodshed’s Dev-C++ Compiler (v4). It includes the gcc compiler version 2.95.2 (Which I stole from Dev-C++).

Project Goals
The overall goal is to create a stable, complete Visual Development Environment for Win32 platforms encompassing all windows common controls, providing the ability for reusable components, and being completely open source. The immediate, short-term goals for this project are to develop a stable code base, standards for developing the GWin Class, creating GWin from within itself, and the ability to save projects to files (doh!).

GWin Class
Note: This is pre-alpha software. No standards have been set as to the final design or implementation. If you create any software with this program, it may not be compatible with future versions. This is the core of the window management. It is surprisingly (even to myself) stable. I have used it to create full applications and it did not crash on me. I have left it running for days with no ill effects. (Please see Known Bugs though). I have taken great care to make this stable and if you find a bug, please report it. This class creates windows, handles messages, sizing, properties, etc. So far it contains just a few basic controls. GWin currently supports windows, buttons, tab controls, static boxes, mdi clients, edit boxes, and list boxes. To use the class, create an object of type GWin, and specify the type of window you would like it to be. For example:


GWin mybutton("BUTTON");


Valid types are ‘BUTTON’,’TABCONTROL’,’STATIC’,’MDICLIENT’,’EDIT’,’LISTBOX’, and ”. The empty type creates a regular window. The GWin class member wincl is a WNDCLASSEX structure that can be modified for the creation of a regular window. The lpfnWndProc is set to GWin::WndProc which allows for easier handling of messages.

Many messages can be sent to windows (or other actions performed) using GWin’s functions. Just check in the appropriate section of gwin.h for the corresponding type of window and see if the function that you want has been implemented. If not, implement it yourself and submit it for inclusion. If you would like, you may use the getWindowHandle() function to get the HWND handle of a window using in standard Windows functions.

Window events are handled by the GWin function GWin::WndProc which is the universal callback procedure for GWin instances. GWin has a list of variables for different events to be used to point to your applications’ event handlers. To do this, just make an assignment of a function address of type LRESULT func_name(GWin * win, UINT message, WPARAM wParam, LPARAM lParam). Then you could take that mybutton object and set mybutton.onClicked = bclicked_func;. Then use a Win32 reference to determine the parameters and return values of BN_CLICKED. Note that the GWin * win that you receive as a parameter in this function will be &mybutton, not mybutton’s parent from WM_COMMAND. For portability, use the win-> reference as much as you can to replace mybutton. in these functions.

For more information, please see gwin.h and gwin.cpp.

Getting Started – The Visual GWin++ IDE
Note: There are two bugs that you should know about. Please see Known Bugs before using. To overcome the Tab problems in the Properties Box, just keep changing tabs until everything shows up normally. You should also not install the software into a path that has a space in it. It won’t work properly. Please edit project.cpp’s build functions to support this.

Ok, so now run the program. (Isn’t it beautiful? – If you don’t think so hot shot, why don’t you try improving it. I haven’t seen your version of a Visual C++ IDE anywhere.) Visual GWin++ is based on the concept of Forms. It has two types of forms. Regular forms, and source forms. A source form is basically just a form.cpp and a form.h file, no visual form. A regular form is a visual window. To create a new form, click on Form->New Form or Form->New Source. Once you have created a regular form, you may add controls to it. When creating a new control, whichever control or window has the current focus will become the parent of the new control. Parents cannot be changed at this time (add this feature if you want it). If you would like the messages of a control to be processed, you must put it on a regular window. Controls such as edit boxes, tab controls, etc. do not report messages that they receive from children. If you know of a workaround for this please submit it. Tabs can only have tabcontrols as parents.

So go ahead, create a control. Move it to where you want it. Now re-select the form to make sure that it will become the parent of the next control that you create. Create another control. Select a control and change its styles. (Refer to a Win32 guide for information on styles.) Choose the events tab and you will see a list of events available for that control. Remember that function that we talked about having to create to handle events, Visual GWin++ will do ths for you. Just make sure that you return the appropriate value for the messages that you handle. If you want to handle a message not in the list, use the onEvent event and check for that message type. If you use onEvent, you must return GWin::defWindowProc if you do not process the message.

If the first form that you create is a regular form, it will be enclosed in a WinMain, and created within that WinMain upon compilation of the project. If you do not want this to happen, make your first form a Source form. You can access the .h and .cpp files of a regular form. To do this, go to Form->Edit Header and Form->Edit Global, respectively. If you are having trouble selecting a control, or need to change tabs, use the Select Control option from the form menu. If the form becomes distorted during editing, choose Form->Reload to re-create it.

The File menu has options for the entire project. From there you can edit the resources file, select a particular form to work on, delete a form, change project options, create compilable C++ code (and Makefile), create compilable code and compile it, and create compilable code, compile it, then run it.

If you want to access one form from another form, make sure to include the form’s .h file (form_name.h) in the global (Form->Edit Global) area. Then make sure that the .h file includes proper references to the elements that you want to reference.

Make a test application. Open Visual GWin++. Create a new form. Go to the events, find onClose and click it. Make it display a MessageBox() that asks if you want to close. If Yes, do win->Destroy();. If no, just return 0;. Build, Compile, and Run this project. Try to close the window, answer the question, and watch the results.

To Do
Please note that any submitted code that does not appear to clean up memory or check bounds properly will be IMMEDIATELY discarded. In a development environment, stability is crucial. I don’t care how cool your addons are, please document them well and show where memory is created and destroyed and where bounds are checked.

Well, a lot. Mainly at this point, we need to create a way to save projects to files and be able to re-open them later on. For this we would like to use libxml2 to create an xml formatted file for each Form with a main project file that would list all of the Forms. This would allow someone to easily copy a single xml file and import a form into another project. Of course, I am open to other ideas as well.

We need to develop more structore for the GWin class. I do not know a lot of Windows programming and would appreciate guidance in making this class better. No, I do NOT care about optimizations right now. I know that a lot of optimizations need to be done, but functionality first, optimization second. There’s a lot of work to be done.

Documentation needs serious help. Someone could help to write a basic documentation structure that the rest of us could follow.

More controls! We want to include as many controls as possible. This is not limited to Windows controls. If you know of or have created your own custom controls, submit those as well. We’ll have to set some standards for this at some point so if you are the first to submit, you may set the pace for the rest.

We need to finish implementing methods for controls. There are a lot of actions that can be performed on the existing controls and there are no functions for doing this. Making some functions for these would be fantastic. Most of them are one-liners and are just convenient in that you don’t have to call the getWindowHandle() for an object.

Known Bugs
There is a bug in the GWin class due to the way window classes are registered. When a window is created, the class is registered. When the window is destroyed, the class should be unregistered, but is not properly unregistered. I have tried to work with this and I cannot figure out why this happens. It is noticeable in the properties dialog box at times when you are switching tabs.

I don’t know if New Project works. Don’t bother to use it. Just close the application and re-start it for now. Ok, I just tested it – it doesn’t work. It is probably due to the deletion and creation of Project objects, but the class is simple and can probably be fixed easily. It will become more important as we gain the ability to save projects, but for now I don’t care. I have other things that need my attention.

I have seen distortion occur on a window when switching between multiple desktops using Microsoft’s Virtual Desktop addon in Windows XP.

Developer’s Info
edit_global.cpp/.h – Edits a form’s Global or .cpp file.
edit_header.cpp/.h – Edits a form’s Header or .h file.
edit_resources.cpp/.h – Edits a project’s resources file.
form.h – defines the Form class.
form.cpp – form handling for run-time of Visual GWin++.
form_build.cpp/.h – used for building a form into a .cpp file.
gpl.h – defines a constant of the GPL version 2.
gwin.cpp/.h – the heart of this software, use for documentation of GWin’s abilities.
main.cpp/.h – startup, menus, basic handling and program control.
new_control.cpp/.h – dialog for a new control.
new_form.cpp/.h – dialog for a new form.
new_project.cpp/.h – dialog for a new project.
project.cpp/.h – class for managing the Project.
project_options.cpp/.h – dialog box for the project’s options.
rsrc.h – includes for our resources.
rsrc.rc – resource file.
select_control.cpp/.h – allows the selection and bringing to focus of a control on the current form.
select_form.cpp/.h – allows the selection of any particular form.

Don’t bother modifying dialogs. We will re-create this project from within Visual GWin++ as soon as saving support is available.