QBDamage is a permanent exhibition of my Windows programming knowledge. Here is a technical overview of QBDamage. Of course, many concepts found in Windows programming can be transferred to other computing areas.
Programming a Visual Basic 6 control (OCX file) raises many technical issues (some issues explain why such controls are outdated):
The control is represented by a given globally unique identifier (GUID). A
GUID looks like:
{A4DBAC87-D36C-4603-AFB2-BF3B0B5400BB}).
Registering the control means mapping the GUID with the location of the OCX file on the disk. The result is stored in the Windows registry. As a result, the web browser only loads the control from the path found in the registry.
Think about the organization of your program, its object model. Otherwise you will write different objects and functions doing the same thing, and which are in conflict with already deployed versions. This is directly related to the need for registration, because each uncompatible version needs seperate registration and client applications must be built again to comply with the new version.
- Circular references are the only way for objects to communicate effectively between each other. Circular references are more effective than events. Circular references found in QBDamage are for example a map containing units, and each unit is bound to that map in particular. Because 2-way references may prevent programs to free memory (e.g. the memory needed for each unit), some developers try to avoid them. In QBDamage, I tried to handle circular references as best as I can, but you should not worry about them.
See the VB documentation for details about circular references.
- Safety: programmers may hard-code whether their software is 'Safe for initialization' and/or 'safe for scripting'. This means whether Internet Explorer will display annoying warnings each time you try to open a page with the software embedded. QBDamage should be marked at least 'Safe to initialize'.
Hard-coding the safety criterion means implementing the notorious IObjectSafety interface in the control.
This is the most important highlight of QBDamage. With scripts in web pages, or programming tools that support Visual Basic controls, you are nearly able to customize a game engine! Tell it how to manage health, magic points etc, and QBDamage will reflect it on the scenario map! It is possible with only 1 line of code in the most basic case! It is interesting to point out that some programming languages offer the ability to edit code without saving it permanently on a file, without the need to restart execution each time, and without doing any 'visible' compilation. Take advantage of such capabilities to develop your own rules in QBDamage.
- All commands (menus, toolbars) are centralized and processed at a single place in the code. As a result, the implementaton of the following has been extremely simplified, quasi-visual, regardless of what commands to include:
- Docking techniques (this is fashion obviously), splitting.
- XP Themes mostly supported (not in Internet Explorer directly however, unfortunately).
- QBDamage uses the 'old' comctl32.ocx, that shipped with Visual Basic 5. Amazing things can be taken out of it, with very little code (flat toolbars, flat column headers, grid lines and full-row-select in the property grid). The 'old' comctl32.ocx supports XP themes, whereas the 'new' mscomctl.ocx doesn't.
- Open and Save File dialogs directly come from windows, with no intermediate file.
- Scrolling is achieved with true windows scroll bars, not the Visual Basic ones which look ugly. To play with windows scroll bars, subclassing is necessary, even if it is implemented in QBDamage in a very basic form. More sophisticated subclassing techniques for VB6 can be found over the web (see the links).
- Multiple language support: all language resources have been moved to external DLLs and can be translated independently from the main executable.
- I hope user interface elements are compliant with the 'standards' seen in main commercial products (fashion again).
All interface features involve an extensive usage of the Windows functions (API). A strong understanding of pointers, function callbacks and argument passing, and, in a word, a solid background in C, have been therefore more than welcome.
Some portions of the QBDamage engine have been written in C, where less overhead or higher speed is expected (repeated calls to windows DLLs and loops).
I tried to write my own routines to read markup languages... no way. msxml is much faster and more reliable.
Well, I definitely don't have time to rewrite QBDamage completely for the .NET framework. I just know that benefits of the .NET framework will be:
None of these benefits is found in Java, I guess.
Much less code should be needed to perform the same tasks with the .NET framework, since a complete class library is available for use.
The major drawback of the .NET framework is the time it takes to just-in-time compile code at startup and during development/debugging. This compile-time is counter productive, but should be improved with faster machines. The size of the runtime does also not encourage the redistribution of the .NET framework.