|
I don't see how. ODBC is a set of functions split on two interfaces (interface in the general sense, not the COM way): one for the database client and one for the database provider. Unless there are some magic ADO->ODBC adapters (I know of none - but on the other hand I do not claim that I know everything  ), I don't see how ADO could ever provide any data for ODBC clients.
--
In Hypno-Vision
|
|
|
|
|
Jim Crafton wrote: If I use ADO to implement this interface, can this wrapper also be said to support ODBC on Windows?
Absolutly, ADO can connect to an amazing number of data sources. The best place to go to find out how to connect to different datasources is http://www.connectionstrings.com/[^]. Biggest chanlenge is supporting all of the various SQL differences out there.
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
|
|
|
|
|
Hi,
I have a VC++/MFC application.
I decided to move the UI to VB.NET to improve it.
I created a VB project with new interface and moved the C++ core into a MFC dll project.
When I run the application I got 'Stack owerflow' inside the MFC code.
For code details:
The C++ code does image processing using some recursive functionality, that is the point where the stack sucks up.
It happens when I passing over 4400 iterrations (the maximum is about 12000).
The recursive function looks like this
<br />
void CBitmapScan::CheckAround(CRect* pBound, int nX, int nY)<br />
{<br />
if(oMemDC.GetPixel(nX, nY) == RGB(0x00, 0x00, 0x00))<br />
{<br />
oMemDC.SetPixel(nX, nY, RGB(0xff, 0xff, 0xff));<br />
<br />
if(pBound->left > nX) pBound->left = nX;<br />
if(pBound->right < nX) pBound->right = nX;<br />
if(pBound->top > nY) pBound->top = nY;<br />
if(pBound->bottom < nY) pBound->bottom = nY;<br />
<br />
CheckAround(pBound, nX + 1, nY);<br />
CheckAround(pBound, nX - 1, nY);<br />
CheckAround(pBound, nX, nY + 1);<br />
CheckAround(pBound, nX, nY - 1);<br />
}<br />
}<br />
Why this happening?!
Thanks in advance
Peter
|
|
|
|
|
Your recursive function does not seem to have any terminating condition, so your recursion is infinite.
you might want to look at your logic here:
CheckAround(pBound, nX + 1, nY);
CheckAround(pBound, nX - 1, nY);
The function will keep bouncing back and forth between those two pixels under some conditions.
|
|
|
|
|
Actualy the terminating condition is in the first line of the function!
If it finds a black point IT REMOVES IT than moves over.
So never will jump back and forth because the first point already removed!
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: void CBitmapScan::CheckAround(CRect* pBound, int nX, int nY)
{
if(oMemDC.GetPixel(nX, nY) == RGB(0x00, 0x00, 0x00))
{
// Remove the pixel to avoid duble-check
oMemDC.SetPixel(nX, nY, RGB(0xff, 0xff, 0xff));
// Set new bounds
if(pBound->left > nX) pBound->left = nX;
if(pBound->right < nX) pBound->right = nX;
if(pBound->top > nY) pBound->top = nY;
if(pBound->bottom < nY) pBound->bottom = nY;
// Check up-down-left-right
CheckAround(pBound, nX + 1, nY);
CheckAround(pBound, nX - 1, nY);
CheckAround(pBound, nX, nY + 1);
CheckAround(pBound, nX, nY - 1);
}
}
You aren't checking to see if nX (nor nY) are within your current bounds before your recursive calls. Thus, the first recursive call will be called infinitely many times (and the subsequent ones will never get called, but would also be infinte if they were called).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
You right, however I have not to do because for every out-of-bound cordinates GetPixel returns -1, and that value will terminate the current run.
As you see the function actualy called only about 4500 times when the 'stack overflow' occured.
And more this function WORKS in a pure VC++ environment, only the in combination with the VB.NET interface it fails!
|
|
|
|
|
I have a solution to this problem.
I enclosed the functionality inside a new thread with a large stack and everything goes well.
The question remains is how to enlarge the stack for a VB.NET project?
|
|
|
|
|
I have a dialog based program using MFC. The program runs as expected when its opened. But when I close the dialog box (clicking the "X" or "esc"), I get the windows message "Program encountered an error and needs to be closed. We are sorry for the inconvenience." and askes to send error report. This happens almost every time I try to close. Since this is occuring only when closing, I have no idea how to debug this. Can anyone help? What could possibly be causing this?
|
|
|
|
|
What is the program doing when it closes? Are you able to comment out all nonessential code and still reproduce the problem? Does this happen in debug or relase mode, or both?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Just looking at the OnCancel() function, all I do is call a function that closes a driver (my program uses SDK provided to access drivers).
I also deallocate a pointer to an array if its allocated.
if (ptrArray)
{
delete []ptrArray;
ptrArray = 0;
}
I thought this might be causing a problem, but I've had the "encountered problem" message before I put this code in.
It occurs in both debug and release mode.
|
|
|
|
|
acerunner316 wrote: It occurs in both debug...
So what happens if you start the program using F5 (instead of Ctrl+F5)? Do you get any useful text in the debug window?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I get this sometimes
HEAP[<my_program_name>.exe]: Invalid Address specified to RtlFreeHeap( 00390000, 0010F57C )
or sometimes i get
The program <my_program_name>.exe exited with code 0x2
I guess I should also note that I don't really know how to use the debugger. I'm a Visual C++ noob. I only use debug and release to check that my code works the same on both, and works as expected.
|
|
|
|
|
acerunner316 wrote: HEAP[.exe]: Invalid Address specified to RtlFreeHeap( 00390000, 0010F57C )
At any point in time are you changing the value of ptrArray?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
oh i just realized, i do intend to change the value, but it doesn't. The ptr is 0 or NULL when i'm not using it, but when i do, i use the new operator. I should really be using malloc so that it returns a pointer value, instead of taking the chance of trying to allocate (new) to ptr 0. Could that be the problem? But then why would it crash only when I close.
|
|
|
|
|
acerunner316 wrote: I should really be using malloc...
No, you shouldn't be.
acerunner316 wrote: But then why would it crash only when I close.
Check the value of the pointer variable after new is called and before delete is called.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
How you have allocated memory for ptrArray.
Can your show.
One possible cause I see is deleting this memory twice(unintentionally may be).
|
|
|
|
|
Just to determin whether that was indeed problem, I got rid of the dynamic allocation of memory to that array. Instead, I set it to a fixed array size when its declared. But I still get that windows error message.
|
|
|
|
|
Can someone explain PostNcDestroy()? I saw it in some sample code, and I tried to look it up but couldn't quite understand the need for it.
|
|
|
|
|
I'm running a thread that constantly checks GetCurSel() to make a comparison. The problem occurs when I click the arrow on the droplist and move the mouse over selections. Before actually clicking to select something, the GetCurSel() seems to be returning the value that the mouse is highlighting. Is that correct? Shouldn't GetCurSel() return the actual value selected? How can I solve this?
|
|
|
|
|
acerunner316 wrote: I'm running a thread that constantly checks GetCurSel() to make a comparison. The problem occurs when I click the arrow on the droplist and move the mouse over selections. Before actually clicking to select something, the GetCurSel() seems to be returning the value that the mouse is highlighting. Is that correct? Shouldn't GetCurSel() return the actual value selected? How can I solve this?
Polling the GUI constantly is probably not what you want to do. Instead, try caching the value you need to compare within your thread and create an even for it to check on each interval to see if he needs to update its value. When you change the selection in the ComboBox, trigger the event.
Alternatively, you could also create a variable that is shared between the GUI thread and the other thread and set its value when there is a new selecting in the combo box. You will need to use Critical Sections for either of these solutions, though.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
If you just need to know when the selection changes, you should handle CBN_SELCHANGE - no need to do something as complex as a polling thread.
|
|
|
|
|
acerunner316 wrote: I'm running a thread that constantly checks GetCurSel()...
Does this thread own the UI control? Only the owning thread, which is usually the primary thread, should be interacting with the UI controls.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
what do you mean "own the UI control"? The thread begins on initialization of the window. And runs continuously with a sleep(10).
Anyways, I've already tooks Zac's advice and stored a variable. That's what I was going to do, but that involved changing a lot of code, so i was hoping there was another way to do it. It's probably the best way though.
|
|
|
|
|
acerunner316 wrote: what do you mean "own the UI control"?
UI controls (e.g., buttons, listboxes) are owned by a thread, usually the primary thread. Folks new to multi-threaded programming often make the mistake of having secondary threads communicate directly (e.g., SendMessage()) with those UI controls. Nasty things happen as a result.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
