|
PatrykDabrowski wrote: I delete some_bitmapX objects (when exiting the app as they are 'global').
If you are creating those object once and deleting at the end, then no problem.
PatrykDabrowski wrote: CreateCompatibleDC()/DeleteDC() slower comparing to CDC::SaveDC()/RestoreDC()??
These two set of APIs are different from each other.
That is, after creating a compatible DC, you have select the needed objects into the DC. At last the original object belong to the DC have to be selected (the object returned, at the first select object, note this appicable for that specific type of object).
DelectDC will delete the DC that you created.
But the SaveDC and RestoreDC is for making the DC to its original state, you need not worry about reselecting the original objects. see below;
CDC dc; dc.CreateCompatibleDC(..);
dc.SaveDC();
dc.SelectObject(bitmap1);
dc.SelectObject(bitmap2);
dc.RestoreDC( -1 );
dc.DeleteDC();
By doing so, you need not have to maintain the old objects returned.
Do your Duty and Don't expect the Result
|
|
|
|
|
|
Programm3r wrote: Please contact the application's support team for more information
so what ! haven't you ???
BTW, what a perfect situation for using a breakpoint, isn't it ?!
|
|
|
|
|
toxcct wrote: so what ! haven't you ???
I wrote the application. You tell me who I must call ??
toxcct wrote: BTW, what a perfect situation for using a breakpoint, isn't it ?!
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?
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3rBronze
My Blog: ^_^
|
|
|
|
|
Programm3r wrote: I wrote the application. You tell me who I must call ??
i was kidding you with the message Windows returned
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?
putting a breakpoint won't tell you what's the problem, but it will put you highly on the way.
do you know using the watch window ? you can inspect the content of your variables at a time, watching if the are correctly set... THIS can help you guessing what's wrong.
|
|
|
|
|
toxcct wrote: i was kidding you with the message Windows returned
Sorry my bad ...
toxcct wrote: do you know using the watch window ?
Yes. I'll try it.
Thank you very much toxcct.
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3rBronze
My Blog: ^_^
|
|
|
|
|
What call stack says to you ?
|
|
|
|
|
prasad_som wrote: What call stack says to you ?
Just before the error:
> Win32ClibRFC.exe!CClibRFC32::rfcCall(char * szUname=0x00417960, char * szTag=0x00417968, char * lpFromDate=0x0041796c, char * lpToDate=0x0041797c, char * szDesc=0x0041798c) Line 262 C++
Win32ClibRFC.exe!wmain(int argc=1, wchar_t * * argv=0x009c5870) Line 281 C++
Win32ClibRFC.exe!__tmainCRTStartup() Line 583 + 0x19 bytes C
Win32ClibRFC.exe!wmainCRTStartup() Line 403 C
But afterwards ... nothing
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3rBronze
My Blog: ^_^
|
|
|
|
|
Programm3r wrote: Win32ClibRFC.exe!CClibRFC32::rfcCall(char * szUname=0x00417960, char * szTag=0x00417968, char *
Is there such function in your app ? Try putting break point there.
|
|
|
|
|
prasad_som wrote: Is there such function in your app ? Try putting break point there.
Yes,
int CClibRFC32::rfcCall(char* szUname, char* szTag, char* lpFromDate, char* lpToDate, char* szDesc)
But inside that function the error occurs at this point:
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);
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3rBronze
My Blog: ^_^
|
|
|
|
|
Programm3r wrote: rfc_char_t * exception_ptr;RFC_PARAMETER changing[MAX_PARA];rc = RfcCallReceiveEx(handle, functionname, exporting, importing, changing, tables, &exception_ptr);
Does RfcCallReceiveEx expects uninitialized RFC_HANDLE handle value, which is case here. Same is case with RFC_FUNCTIONNAME parameter.
|
|
|
|
|
prasad_som wrote: Does RfcCallReceiveEx expects uninitialized RFC_HANDLE handle value, which is case here. Same is case with RFC_FUNCTIONNAME parameter.
Not quite, take the following into account (I know I didn't mention it before)
sprintfU (connect_param, cU("DEST=%s CLIENT=%s USER=%s PASSWD=%s LANG=%s"), dest, client, user, pass, lang);
handle = RfcOpenEx(connect_param, &error_info);
strncpyU (functionname, "RFC_FUNCTION_NAME", sizeofU (RFC_FUNCTIONNAME) - 1);
And even if that was the case, I have never before had a compiler error like that, where I didn't initilized my variables.
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3rBronze
My Blog: ^_^
|
|
|
|
|
Oh !
And what about last paramter of RfcCallReceiveEx , is it expected to pass initialized pointer ? Or RfcCallReceiveEx does that ?
Who is owner of RfcCallReceiveEx ? Can you debug it ?
|
|
|
|
|
prasad_som wrote: And what about last paramter of RfcCallReceiveEx, is it expected to pass initialized pointer ?
No it is not expected to pass an initialized pointer:&exception_ptr
prasad_som wrote: Who is owner of RfcCallReceiveEx ? Can you debug it ?
A library called librfc32 developed by I have no idea. Can I debug it? No I can not. But I have used it previously without any problem, surely I'm doing something stupid.
Thank you very much for your patients prasad_som.
Regards,
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3rBronze
My Blog: ^_^
|
|
|
|
|
Programm3r wrote: surely I'm doing something stupid.
Only thing you can do wrong here is about parameters, as function is owned by some library. Check any information available about this function, and you are passing parameters are in correct manner.
|
|
|
|
|
|
Programm3r wrote: Compiler opens isctype.c file at the following location
this cannot be the source of the problem.
only your code is wrongly propagating dummy values. go through the call stack, from where the debugger stopped, and go up the stack until you reach a piece of code of your own... (and here, use the watch window )
|
|
|
|
|
toxcct wrote: this cannot be the source of the problem
I know and yes you are right.
I'm still working on the problem.
Thanx again toxcct
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3rBronze
My Blog: ^_^
|
|
|
|
|
prasad_som wrote: What call stack says to you ?
usually this error come when executable is in Release mode!.. so no call stack available for you there!
|
|
|
|
|
ThatsAlok wrote: usually this error come when executable is in Release mode!..
Dont think so this time. He has provided call stack. See his reply.
|
|
|
|
|
prasad_som wrote: Dont think so this time. He has provided call stack. See his reply
my mistake.. but generally this type of error comes in RELEASE mode!
|
|
|
|
|
|
Try using GetLastError() .
Regards,
Paresh.
|
|
|
|
|
Programm3r wrote: Microsoft Visual C++ Runtime Library
Runtime Error!
Program:..\executableName.exe
some uncatchable error!
|
|
|
|
|