CamStudio TODO List

There had to be one, right? ~~In no particular order:~~ Scratch that. Add to the top - the nail that sticks out gets the hammer. ;)

Sub-projects
Coding Conventions
1. Naming Conventions
2. Brace Layout du jour
Projects & Solutions
Notes

Sub-projects

Remember to look for TODOs to find what to do!

Combine various option and settings into a single configure dialog.
Delete legacy profile section when fully converted.
CamStudio needs to use the OpenDML (AVI 2.0) extensions so files with size greater than 2 GB can be created.
Move global variables into classes (doc, mainframe and view) and use the profile class to read and set them through the App interface to the profile class.
Rename profile setting strings to remove programming artifacts. Color values are always single values (DWORD). Cursor folder and file name should be strings not integer lengths.

Coding Conventions

Code layout needs to be standardized.

No underscores
Use Camel casing, e.g. iTextAttribute, dwMyLongNumber
Generally tighten up the code
No more than one blank line in a row
White space around operators
Variable declarations at the closest scope to usage
Variable declarations and initialization on one line
Use the global scope operator
Reduce gratuitous code drift across the page
ASSERT only what should never be FALSE
DO NOT ASSERT valid error states
Use Trace statements liberally
Debug new code and step through every line
Use unnamed parameter convention to prevent warnings when compiling verbosity 4
Initialize all variables
I'm sure there's more here...

Naming Conventions

Use Hungarian notation for variable names, please!

Data type	Naming example
int	iValue
char	chChar
long	lValue
unsigned int	uValue
WORD	wValue
DWORD	dwValue
CString	strValue csValue (if STL string)
struct X	sxValue
X *	pxValue

Brace Layout du jour

if (<exp>)
{
	<stmt list>
}
else
{
	<stmt list>
}

Early exit in if statements is fine, but only if they have no "else"

if (<exp>)
{
	<stmt list>
	return;
}
// there is no else here!

Projects & Solutions

Error handling. Use OnError() [see RecorderApp.cpp] for Windows errors (the other functions are depreciated and will be removed). Create an overloaded OnError for class or library specific errors.
Look for header reduction. Class implementation files should have the class header immediately following the standard project headers:
```
#include "stdafx.h"
#include "project.h"	// Recorder.h, Producer.h, etc.
#include "class.h"
#include "other.h"	// headers required ONLY by the class implementation
```
Prefer forward declarations in class headers to inclusion. Angle brackets (i.e. #include <header.h>) for MS windows and MS library files. All other use quoted names.
Warning level 4 ONLY!
Move global variables and functions into classes
Remove hard coded paths in include files, resources, etc. - use project settings instead

Prefer string format to piecewise construction, e.g.,

CString strFileName = "MyFile.txt";
CString strProgPath = "\\Recorder\\";
CString strFullName = ::GetProgPath() + strProgPath + strFileName;

can be done as,

CString strFullName;
strFullName.Format("%s\\Recorder\\MyFile.txt", ::GetProgPath());

And if later we do folder APIs:

strFullName.Format("%s%s\\MyFile.txt", ::GetProgPath(), ::TargetFolder());

Fix unreachable code; don't just remove it - it probably needs to be refactored
Don't turn off warnings with #pragma without a comment why
Drop "TODO" comments freely in the code
Remove "TODO" comments from completed tasks or the superfluous "TODO: Add your code here."

Notes

CEditTransparencyDlg and CTransparentWnd

The interaction between these 2 classes is artificially convoluted.

In order allow the edit dialog to update the calling CTransparentWnd the dialog overloads PreModal() to pass pointers to the CTransparentWnd window and its members that control transparency. Then as the user edits the values the dialog calls CTransparentWnd::InvalidateTransparency to update the image. All this was done using pointers and casts. Ugh. The dialog class has been changed to force the caller to use the constructor to pass in references to the control values it uses and a pointer to itself. As before, the dialog will call CTransparentWnd::InvalidateTransparency when the values change.

What should be done is to pass the new values as arguments to CTransparentWnd::InvalidateTransparency(bool bEnable, int iLevel) and let it deal with its own internal state. The call to the edit dialog should simply pass in the current state values and copy the new state after the dialog completes. Note that the dialog still retains the old values and restores them on cancel.

warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning)

Here is the quick fix, but it doesn't really deal with the fact that the type of iTemp should be bool.

int iTemp = 0;
f(iTemp ? true : false);