|
Open Excel file,Error
_ConnectionPtr m_adoConn;
_RecordsetPtr m_adoRec;
::CoInitialize(NULL);
m_adoConn.CreateInstance(__uuidof(Connection));
m_adoConn->Open("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=c:\\1.xls;Extended Properties=Excel 8.0;IMEX=1;","","",adModeUnknown);
stop this function:
inline HRESULT Connection15::Open ( _bstr_t ConnectionString, _bstr_t UserID, _bstr_t Password, long Options ) {
HRESULT _hr = raw_Open(ConnectionString, UserID, Password, Options);
if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this));
return _hr;
}
why error
thank
Blog:
http://taotesea.spaces.live.com
|
|
|
|
|
What error do you get (usually errors are quite informative)? On what line of code?
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
|
|
|
|
|
|
there are several choices of exceptions handling for c/c++(win32 platform).
but what are the differences among try...catch, __try...__except,and try...finally?
and when we should use the most suitable one of them?
Regards.
modified on Sunday, March 9, 2008 1:28 AM
|
|
|
|
|
|
but they are more complex in my mind,for example
DWORD test()
{ //cout<<"A exception handled."<<endl;
return EXCEPTION_EXECUTE_HANDLER;
}
void main()
{
try//__try
{
__asm int 3;
}
catch//__except(test())
{
cout<<"A exception "<<endl;
}
}
here,the program can't work will ,but if replaced by __try...__except,it works well.why?
|
|
|
|
|
Structured exception handling works with C and C++ source files.
It was not designed for C++ specifically. To ensure your code is portable, you will want to use C++ exception handling.
As stated by MSDN, for "C++ programs, C++ exception handling should be used instead of structured exception handling"
SkyWalker
|
|
|
|
|
thanks.
I will go and read it carefully.
|
|
|
|
|
If this a C program, i think you cannot use C++ exception.
|
|
|
|
|
but if i treat it as a c++ program?
the code can be compiled and linked no matter i use try...catch or __try...__except.
the only difference is the result of running.
|
|
|
|
|
By default, VS2005 uses synchronous exception model by default. Try changing to /EHa (vsproperty->C/C++->Code generation->Enable C++ Exception = /EHa).
And read the msdn document whose link i already given (especially Synchronous & Asynchronous exception handling).
|
|
|
|
|
|
Hi,
I like to draw lines with delay but using threads. The data will be fetched from different list (m_lstpoints). they have to be drawn simultaneously. When i tried to do this i am getting illegal.
I am very much new to threads. Can u help me.
//Code
CRITICAL_SECTION g_csGDILock; //Initialized
AfxBeginThread(DrawStrokesUsingThrd, (LPVOID)pTInfo1);
AfxBeginThread(DrawStrokesUsingThrd, (LPVOID)pTInfo2);
AfxBeginThread(DrawStrokesUsingThrd, (LPVOID)pTInfo3);//This list
is dynamic
//The pTInfo contains the g_csGDILock pointer and other info
//to draw points such as dc and list of points.
void CPlotPoints::TDrawPoints(HDC hdc, PRTL_CRITICAL_SECTION pMutex){//Non static
POSITION pos =NULL;
CPoint pt1, pt2;
pos =m_lstPoints.GetHeadPosition();
pt1=(CPoint) m_lstPoints.GetNext(pos);
while (pos){
EnterCriticalSection(pMutex);
{
pt2=(CPoint) m_lstPoints.GetNext(pos);
CDC dc; //hdc is a CClientDC
dc.Attach(hdc);//I had even tried to Send CClientDC* directly
//Plot code begins
//Here we draw rectangles,lines or something using dc
//dc.Moveto(pt1); //These lines are giving assertion
//Plot code ends here
dc.Detach();
GdiFlush();
}
LeaveCriticalSection(pMutex);
Sleep(300);
}
}
Thank you.
Manu
|
|
|
|
|
|
Several remarks first:
- You don't describe which problem you are having: "i am getting illegal" is not very informative sentence to me 
- Use the pre tags to format your code properly because it is almost unreadable.
- Please, read the posting guidelines on top of this forum.
Now for your problem: if you are trying to draw things from multiple threads, that's probably why your code crashes. You should only have the main thread that access the UI.
|
|
|
|
|
Sir,
You got it. I am sorry to say this that i mentioned in the code
with a comment where i am getting illegal or assertion dailog.
("//dc.Moveto(pt1); //These lines are giving assertion").
I am clearly and purposefully making my child threads to
draw the lines. What is the alternative. More over i had initialized
the critical section also.
1. Shall i ask the view to redraw the points by sending the points
2. or else i have to do something else.
Thanks for answering my question.
Regards,
Manu
|
|
|
|
|
kanduripavan wrote: 1. Shall i ask the view to redraw the points by sending the points
Yes, you should find a mechanism that let the view (and only the view) redraw the data? Everything that is 'generated' from the threads should be independant from the view. You'll need to store this data somewhere and inform the view that new data is available by sending a message to the view. Access to the data should also be protected with critical sections (for example).
|
|
|
|
|
Sir,
Thank you very much. I am very much new to threading.
I like to plot points without timer and using threads only.
The output which i wanted was that each points has to be plotted
individually. Nothing professional. i am just entering into this
new world of threading and experiencing the problems of multi thread
programming if i am going to implement in near future.
I will try and implement the same and get back to you.
I saw similar kind of codes in MTGDI but they are subclassed(CWinthread).
I want to experiment if a particular section of the code is implemented
by multiple threads then what will happen.What will happen to CList object poistion variables, and impact of other things. This is my intention.
Thank you very much.
Manu
|
|
|
|
|
Hi,
I did it as you said. It has fixed my problem of plotting multiple points simultaneously.
<br />
EnterCriticalSection(pMutex);<br />
{<br />
<br />
pt2=(CPoint) m_lstPoints.GetNext(pos);<br />
pView->SendMessage(ID_VIEW_DRAWOFFLINE, (LPARAM)&pt1,(WPARAM)&pt2 );<br />
LeaveCriticalSection(pMutex);<br />
}<br />
<br />
Thank you very much Cédric Moonen, Mark Salsbery,Suman and others who looked after my issue.
|
|
|
|
|
And, It seems to me you are using document view architecture. I understand MFC framework has mechanism for achieving this type of requirement.
Have a look at CDocument::UpdateAllViews() and
CView::OnUpdate
"Typically you should not perform any drawing directly from OnUpdate. Instead, determine the rectangle describing, in device coordinates, the area that requires updating; pass this rectangle to CWnd::InvalidateRect. This causes painting to occur the next time a WM_PAINT message is received." from msdn.
This allows all the drawing code happens in WM_PAINT message than custom message.
In your thread modify the members of document object which stores the points and call UpdateAllViews(). which finally results WM_PAINT message for the views, in the paint handler of the view get the points from Document object (must be synchronised) and draw the view.
|
|
|
|
|
You can do drawing from another thread, but you need to really understand thread
synchronization.
Nothing in GDI is thread safe, so ALL GDI operations need to be synchronized between threads.
Have you initialized your GDI critical section?
Do you have one and ONLY one critical section object shared by all the threads?
If you answered no to either of those, you aren't using thread synchronization objects correctly.
Don't forget to synchronize the UI thread as well.
What is causing the assertion? You should be able to look right at the offending line of
code in the debugger.
What is the exact assertion message?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
I have one one critical section shared by all the threads. I had Initialized the critical section before creating the child threads.
I have 2 doubts.
1.The critical section is initialized by the UI Thread ie by the primary thread. So is it there it can go wrong.
2.Lets leave the GDI issue and consider the handle as a shared object
which is inside the critcal section. SO how can the 2nd or the 3rd thread can enter and access it. As a beginner it seems for me that is is not logically valid. (the thread trying to acess gdi handles which is inside the critical section). I am extremely sorry to say these lines.
The assertion is shown in GDI files. But as far as i know it occured
due to the line
dc.LineTo(pt1);//From here onwards the error might have occured
I like to thank you for supporting the one who doesnt knows anything.
Thank you.
|
|
|
|
|
kanduripavan wrote: 1.The critical section is initialized by the UI Thread ie by the primary thread. So is it there it can go wrong.
Any thread can initialize it, as long as it's initialized before a thread tries to use it.
kanduripavan wrote: consider the handle as a shared object
which is inside the critcal section
This is only a logical way to think about it. In reality, there's no protection of the handle by the critical section.
What the critical section does is prevent execution of code by a thread until another thread owning the critical section
releases the critical section. This can be used to prevent two threads from using/changing the same handle/variable/data or
any other resource shared by multiple threads. Critical sections can also be used just to prevent two threads from
executing the same code simultaneously - there doesn't have to be any data or other resource involved.
kanduripavan wrote: The assertion is shown in GDI files
You have the source code - what's the line of code??
Using MFC may not work for what you're doing, since MFC has internal containers that are thread-specific.
To get around this, you can use an HDC directly instead of through the CDC and derived classes.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I looked at the MFC source code - the only way I can see LineTo() asserting is if
the HDC is NULL.
That's a problem elswhere in the creation of your dc.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
hi ,
Thats great as what you said. The problem was in creating the dc.
The code was
<pre>
void CThreadDemoView::OnMenuOffline()
{
// TODO: Add your command handler code here
CClientDC dc(this);
CreateThreadsToPlot(pDC, CPoint(100,100) );
}
</pre>
CreateThreadsToPlot will create the required no of threads to plot the
points.
After seeing your reply i tried this as a last attempt before giving it up. I went and browsed into the gdi code and found that my dc was not null. but surprisingly i think its invalid. This could be probably one
of the reason i might have got the assertion. The code change was
<pre>
void CThreadDemoView::OnMenuOffline()
{
// TODO: Add your command handler code here
CDC* pDC =GetDC();<B>//code changed here only</B>
CreateThreadsToPlot((CDC*)pDC, CPoint(100,100) );
}
</pre>
This way of getting the DC has fixed the same issue without changing
not even a single line of code in the program.
Thank you very much Mr. Mark Salsbery.
By,
Manu
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
