C / C++ / MFC

Programm3r wrote:

Please contact the application's support team for more information

toxcct wrote:

so what ! haven't you ???

toxcct wrote:

BTW, what a perfect situation for using a breakpoint, isn't it ?!

---

The only programmers that are better than C programmers are those who code in 1's and 0's.....

Programm3r
Bronze

My Blog: ^_^

Programm3r wrote:

I wrote the application. You tell me who I must call ??

Programm3r wrote:

I know where it happens, but a breakpoint doesn't tell me what the problem was after the specific funtion call. After the error occured, does it?

toxcct wrote:

i was kidding you with the message Windows returned

toxcct wrote:

do you know using the watch window ?

---

The only programmers that are better than C programmers are those who code in 1's and 0's.....

Programm3r
Bronze

My Blog: ^_^

prasad_som wrote:

What call stack says to you ?

---

The only programmers that are better than C programmers are those who code in 1's and 0's.....

Programm3r
Bronze

My Blog: ^_^

Programm3r wrote:

Win32ClibRFC.exe!CClibRFC32::rfcCall(char * szUname=0x00417960, char * szTag=0x00417968, char *

prasad_som wrote:

Is there such function in your app ? Try putting break point there.

int CClibRFC32::rfcCall(char* szUname, char* szTag, char* lpFromDate, char* lpToDate, char* szDesc)

RFC_HANDLE handle;
RFC_FUNCTIONNAME functionname;
RFC_PARAMETER exporting[MAX_PARA];
RFC_PARAMETER importing[MAX_PARA];
RFC_TABLE tables[MAX_PARA];
rfc_char_t * exception_ptr;
RFC_PARAMETER changing[MAX_PARA];

rc = RfcCallReceiveEx(handle, functionname, exporting, importing, changing, tables, &exception_ptr); 
//At this function call

---

The only programmers that are better than C programmers are those who code in 1's and 0's.....

Programm3r
Bronze

My Blog: ^_^

Programm3r wrote:

rfc_char_t * exception_ptr;RFC_PARAMETER changing[MAX_PARA];rc = RfcCallReceiveEx(handle, functionname, exporting, importing, changing, tables, &exception_ptr);

prasad_som wrote:

Does RfcCallReceiveEx expects uninitialized RFC_HANDLE handle value, which is case here. Same is case with RFC_FUNCTIONNAME parameter.

sprintfU (connect_param, cU("DEST=%s CLIENT=%s USER=%s PASSWD=%s LANG=%s"), dest, client, user, pass, lang);
// Connect to SAP - get handle
handle = RfcOpenEx(connect_param, &error_info);
// Set RFC Function Name
strncpyU (functionname, "RFC_FUNCTION_NAME", sizeofU (RFC_FUNCTIONNAME) - 1);

---

The only programmers that are better than C programmers are those who code in 1's and 0's.....

Programm3r
Bronze

My Blog: ^_^

prasad_som wrote:

And what about last paramter of RfcCallReceiveEx, is it expected to pass initialized pointer ?

prasad_som wrote:

Who is owner of RfcCallReceiveEx ? Can you debug it ?

---

The only programmers that are better than C programmers are those who code in 1's and 0's.....

Programm3r
Bronze

My Blog: ^_^

Programm3r wrote:

surely I'm doing something stupid.

_LocaleUpdate _loc_update(plocinfo);

_ASSERTE((unsigned)(c + 1) <= 256);
if (c >= -1 && c <= 255)
{
    return (_loc_update.GetLocaleT()->locinfo->pctype[c] & mask);
}
else
{
    return (_loc_update.GetLocaleT()->locinfo->pctype[-1] & mask);
}

---

The only programmers that are better than C programmers are those who code in 1's and 0's.....

Programm3r
Bronze

My Blog: ^_^

Programm3r wrote:

Compiler opens isctype.c file at the following location

toxcct wrote:

this cannot be the source of the problem

---

The only programmers that are better than C programmers are those who code in 1's and 0's.....

Programm3r
Bronze

My Blog: ^_^

prasad_som wrote:

What call stack says to you ?

ThatsAlok wrote:

usually this error come when executable is in Release mode!..

prasad_som wrote:

Dont think so this time. He has provided call stack. See his reply

Programm3r wrote:

Microsoft Visual C++ Runtime Library

Runtime Error!
Program:..\executableName.exe