|
I only commented about the original context, because it reminded me of the bad example,
and definitely didn't explain myself.
Your example has a recognizable context, thus easy for me to read. Same with some examples
in the other posted links.
A POINT class with a function operator that takes two ints, and uses those ints to offset
the POINT? Not very clear to me.
Thanks Hans,
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
To be completely honest, this TRACE example was the first one that I saw that made me realize how useful it could be. Like you, I had seen "academic" examples, but this one brought it home.
|
|
|
|
|
emilio_grv wrote: I don't see any need
Thanks, we'll be sure to check with you from now on.
Get over yourself
|
|
|
|
|
Thanks, I appreciate.
But, as you can see, that served as a prompt to the author to better explain is position.
It's called "reverse psychology"
It worked.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
yadrif wrote: So, what is the purpose of oerloading the () operator
Functors[^], of course.
|
|
|
|
|
Thanks to everyone for the help.
Thanks.
|
|
|
|
|
Hi everybody,
it's seriously possible to handle a click on the statusbar, or not?
This it work with OnNcHitTest?
Big thanks for help
Nice weekend everybody
|
|
|
|
|
A status bar is not a piece of "non-client area" (hence it has nothing to deal with OnNCHitTest).
It is just a child window, so you can either subclass it to get the messages it receives in a supplied procedure, or process it's notifications inside the parent message processing
(WM_NOTIFY, WM_PARENTNOTIFY etc.)
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
|
Hi Guys,
we have our own database and API. which is used by many application.
we have some ODBC SQl interface to support odbc driver to export data in Excel and any application.
I am able to understand the complte functionlity, but i am not much aware how OS will recognise odbc driver (may be using function )
i want some good article and good link on creating odbc driver with eg if possible
thanks Guys
|
|
|
|
|
I'm not clear on your question.
Are you trying to create an ODBC driver for your app ?
If so, a good place to start is here: http://www.iodbc.org/[^]
...cmk
Save the whales - collect the whole set
|
|
|
|
|
I've been doing this for years...
// When need access to specific item in my derived App class
CSomeApp* pApp=(CSomeApp*)AfxGetApp();
if (pApp) {
// Do something
}
// When need access to just the generic CWinApp class
CWinApp* pApp=AfxGetApp();
if (pApp) {
// Do something
}
Do I really need to check this pointer?
I struggle with the need to check the result from...
CView::GetDocument();
AfxGetApp();
Since CView seems to fail and assert like crazy without a document and the app thingy, well can you really not have something for the app pointer?
|
|
|
|
|
Safety is the best policy! (... unless you like crash)
Maxwell Chen
|
|
|
|
|
well... AfxGetApp returns an internally stored global pointer initialized by the CWinApp constructor.
Unless you are inside an MFC application with no CWinApp object, such pointer should never be NULL.
If you cannot exclude that certainly, you'd better to check.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
emilio_grv wrote: such pointer should never be NULL
That's what I'm thinking but I'm not sure if there is a situation where it could burn me. I couldn't imagine when it would fail.
CView without a CDocument. Theoretically it can be done but I've not the slightest idea how to get through all the ASSERTs if I tried.
|
|
|
|
|
bob16972 wrote: if there is a situation where it could burn me.
If you are the writer of the application you must know if and when the CWinApp is constructed / destroyed (that is: if it's a global variable, it is never null inside the CWinApp running)
If not (you're working on a part of somebody else application) don't trust.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
I'll probably keep coding the same way as usual then.
I prefer to be cautious anyway.
Thanks for the guidance.
|
|
|
|
|
If you are writing a console (DOS-box) application with MFC support, this might happen.
Maxwell Chen
|
|
|
|
|
The approach I've seen in that case is to just use a bare CDocument .
Software Zen: delete this;
|
|
|
|
|
I am developing application which has to use third party dll,(for scanning)who only has described exported functions with function definition.
After I developed a application,which gives proper result but it gives assertion in debug mode at each and every call of function imported from dll. Following is assertion.
"The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention."
And after completion of process (scanning) application terminates.
I read articles from google,msdn and included __stdcall ,WINAPI ,combination
but error comes as it is. In release mode assertion does not come.but application crashes everytime. I cannot debug it as application is terminating after passing end of function call. Only all it shows in debug is access violation and all binary code.
|| ART OF LIVING ||
|
|
|
|
|
This normally happens when you are using a wrong version of the library for linking with the dll. If you have the source code for the dll try rebuilding the dll and rebuilding the application.
Have you tried invoking the dll routines using LoadLibrary, and GetProcAddress. If the functions works perfectly using LoadLibrary calls, the problem is because of your wrong linking.
Arun Krishnan
|
|
|
|
|
The "calling convention" refers to which end of the function call is responsible for cleaning the stack. From your error, it sounds like you are using the wrong call and the stack is not being cleaned correctly. An important thing to note here, when a function is called, a pointer is pushed onto the stack so that the function knows which part of the code to return to. If the stack is not cleaned correctly, this pointer is lost causing the function to return to an incorrect location, causing a crash.
Read this[^] to get a better idea.
|
|
|
|
|
I am not having source code of dll and no contact with writer of that dll.
I also agree it is problem of calling convention. But what is solution for that.
I tried allmost all __cdecl,__stdcall,WINAPI, something like __forcecall (not exact)
.But it crashes after end of function.
|| ART OF LIVING ||
|
|
|
|
|
Do you have the header file for the dll? If not then how do you know the function paramaters?
|
|
|
|
|
Try calling your function using LoadLibrary and verify the results. If the problem is because of calling convention or linkage, LoadLibrary call will be successful.
I am not sure whether i am mis guiding you or not, but this is another alternative when you are stuck.
Arun Krishnan
|
|
|
|