Search Results

Search found 5 results on 1 pages for 'evc4 0)'.

Page 1/1 | 1 

  • How to use WINAPI from newer SDK but still using the old SDK in WindowsMobile.

    - by afriza
    Specifically, I want to use Point-to-point Message Queue but because I am still using legacy codes in eVC++ 4 and it only support until PocketPC 2003SE SDK, I cannot find CreateMsgQueue and friends in the headers (the port to newer VisualStudio is still in progess) I am using the Message Queue to do IPC with apps developed with WM-6.5-DTK (VS2005). Update: I am using the following code (taken from msgqueue.h) to store function pointers and load CoreDLL.dll using GetProcAddress() and LoadLibrary() respectively. HANDLE /*WINAPI*/ (*CreateMsgQueue)(LPCWSTR lpName, LPMSGQUEUEOPTIONS lpOptions); HANDLE /*WINAPI*/ (*OpenMsgQueue)(HANDLE hSrcProc, HANDLE hMsgQ , LPMSGQUEUEOPTIONS lpOptions); BOOL /*WINAPI*/ (*ReadMsgQueue)(HANDLE hMsgQ, /*__out_bcount(cbBufferSize)*/ LPVOID lpBuffer, DWORD cbBufferSize, LPDWORD lpNumberOfBytesRead, DWORD dwTimeout, DWORD *pdwFlags); BOOL /*WINAPI*/ (*WriteMsgQueue)(HANDLE hMsgQ, LPVOID lpBuffer, DWORD cbDataSize, DWORD dwTimeout, DWORD dwFlags); BOOL /*WINAPI*/ (*GetMsgQueueInfo)(HANDLE hMsgQ, LPMSGQUEUEINFO lpInfo); BOOL /*WINAPI*/ (*CloseMsgQueue)(HANDLE hMsgQ); Is the above code alright since I need to comment out WINAPI and __out_bcount(cbBufferSize) in order for them to compile.

    Read the article

  • How do I find a source code position from an address given by a crash in Window CE

    - by Shane MacLaughlin
    I have a Windows mobile 4.0 application, written using EVC++ 4.0 SP4 with MFC, that is exhibiting a random occasional crash in the field. e.g. Exception ox800000002 at 00112584. It does not happen under various emulators and simulators, hence is very difficult to trace using a debugger. The crash throws up and address and exception type. Given that I have the PDB is there any way to track this address to the source. I can't recompile using VC++ 8 as it doesn't support the mobile 4 SDK. My guess is that without a stack trace I'm not going to have much joy, as the chances are that the exception may not be in my source. Worth a try all the same. Edit As suggested, I have looked at the address in the context of the .MAP file for the program. This reveals the following Address Publics by Value Rva+Base Lib:Object 0001:00000000 ?GetUnduValue@@YANMM@Z 00011000 f 7Par.obj ' ' ' 0001:001124b8 ?OnLButtonUp@CGXGridUserDragSelectRangeImp@@UAAHPAVCGXGridCore@@AAVCPoint@@AAI@Z 001234b8 f gxseldrg.obj 0001:001126d8 ?OnSelDragStart@CGXGridUserDragSelectRangeImp@@UAAHPAVCGXGridCore@@KK@Z 001236d8 f gxseldrg.obj Which suggests the error occured during CGXGridUserDragSelectRangeImp::OnLButtonUp(), which seems a bit odd as I don't think there was a mouse / keyboard / screen button pressed at the time. Could be the stack got fragged before the crash got reported, and I'm wasting my time. I'll recompile with assembler output to try to isolate it to a given line, but don't hold out much hope :( Does the fact that the map file reports segmented addresses e.g. 0001:xxxxxxxxx and the crash report unsegmented addresses mean I have to carry out some computation to get the map address from the crash address?

    Read the article

1