The problem is probably due to the member structure alignement: the data in the file have probably been saved with another program which specified a member struct alignement of 1. Member struct alignement means on which byte boundaries are stored all the fields of your structure in memory. Thus, specifying a member struct of 8 (the default), every fields of the structure start on a 8 byte boundary. When you try to read directly data from a file and 'copy' it in memory, if the structure was not saved with the same member struct alignement, this will results in misalignement of your fields (and so, you won't be able to read anything). To avoid the problem, try to set the alignement of your structure to 1: #pragma pack(1) struct Info { //unsigned short ID; int ID; float GPA, FinAid; char state[3]; char gender[2]; char Fname[15]; char Lname[15]; char status[15]; }; #pragma pack // reset to default

Thanks everyone. GetStatus worked.

u can try about this: CString szFilePath ,szFileType ,szFileMask ; szFilePath = "c:\\"; szFileType = "*.txt"; szFileMask = szFilePath + szFileType; hFile = FindFirstFile(szFileMask,&FindFileData); while(hFile != INVALID_HANDLE_VALUE) { //do copy operation if(!FindNextFile(hFile,&FindFileData)) break; }

Posting WM_CLOSE message to the main thread using PostThreadMessage doesn't close your application also. You have to post WM_CLOSE message to all windows on the main thread, as vikrams said. Here's the code how to do this : // define callback function like below BOOL CALLBACK EnumThreadWndProc(HWND hwnd, LPARAM lParam) { ::PostMessage(hwnd,WM_CLOSE,0,0); return TRUE; } // call EnumThreadWindows instead of PostThreadMessage EnumThreadWindows(rp[option-1].dwThreadId,EnumThreadWndProc,0); Regards, Andrzej Markowski My Latest ArticlesCCustomBitmapButton: An owner-draw button and a frame for the caption bar, in one class. CCustomTabCtrl: A clone of the Excel tab sheet control.

The program now outputs duration however, this is something I dont understand. If I run the program normally, meaning without debugging(stepping through it) it says the process takes 0.08000 seconds but if I insert a breakpoint when the file is closing and debug it, it will say the process takes 24.795 secs to do. When I was debugging I put a watch on duration and that was the 24.795 was the correct output. If I run it without the debugging it says 0.08. How or why does debugging change the value of the variable duration?

The problem you're having is that Username is a string field, so you need to quote your field: "SELECT Username, Password FROM tblLogin WHERE Username = '" + txtUIserName.Text + "'" BUT NEVER, EVER build SQL expressions using concatenation. Sorry, but that isn't very smart at all. What if I pass "blah' AND 1=1; drop table tblLogin" from your TextBox? Bye bye login table. It's even worse that you store passwords in plain text. I could, instead, select all those and impersonate any user on your system. Can you say "lawsuits"? Read http://www.codeproject.com/script/comments/forums.asp?msg=932507&forumid=1649&XtraIDs=1649&searchkw=parameterized&sd=7%2F8%2F2004&ed=10%2F6%2F2004#xx932507xx[^] for other problems and more things I could do using your SQL concatenation code. ALWAYS use parameterized queries. Read the link above for an example, or the OleDbParameter class documentation in the .NET Framework SDK. Also, your expression is very insecure besides not using parameterized queries. Don't select the password as part of the result set. Send the password and use it in the WHERE clause like so: SELECT COUNT(*) FROM tblLogin WHERE Username = ? AND Password = ? In fact, even that's bad. You should never store passwords in plain text. Hash them using a one-way algorithm like MD5 or SHA1, both of which are supported by the .NET Framework base class libraries (see the MD5 and SHA1 class). Hash the password before sending it to the database server (and I assume this is actually for an ASP.NET application, which belongs in the ASP.NET forum but I'll continue anyway) or across the wire, then compare that to the hash you store in the Password field (using the same query as above). In fact, even that's insecure. It's subject to replay attacks where someone sniffs your password and while they might not be able to unhash or decrypt it (at least with a given amount of time and resources), they could simply capture the packets, play them back, and you've been 0wned. Instead, store a salt, send it to the client, hash your password + the salt value and s