|
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++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
|
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
|
|
|
|
|
Thanks for the detailed feedback!
/Moak
|
|
|
|
|
That's all cool info, but how does it affect the failed creation of the window using the OP's registered
window class?
Thanks,
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Moak explained that he was creating a resource-only DLL[^] for his dialogs and other misc resources. How can you instantiate a dialog if you cannot locate the dialog resources. The WNDCLASS structure is populated with information from the resource section. Therefore his call to GetClassInfo() failed.
AfxGetInstanceHandle() will return the base address of MyApplication.EXE
AfxGetResourceHandle() will return the base address of MyModule.DLL
So when he used AfxGetInstanceHandle() the window creation failed because it was searching for the dialog resources in MyApplication.EXE when they were actually located in MyModule.DLL
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: Therefore his call to GetClassInfo() failed.
That's the part I was missing!
Thanks man!
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
It should be known that the explanation I gave was actually a simplified description of what actually happens under the MFC hood. I neglected to mention AfxSetResourceHandle() and afxCurrentResourceHandle. I also left out AFX_MANAGE_STATE(AfxGetStaticModuleState())[^] and duplicate resource ID issues all for the sake of brevity.
Best Wishes,
-David Delaune
|
|
|
|
|
Right. I got all that. I was just not wrapping my head around what was specifically causing failure in this
case, and why the change fixed it.
Thanks again,
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Is there a simple code to print the Image to the printer ?
I already have 'screen capture' and save its to a .bmp file.
( http://84.244.8.225/winscreen.html ) .
Thx ,
Frederik Pot (Holland)
|
|
|
|
|
I found a sort of solution:
I get the pixels from the screen with GetPixel().
First : HDC im = GetDC(hwnd);
And the something like:
kleur = GetPixel(im, x, y);
rood = (int) GetRValue(kleur);
groen = (int) GetGValue(kleur);
blauw = (int) GetBValue(kleur);
SetPixel(hPrinter, x, y, RGB(rood, groen, blauw));
But it looks it delivers verry small images...
So any other tips will be welcome... Thx !
|
|
|
|
|
For a rectangular region of pixels, there's no need to copy a pixel at a time.
You can use something like StretchBlt() instead.
Most modern printers (and thus their DCs) have a much larger dots-per-inch (DPI) value
than screens, so you should use GetDeviceCaps() to get the HORZRES/VERTRES and/or
LOGPIXELSX/LOGPIXELSY values for the printer DC so you know what dimensions to
stretch the captured pixels to.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
You can use of StretchBlt or BitBlt and you need to handle (hdc) of printer.
|
|
|
|
|
I've got an application that runs on several computers which handles simultaneous video capture (to be clear, each system runs it's own copy of the capture software). I've got another application that runs on another computer and is used to control capture software that is running on the other systems.
Currently, the capture software uses the winsock call "listen" to listen for incoming connections on a specific port. When I want to connect to the capture systems from the control system, I use the winsock call "connect" to make the connection. Currently, I cycle through a list of possible capture machines and attempt to connect to each one, however, the capture systems may or may not be running the capture software. Because connect doesn't allow me to specify a timeout, this connection process can take an extremely long time if even a single capture system is powered down or isn't running the software.
So my question is:
Is there a way to check to see if a system is listening for a connection before I call connect? Or, is there a better way to handle establishing connections between my machines.
Thanks,
Adam Kraver
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
