C / C++ / MFC

FirstPrevNext

Re: How compare two Bitmap 2 MAAK18-Feb-03 8:45 MAAK 18-Feb-03 8:45  Sorry but I can't understand exactly what you want. 1.Does memcmp return 0 even if the bitmaps are different? If there is any difference in pixels it should return a non-zero value, doesn't it do that? 2.The handles of the bitmaps should not be passed to memcmp, what should be passed is their bytes array did you just miss-typed the message? Re: How compare two Bitmap 2 jeremysay18-Feb-03 8:51 jeremysay 18-Feb-03 8:51  thx for your answer but i have solved the problem, it was a problem with the size of bitmap. now it will works fine (i hope ) Thx MAAK for your help Re: How compare two Bitmap 2 MAAK18-Feb-03 8:56 MAAK 18-Feb-03 8:56  You are welcome How to develop a parser or wrapper? DengJW18-Feb-03 2:34 DengJW 18-Feb-03 2:34  Dear Sirs, I develop a mediaplayer (mPlayer.exe), which uses the runtime argument to pass in the file name that refers to the movie to be played back in the player. Instead of entering the file name each time when I run the mPlayer.exe, is there any way I can develop a wrapper, which will make use of the mPlayer.exe and the file name as input and generate a new mediaplayer inside which the file name had been hardcoded. Thus a stand alone executable could be run instead of a mPlayer.exe and a file name. I tried to do like this because only the new wrapper and the excutable mediaplayer (mPlayer.exe) could be released under my current development plan. Thanks DJ how do i retreive the IP adress from a SOCKET? Willem B18-Feb-03 2:26 Willem B 18-Feb-03 2:26  i have the SOCKET that i use to send/recv data, now i want to know the IP adres of the connected client. how can i do this? greetz []D [] []D [] Re: how do i retreive the IP adress from a SOCKET? Hans Ruck18-Feb-03 3:47 Hans Ruck 18-Feb-03 3:47  Try this: int namelen=sizeof(sockaddr_in); sockaddr_in name; getpeername(sock, (sockaddr *)&name, &namelen); char *sz=inet_ntoa(name.sin_addr); rechi Dr Watson dump :-\ will138318-Feb-03 2:19 will1383 18-Feb-03 2:19  Hi Guys, I have a release version of an application out in the field. Seems some of my customers are having problems with the application just dying. It's a release version, and this is all I have to go on: State Dump for Thread Id 0x2a8 eax=00000000 ebx=00407ca7 ecx=00982548 edx=6c440220 esi=00000000 edi=00982548 eip=00407cad esp=0012fcd0 ebp=0012fcd0 iopl=0 nv up ei ng nz na pe cy cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000283 function: <nosymbols> 00407c9e 5f pop edi 00407c9f 5e pop esi 00407ca0 5d pop ebp 00407ca1 5b pop ebx 00407ca2 59 pop ecx 00407ca3 c3 ret 00407ca4 c20400 ret 0x4 00407ca7 55 push ebp 00407ca8 8bec mov ebp,esp 00407caa 8b450c mov eax,[ebp+0xc] ss:00cbd2a6=???????? FAULT ->00407cad 83780402 cmp dword ptr [eax+0x4],0x2 ds:00b8d5d6=???????? 00407cb1 751d jnz 004172d0 00407cb3 f6401001 test byte ptr [eax+0x10],0x1 ds:00b8d5d6=?? 00407cb7 7417 jz 004107d0 00407cb9 8b400c mov eax,[eax+0xc] ds:00b8d5d6=???????? 00407cbc 33c9 xor ecx,ecx 00407cbe a801 test al,0x1 00407cc0 7508 jnz 00414dca 00407cc2 d1e8 shr eax,1 00407cc4 41 inc ecx 00407cc5 83f91a cmp ecx,0x1a 00407cc8 7cf4 jl 0040fdbe *----> Stack Back Trace <----* FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name 0012FCD0 6C371ED5 00000007 00000000 00982548 00982548 !<nosymbols> 0012FD50 6C371CEA 00000219 00000007 0040B268 0012FD6C !Ordinal5163 0012FD70 6C371C73 00000219 00000007 00000000 0040E4EC !Ordinal6374 0012FDD0 6C371BFB 00000000 001203B6 00000219 00000007 !Ordinal1109 0012FDEC 6C371BBA 001203B6 00000219 00000007 00000000 !Ordinal1578 0012FE18 77E148DC 001203B6 00000219 00000007 00000000 !Ordinal1579 0012FE38 77E14AA7 6C371B81 001203B6 00000219 00000007 user32!PtInRect 0012FEC4 77E266FD 0040E4EC 00000001 6C3711CE 0040E4EC user32!TranslateMessageEx 0040E4EC 00000219 00000007 00000000 1DDEB5AD 000001C0 user32!DispatchMessageA *----> Raw Stack Dump <----* 0012fcd0 50 fd 12 00 d5 1e 37 6c - 07 00 00 00 00 00 00 00 P.....7l........ 0012fce0 48 25 98 00 48 25 98 00 - d0 68 13 00 cd ab ba dc H%..H%...h...... 0012fcf0 14 fd 12 00 f9 7e e1 77 - 68 1c b5 77 60 03 09 00 .....~.wh..w`... 0012fd00 20 00 00 00 6c fd 12 00 - f8 eb fd 7f 00 00 00 00 ...l........... 0012fd10 38 fd 12 00 87 2b f8 77 - 00 ec fd 7f 20 00 00 00 8....+.w.... ... 0012fd20 44 fd 12 00 54 c9 40 6c - 10 00 00 00 22 03 09 00 D...T.@l...."... 0012fd30 f8 eb fd 7f 00 00 00 c0 - 94 fd 12 00 e8 b1 40 00 ..............@. 0012fd40 00 00 00 00 c4 fd 12 00 - 0a 2e 40 6c ff ff ff ff ..........@l.... 0012fd50 70 fd 12 00 ea 1c 37 6c - 19 02 00 00 07 00 00 00 p.....7l........ 0012fd60 68 b2 40 00 6c fd 12 00 - 19 02 00 00 00 00 00 00 h.@.l........... 0012fd70 d0 fd 12 00 73 1c 37 6c - 19 02 00 00 07 00 00 00 ....s.7l........ 0012fd80 00 00 00 00 ec e4 40 00 - f4 e4 40 00 00 00 00 c0 ......@...@..... 0012fd90 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 0012fda0 00 00 00 00 00 00 00 00 - 00 00 00 00 18 10 37 6c ..............7l 0012fdb0 06 00 00 00 ec e4 40 00 - f4 e4 40 00 d0 68 13 00 ......@...@..h.. 0012fdc0 84 fd 12 00 0c fe 12 00 - 82 2d 40 6c 00 00 00 00 .........-@l.... 0012fdd0 ec fd 12 00 fb 1b 37 6c - 00 00 00 00 b6 03 12 00 ......7l........ 0012fde0 19 02 00 00 07 00 00 00 - 00 00 00 00 18 fe 12 00 ................ 0012fdf0 ba 1b 37 6c b6 03 12 00 - 19 02 00 00 07 00 00 00 ..7l............ 0012fe00 00 00 00 00 00 00 00 00 - d0 68 13 00 b4 fe 12 00 .........h...... State Dump for Thread Id 0x480 eax=00148fb0 ebx=80020000 ecx=00145738 edx=00000000 esi=00145528 edi=00000100 eip=77f82230 esp=010afe28 ebp=010aff74 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000206 function: NtReplyWaitReceivePortEx 77f82225 b8ac000000 mov eax,0xac 77f8222a 8d542404 lea edx,[esp+0x4] ss:01c3d3ff=???????? 77f8222e cd2e int 2e 77f82230 c21400 ret 0x14 77f82233 55 push ebp 77f82234 8bec mov ebp,esp 77f82236 56 push esi 77f82237 57 push edi 77f82238 53 push ebx 77f82239 8bf4 mov esi,esp 77f8223b ff7514 push dword ptr [ebp+0x14] ss:01c3d54a=???????? 77f8223e ff7510 push dword ptr [ebp+0x10] ss:01c3d54a=???????? 77f82241 ff750c push dword ptr [ebp+0xc] ss:01c3d54a=???????? 77f82244 ff5508 call dword ptr [ebp+0x8] ss:01c3d54a=???????? 77f82247 8be6 mov esp,esi *----> Stack Back Trace <----* FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name 010AFF74 77D525D2 77D52C07 00145528 00000000 40145094 ntdll!NtReplyWaitReceivePortEx 010AFFA8 77D52BB9 00141DF0 010AFFEC 77E837CD 00145628 rpcrt4!NdrVaryingArrayFree 010AFFB4 77E837CD 00145628 00000000 40145094 00145628 rpcrt4!NdrVaryingArrayFree 010AFFEC 00000000 77D52BA1 00145628 00000000 00905A4D kernel32!TlsSetValue *----> Raw Stack Dump <----* 010afe28 5f 27 d5 77 94 00 00 00 - 54 ff 0a 01 00 00 00 00 _'.w....T....... 010afe38 50 83 14 00 58 ff 0a 01 - d0 fa 13 00 f0 1d 14 00 P...X........... 010afe48 28 56 14 00 d0 26 df 84 - b4 fb 21 bb f2 f0 44 80 (V...&....!...D. 010afe58 88 85 00 e1 60 f1 de 84 - 87 fa 49 80 b8 88 00 e1 ....`.....I..... 010afe68 b0 fc 00 00 b8 88 00 e1 - 00 00 00 00 00 00 00 00 ................ 010afe78 b4 fb 21 bb 8a f4 44 80 - 01 00 00 00 90 01 00 00 ..!...D......... 010afe88 00 00 00 00 10 00 f8 00 - 8a 34 90 84 7c 00 f8 00 .........4..|... 010afe98 9a 34 90 84 68 26 df 84 - b8 88 00 e1 00 00 00 00 .4..h&.......... 010afea8 1f 00 00 00 d0 26 df 84 - d0 26 df 84 00 00 00 00 .....&...&...... 010afeb8 01 00 00 00 10 fc 21 bb - 00 00 00 00 18 f7 2f e2 ......!......./. 010afec8 d4 fb 21 bb 00 00 00 00 - eb 4d 41 80 d0 27 df 84 ..!......MA..'.. 010afed8 60 f1 de 84 c4 fc 21 bb - de e8 44 80 04 00 00 00 `.....!...D..... 010afee8 88 34 90 84 99 a8 49 80 - 80 f3 12 00 00 00 00 00 .4....I......... 010afef8 48 f3 12 00 02 24 33 02 - 00 00 00 00 00 00 00 00 H....$3......... 010aff08 01 00 00 00 19 00 02 00 - 44 2a 50 c0 eb 01 00 00 ........D*P..... 010aff18 00 00 00 00 40 2a 50 c0 - eb 01 00 00 01 00 00 00 ....@*P......... 010aff28 00 20 50 c0 60 8b 9e 84 - a0 92 a4 84 00 00 00 00 . P.`........... 010aff38 a0 92 a4 84 30 94 a4 84 - 64 fc 21 bb 2d d8 42 80 ....0...d.!.-.B. 010aff48 de d7 42 80 c4 4b 06 80 - 00 94 a4 84 00 00 02 80 ..B..K.......... 010aff58 00 a2 2f 4d ff ff ff ff - 50 fe 0a 01 00 00 02 80 ../M....P....... State Dump for Thread Id 0x490 eax=77d52ba1 ebx=00148998 ecx=00000000 edx=00000000 esi=00145528 edi=00000100 eip=77f82230 esp=012cfe28 ebp=012cff74 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000202 function: NtReplyWaitReceivePortEx 77f82225 b8ac000000 mov eax,0xac 77f8222a 8d542404 lea edx,[esp+0x4] ss:01e5d3ff=???????? 77f8222e cd2e int 2e 77f82230 c21400 ret 0x14 77f82233 55 push ebp 77f82234 8bec mov ebp,esp 77f82236 56 push esi 77f82237 57 push edi 77f82238 53 push ebx 77f82239 8bf4 mov esi,esp 77f8223b ff7514 push dword ptr [ebp+0x14] ss:01e5d54a=???????? 77f8223e ff7510 push dword ptr [ebp+0x10] ss:01e5d54a=???????? 77f82241 ff750c push dword ptr [ebp+0xc] ss:01e5d54a=???????? 77f82244 ff5508 call dword ptr [ebp+0x8] ss:01e5d54a=???????? 77f82247 8be6 mov esp,esi *----> Stack Back Trace <----* FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name 012CFF74 77D525D2 77D52C07 00145528 00000000 00000000 ntdll!NtReplyWaitReceivePortEx 012CFFA8 77D52BB9 00144BB0 012CFFEC 77E837CD 00148998 rpcrt4!NdrVaryingArrayFree 012CFFB4 77E837CD 00148998 00000000 00000000 00148998 rpcrt4!NdrVaryingArrayFree 012CFFEC 00000000 00000000 00000000 00000000 00000000 kernel32!TlsSetValue I have no clue how to decipher what I'm looking at in a manner that I can find a place in the code to look. any suggestions are greatly appreciated. Thanks Dan Willis Re: Dr Watson dump :-\ AlexO18-Feb-03 3:05 AlexO 18-Feb-03 3:05  Unless you are very good with assembler (or you are planning to learn it) Dr. Watson is very difficult to use for diagnostic. Try the following (first and/or second) 1. Build your app in release with pdb. This does not effect anything, except if pdb is present most debuggers will pin point the location, including function name. 2. Install debugger from MS SDK (do not worry it has very small foot print, and does not cripple your system like VC debugger, it is optimal for servers). The only drawback is it has very cryptic interface and command line options. When used properly this debugger gives you (!)readable(!) dump at the time of crush. Re: Dr Watson dump will138318-Feb-03 3:17 will1383 18-Feb-03 3:17  Ok, On my way! But if I didn't have a machine I could reproduce this error on, how would I go about deciphering the drwatson stuff? I understand assembler enough to work with it, but I'm not sure how to go backwards from the drwatson to trace it to my application. I'll report back after I try the pdb and debugger route thanks! Dan Willis Re: Dr Watson dump AlexO18-Feb-03 3:50 AlexO 18-Feb-03 3:50  As you probably guessed Dr. Watson dumps stack, assembly, and memory dump for each thread in your program. Stack is meaningless unless you have PDB symbol file. In you example "OrdinalXXXX" and "!<nosymbols>" could be real function name. 0012FCD0 6C371ED5 00000007 00000000 00982548 00982548 !<nosymbols> 0012FD50 6C371CEA 00000219 00000007 0040B268 0012FD6C !Ordinal5163 0012FD70 6C371C73 00000219 00000007 00000000 0040E4EC !Ordinal6374 0012FDD0 6C371BFB 00000000 001203B6 00000219 00000007 !Ordinal1109 0012FDEC 6C371BBA 001203B6 00000219 00000007 00000000 !Ordinal1578 0012FE18 77E148DC 001203B6 00000219 00000007 00000000 !Ordinal1579 0012FE38 77E14AA7 6C371B81 001203B6 00000219 00000007 user32!PtInRect 0012FEC4 77E266FD 0040E4EC 00000001 6C3711CE 0040E4EC user32!TranslateMessageEx 0040E4EC 00000219 00000007 00000000 1DDEB5AD 000001C0 user32!DispatchMessageA From what I can guess one thread in your example just received WP_PAINT (or some UI windows message) and stumbled on 0 pointer or something, another was dealing with stack allocation. But again I could be wrong. This looks like typical crash from MS Office (probably Excel). P.S. build pdb with detailed information. Re: Dr Watson dump :-\ will138318-Feb-03 3:43 will1383 18-Feb-03 3:43  Would you believe I don't have the MS SDK? All I have is VC++ Pro. I can't find a stand alone debugger. Sheesh! I'm looking on the microsoft site. Got any ideas where I can find it? UGH I also started to sift through the drwatson file. If I could find this: FAULT ->00407cad 83780402 cmp dword ptr [eax+0x4],0x2 ds:00b8d5d6=???????? Then I'd be able to trace it back to the place in the application which it is dying. I'm assuming the 00407cad is the location in memory the call is at, and I know what the call is I'm looking at. but what is the 83780402 number? and what is the ds:00b8d5d6=????? Is that the other place in memory that the cmp is checking against? Again, thanks. I'm just trying to learn more. Still have alot to learn I see. lol Dan Willis Re: Dr Watson dump :-\ AlexO18-Feb-03 3:55 AlexO 18-Feb-03 3:55  http://www.microsoft.com/ddk/debugging/default.asp Re: Dr Watson dump will138318-Feb-03 4:18 will1383 18-Feb-03 4:18  Thanks! Off to the races again! Dan Willis Re: Dr Watson dump :-\ pete mcquain18-Feb-03 4:49 pete mcquain 18-Feb-03 4:49  There's a much easier way to debug this problem that doesnt (normally) require anything to be done to your clients machine. Use the .MAP file generated by the compiler. Look in the .MAP file for the next lowest function offset from the FAULT entry offset in the Dr. Watson log file. That will show you what function the fault is happening in. If you didn't have the .MAP file enabled when you built what's running on your customer's machine, you can enable it now and build it as long as everything else is the same. -pete Re: Dr Watson dump :-\ will138318-Feb-03 5:22 will1383 18-Feb-03 5:22  What do you mean by pete mcquain wrote: the next lowest function offset from the FAULT entry offset in the Dr. Watson log file. Do you mean this: 00407ca8 8bec mov ebp,esp 00407caa 8b450c mov eax,[ebp+0xc] ss:00cbd2a6=???????? FAULT ->00407cad 83780402 cmp dword ptr [eax+0x4],0x2 ds:00b8d5d6=???????? -->>>> 00407cb1 751d jnz 004172d0 00407cb3 f6401001 test byte ptr [eax+0x10],0x1 ds:00b8d5d6=?? 00407cb7 7417 jz 004107d0 00407cb9 8b400c mov eax,[eax+0xc] ds:00b8d5d6=???????? the one with the -->>>> ?? The drwatson log is in my first post. What should I be looking for? I don't see anything in the .map that has the 00407cad in it. Or am I looking in the wrong place Dan Willis Re: Dr Watson dump :-\ jhwurmbach18-Feb-03 5:42 jhwurmbach 18-Feb-03 5:42  What DrWatson tried to tell you was that while executing machine instructions from the address 00407cad to 00407cb0 (hexadecimal numbers!), where the bytes '83 78 04 02' (being the assembler instructions cmp dword ptr [eax+0x4],0x2 ds:00b8d5d6) had been located, a fault occured. Now, you need to look into the .MAP file of your program (has to be from the same build as the dying one!) and find the function that contains the instructions at 00407cad to 00407cb0. This is the function with the highest start address (listed in the .MAP-file) that is also below your FAULT-adress (00407cad, from DrWatson). Here the Error had occured. Now you have a place to start looking for the error - up until here has been the easy part Hope this helps My opinions may have changed, but not the fact that I am right. Re: Dr Watson dump :-\ pete mcquain18-Feb-03 6:34 pete mcquain 18-Feb-03 6:34  Yeah, what he said -pete Re: Dr Watson dump :-\ will138318-Feb-03 7:32 will1383 18-Feb-03 7:32  You were right, That WAS the easy part. Thanks. At least deciphering is a little clearer. But sheesh! trying to track down why is a whole 'nother issue! Seems I'm chasing a phantom. Sometimes it dies, other times it will stay running for hours At least I know where to look and it has to do with clearing out memory, so I'm on my way, but sheesh, it keeps changing on me well, back to the testing ground. I'll see what I can come up with using this new found knowledge Dan Willis I'm This Far Now will138318-Feb-03 7:48 will1383 18-Feb-03 7:48  OK, I found where it is consistantly dying, but I'm not sure why. Here's the function it is dying in: void CFileView::OnGetDispInfo(NMHDR* pNMHDR, LRESULT* pResult) { CString string; LV_DISPINFO* pDispInfo = (LV_DISPINFO*) pNMHDR; if (pDispInfo->item.mask & LVIF_TEXT) { ITEMINFO* pItem = (ITEMINFO*) pDispInfo->item.lParam; switch (pDispInfo->item.iSubItem) { case 0: // File name ::lstrcpy (pDispInfo->item.pszText, pItem->strFileName); break; case 1: // File size string.Format (_T ("%u"), pItem->nFileSizeLow); ::lstrcpy (pDispInfo->item.pszText, string); break; case 2: // Date and time CTime time (pItem->ftLastWriteTime); BOOL pm = FALSE; int nHour = time.GetHour (); if (nHour == 0) nHour = 12; else if (nHour == 12) pm = TRUE; else if (nHour > 12) { nHour -= 12; pm = TRUE; } string.Format (_T ("%d/%0.2d/%0.2d (%d:%0.2d%c)"), time.GetMonth (), time.GetDay (), time.GetYear () % 100, nHour, time.GetMinute (), pm ? _T ('p') : _T ('a')); ::lstrcpy (pDispInfo->item.pszText, string); break; } } *pResult = 0; } Does anyone see anything wrong it? I'm still pluggin away, but this is the root of my problem I believe. All paths merge in this function. Any comments are greatly appreciated guys Thanks! Dan Willis Re: I'm This Far Now AlexO18-Feb-03 8:00 AlexO 18-Feb-03 8:00  Are you sure pDispInfo->item.pszText is always initialized and it has sufficient size? Same goes for pItem->strFileName. Re: I'm This Far Now will138318-Feb-03 8:04 will1383 18-Feb-03 8:04  no I'm not sure. I didn't realize I needed to be concerned with here. mmmm..... What should I do to initialize it in this case.. I think you're on to something here. But I thought if I created a pointer to the LV_DISPINFO and then made that pointer point to the pNMHDR that being passed in, I wouldn't have to initialize the pDispInfo->.... since all I'm doing to making the pointer point to the pNMHDR being passed in. Am I right in this assumption? Dan Willis Re: I'm This Far Now AlexO18-Feb-03 8:13 AlexO 18-Feb-03 8:13  Do not get it. Run it by me again . Could you publish the structure here? Re: I'm This Far Now will138318-Feb-03 8:33 will1383 18-Feb-03 8:33  Ok Here's the LV_DISPINFO structure and the LVITEM structure that's embedded in it typedef struct tagLVDISPINFO { NMHDR hdr; LVITEM item; } NMLVDISPINFO, FAR *LPNMLVDISPINFO; typedef struct _LVITEM { UINT mask; int iItem; int iSubItem; UINT state; UINT stateMask; LPTSTR pszText; int cchTextMax; int iImage; LPARAM lParam; #if (_WIN32_IE >= 0x0300) int iIndent; #endif } LVITEM, FAR *LPLVITEM; Ok, looking at the code I posted before referencing this data structure: LV_DISPINFO* pDispInfo = (LV_DISPINFO*) pNMHDR; if (pDispInfo->item.mask & LVIF_TEXT) { ITEMINFO* pItem = (ITEMINFO*) pDispInfo->item.lParam; switch (pDispInfo->item.iSubItem) { case 0: // File name ::lstrcpy (pDispInfo->item.pszText, pItem->strFileName); break; case 1: // File size string.Format (_T ("%u"), pItem->nFileSizeLow); ::lstrcpy (pDispInfo->item.pszText, string); break; case 2: // Date and time CTime time (pItem->ftLastWriteTime); BOOL pm = FALSE; int nHour = time.GetHour (); if (nHour == 0) nHour = 12; else if (nHour == 12) pm = TRUE; else if (nHour > 12) { nHour -= 12; pm = TRUE; } string.Format (_T ("%d/%0.2d/%0.2d (%d:%0.2d%c)"), time.GetMonth (), time.GetDay (), time.GetYear () % 100, nHour, time.GetMinute (), pm ? _T ('p') : _T ('a')); ::lstrcpy (pDispInfo->item.pszText, string); break; } } *pResult = 0; I thought I would have enough space in the pDispInfo->item.pszText to put what ever string I needed to in there. I guess what you are saying is that I need to initialize my structure to ensure the proper size. Dan Willis Re: I'm This Far Now Alvaro Mendez18-Feb-03 8:50 Alvaro Mendez 18-Feb-03 8:50  I think AlexO hit the nail in the head. According to the docs for LVITEM, pszText is an LPTSTR, which means that it's just a pointer. It's not a character buffer, like your program is treating it. When you copy onto it, you're overwriting whatever memory it's pointing to at the moment, which may be harmless in some cases but not in others. I'm not sure what your function is used for, but it looks like its intent is to change the text of the list view items. I don't understand why you're doing it this way instead of using SetItemText but whatever. At any rate, the quick solution to this problem is to stop copying into the pointer and just assign it to a buffer that does not go away. The easiest way to do that is to make your string declaration static: static CString string; Then instead of ::lstrcpy (pDispInfo->item.pszText, string), you can do something like this: pDispInfo->item.pszText = (LPTSTR)(LPCTSTR)string; This will point it to the string's buffer, which will not go away since it will be static. That's the quick and dirty solution, without knowing much else. Regards, Alvaro All you need in this life is ignorance and confidence, and then success is sure. -- Mark Twain Re: I'm This Far Now AlexO18-Feb-03 9:02 AlexO 18-Feb-03 9:02  that and ITEMINFO. What is ITEMINFO? I could not find in the standard headers.

Last Visit: 31-Dec-99 18:00     Last Update: 1-Jul-24 1:43 Refresh ᐊ Prev1...15367153681536915370153711537215373153741537515376 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.