|
I am again with the question refered before as COleDateTime.
I am using classes derived from CRecordSet to do ODBC connectivity. I want to pass null values to the database. The wizard have created variables for every table field. How do I pass null values to the DB especially DateTime.
This is urgent.. please.
|
|
|
|
|
Call CRecordSet::SetFieldNull. Pass field variable address as first param and TRUE as second.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
|
I know this is more than likley a dumb question but... I have seen some dialog boxes where right below the menu they have drawn a simple straight line to devide the menu from the dialog box.. how do they draw a straight line?
Thanks,
Rob
|
|
|
|
|
Use a group box with no caption and make the height of the box smallest size.
cheers
Alfadhly
|
|
|
|
|
There are no dumb questions, only dumb people!
|
|
|
|
|
how can I send to a MFC called "A" information of a "mthing" to another MFC called "B"???
For example, I want to transmit to "A" a name stocked in "B" when I pushed a button "OK"
thanks...
|
|
|
|
|
whats an MFC?
an MFC window? an MFC program? an MFC Dll? an MFC Class?
if you want to transfer data between applications you can use any of the various IPC methods. The simplest way is to send a WM_COPYDATA message.
|
|
|
|
|
hi!!!
thanks to answer to my question!!!
I want to send parameters from a dialog Box "A" to a Dialog Box "B"....
|
|
|
|
|
You can create a new member variable for your CbDlg dialog box(example type CbDlg name m_dBdlg)in CaDlg class then use the class wizzard assign member variables to your drop down boxes, edit boxes etc.. now within dialog box "a" you can for example use m_dBdlg.m_editbox() etc..
Hope this helped. Not sure if im being very clear.
Rob
|
|
|
|
|
thanks!!!!
Link you later!!!
|
|
|
|
|
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!!!
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.
|
|
|
|
|
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-.
|
|
|
|
|
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.
|
|
|
|
|
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!)
|
|
|
|
|
I don't know about recordsets but with normal files EOF only gets set after you go past the end of file. Meaning while(!eof) produces an extra read resulting in garbage
|
|
|
|
|
I am developing a project using ODBC RecordSet classes. I have a table with a date and time in it. The RecordSet class derived from CRecordSet contains COleDateTime object against the two i.e the date and the time.
Now I want to edit and clear these dates. How do I clear the dates from the Database.
This is urgent.. Anybody.. please
|
|
|
|
|
I have a small problem here, I need to somehow get the parameter from a template, eg <int> passed to a thread function...
I was thinking about something like:
template <typename T>
DWORD WINAPI WorkThread(LPVOID lpParameter);
but the compiler get's mad at me...
"error C2664: 'CreateThread' : cannot convert parameter 3 from 'unsigned long (void *)' to 'unsigned long (__stdcall *)(void *)'"
Is there any way to do this 
I really need it, because I have a template class which get another class as it's parameter, then starts some threads, where the thread parameter is a pointer to the class passed as the template parameter.
In the thread I need to declare a pointer to that class, and then cast my thread parameter to that...
Does that make any sence???
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
I don't think that you can take an address of a template function. Even reinterpret_cast or old-style cast will not help.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I was recently trying to do something similar and ended up using a virtual function with an abstract base. The worker thread is implemented as
UINT CMTDataAccess::RunQueryAllocateDataItems(LPVOID pParam)
{
CMTDataAccess* pThis = (CMTDataAccess*)pParam;
pThis->RunQueryAllocateDataItems();
pThis->m_bRunning = false;
return 0;
}
And each class that I implement, must inherit from the CMTDataAccess class. As well, each class must then implement a version of the RunQueryAllocateDataItmes() method.
Drop me an email, if you'd like any other gory details!
Chris
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
