OK, you are correct. The return value should always be checked for success, but if the filename was valid (and this is where the real issue is) the OP probably would have never noticed that, because it wouldn't be returning NULL.

I think everyone here missed the real issue here. "c:\test_1/2.txt" There is a \t in the filename, which is converted to a tab character by the compiler. The file path getting passed into fopen is "c: est_1/2.txt" You need to escape this backslash with another backslash, so your filename becomes "c:\\test_1/2.txt". as for the forward slash, windows will interpret this as a path slash too, but you don't need to escape it because the compiler wont change it. So, the path you are accessing is C: > test_1 > 2.txt Additionally, fopen will not create the folder "test_1" if it does not exist, it will just fail to open it and return NULL.

Could you please post code from your header definition and source file, only relevant parts please. At a guess tho, I would say it is because you didn't declare it as a virtual function. In the header file it should be declared as virtual void OnInitialUpdate();

Ok, great start. Check out the MSDN page[^] for OnCtlColor(). Notice the nCtlColor parameter? Only do pDC->SetBkMode(TRANSPARENT) if it is equal to CTLCOLOR_STATIC and you should be set. EDIT: If you only want to set specific controls as transperent, rather than all controls of a type, check if pWnd is the instance you want to set instead.

What are your child controls? Static text? Typically you would need to override the WM_ERASEBKGND (OnEraseBkgnd in MFC) in the child controls to stop it painting the background or to copy the parent background (depending on what you are doing). Check out some of the transparent controls[^] in the articles section.

I could be completely wrong on this, but to me, it appears that he has defined a variable, something like CListCtrl m_ListDrive in the CRecoverDriveDlg class. He is expecting this variable to automatically attach to some list control he has in the dialog template (I dont see a call to m_ListDrive.Create()). My suggestion was to manually attach m_ListDrive to this control somehow. It is possible that he has called m_ListDrive.Create() elsewhere in his code and simply hasn't shown it and hence I am completely wrong. Since the original issue is m_ListDrive is NULL, then this call has failed, and that code would be relevant to helping him find a solution.

I have not used MFC for about a year now, so my memory could be a bit flaky, but: "These controls are laid out based on a dialog-template resource." - CFormView Class[^]. The form view is a pretty way of embedding a dialog into a MFC view. All of the controls on it have a dialog ID associated with them.

I'm guessing what you mean is m_ListDrivis.m_hwnd is null. The variable somehow needs to be attached to the dialog control. This can be done with Dynamic Data eXchange (DDX) or the SubclassDlgItem[^] function, which must be called before m_ListDrive.SetExtendedStyle(LVS_EX_FULLROWSELECT);. You could also make it into a pointer in the class definition, and then use

m_ListDrive = (CListCtrl *)GetDlgItem(IDC_MY_LIST); //CListCtrl is whatever control type it is, IDC_MY_LIST is the control ID set in the properties window in the dialog editor.
m_ListDrive->SetExtendedStyle(LVS_EX_FULLROWSELECT);

Could make it threadsafe with Mutexes[^]

sawerr wrote:

If one application grabs a port no other application can use it.

Application specific would imply that each application could have its own set of ports. I think you meant to say "System Specific".

sawerr wrote:

So, for example,that means one computer mustn't have 2 or more web server that listening port 80. Right?

That is correct. This is called System Specific. 1 per system.

sawerr wrote:

But also a lot of clients can connect same port.

Yes, me and you can both connect to www.google.com on port 80 at the same time. (ignore the fact that we would almost certainly get different servers altogether). When a server is listening, it has the option of setting the maximum number of sessions. When you look at some code for starting a server you have something like this:

SOCKET sConnection = socket(AF_UNSPEC, SOCK_STREAM, IPPROTO_TCP); //Create a TCP stream socket with any address type (IPv4, IPv6, ...)
//pAddress = get listening address, usually 0.0.0.0
bind(sConnection, pAddress->ai_addr, pAddress->ai_addrlen);
listen(sConnection, SOMAXCONN);
for (;;) {
SOCKADDR saClient;
DWORD nClientAddrLen = sizeof(saClient);
SOCKET sClient = accept(sConnection, &saClient, &nClientAddrLen);
CreateThread(); //Create a new thread to handle the new connection
//Now wait for the next connection in the new loop
}

Your knowledge is correct from a simplistic point of view. Perhaps you should get some first hand experience with Wireshark[^]. Sniff a session, such as a opening the google homepage. For a TCP session to work the following must happen: 1. The server starts up and listens (binds) on a port. No other programs can be listening for data on this port (although they can send from it which is a different session) This port is almost always pre-determined (like 80 for HTTP) but if you specify 0 the OS will give a random port which the client must be sent by some other means (like an email) before connecting 2. The client connects to the IP of the server and the port from part 1. If you looked at Wireshark, this does the SYN, SYN/ACK and ACK that starts the session 3. Send/receive from both server and client. 4. Shutdown the socket when done with it from both ends, both server and client must shutdown both send and receive directions when finished. If you looked at Wireshark, this does the FIN/ACK and ACK once from each end. 5. Close the socket. This frees the system handle on the socket

None of them are correct. The message determines what you must do. At the bottom of the DlgProc function there would be a call to DefWndProc() or the original window procedure. Read the MSDN pages for what the return should be. WM_INITDIALOG[^]: "The dialog box procedure should return TRUE to direct the system to set the keyboard focus to the control specified by wParam. Otherwise, it should return FALSE to prevent the system from setting the default keyboard focus." Generally you would break and let the default procedure take care of this, but you can return either TRUE or FALSE. WM_COMMAND[^]: "If an application processes this message, it should return zero." implies that you should break the switch and call the original procedure if you don't handle it. WM_CLOSE[^]: "If an application processes this message, it should return zero."

LRESULT CALLBACK DlgProc(HWND hwnd, UINT Msg, WPARAM wParam, LPARAM lParam) {
switch (Msg) {
case WM_INITDIALOG:
break; //You can do whatever here

    case WM\_COMMAND:
        switch (LOWORD(wParam)) {
            case IDC\_MYBUTTON:
                return 0; //something happened to MYBUTTON
        }
        break; //We havn't handled it, use default handler

    case WM\_CLOSE:
        //cleanup
        return 0;
}
return pOriginalProcedure(hwnd, Msg, wParam, lParam); //This is set as GetWindowLong(GWL\_MSGPROC) before changing the procedure.

}

Well, I know that scrollbars work by moving the screen data, rather than redrawing, in things like ListBox's and web browser controls. Presumably this behaviour could be implemented into your solution too, but for something so simple, it would not be worth the complexity that I imagine it might take.

The general solution is to just invalidate the window[^] or better yet, the old ball rectangle and the new ball rectangle and then draw it again in the WM_PAINT which is called automatically when you invalidate the area. 1 minor issue with this is that it will do what is called "flickering" where it flashes. To fix this mute the WM_ERASEBKGND message and use a memory DC. Search codeproject or google for "memory DC" or "flicker free drawing" to see how this is done in code.

By far, the simplest way is GetSystemTimeAsFileTime[^]. This returns a FILETIME[^] struct which contians 2 DWORDs which you can then drop directly into a ULARGE_INTEGER[^].

FILETIME ftStart, ftEnd; //Increments every 100 nanoseconds
GetSystemTimeAsFileTime(&ftStart);
//do something
GetSystemTimeAsFileTime(&ftEnd);
ULARGE_INTEGER liStart = { ftStart.dwLowDateTime, ftStart.dwHighDateTime };
ULARGE_INTEGER liEnd = { ftEnd.dwLowDateTime, ftStart.dwEndDateTime };

printf("Duration: %I64u ms\n", (liEnd - liStart) / (10 * 1000));

or, if you dont mind using casts since ULARGE_INTEGER and FILETIME have the same structure:

ULARGE_INTEGER liStart, liEnd;
GetSystemTimeAsFileTime((FILETIME *)&liStart);
//do something
GetSystemTimeAsFileTime((FILETIME *)&liEnd);

printf("Duration: %I64u ms\n", (liEnd - liStart) / (10 * 1000));

In the toolbars at the top there is the configuration boxes, 1 containing Debug or Release and the other containing Win32. Drop down either of those boxes and select Configuration Manager. From the Configuration Manager you can add extra configurations to each individual project. Select the configuration (debug or release) next to your MFC DLL project and select from the dropdown. Call it Static Debug (or anything else if you feel like it) and then change Copy settings from: to Debug. Repeat again for Release, calling it Static Release. If you want to change the default configuration from DLL to static LIB then you can change the Configuration type for the MFC DLL in the Configuraion Manager that is to be build with the Debug and Release compiles. Close the Configuration Manager. Now right click on the MFC DLL project in the solution explorer and select Project Properties. Change the configuration at the top of the properties box to Static Debug, then go to the General page from the list at the left. change Configuration Type to Static Library. Do the same for Static Release. You may need to change a few other things as well, there is probably a definition in the C++>Preprocessor page for DLL or something that you will need to get rid of.

Perhaps elaborate on what you are trying to do so that we can help you better. Also note that Bitmap pictures pad each scanline to a multiple of 4 bytes. If your bitmaps are 32bit, then you can ignore this. That is if your picture is 5 pixels wide, each pixel taking 3 bytes (24 bits) then each scanline would be 5 * 3 = 15bytes wide. Since that is not a multiple of 4 some bytes (1 in this case) are added to align the next scanline. Note: The MSDN page for BITMAP[^] says they are WORD (2 byte) aligned, but from previous experience I have found that they are DWORD (4 byte) aligned. This means that you must iterate through bm.bmHeight, and then for each iteration of that, iterate through bm.bmWidth.

BYTE *pBitmapData = (BYTE *)XXX; //XXX is the value from CreateDIBSection
int nBytesPerPixel = bm.bmBitsPixel / 8;
for (int y = 0; y < bm.bmHeight; ++y) {
for (int x = 0; x < bm.bmWidth; ++x) {
COLORREF clrRef = *((COLORREF *)pBitmapData);
//blend images somehow
pBitmapData += nBytesPerPixel; //Simply skip to the next pixel
}
pBitmapData += (nBytesPerPixel * bm.bmHeight + 3) & 3; //Round up to the next DWORD.
}

It is most likely 1 of 2 things wrong. You don't have the correct language packs installed on your system, so the character is unprintable, or it is not supported by the selected font. If the character works elsewhere on your computer, like in Wordpad or web pages (excluding wikipedia because it often uses images) then this is not your problem. The character can't fit into Unicode. Unicode only defines space for 65535 characters. Some characters are out of this range, character sets like UTF-x can go up to a bit over 1.1 million characters (limited by a standard in the case of UTF-8, not the limits of the encoding). Visual studio provides a Multi-byte option, which I have not used which may be able to help your problem, however the Windows core is coded in Unicode. Other than this, make sure you have the correct character in the string to begin with.

Unless someone else has something to say, you're out of luck. Interactions like this with controls are all done through messages, like SetWindowText() is an alias for PostMessage(WM_SETTEXT), and it appears that GetComboBoxInfo() is an alias for CB_GETCOMBOBOXINFO[^], which as that MSDN page says is only implemented on Windows XP and later. If this query message is not supported by the control on your platform then you are going to have a hard time getting the internal state. Not sure if it will work, and if it will it is probably not a good idea, but you might be able to update the common control library from something like Windows XP, which should have all features of NT, plus more by copying and pasting.

I thought it was a standard thing, but when I do int(1.732) I get 1 and int(-1.732) I get -1. A look at the disassembly shows that a function from the CRT (_ftol2 in my case) is used, so it could be implementation specific. If this is the case then you should use something like floor/ceil as Bernhard Hiller suggested. This function will result in the behaviour described above, where numbers round towards 0. It includes epsilon rounding to account for epsilon errors. In some cases 3 = 2.99999999999 (or something similar) due to rounding errors in previous operations. See http://en.wikipedia.org/wiki/Double_precision[^] for more details

int DoubleToInt(double nDouble) {
if (nDouble >= 0) {
retrun (int)floor(nDouble + DBL_EPSILON);
} else {
retrun (int)ceil(nDouble - DBL_EPSILON);
}
}