|
HDC hdc = GetDC(NULL);
COLORREF cr = GetPixel(hdc, x,y);
ReleaseDC(hdc);
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
it's perfect, thank you very much!
|
|
|
|
|
It seems you need toget pixel of a bmp file that you read of clipboard,right?
|
|
|
|
|
Hello everyone,
I posted the code and related compile error below. My analysis below,
1. I think the reason of compile error is, the copy constructor of Goo accepts const reference as input parameter, so the pf member of input parameter is also treated const?
2. And since auto_ptr does not have a copy constructor which accepts const reference auto_ptr as input parameter, the compile error occurs.
My analysis (1) and (2) are both correct?
What makes me confused is it seems the compile error message does not reflect my analysis (1) and (2) above. Any ideas?
#include <memory>
using namespace std;
class Foo {
};
class Goo {
public:
auto_ptr<Foo> pf;
Goo (const Goo& input)
{
this -> pf = input.pf;
}
};
1>d:\visual studio 2008\projects\test0330\test0330\main.cpp(18) : error C2679: binary '=' : no operator found which takes a right-hand operand of type 'const std::auto_ptr<_Ty>' (or there is no acceptable conversion)
1> with
1> [
1> _Ty=Foo
1> ]
1> d:\program files\microsoft visual studio 9.0\vc\include\memory(689): could be 'std::auto_ptr<_Ty> &std::auto_ptr<_Ty>::operator =<Foo>(std::auto_ptr<_Ty> &) throw()'
1> with
1> [
1> _Ty=Foo
1> ]
1> d:\program files\microsoft visual studio 9.0\vc\include\memory(701): or 'std::auto_ptr<_Ty> &std::auto_ptr<_Ty>::operator =(std::auto_ptr<_Ty> &) throw()'
1> with
1> [
1> _Ty=Foo
1> ]
1> d:\program files\microsoft visual studio 9.0\vc\include\memory(707): or 'std::auto_ptr<_Ty> &std::auto_ptr<_Ty>::operator =(std::auto_ptr_ref<_Ty>) throw()'
1> with
1> [
1> _Ty=Foo
1> ]
1> while trying to match the argument list '(std::auto_ptr<_Ty>, const std::auto_ptr<_Ty>)'
1> with
1> [
1> _Ty=Foo
1> ]
thanks in advance,
George
|
|
|
|
|
IMHO your analysis is correct (both point 1 and 2. However, with regard to point 1, my interpretation is: since Goo copy constructor declares its argument const , then its content cannot be modified, but assigment operator of auto_ptr modify its argument, hence the problem).
George_George wrote: What makes me confused is it seems the compile error message does not reflect my analysis (1) and (2) above. Any ideas?
I think that (it's just an hypothesis), since no auto_ptr copy constructor can match the this -> pf = input.pf; , the compiler tries to search for an assignment operator match, but it fails again and gives such error.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Cool, CPallini!
1.
CPallini wrote: I think that (it's just an hypothesis), since no auto_ptr copy constructor can match the this -> pf = input.pf;, the compiler tries to search for an assignment operator match, but it fails again and gives such error.
You mean compiler search for all forms of assignment operator of auto_ptr, then no one matches so the compile errors come?
2.
The source of error is because the basic C++ ruls is violated -- can not assign const reference (input.pf) to non-const reference (input parameter of assignment operator of class auto_ptr)?
regards,
George
|
|
|
|
|
George_George wrote: 1.
CPallini wrote:
I think that (it's just an hypothesis), since no auto_ptr copy constructor can match the this -> pf = input.pf;, the compiler tries to search for an assignment operator match, but it fails again and gives such error.
You mean compiler search for all forms of assignment operator of auto_ptr, then no one matches so the compile errors come?
Yes, I think so.
George_George wrote: 2.
The source of error is because the basic C++ ruls is violated -- can not assign const reference (input.pf) to non-const reference (input parameter of assignment operator of class auto_ptr)?
Yes.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Thanks CPallini,
Question answered! Cool!!
regards,
George
|
|
|
|
|
say i have a function int fun(int *a),
and other function int fa(); int fb(), int fc(),....int fn();
all the them will call the fun(int *a),
but the problem is, when I run the program, the vc++ tells me some of them pass the NULL pointer to the fun(int *a) which make mistake, but could not tell me which function calls the fun(int *a) and then pass the NULL pointer to it,
so dear guys, how could I know which one call the fun(int *a) that pass the NULL pointer?
Thanks.
|
|
|
|
|
I didn't really understand your problem. Do you have a crash and would like to find the problem ? If yes, did you use your debugger to track the problem ? Using the callstack you'll be able to find which function passed a NULL pointer.
|
|
|
|
|
Hi,
If your program stops with runtime error, as Cedric said, use the "call stack" window and see which one of fa(), fb().. fn() is called just before fun().
Or try using only one function from fa(), fb() ... fn() at a time
and find out.
If you have problem still post the relevant code snippet.
Best Regards,
Suman
--
"Programming is an art that fights back!"
|
|
|
|
|
Well one way like others said, if you are programming in Visual Studio, you can set break point and check the call stack when program crashes.
Another way is to do it like this:
int fa()<br />
{<br />
int* a;<br />
.<br />
.<br />
.<br />
if(a == NULL)<br />
{<br />
cout << "fa is the culprit";<br />
}<br />
fun(a);<br />
}
-Saurabh
|
|
|
|
|
Use the debugger to set a breakpoint in fun() . When a equals NULL , check the call stack.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Did you get runtime error?
|
|
|
|
|
Without asking how to do it, I'd like to ask if it's theoretically possible for me to create my own version of the C++ runtime, and have VC++ link my programs to that instead of the usual one.
Is such a thing possible?
“Cannot find REALITY.SYS...Universe Halted.”
~ God on phone with Microsoft Customer Support
|
|
|
|
|
Yes it's possible.
See the /ENTRY linker option...
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
|
Do you want to make an exe file yourself without vc++ compiler?
|
|
|
|
|
Hi,
I recently moved application resources (dialogs and strings) into a resource only DLL and came across a problem that I don't fully understand... thanks for some help.
As soon as I created my main dialog from the loaded DLL it failed and the debug output showed something like: >>> If this dialog has OLE controls: AfxEnableControlContainer has not been called yet . I traced it back to an owner draw control in the dialog, when I removed this control all worked fine. So I played around a bit with my owner draw control. It is derived from CWnd and tries to register a window class, here is the code:
WNDCLASS wndcls;
HINSTANCE hInst = AfxGetInstanceHandle();
if(!(::GetClassInfo(hInst, MY_CONST_CLASSNAME, &wndcls)))
{
wndcls.style = CS_DBLCLKS | CS_HREDRAW | CS_VREDRAW;
wndcls.lpfnWndProc = ::DefWindowProc;
wndcls.cbClsExtra = wndcls.cbWndExtra = 0;
wndcls.hInstance = hInst;
wndcls.hIcon = NULL;
wndcls.hCursor = AfxGetApp()->LoadStandardCursor(IDC_ARROW);
wndcls.hbrBackground = NULL;
wndcls.lpszMenuName = NULL;
wndcls.lpszClassName = MY_CONST_CLASSNAME;
AfxRegisterClass(&wndcls)
}
After I replaced AfxGetInstanceHandle() with AfxGetResourceHandle() it works. This was just try and error, am I doing it right? Because MSDN says hInstance = "Handle to the instance that contains the window procedure for the class".
/Moak
|
|
|
|
|
Moak wrote: After I replaced AfxGetInstanceHandle() with AfxGetResourceHandle() it works.
It's interesting that it works, since DefWindowProc() isn't in either of your modules
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark now I am more confused
...did I do something stupid?
|
|
|
|
|
Moak wrote: ...did I do something stupid?
Heh not that I can see off hand. I'm just curious why it works with one HINSTANCE and not
the other...unless one is NULL?
Do you use AfxSetResourceHandle() somewhere?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: Do you use AfxSetResourceHandle() somewhere?
Yup, the resources are loaded from a satellite DLL with LoadLibrary() and AfxSetResourceHandle(). The HINSTANCE for both (application or DLL) is not NULL.
|
|
|
|
|
I just found something. Looks like my code for registering the window class is like in Chris Maunder's article Creating Custom Controls[^] and someone mentions the same problem there.
Thanks for help
/M
|
|
|
|
|
Hei Moak,
Yes, you have made the correct fix. Now let me explain why. I will try to be very detailed so forgive me if I walk at too low of a level.
You see... at the very root it all has to do with Protected Mode[^] and how the operating system handles virtual addresses. When you load a resource, naturally the operating system needs to know where this resource is located in memory before you can use it. Normally if the resource is located in the executable you can simply pass AfxGetInstanceHandle() and at the lower levels the translation lookaside buffer[^] looks for the location for your processes virtual address. If there is a TLB-miss then it would have to access the page table to find this physical memory offset.
Essentially what I am saying is that AfxGetInstanceHandle() is nothing more than the module base address. These addresses are used for finding the resource.
You can see this by doing the following experiment:
#define MyGetInstanceHandle((HINSTANCE)&__ImageBase)
You can do something similar inside the DLL to see that all your actually passing is the module base address:
__inline HINSTANCE MyGetResourceHandle(LPCTSTR lpModuleName)
{
HINSTANCE h;
GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS, lpModuleName, &h);
return h;
}
Best Wishes,
-David Delaune
|
|
|
|