C / C++ / MFC

FirstPrevNext

Re: Now why doesn't this COMPILE!?!?!? jeffluckett31-Jul-02 7:09 jeffluckett 31-Jul-02 7:09  Under your project settings, make sure that you have chosen one of the "Using MFC" options. (IE. "Using MFC in a shared .dll" or "Using MFC in a statically linked .dll") Re: Now why doesn't this COMPILE!?!?!? Tommy Svensson31-Jul-02 7:16 Tommy Svensson 31-Jul-02 7:16  No, it works with a project I have and there's no MFC at all. And there shouldn't be! It must be something else! Mail me and I'll send the project to anyone who wants it! /T Re: Now why doesn't this COMPILE!?!?!? pépé2-Aug-02 0:35 pépé 2-Aug-02 0:35  I had the same problem : - put an empty main funxion somewhere to keep the linker happy - don't use LIBC funxions - tell me if you find another solution Re: Now why doesn't this COMPILE!?!?!? Vagif Abilov2-Aug-02 0:46 Vagif Abilov 2-Aug-02 0:46  This is a famous one. It is cause by _ATL_MIN_CRT preprocessor definition. Look here[^] for details. Vagif Abilov MCP (Visual C++) Oslo, Norway If you're in a war, instead of throwing a hand grenade at the enemy, throw one of those small pumpkins. Maybe it'll make everyone think how stupid war is, and while they are thinking, you can throw a real grenade at them. Jack Handey, Deep Thoughts Dialog Box & Property Sheet :: MFC valikac31-Jul-02 6:35 valikac 31-Jul-02 6:35  Hi. I have some fundamental questions about dialog box and property sheet. Most ultimately have to do with program design and memory management. Dialog Box: Is the following good program design? ----- MyBox mBox; if (mBox.DoModal == IDOK) // Is it good program design to get data from a dialog box after it has been closed/distroyed? DataType = mBox.GetData(); ----- Dialog Box & Property Sheet: What do you think about declare all dialog box and/or property sheets as private data member rather than local data member? In general, I want to make sure there is not memory leak with dealing with dialog box and/or property sheet and local data members. Thanks, Kuphryn Re: Dialog Box & Property Sheet :: MFC Joaquín M López Muñoz31-Jul-02 6:43 Joaquín M López Muñoz 31-Jul-02 6:43  Question 1: It is not only good style, but also about the only reasonable way to retrieve data entered by the user into the dialog. Go ahead with this solution. Question 2: I don't know how keeping these private will help you prevent memory leaks. Could you be more specific? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo Re: Dialog Box & Property Sheet :: MFC valikac31-Jul-02 6:50 valikac 31-Jul-02 6:50  Thanks. If you declare a dialog box locally, what if the function goes out of stack? If it is local, you can create a new box and delete each box every time. Again, I would like to make sure everything is safe and good program design. Kuphryn Re: Dialog Box & Property Sheet :: MFC Joaquín M López Muñoz31-Jul-02 6:55 Joaquín M López Muñoz 31-Jul-02 6:55  I'm still not very sure about what your question is, but in general you should prefer to declare variables locally rather than as member variables (unless there are compelling reasons not to do so). Joaquín M López Muñoz Telefónica, Investigación y Desarrollo Re: Dialog Box & Property Sheet :: MFC valikac31-Jul-02 6:56 valikac 31-Jul-02 6:56  Here is an example of the second questions. ----- Class MyClass() { void TestFunc(); privete MyDialogBox *dBox; } void MyClass::TestFunc() { dBox = new MyDialogBox; if (MyDialogBox->DoModal == IDOK) ... delete dBox; dBox = NULL; } ----- In the code above, MyDialogBox is created on the heap instead of being a local call. Kuphryn Re: Dialog Box & Property Sheet :: MFC Joaquín M López Muñoz31-Jul-02 6:59 Joaquín M López Muñoz 31-Jul-02 6:59  It is much better to do it this way: class MyClass { void TestFunc(); }; void MyClass::TestFunc() { MyDialogBox dBox; if (dBox.DoModal() == IDOK) ... } Joaquín M López Muñoz Telefónica, Investigación y Desarrollo Re: Dialog Box & Property Sheet :: MFC valikac31-Jul-02 9:11 valikac 31-Jul-02 9:11  Thanks. Nicely explained. Kuphryn socket monitor, is it possible? includeh1031-Jul-02 6:17 includeh10 31-Jul-02 6:17  how to know info about sockets currently run in a PC? the sockets are created by other apps. info includes ports, addresses for both side of sockets. is it possible? thx includeh10 Re: socket monitor, is it possible? jmkhael31-Jul-02 6:22 jmkhael 31-Jul-02 6:22  one link http://www.sysinternals.com/ntw2k/source/tcpview.shtml Papa Murex Co. while (TRUE) Papa.WillLove ( Bebe ) ; Re: socket monitor, is it possible? jmkhael31-Jul-02 6:24 jmkhael 31-Jul-02 6:24  another one http://www.sysinternals.com/ntw2k/freeware/tdimon.shtml Papa Murex Co. while (TRUE) Papa.WillLove ( Bebe ) ; Re: socket monitor, is it possible? includeh1031-Jul-02 6:28 includeh10 31-Jul-02 6:28  thank u! before i try, i want to know if it is only avaliable on NT and win2k? a flower ... includeh10 Re: socket monitor, is it possible? jmkhael31-Jul-02 6:32 jmkhael 31-Jul-02 6:32  there's a version for win 95/98/Me also, check it out at www.sysinternals.com Papa Murex Co. while (TRUE) Papa.WillLove ( Bebe ) ; Re: socket monitor, is it possible? includeh1031-Jul-02 7:15 includeh10 31-Jul-02 7:15  i downloaded 20 (or all) zips from the company. they look very wanderful! i will go through to find key code. i think u use them before, u should be an expert about the stories. thx again 2 flowers ... includeh10 Re: socket monitor, is it possible? lucy31-Jul-02 10:16 lucy 31-Jul-02 10:16  another tool: in MS-DOS command window, type "netstat -a". DLL hell with msvcrt.dll Jim Crafton31-Jul-02 6:15 Jim Crafton 31-Jul-02 6:15  OK I have my app which I am trying to test on other machines I have built it as a Multi threaded DLL so I am using the MSVCRT.dll as well as the MSVCP60.dll due to C++ and STL On my machine (a win2K box) all is well. On the two NT server 4 sp6 machines where I ahve tried to run it all is NOT well. I put the exe plus my lib's .dll and the msvcrt.dll and msvcp60.dll all in the same directory. I try and run the app (it is a console app) and I get this: "The procedure entry point __lc_collate_cp could not be located in the dynamic link library MSVCRT.dll" Hmm...well I drag a copy of depends.exe over and open the app in it and it reports no errors ( i.e. problems with linked functions that don't exist), and in fact reports that the version of MSVCRT.dll I am using is the one in the app's directory (naturally), NOT the one in winnt\system32\. The one in the c:\winnt\system32\ dir has a version of 4.20.6201 and the one I am using (or need to use) is 6.10.8924.0 I had always understood that you should avoid replacing the stuff in system32 to prevent breakage in other apps. Should I in fact change the installer to just overwrite it (if it is older than mine) ? This app will be installed on server machines so I am a but leery of doing this. Any suggestions will be greatly appreciated, and I happily send you a virtual beer ! Re: DLL hell with msvcrt.dll Joaquín M López Muñoz31-Jul-02 6:41 Joaquín M López Muñoz 31-Jul-02 6:41  Well, this masks the error rather than solve it, but have you considered statically linking the pogram? When I have to release an applicaton I always choose this option to save me the hassle and latenight calls from clients Joaquín M López Muñoz Telefónica, Investigación y Desarrollo Re: DLL hell with msvcrt.dll Jim Crafton31-Jul-02 7:27 Jim Crafton 31-Jul-02 7:27  Yeah thats what I am getting readyto do now but I am REALLY pissed off that I have to resort to this. Stupid fsckin' MS, pardon my french.... Re: DLL hell with msvcrt.dll Daniel Lohmann31-Jul-02 8:52 Daniel Lohmann 31-Jul-02 8:52  Jim Crafton wrote: Hmm...well I drag a copy of depends.exe over and open the app in it and it reports no errors ( i.e. problems with linked functions that don't exist), and in fact reports that the version of MSVCRT.dll I am using is the one in the app's directory (naturally), NOT the one in winnt\system32\. The one in the c:\winnt\system32\ dir has a version of 4.20.6201 and the one I am using (or need to use) is 6.10.8924.0 I had always understood that you should avoid replacing the stuff in system32 to prevent breakage in other apps. Should I in fact change the installer to just overwrite it (if it is older than mine) ? This app will be installed on server machines so I am a but leery of doing this. Yes, you should change the installer to overwrite it. Depends.exe seems to give you the wrong hint here The problem is, that on NT4 (and maybe also Win2k, but not XP) MSVCRT.dll is a so-called "well-known DLL" (the list of well-known DLLs is stored in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs). These DLLs are never loaded side-by-side, because they are a vital part of the OS. For well-known DLLS always the copy in %SYSTEMROOT%\System32 is taken. While this makes much sense for the "really vital" OS DLLs e.g. kernel32.dll and advapi32.dll, which are heavily dependend on each other and replacing one of them side-by-side with another version could break the whole system, I never understood why msvcrt.dll is also on this list. But on NT4 it is! So the official and recommended way is to replace it. However, msvcrt.dll is the very best tested thing from MS and, (regarding DLL-Hell) in no way comparable with MFC or Common Controls: Every of their own application and every OS component depends on it . So it is rather safe to replace it with a newer version (and do the damned reboot afterwards). In fact, I have never heard of any problem with replacing it. -- Daniel Lohmann http://www.losoft.de Re: DLL hell with msvcrt.dll Jim Crafton31-Jul-02 10:23 Jim Crafton 31-Jul-02 10:23  Thanks for hte info ! I will change the installer to do this then. I had never heard about the "well known DLL" issue, and while I kind of understand it, that REALLY sucks. I wonder what would happen if you were to just remove the entry? Curiously, I just walked over to the one of the machines and opened regedit and I saw a number of DLLs under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs key but NOT msvcrt.dll - is this one hardcoded somewhere else I wonder ? Re: DLL hell with msvcrt.dll Daniel Lohmann31-Jul-02 13:39 Daniel Lohmann 31-Jul-02 13:39  Jim Crafton wrote: Curiously, I just walked over to the one of the machines and opened regedit and I saw a number of DLLs under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs key but NOT msvcrt.dll - is this one hardcoded somewhere else I wonder ? Oh sorry - I was not able to check this (no NT4 box available here ). AFAIR (it's some time ago I struggled about this topic) the "know-dll" property is a transitive property. This means, that every DLL that is implicitly loaded from a known-dll is also treated as known-dll (The whole mechanism is for stability purposes, so this makes sense). I simply assume that some of the DLLs imports msvcrt.dll. Hm... I just checked it on my XP box. Using the "WinObj" tool from http://www.sysinternals.com[^] you can view all dlls that are actually treated as a known dll (also the imported ones). And I had to find out that even on XP msvcrt.dll is a member of this list Obviously you just not ran into problems on Win2k and above, because it is shipped with a newer version of msvcrt.dll. Your side-by-side copy has never been loaded on any version of NT, it is just wasting disk space... -- Daniel Lohmann http://www.losoft.de (Hey, this page is worth looking! You can find some free and handy NT tools there ) Drawing text rsasalm_31-Jul-02 6:12 rsasalm_ 31-Jul-02 6:12  Hi all, I am learning window programming. I want to draw text when my mouse moves on client rectangle. I have two alternatives to choose from 1. TextOut 2. DrawText Which one should I use and why? I try with the simple test code using TextOut to draw text at point(10,30) on client rect But I don't get it work. the code is as follow: LRESULT CALLBACK WndProc (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) { HDC hdc ; PAINTSTRUCT ps ; RECT rect ; TCHAR szBuff[10] = "Hello"; switch (message) { ..... case WM_MOUSEMOVE: hdc = BeginPaint (hwnd, &ps) ; TextOut (hdc, 10, 30, szBuff, lstrlen(szBuff)); EndPaint (hwnd, &ps) ; return 0 ; .......... } } int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) { static TCHAR szAppName[] = TEXT ("HelloWin") ; HWND hwnd ; MSG msg ; WNDCLASS wndclass ; wndclass.style = CS_HREDRAW | CS_VREDRAW | CS_DBLCLKS ; 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 (WHITE_BRUSH) ; wndclass.lpszMenuName = NULL ; wndclass.lpszClassName = szAppName ; if (!RegisterClass (&wndclass)) { MessageBox (NULL, TEXT ("This program requires Windows NT!"), szAppName, MB_ICONERROR) ; return 0 ; } hwnd = CreateWindow (szAppName, // window class name TEXT ("The Hello Program"), // window caption WS_OVERLAPPEDWINDOW, // window style CW_USEDEFAULT, // initial x position CW_USEDEFAULT, // initial y position CW_USEDEFAULT, // initial x size CW_USEDEFAULT, // initial y size NULL, // parent window handle NULL, // window menu handle hInstance, // program instance handle NULL) ; // creation parameters ShowWindow (hwnd, iCmdShow) ; UpdateWindow (hwnd) ; while (GetMessage (&msg, NULL, 0, 0)) { TranslateMessage (&msg) ; DispatchMessage (&msg) ; } return msg.wParam ; } Once I get the above code to work then I would like that text "Hello" is followed when I move my mouse on the client area. I would appreciate if you could give my a sample code for that or any suggesion. Thanks in advance regards /rsasalm

Last Visit: 31-Dec-99 18:00     Last Update: 11-Jun-24 18:23 Refresh ᐊ Prev1...16496164971649816499165001650116502165031650416505 Next ᐅ

General    News    Suggestion    Question    Bug    Answer    Joke    Praise    Rant    Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.