Unbreak my code, say it will work again ...

April 03, 2005

approximately 1 minutes to read

Today, I was cleaning up the code, trying to get the report page work again. Got it working finally :) The report wizard consists of two pages, the first one allows to choose the module, and the second is for entering details. One thing I don’t like that much is that I have to call API::getClass('Bug'); in order to call Bug::createNew(), but I don’t think there is a much cleaner or better solution (moving static code from the bug class into a bug module would just cause confusion).

Roadmap

A quick, updated roadmap for the next week:

Get the broken code working again - mainly, bug edit should work
Finish merging project and module overviews into a new, unified overview page
Add project/module administration
Fix up the base/child JScript select code
A tabbed menu system

The long term roadmap includes:

Notification system
Rights management
Statistics module
Support for several languages

Hopefully I’ll be able to finish those next week, as I plan to stop active development on the bugtracker in two weeks. I’ll keep on fixing bugs, but I’m going to focus on my 3D engine.

Bugtracker on SVN

The complete bugtracker source code is now in a dedicated Subversion repository. Later, I’m gonna open this repository for a friend so he can keep on maintaining the bugtracker while I’m working on the 3D engine.

ADOdb & custom error handler

After adding a custom error handler to my bugtracker, the ADOdb library didn’t work properly any longer - debug output caused a script error. All other functions worked right. This was with ADOdb 4.4x, today, I upgraded to the latest (4.54) and it stopped working at all. Fortunately, I found a solution: I include ADOdb before setting up my error handler. This seems to work fine so far, no errors while including ADOdb, and yet it does call my custom handler when an error occurs later.