|
Good Afternoon,
I've been writing code for about two years, C++, VB, Java in a box ( no coder guru over the shoulder stuff ). Am self taught, through books, and powerful( kiss up, kiss up )websites like this one. But I am sensing something is missing. All the examples/books/source code is kinda written in isolation to prove a single point, and not "this is how to write good software". I realize it is improbable to expect a standard way of writing code that is consistently expected... ASSERTs always go here... or are there things that most good coders do consistently? Sounds like I'm confused, doesn't it?
Here is my point( finally )...
would it be possible to have a complete sound commercial application written by a respected coder posted, chopped up by other good coders, and realize some sort of Best practices with reasons. Ie. I've read Newcomer's stuff about having if( DebugLevel ) do these things, then a novice could change the application debug level, and inform him of specific wrongs, but I've read other docs that say use lots and lots of ASSERTs and when problems... debug.
I realize this is an overwhelming task, but if done, would speed the process of novice coders, like me, becoming efficient with good practices as a foundation. Not to mention how it could affect the industry...
Maybe there is something out there like this already. If so, I'd love to see it an participate with questions and an open mind.
Thanks!
Scott!
|
|
|
|
|
Hi,
There are some good books on this topic: Writing solid code, Code complete, etc. They are trying to cover a topic of how to write a good software. I strongly recommend to start with them (check also Extreme Programming), although I agree that there is a space for a good book, covering maybe one big project and revealing some code techniques. But there will be always a place for small articles, covering in more details, how to do this or that, e.g. how to implement trace, logging, assert, etc.
Igor Proskuriakov
|
|
|
|
|
There's no one best way, you can start an argument about any coding technique you could name.
Still, I think that "Code Complete" by Steve McConnell (Microsoft Press) is about the best book on the overall process of actually writing computer code. If you haven't read his book, I strongly suggest you do so. This book is written by a person who's written a lot of commercial code. He's not a pointy headed academic spouting theory, he's speaking from real experience.
|
|
|
|
|
Writing good code is more art than science in many ways.
There are no silver bullets. Everyone's style is different, and everyone works best in different ways. The trick to writing good code is to be consistent in whatever methods you choose, and always follow them.
Having said that, I'll third the recomendations for the MS Press books "Code Complete" and "Writing Solid Code", however I should also point out that these books are getting rather long on the tooth and are showing their age. Don't take them as gospel, but rather as advice. If the advice works for you, use it. If it doesn't, don't.
Also, these books are big on a few techniques which many find of questionable use. Hungarian notation is almost universally hated by people with lots of experience (although a few things such as m_ seem to still be popular, even among people that normally hate hungarian notation). Also, at least one of those books recommends placing constants first in equality tests (ie: if (10 == variable) since this will generate an error if you only use one = instead of 2. I don't agree with this practice, since it makes the logic much harder to read. Instead, I recommend devloping a near manic compulsive double-checking of your code everytime you type the = character. It's more error prone in development, but it doesn't screw up everyone that has to read your code for the rest of it's life.
Another book i'd recommend is "The Pragmatic Programmer" by Andrew Hunt and David Thomas (Addison-Wesley press). This book is a little more about process and management, but it includes some good gems of programming advice.
|
|
|
|
|
> Hungarian notation is almost universally hated by people with lots of experience
Make sure we do not confuse *experience* with *age*. Lots of the "older" crowd that I know, that were coding before the advent of (reverse) hungarian notation, or other common naming conventions, tend to not like it. The same goes for most of the Unix-heads that I know and have worked with. The ones that were "raised" on it, however, tend to like it.
Personally, I can speak from (bad) experience that nothing is worse than having to go through someone else's code who thinks that all variables should start with an "_", and then just have no naming convention whatsoever. Can you tell me anything about the following variables (besides their names)?
_Id
_RetValue
_StatusValue
_BookObject
What types are they? Pointers? Objects? Basic Types? Member Variables?
How about these?
m_iId
_dwRetValue
m_bStatusValue
_pBookObject
Even without knowing exactly what convention is in use, you know more about these identifiers than you did with the ones above. When dealing with smaller projects, it is not such a big deal. When dealing with megabytes of production-server-quality code, that little bit of knowledge can save LOTS of time (and money).
But I agree with the fact that using a naming convention does not make one a great coder. There are still people out there that may know all of the naming conventions, use them all the time, but still do stupid stuff like writing functions that take complex, or memory-intensive objects by value instead of by reference, or taking a _bstr_t as a parameter when a BSTR would do fine (and not require the allocation and deallocation of memory).
You have to learn the right thing to do, and then do it. Practice does not make perfect. Practice makes habit (age reference). *Perfect* practice makes perfect.
Good coders are concerned about both stability/robustness and speed. Good code is fast. Good code is robust. A few things (most) good coders do (by no means a complete list):
o Comment their code *well*
o *Always* initialize
o *Always* check any pointers before use
o *Always* check any return codes/values
o Never confuse NULL with NUL
o Know when to use a temporary (and when NOT to)
o Never use "catch( ... ) { /* Do Nothing */ }"
o Know how to read a crash-dump (or at least how to read the registers to know if you dereferenced a NULL, or had garbage data, etc.)
o If accepting a pointer to a buffer, accept the length of that buffer, too
o Do not use ::printf(...) when ::puts(...) will do (and similar)
o Do not take wrapper objects (or string objects) as parameters when the actual type (or a char/TCHAR pointer) will do (e.g., do not accept a _bstr_t when a BSTR will work)
o Do not use a dynamically-allocated string class when a stack-allocated buffer will do
o Always use the "length-specified" versions of string manipulation functions (like ::snprintf, ::strncat, etc.)
o Be aware of platform-specific (like the processor you are targeting) concerns/optimizations, alignment issues, etc., and code accordingly
o Know the "cost" of anything that you use (like STL container classes, COM, DCOM, etc.) and know how they do and do not work
o Use dynamic memory allocation only when necessary (esp. when doing multithreaded development and targeting a multiple-CPU system)
That is a good start...
-=- James.
|
|
|
|
|
Does anyone knows of a window DLL which can help to detect wm_message of an active window? I need this dll urgently.
|
|
|
|
|
Alright I was going to try and solve this problem on my own, but with school I just don't have the time and its really starting to bug me. Here it is. I want to have a menu item that when selected will change the dimensions of the main dialog. I'd like it to be able to resize the dialog to fit the screen. I'd also like to have a 640x480, 800x600, and a 1024x768 item that when selected will change the dialog to these sizes. I've tried using MoveWindow(), but this only seems to work in the dialogs initialization. I'd like to solve this myself, but it's gotten to the point that not having the answer is too annoying. Thank you.
|
|
|
|
|
Use SetWindowPos() to set the position and size of the dialog at the same time:
SetWindowPos ( hwndDialog, NULL, 0, 0, nWidth, nHeight, SWP_NOZORDER );
--Mike--
http://home.inreach.com/mdunn/
"That probably would've sounded more commanding if I wasn't wearing my yummy sushi pajamas."
--Buffy
|
|
|
|
|
Thanks Mike. It works! 
|
|
|
|
|
Hi!
I would like to know how can I get the following information from PowerDVD:
current file , current time within file
It is for a synchronised subtitling project, and any help is welcome!!!
Thanks, MAXXxxx
|
|
|
|
|
How would I go about building a custom font application?
E.g. In an Indian language.
|
|
|
|
|
How can I implement an application with the web view of a file like in Windows Explorer? Any ideas?
|
|
|
|
|
The Win32 console API has a lot of functions to change
a console window's size, color, scroll range and whatsoever.
It is even possible to change the window's code page.
(Normally, it is 437 on US english systems and 850 on german systems).
The font normally used by console windows is not capable of displaying any other codepage than the system's default code page; if for instance I try to display text using the ANSI codepage (1252), some characters are not displayed properly.
If I change the console window's font to a non-bitmap font (such as "Lucida Console" or "Andale Mono"), text can be displayed in any codepage whatsoever.
However, the only way to change the console window's font seems to be using the console window's property menu or the control panel applet 'Console'.
I would like to change the font *programmatically*, that is, without user intervention.
Any clues?
|
|
|
|
|
Hi,
Did anyone know something about news protocol ? I need to enumerate news grups, read messages, etc...
Sasa Kajic
|
|
|
|
|
http://www.faqs.org/rfcs/rfc977.html
|
|
|
|
|
|
Thanx, this is what I need...
|
|
|
|
|
Hi,
Did anyone know something about news protocol ? I need to enumerate news grups, read messages, etc...
Sasa Kajic
|
|
|
|
|
Hey how can i send messages to pagers...
|
|
|
|
|
there is a pager class on codetools http://www.codetools.com/library/wfc.asp
however most pagers can be communicated with by dialling to the service provider and sending a alphanumeric message once connected. ie like you would if you was using a touch tone phone
Holy Handgrenade of Antioch instructions
|
|
|
|
|
I cannot figure out how to persistently change the clipping region of a child window control.
I have a rich edit control (non-mfc... created with CreateWindowEx), and I want to change the visible area of the control dynamically. There seem to be three approaches, and I cannot seem to figure out how to get any of them to work:
1. Call SetWindowRgn() on the child window control: this weirdly enough seems to make the specified region invisible, rather than visible, and is not persistent (the next InvalidateRect call re-draws the region.
2. Call SelectClipRgn(): this isn't persistent after the display context is released. The following code for example completely ignores my call to SelectClipRgn():
hdc = GetDC(hwnd);
rgn1 = CreateRectRgn(0, 0, 50, 50);
(void)SelectClipRgn(hdc, rgn1);
(void)ReleaseDC(hwnd, hdc);
hdc = GetDC(hwnd);
(void)GetClipBox(hdc, &WinRect);
rgn1 = CreateRectRgnIndirect((const RECT *)(&WinRect));
hbr = (HBRUSH) GetStockObject(WHITE_BRUSH);
(void)FillRgn(hdc, rgn1, hbr);
...
3. Intercept the WM_PAINT message of the control, and change the clipping region before the control is painted. The problem here is that I don't know how to intercept the child window WM_PAINT message without completely re-writing the control, and that doesn't seem to be the right solution.
Anyway, I love your site... first time I've logged onto CodeProject.com. I would appreciate any insight into how to clip a child control (a rich edit control in particular), but I have some buttons that I also want to clip in the same region.
Thank you,
Brian
Brian Rosenthal
Chief Technology Officer
MyBestHealth, Inc.
brosenthal@mybesthealth.com
|
|
|
|
|
Being completely confused, I wrote this test application I built to illustrate exactly what is happening to my code. It's a simple application that compiles by itself in VC6.0. A quick glance, and then running it, is meant to illustrate perhaps more in detail my confusion with setting the window region of a child control. I have marked three points in the code that can be either commented or not to produce results that to me were surprising and erratic. So, I guess my real question is to explain the results and tell me what I can do to get the richedit control in this example to have its region set properly.
Here is a quick description of the code, and then the actual source follows (you can just cut and paste into VC6.0, and it works). Sorry, I know the tabs didn't copy into the message, but I cannot figure out what to do to get them in there.
Simple WinProc:
I. WM_CREATE:
// Create a RichEdit Control
// Create a button
// Call ShowWindow() on each.
II. WM_COMMAND:
// If the button is clicked:
// 1. call SetWindowRgn(richedit) to set the region
// to only the top left.
// 2. (C. Call InvalidateRgn(...) on the window)
// 3. (D. Call InvalidateRgn(...) on the richedit control)
III. WM_PAINT:
// B. SendMessage(...WM_PAINT...) to both children, then return 0
// A. break;
As you can see, I note four places in the code which each produce a different behavior that confuses me. It's very easy to uncomment the proper lines and see the result.
Anyway, thank you very much in advance. If you would like me to clarify something, please send me e-mail at brosenthal@mybesthealth.com. Sorry if this is a stupid question. I feel like a dunce. Have been beating my head against the wall about this for a while. Anyway, here is the sourcecode that works in VC6.0:
I will post the sourcecode immediately following this on this thread (too long for one message)
|
|
|
|
|
#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0400
#endif
#include <windows.h>
#include <math.h>
#include <iostream>
#include "richedit.h"
/*
* Define a block of globally accessible information
*/
typedef struct tagAPPBLOCK {
/* Windows types */
HINSTANCE hInstance; /* application instance */
HWND hMainWnd; /* handle to main window */
HWND hwndRichEditChatWindow; /* Host rich edit chat window */
HRGN hwndRichEditChatRegion; /* The region of the rich edit control */
HWND hwndGoButton;
} APPBLOCK, *LPAPPBLOCK;
// Define the WndProc function
LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM);
APPBLOCK appblock;
/*
* Two child windows: A Rich edit control and a button
*/
#define ID_RICHEDITCHATWINDOW 1
#define ID_GOBUTTON 2
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
{
static TCHAR szAppName[] = TEXT("RichEdit Region Clipping Test"); // name
HWND hwnd; // this window
MSG msg; // for the message loop
WNDCLASS wndclass; // I will define a class for this window
char tmpStr[128]; // for debugging information
appblock.hInstance = hInstance; // Store the instance value in a global variable.
wndclass.style = 0;
wndclass.lpfnWndProc = WndProc;
wndclass.cbClsExtra = 0;
wndclass.cbWndExtra = 0;
wndclass.hInstance = hInstance;
wndclass.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wndclass.hCursor = LoadCursor (NULL, IDC_ARROW);
wndclass.hbrBackground = (HBRUSH) GetStockObject(TRANSPARENT);
wndclass.lpszMenuName = NULL;
wndclass.lpszClassName = szAppName;
// LoadLibrary("Riched20.dll");
// Necessary to use the rich edit control
if (!LoadLibrary("Riched20.dll")) {
(void)MessageBox(NULL, "Error! Load Riched20.dll.", "Fatal Error.", MB_OK | MB_ICONASTERISK);
sprintf(tmpStr, "Error Information: %d", GetLastError());
return false;
}
// Register the class
if (!RegisterClass(&wndclass))
{
MessageBox(NULL, TEXT("Error registering the class"), szAppName, MB_ICONERROR);
return 0;
}
// Create a main window to hold the button and the rich edit control
hwnd = CreateWindow(
szAppName,
TEXT("Richedit Clipping Test"),
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
NULL,
NULL,
hInstance,
NULL);
ShowWindow(hwnd, iCmdShow);
UpdateWindow(hwnd);
while(GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return msg.wParam;
}
/*
* Contains a richedit and a button
*/
LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
HINSTANCE hInstance;
LPAPPBLOCK lpab;
char tmpStr[256];
// global block of information.
lpab = &appblock;
switch (message)
{
case WM_CREATE:
hInstance = lpab->hInstance;
// Create the richedit control
// Give it a black background
// Show it.
if (!(
lpab->hwndRichEditChatWindow = CreateWindowEx(
0,
RICHEDIT_CLASS, TEXT(""),
WS_CHILD | ES_MULTILINE | WS_VISIBLE, // !WS_BORDER & (WS_CHILD | WS_VISIBLE | BS_FLAT| BS_BITMAP),
5, // left
5, // top
500, // btnWidth, pressing the button will change the region to make part of this invisible
100, // btnHeight
hwnd,
(HMENU) ID_RICHEDITCHATWINDOW,
lpab->hInstance,
NULL)
)){
(void)sprintf(tmpStr, "Error. Could not create RichEditChatWindow. Error Information: %d", GetLastError());
(void)OutputDebugString(tmpStr);
(void)MessageBox(NULL, tmpStr, "Fatal Error.", MB_OK | MB_ICONASTERISK);
exit(1);
}
if (!(
lpab->hwndGoButton = CreateWindowEx(
0,
"button", TEXT("Go!"),
WS_CHILD | WS_VISIBLE, // !WS_BORDER & (WS_CHILD | WS_VISIBLE | BS_FLAT| BS_BITMAP),
20, // left
300, // top
50, // btnWidth
20, // btnHeight
hwnd,
(HMENU) ID_GOBUTTON,
lpab->hInstance,
NULL)
)){
(void)sprintf(tmpStr, "Error. Could not create Go Button. Error Information: %d", GetLastError());
(void)OutputDebugString(tmpStr);
(void)MessageBox(NULL, tmpStr, "Fatal Error.", MB_OK | MB_ICONASTERISK);
exit(1);
}
ShowWindow(lpab->hwndRichEditChatWindow, true);
ShowWindow(lpab->hwndGoButton, true);
SendMessage(lpab->hwndRichEditChatWindow, EM_SETTEXTMODE, TM_RICHTEXT, 0);
/*
* Set the background to yellow (okay, so this is an ugly color...).
*/
SendMessage(lpab->hwndRichEditChatWindow, EM_SETBKGNDCOLOR, 0, RGB(255, 255, 0));
InvalidateRgn(lpab->hwndRichEditChatWindow, NULL, true);
InvalidateRgn(lpab->hwndGoButton, NULL, true);
InvalidateRgn(hwnd, NULL, true);
return 0;
case WM_SIZE:
return 0;
case WM_COMMAND:
switch(LOWORD(wParam)) {
case ID_GOBUTTON:
if (HIWORD(wParam) == BN_CLICKED) {
// Define a small rectangle. Note, this is a global variable,
// and is not de-allocated until WM_DESTROY
lpab->hwndRichEditChatRegion = CreateRectRgn(0, 0,50, 50);
// Set the region of the richedit chat window to be the small rectangle.
SetWindowRgn(lpab->hwndRichEditChatWindow, lpab->hwndRichEditChatRegion, true);
// *********************
// WEIRD OUTCOME C:
// Invalidating the main window seems to
// nullify the SetWindowRgn call above
// InvalidateRect(hwnd, NULL, true);
// END WEIRD OUTCOME C
// **********************
// WEIRD OUTCOME D:
// Invalidating the RichEdit seems to
// nullify the SetWindowRgn call above
//InvalidateRect(lpab->hwndRichEditChatWindow, NULL, true);
// END WEIRD OUTCOME D
return 0;
}
break;
}
break;
case WM_PAINT:
// WEIRD OUTCOME B:
// If these lines are uncommented, there is erratic behavior. The
// go button disappears permanently, and the rich edit is not resized properly
//(void)SendMessage(lpab->hwndRichEditChatWindow, WM_PAINT, 0, 0);
//(void)SendMessage(lpab->hwndGoButton, WM_PAINT, 0, 0);
// return 0;
// END WEIRD OUTCOME B
// WEIRD OUTCOME A. If this line is uncommented, the child window is resized,
// but only temporarily. Alt-tabbing between applications seems to lose the region.
break;
// END WEIRD OUTCOME A
case WM_DESTROY:
DeleteObject(lpab->hwndRichEditChatRegion);
PostQuitMessage(0);
return 0;
}
return DefWindowProc(hwnd, message, wParam, lParam);
}
|
|
|
|
|
It says in the documentation for SetWindowRgn:
"After a successful call to SetWindowRgn, the system owns the region specified by the region handle hRgn. The system does not make a copy of the region. Thus, you should not make any further function calls with this region handle. In particular, do not delete this region handle. The system deletes the region handle when it no longer needed."
In case 'A' below, if you comment out the break statement then you destroy the window region after the first WM_PAINT message, thus putting your display into an undefined state.
Jim
// WEIRD OUTCOME A. If this line is uncommented, the child window is resized,
// but only temporarily. Alt-tabbing between applications seems to lose the region.
break; //if this is commented out, then lpab->hwndRichEditChatRegion is destroyed, violating rules for SetWindowRgn
// END WEIRD OUTCOME A
case WM_DESTROY:
DeleteObject(lpab->hwndRichEditChatRegion);
PostQuitMessage(0);
return 0;
}
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
