ANY GURU TO EXPLAIN THIS?
-
Anybody heard about CListCtrl... there is a member function called SetItemData(int,dword). I use this function when i retrieve data from an ado cursor while (!RecSet->EndOfFile()) { //here insert data from recset into CListCtrl SetItemData(nItem,anyvalue); RecSet->MoveNext() } Now the interesting part: Probably nobody believes me!(:-) After two loops no problem...In the third loop my application die. Then i modified the code like this: while (!RecSet->EndOfFile()) { //here insert data from recset into CListCtrl SetItemData(nItem,anyvalue); for (int i=0;i<100.000;i++); RecSet->MoveNext() } Error again... Then I tried this: while (!RecSet->EndOfFile()) { //here insert data from recset into CListCtrl SetItemData(nItem,anyvalue); for (int i=0;i<1.000.000;i++); RecSet->MoveNext() } NO PROBLEM AT ALL... My question is WHY? WHY? WHY?
-
Anybody heard about CListCtrl... there is a member function called SetItemData(int,dword). I use this function when i retrieve data from an ado cursor while (!RecSet->EndOfFile()) { //here insert data from recset into CListCtrl SetItemData(nItem,anyvalue); RecSet->MoveNext() } Now the interesting part: Probably nobody believes me!(:-) After two loops no problem...In the third loop my application die. Then i modified the code like this: while (!RecSet->EndOfFile()) { //here insert data from recset into CListCtrl SetItemData(nItem,anyvalue); for (int i=0;i<100.000;i++); RecSet->MoveNext() } Error again... Then I tried this: while (!RecSet->EndOfFile()) { //here insert data from recset into CListCtrl SetItemData(nItem,anyvalue); for (int i=0;i<1.000.000;i++); RecSet->MoveNext() } NO PROBLEM AT ALL... My question is WHY? WHY? WHY?
I think the problem is that the application need time to SendMessage to ListCtrl... When you did the for from 0 to 1.000.000 the SendMessage had the necesary time. I belive that this is the problem. Please try this: while(!RecSet->EndOfFile()) { //here insert data from recset into CListCtrl SetItemData(nItem,anyvalue); ProcessMessages(); RecSet->MoveNext(); } void ProcessMessages() { MSG msg; if(PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) ) { TranslateMessage( &msg ); DispatchMessage( &msg ); } } Cheers!!! :-D Carlos Antollini.
-
I think the problem is that the application need time to SendMessage to ListCtrl... When you did the for from 0 to 1.000.000 the SendMessage had the necesary time. I belive that this is the problem. Please try this: while(!RecSet->EndOfFile()) { //here insert data from recset into CListCtrl SetItemData(nItem,anyvalue); ProcessMessages(); RecSet->MoveNext(); } void ProcessMessages() { MSG msg; if(PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) ) { TranslateMessage( &msg ); DispatchMessage( &msg ); } } Cheers!!! :-D Carlos Antollini.
But SendMessage is synchronous, is it not? It waits for the message to be processed before returning. So I doubt that's his issue. I would wonder if he has stepped into the code to determine if it is, in fact, the List control that is failing, and not the Record Set. Given the code is has shown here, there is really no way to determine the cause. An error like that could be coming from anywhere. I would suggest taking the record set out of the equation, and just post constant data to the list control to see what happens. If it is the list control, I would suggest the app has some serious memory related issues going on somewhere. I don't think he has a problem with the List control, the problem is somewhere else.
-
But SendMessage is synchronous, is it not? It waits for the message to be processed before returning. So I doubt that's his issue. I would wonder if he has stepped into the code to determine if it is, in fact, the List control that is failing, and not the Record Set. Given the code is has shown here, there is really no way to determine the cause. An error like that could be coming from anywhere. I would suggest taking the record set out of the equation, and just post constant data to the list control to see what happens. If it is the list control, I would suggest the app has some serious memory related issues going on somewhere. I don't think he has a problem with the List control, the problem is somewhere else.
-
Agree with Stan. This is probably a memory leak overwriting the list control or the recordset's memory, causing the unexplained behavior. I've done this same type of thing before with ADO with no problems.
Sorry guys... PeekMessage doesnt solve the problem. Any other ideas? I want to know THE REASON !!! PS: I solve the problem puting the "anyvalue" in lParam member of LVITEM structure-it works-.
-
Sorry guys... PeekMessage doesnt solve the problem. Any other ideas? I want to know THE REASON !!! PS: I solve the problem puting the "anyvalue" in lParam member of LVITEM structure-it works-.
I realize i have to be more, more specific. Here the code is simplified for you to understand faster. Have fun! First: RecSet is a member of my CDialog derived class and i never call RecSet->Close() void CDemosDlg::PopulateList() { m_list1.SetExtendedStyle(LVS_EX_FULLROWSELECT); m_list1.InsertColumn(0,"Camp0",LVCFMT_LEFT,100); m_list1.InsertColumn(1,"Camp1",LVCFMT_LEFT,100); m_list1.InsertColumn(2,"Camp2",LVCFMT_LEFT,100); try { for (int i=0;i<10;i++) { //code for inserting first item -NEVER CALL RecSet- //code for inseting subitems -NEVER CALL RecSet- m_list.SetItemData(i,i); } } catch(_com_error &e) { MessageBox(e.Description()); MessageBox(e.Source()); } catch(...) { MessageBox("Others"); } } THE RESULT?_com_error!!! MessageBox("The Operation requested by the application is not allowed if the object is closed") MessageBox("ADODB.Recordset"); OK. If i put "for(int j=0;j<1.000.000;j++);" just after "m_list.SetItemData(i,i)" no problem at all. OK. if i drop "m_list.SetItemData(i,i)" from the code above no problem at all. OK. Doesnt matter if i use or not the RecSet in code above.The same result. I hope i made myself clear. How come "m_list.SetItemData" is so weird??? PS: My application is finished and it is ok. The extra data is placed in lParam of LVITEM structure.
-
Anybody heard about CListCtrl... there is a member function called SetItemData(int,dword). I use this function when i retrieve data from an ado cursor while (!RecSet->EndOfFile()) { //here insert data from recset into CListCtrl SetItemData(nItem,anyvalue); RecSet->MoveNext() } Now the interesting part: Probably nobody believes me!(:-) After two loops no problem...In the third loop my application die. Then i modified the code like this: while (!RecSet->EndOfFile()) { //here insert data from recset into CListCtrl SetItemData(nItem,anyvalue); for (int i=0;i<100.000;i++); RecSet->MoveNext() } Error again... Then I tried this: while (!RecSet->EndOfFile()) { //here insert data from recset into CListCtrl SetItemData(nItem,anyvalue); for (int i=0;i<1.000.000;i++); RecSet->MoveNext() } NO PROBLEM AT ALL... My question is WHY? WHY? WHY?
-
I realize i have to be more, more specific. Here the code is simplified for you to understand faster. Have fun! First: RecSet is a member of my CDialog derived class and i never call RecSet->Close() void CDemosDlg::PopulateList() { m_list1.SetExtendedStyle(LVS_EX_FULLROWSELECT); m_list1.InsertColumn(0,"Camp0",LVCFMT_LEFT,100); m_list1.InsertColumn(1,"Camp1",LVCFMT_LEFT,100); m_list1.InsertColumn(2,"Camp2",LVCFMT_LEFT,100); try { for (int i=0;i<10;i++) { //code for inserting first item -NEVER CALL RecSet- //code for inseting subitems -NEVER CALL RecSet- m_list.SetItemData(i,i); } } catch(_com_error &e) { MessageBox(e.Description()); MessageBox(e.Source()); } catch(...) { MessageBox("Others"); } } THE RESULT?_com_error!!! MessageBox("The Operation requested by the application is not allowed if the object is closed") MessageBox("ADODB.Recordset"); OK. If i put "for(int j=0;j<1.000.000;j++);" just after "m_list.SetItemData(i,i)" no problem at all. OK. if i drop "m_list.SetItemData(i,i)" from the code above no problem at all. OK. Doesnt matter if i use or not the RecSet in code above.The same result. I hope i made myself clear. How come "m_list.SetItemData" is so weird??? PS: My application is finished and it is ok. The extra data is placed in lParam of LVITEM structure.
As others have mentioned, you problem is showing up at the 'SetItemData' call, but unlikely to be caused by this. Your own testing shows you that the error is a COM error reported by ADODB.RecordSet, and is an 'Object is closed' problem. This is very, very unlikely to be in anyway related to "SetItemData". You need to re-examine the ADO record set code - somewhere there lies the problem. The suggestion that you are reading one past the end of the records is worth pursuing. So why does "SetItemData" trigger the problem ? It probably doesn't - it's just the unlucky 'innocent victm' of some other piece of rogue software. Stop concentrating on "SetItemData", and check the rest of the code.
-
As others have mentioned, you problem is showing up at the 'SetItemData' call, but unlikely to be caused by this. Your own testing shows you that the error is a COM error reported by ADODB.RecordSet, and is an 'Object is closed' problem. This is very, very unlikely to be in anyway related to "SetItemData". You need to re-examine the ADO record set code - somewhere there lies the problem. The suggestion that you are reading one past the end of the records is worth pursuing. So why does "SetItemData" trigger the problem ? It probably doesn't - it's just the unlucky 'innocent victm' of some other piece of rogue software. Stop concentrating on "SetItemData", and check the rest of the code.
Mike Burston told me: "Stop concentrating on "SetItemData", and check the rest of the code." The code is well finished WITHOUT SetItemData as I always told you. The code is very simple: Open a connection, open a cursor, bind the cursor and then populate the list. If you have 5 minutes free please try on your computer and let me know the result... Dont forget to put into the code SetItemData. ;) Thanks.
-
Mike Burston told me: "Stop concentrating on "SetItemData", and check the rest of the code." The code is well finished WITHOUT SetItemData as I always told you. The code is very simple: Open a connection, open a cursor, bind the cursor and then populate the list. If you have 5 minutes free please try on your computer and let me know the result... Dont forget to put into the code SetItemData. ;) Thanks.
Daniel, I cannot try an exact test of your problem because you have not posted the entire code, only the portions relating to the 'populateList' function, which is where you are getting a crash/error in the SetItemData (after a few iterations). The point I am making is that you probably have an error somewhere else - nothing in the 'populateList' code appears likely to generate the errors you are reporting. The exception you are trapping is telling you clearly that you are attempting an operation on a closed ADO object. "SetListItem" is not related to ADO in any way. A quick search of the MFC source shows that SetItemData is like many MFC functions - a very thin wrapper around the corresponding win32 API calls. In this case, it's essentially just a call to "SendMessage(m_hwnd, LVM_SETITEM, 0, (LPARAM)pItem)". _AFXCMN_INLINE BOOL CListCtrl::SetItem(const LVITEM* pItem) { ASSERT(::IsWindow(m_hWnd)); return (BOOL) ::SendMessage(m_hWnd, LVM_SETITEM, 0, (LPARAM)pItem); } _AFXCMN_INLINE BOOL CListCtrl::SetItemData(int nItem, DWORD dwData) { ASSERT(::IsWindow(m_hWnd)); return SetItem(nItem, 0, LVIF_PARAM, NULL, 0, 0, 0, (LPARAM)dwData); } The point is, and remains, that it is likely you have a subtle problem somewhere in the ADO record set handling code. This problem is subtle enough that it only causes an exception in some circumstances - in other cases (something as apparently simple as removing a call to "SetItemData") the error still occurs, but has not visible effect. In other words, your program may 'appear' to run fine now that you have removed the "SetItemData" call, but it is probable that you have simply curied a symptom, not the disease. Again, I think you need to leave "SetItemData" alone, and concentrate on the rest of the code. Somewhere in there you have a logic error waiting to bite you at some point in the future (probably when you can least afford the time to find it!)