head.gif (2436 bytes) Latest source from CVS My Binaries My sourcecode

Contact me at :
FahimF@email.com

11 July 99

I had to attend a party and wasn't at home most of the day. So didn't get any coding done today at all. So I still need to look at all the buggy stuff that has gotten into the source recently. Oh well ...


10 July 99

I know, I know ... updates have been noticeable by their absence <g> But the problem was that I was so busy with the source codes and real life stuff that I just didn't have the time to update the pages. Anyway, I spent most of the day working on the source codes for all three modules that I've released so far - LSTasks, LSTicker and LSDesk - as I wanted to clean up and update them all.

I just realized how much of a greenhorn I must have been at LS coding when I started up because my first module LSTasks looks so crude to me now :-)

I learnt somewhere on the Net that if you create a DC by using CreateCompatibleDC and select a bitmap into it, that you should save the original bitmap and select it back into the DC before you delete the DC or that GDI leaks could occur. I had been trying to locate a GDI resource leak in LSDesk for the longest time and I thought that this might be the reason. So, I decided to fix the problem everywhere - including the LS sources and that took care of the whole day.

I heard from several people about their popups not behaving properly with the latest binaries I'd uploaded yesterday and with jugg's help managed to discover that the problem was in the transparency code somewhere. If you use NoPopupTransparent in your Step.Rc the problem disappears. I set finding the exact problem and correcting it till later as I needed to finish the stuff I was doing.

Finally got everything done by evening but discovered that the selecting of the old bitmap broke the popup painting code and had to revert to the old code for the popups. I need to find out what that is about too ...


09 July 99

Well I have been busy indeed with Bounds Checker as I promised yesterday. I found memory leaks in the core modules ranging from Desktop to Popups to LSTime to LSAPI. Some were insignificant while others could be quite significant and so, I set about plugging all the leaks that I found. Incidentally, I found some leaks in some of the modules I've written (as well as done certain modifications to them as I went on) and I probably will be devoting the next few days to releasing new version of LSTasks, LSTicker and LSDesk.

Anyway, here are the leaks that I found and reasons why they occurred and how I fixed them. The first leak I found was in LSTime. The offending section was:

HDC thdc = CreateCompatibleDC(themePic.picDC);
...
if (curTimeTheme.bBackground && themePic.usePic) {
	...
	DeleteDC(thdc);
}

Looks inoffensive enough right? Well the problem was with the DeleteDC statement being inside the if loop as if the loop was not entered, the device context handle doesn't get deleted. So all I did to fix the leak was change the code to:

HDC thdc = CreateCompatibleDC(themePic.picDC);
...
if (curTimeTheme.bBackground && themePic.usePic) {
	...
}
DeleteDC(thdc);

Simple huh? :-) Well the next problem was in LSAPI where two similar code sections were tagged as creating a resource leak. The code snippet was:

HRGN h = ExtCreateRegion(NULL, sizeof(RGNDATAHEADER) + (sizeof(RECT) * maxRects), pData);
if (hRgn) {
	CombineRgn(hRgn, hRgn, h, RGN_OR);
	DeleteObject(h);
} else
	hRgn = h;

By now, being the seasoned veteran of memory leaks I was <g>, I knew the problem was in the if conditional loop and changed the code to:

if (hRgn) {
	h = ExtCreateRegion(NULL, sizeof(RGNDATAHEADER) + (sizeof(RECT) * maxRects), pData);
	CombineRgn(hRgn, hRgn, h, RGN_OR);
	DeleteObject(h);
} else
	hRgn = ExtCreateRegion(NULL, sizeof(RGNDATAHEADER) + (sizeof(RECT) * maxRects), pData);

While this fixed that particular problem, the same code segment generated a resource leak in Popups in the next iteration of Bounds Checker. I checked further to find that the code segment was part of the following function:

HRGN BitmapToRegion (HBITMAP hBmp, COLORREF cTransparentColor, COLORREF cTolerance, int xoffset, int yoffset)

And that the hRgn variable was being returned by BitmapToRegion to the caller thus:

titleBMP.region = BitmapToRegion(titleBMP.bitmap, RGB(255,0,255), 0x10101010, 0, 0);

Now titleBMP in the code above was an instance of the class BitMP and when I checked the destructor for the class, I found that it wasn't deleting the member variable "region" which was of type HRGN and hence the memory leak. So all I had to do was introduce the following into the destructor codd:

if (region) {
	DeleteObject(region);
	region = NULL;
}

Then came another error in Popups. The code segment was:

T *pOldList = data;
int inc = (num > 0) ? num : increment;
_ASSERT(inc > 0);
data = new T[allocated + inc];
allocated += inc;
memcpy(data, pOldList, sizeof(T)*count);

This was simply because the previously allocated memory for "data" wasn't being freed. So I added the following line after the code snippet above:

delete [] pOldList;

I couldn't fathom the errors that popped up for Desktop and VWM but they seemed to sort themselves out once I fixed the other errors - so maybe they were related in some way or maybe it was just Bounds Checker being confused :-) Anyway, my final iteration of running LiteStep under Bounds Checker showed no memory leaks at all and so you've got a brand new binary which is certified (at least till the next coded change <g>) to be mem leak free. Enjoy!


08 July 99

I am sorry about not updating the journal for the 8th on the 8th <g> because I was really busy. As some of you may know, I'm currently looking for employment and one of the prospective employers needed me to know C/C++ dev tools in the UNIX environment. As I had had no prior experience with developing under UNIX at all, I spent most of the day messing around with Cygwin which provides a UNIX environment under Windows. So sorry fellows, no update today.

I did spend the evening running the LS code through Bounds Checker and found quite a few resource leaks in many of the components from Desktop to VWM to Popups. So I am still in the process of plugging the leaks and cleaning up the code but as the code isn't stable yet, no binary. Sorry! But maybe tomorrow ...

I just discovered that I had corrected the wrong binary being on the server but had uploaded it to the wrong directory. So all of you who tried to get PopupBackImage working couldn't because it wasn't the right binary. I am extremely sorry ... now the stuff is in the correct place - just blame it on trying to attend to real life and trying to do LS dev at the same time :-)


07 July 99

Update: William Cotton pointed out that I probably had the wrong binary ZIP file up and I indeed did. I've corrected the problem since then. Apologies to all who laboured with the slow connections at Tripod to download the files before.

I had been having crashes every time I tried to recycle or quit LiteStep for a couple of days and on investigation, the problem proved to be the following line in Lsapi.C in the CloseRC function:

free(BangAdded[loop].name);

Now this line was simply releasing the memory allocated for the "name" variable and shouldn't be causing a problem. So I looked at the portion where the memory was being allocated for "name" - in the AddBangCommand and AddBangCommandEx functions in Lsapi.C and I found the culprit in AddBangCommand. For some reason, the relevant code segment there was written thus:

char * temp;
...
temp = malloc (strlen (command) + 1);
strcpy (temp, command);
BangAdded[Bangs].name = temp;
...
free(temp);

The offending line was the last one which freed the "temp" variable as that basically freed the "name" variable as well because it is simply a pointer to a char type. I took out the last line the segment above and everything was OK with recycling and quitting.

Syntruth had e-mailed me again giving me more information on how WindowMaker themes implemented full images for Popups and I decided to see whether I could do something similar for the LiteStep Popups as that should give something for the themers to play with :-) The first thing I realized was that now there were so many options for painting the Popups that I had to find some way to keep track of the method that was being used. So I introduced a new enumerated type called Style and a variable of that type called popStyle.

enum Style {ps_colors, ps_itempic, ps_desktop, ps_fullpic};
Style popStyle;

There ps_colors was for solid colors, ps_itempic was for individual bitmaps for items, ps_desktop was for drawing the desktop background and ps_fullpic was for the new full image background option. The new drawing option also necessiated the addition of a new Step.Rc command called PopupBackImage which specifies the path of the image. This meant a code addition to read the value from the Step.Rc.

useDeskImage = GetRCBool("PopupUseDeskImage", TRUE);
GetRCString("PopupBackImage", popBMP.name, "", 256);
GetRCString("PopupTitlePix", titleBMP.name, "", 256);
GetRCString("PopupEntryPix", backBMP.name, "", 256);
GetRCString("PopupSelEntryPix", selectBMP.name	, "", 256);
GetRCString("PopupBottomPix", bottomBMP.name, "", 256);
GetRCString("PopupFontFace", popupFontFace, "Arial", 256);
// decide on the Popup style
if (useDeskImage)
	popStyle = ps_desktop;
else if (!strlen(popBMP.name)==0)
	popStyle = ps_fullpic;
else if (!strlen(titleBMP.name)==0 && !strlen(backBMP.name)==0 && !strlen(selectBMP.name)==0)
	popStyle = ps_itempic;
else
	popStyle = ps_colors;

I then added the following code to the paint function in Popup.C and made a few more minor code adjustments and voila! You now have the ability to use full background images with the Popups.

if (popStyle == ps_desktop)
	PaintDesktop(hdc);
else
	paintBMP(hdc, memDC, popBMP, rcWnd);
Grab the new binaries and sources now! BTW, even if I don't mention it explicitly, every new entry to this journal is accompanied by new binaries and sources if I do make any changes. Just thought you'd like to know :-)

06 July 99

I'd received two e-mails one from Floach and the other from David Harrison (Trog) and both were about the wharf. Floach had forwarded a message from Sergey Popov who had fixed a problem with the wharf where if WharfAutoHide and WharfNoAnim are switched on, wharves are not removed from the screen in some cases. Trog's e-mail contained his modifications to the wharf sources to allow you to specify your own size for the wharf instead of the default size of 64 pixels that LS normally has.

Unfortunately, the sources had changed so much since the version that Trog sent me, I had to go through the code myself and redo most of his work. On a related note, maybe I spoke too early in praise of WinMerge <g> because I'd just got a new version of WinMerge and it performed abysmally in finding the changes and I had to switch back to Microsoft's own Windiff. I don't know whether it was the new version or just WinMerge itself because I had deleted the old version by that time and couldn't do anything to check it out.

Anyway, the work involved was pretty minimal though there was a lot of finding and replacing to be done. For some reason, when the wharf was originally coded, it had been decided to keep wharf tile sizes at 64 pixels and the value was hardcoded into the wharf code. So all that had to be done was to introduce a variable to hold the wharf tile size and use that everywhere that the 64 pixel value was used. In order to let the user specify the wharf tile size, a new Step.Rc value called (appropriately enough <g>) WharfTileSize was introduced. If that entry is not in the Step.Rc, a default size of 64 is assumed. Be aware though that most module coders assume that the wharf will be 64 pixels and don't code to take other sized wharves into account.

I also realized that my journal entries were getting too numerous to fit into one page comfortably and so, introduced an archive page (linked at the bottom) that would contain all journal entries except for the current week. This should make the page a lot less shorter and faster to load.


05 July 99

I had a talk yesterday with Murphy when he released his LiteStep preview build as he'd included some bug fixes in the sources. So he sent me over all the stuff he'd been working on and I decided to include everything except for the image filter stuff as that is still not fully complete according to Murphy himself. You can find full details about the changes he's made to the popups at his site. He'd also made some changes to the Lsapi sources so that you could integrate environmental variables into your Step.Rc simply by using them as a LiteStep variable. For example, $TEMP$ in your Step.Rc would point to your temporary directory and $WINDIR$ would point to your windows directory. Great for people who use LiteStep in two environments (Win9x and NT) on the same machine! It is also great for using the same Step.Rc on a network.

Then I ran into Peter Edwards on ICQ and he ran the latest sources through Bounds Checker for me and he came up with a few problems in the source codes that could be fixed.

So I decided to make today source merging day. Talking of source merging, a tool that you have to have is WinMerge. It is freeware and works much better than WinDiff (at least in my opinion). WinMerge made the finding of differences between the different files a breeze and I had everything updated pretty quickly. So now you've got another build (and sources) to try out.

Incidentally, I've heard from several people that the downloads from this site are abysmally slow. I'm really sorry about this but hang in there folks because a lot of people have been kind enough to offer web space to me but I have finally decided to go with a new site that will be opening soon. I will let you know further details as (and when) they develop :-)


Back to Home Page Journal Archive Nedstat Counter

Site Design by : Lowspirit