Also, about the addresses, they will most likely not be the same as what is on your machine, because it is the memory address used by that machine. These addresses could even differ between different 'runs' of the program. It would depend on where the user's operating system put the program in memory for that particular execution. So using the memory addresses to find the error will not work in this case. One more possibility, which you probably already know about, is that you could have written past the end of an allocated buffer. David Spain, C++ Applications Programmer

It could also be that you are using a pointer to a heap object, 'delete' was called on the pointer, and then this pointer variable was used again a few lines later in the code. The compiler would not catch this I don't believe, but may have given a warning in the compilation if the warning level was set high enough. Another thing that could be the cause is uninitialized memory. Release mode does not initialize the variables I believe. So you may be using a pointer somewhere that refers to a bogus address. You may already know this, but one thing you could do is to build it in release mode and run it on your machine, trying exactly what the user did, and see if it breaks for you also. If it does, then you know approximately where in the code it crashed and can look into the code to fix it. You have to run it in release mode, for the reason in the previous paragraph. In fact, for this same reason, one should always test in release mode before shipping. David Spain, C++ Applications Programmer

Jose Lamas Rios wrote: I don't think so. You might obtain the CMemFile data using Detach, which returns a BYTE* and also closes the file. The return type is a BYTE* because a file may contain any type of data, not just text. Casting it to an LPCTSTR makes no sense: it may fool the compiler into accepting it, but the content will still be the same, and if it wasn't text, no one interpreting it as such will have correct results. In this case, in fact, it's an executable (binary) file. You are right. What I wrote actually made no sense. Obviously the ShellExecute function wants a string pointer, that points to the name of an actual file on disk. As simply another idea, an executable in memory seems similar to a running process. Would using CreateProcess or something similar be a better avenue to pursue instead of ShellExecute? David Spain, C++ Applications Programmer

Look in the CFrame, CMDIFrame, CView, or a class derived from one of these, for some methods to do this. Those classes perform the drawing of the windows and their background. There may be some public members that can be directly set also. My personal guess is a CFrame derived class. I don't remember completely, but you may have to use some API functions to get the pointers to the objects that would need to be changed. The form background should not be in the App class or the Doc class, since these have to do with running the program and storing the data. I know this does not provide all the answer, but just gives somewhere to start. David Spain, C++ Applications Programmer

How does CMemFile store its data? Most likely it stores a pointer to the memory that contains the actual data. Look in the Microsoft documentation for CMemFile to see how it stores the data. Hopefully, CMemFile has a method to provide this pointer. An LPCSTR is a pointer to a string, so method could be called and the result could be cast to an LPCSTR if it is not already returned that way. Then this could be provided to the ShellExecute function. David Spain, C++ Applications Programmer

You would have to find the length of the string you are copying, then allocate a character array on the heap with length + 1 size, do a memset to set this new memory to 0, do a memcpy from the CString's psz pointer to this new memory, then set the array psz to be the new pointer. That way the memory will always be there in the array psz. Just be sure to do a delete [] on this array psz when this array is no longer needed, or will get a memory leak. (The memset to 0 may not be needed, it may be done automatically when call new.) David Spain

Also, don't play in the three squares that are one away from each of the corners unless/until you have a really good reason to do it. I was about a middle level ability player on the Microsoft game site. Also, like one other person here said, the good players there knew how to play the middle well. They would force you to play on the next row to the outside then take they would take the outside. The piece on the outside cannot be outflanked, so is a great advantage. David

No need for anyone to spend any more time on this -- Sorry if anyone spent time on this, I think there is code on this website in the articles that would help me. In the COM section, "STL Compliant Class for SafeArrays", the code returns safearrays from a COM object, which was my problem. There may be other articles as well. I will look at that to find out what I am doing wrong, so no need for anyone to look at this any further, thanks for the effort. David Spain, C++ Applications Programmer

Ok, here is the code in question: I was wanting to return a safearray of BSTR, but was having trouble with that, so thought maybe it had to do with the pointers, so tried float safearray, but is having same problem. This is the code with float safearray: >>> psaFloatReturn is the safearray in question <<< IDL code: [ object, uuid(13AE8E35-3726-11D6-9913-000102476F95), dual, helpstring("IRemoteServerDisp Interface"), pointer_default(unique) ] interface IRemoteServerDisp : IDispatch { [id(2), helpstring("method Method2")] HRESULT Method2([in] BSTR sName, [in] SAFEARRAY(float) *psafloatAr1, [in] SAFEARRAY(VARIANT_BOOL) *psaBoolAr, [in] SAFEARRAY(float) *psafloatAr2, [in] long cnt, [in] float singlefloat1, [in] float singlefloat2, [in,out] SAFEARRAY(float) *psaFloatReturn, [out,retval] long* errcode); }; -------------------- CoClass method: STDMETHODIMP CCoRemoteServer::Method2(BSTR sName, SAFEARRAY **psafloatAr1, SAFEARRAY **psaBoolAr, SAFEARRAY **psafloatAr2, long cnt, float float1, float float2, SAFEARRAY **psaFloatReturn, long* errcode) { . . . float HUGEP *pfloatTemp; long val = SafeArrayAccessData(*psaFloatReturn, (void HUGEP**)&pfloatTemp); float sldk = 3.0f; for(int q=0; qpvData = tempfloat; SafeArrayLock(psaFloatReturn); // call to DCOM object BSTR bstrName = sName.AllocSysString(); HRESULT hResult = m_pRemoteServer->Method2(bstrName, &psafloatar1, &psaBoolAr, &psafloatar2, cnt, float1, float2, &psaFloatReturn, errcode); SysFreeString(bstrName); SafeArrayDestroy(psafloatar1); SafeArrayDestroy(psafloatar2); SafeArrayDestroy(psaBoolAr); bool ret = false; if(SUCCEEDED(hResult)) ret = true; if(psaFloatReturn!=NULL) SafeArrayDestroy(psaFloatReturn); delete []tempfloat; } About the count in initializing and retu

The program, in C++, is sending a call to a DCOM object installed on a remote NT machine, and am trying to return a Safearray of float (as SAFEARRAY **ppfloatarray), have set that parameter as [in,out], (plus other parameters before this as [in]). Client is running Windows 98. On the client end, the data is not being written back to the passed-in safearray, and HRESULT returned is 8002000D, array is locked. How is the client and server to be set up to do this? My solution was to try various combinations for the flags in the fFeatures member of the safearray, also to try setting the array to locked or unlocked before it was sent and before it was returned from server. I have a debug text file written, so I know that the DCOM object is executing, and the correct values are written to the safearray and are there just before it returns. David Spain, C++ Applications Programmer