Informative message in the Aboutdlg when processing versiondata failed

Bug #242365 reported by eMTee
2
Affects Status Importance Assigned to Milestone
DC++
Fix Released
Low
Unassigned

Bug Description

A fix has just missed the release of 0.707 is already commited to avoid crash in the Aboutdlg when a malformed versiondata downloaded. Here's a propose to show a message in case of any error instead of still showing ' Downloading... '

Revision history for this message
eMTee (realprogger) wrote :
Changed in dcplusplus:
importance: Undecided → Low
Revision history for this message
poy (poy) wrote :

a few remarks:
- if you use T_ instead of _T, the string will be translatable.
- no need to allocate the 1st string on top of the block, because it is not always going to be used; also, before the 2nd string is allocated, the 1st should have been deleted. instead, i would create an empty string at first, and change it to the error message if it is still empty after the block.

Changed in dcplusplus:
status: New → In Progress
Revision history for this message
eMTee (realprogger) wrote :

It was a part of the quick fix for the release to avoid possible crash, now here's a probably better solution :P

Revision history for this message
eMTee (realprogger) wrote :

...and another one recommended by poy, choose which is safer / more correct :)

Revision history for this message
Steven Sheehy (steven-sheehy) wrote :

I'm sorry maybe I'm missing it, but where is this tstring* x being deleted? To me it looks like a memory leak.

Revision history for this message
poy (poy) wrote :

Steven, the speak function sends a message to the dialog with that string pointer as an argument; then the message is caught (AboutDlg::handleSpeaker) and the string gets associated to a boost::scoped_ptr container, which deletes the pointer when it goes out of scope.

both patches 2 & 3 look fine to me, i tend to prefer the 3rd one a little bit; i'd like to see which one is accepted... ;)

Revision history for this message
Jacek Sieka (arnetheduck) wrote :

Heh, well, I guess both approaches can be argued for - the first one because there are fewer calls to new which is always good while the second one is cleaner because that's what null pointers are for - differentiating an invalid value from an empty valid value...

Changed in dcplusplus:
status: In Progress → Fix Committed
MikeJJ (mrmikejj)
Changed in dcplusplus:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.