This is Familiar, in particular with the multi threaded question you asked earlier.
MFC cannot realy handle multiple threads. No one seems to know why, I have asked the question before.
At any rate, the only way MFC objects can communicate between threads is with the Old Fashioned WDK Kernel Function ::SendMessage(hWnd, Param1,Param2);
In MFC you create your Message as WM_USER+(X), Create a Message Handler, and, manually add it to the message map.
Any attempt to call an MFC Object from a different thread than in which it was created always ultimately lead to failure.
The Symptoms are: Works, Add a Virtual Function: It stops Working
No I Did Not intend this for you.
This topic became a Sort of a Labyrinth.
The Original Person is evidently out of his/her depth! (S)he is still hammering the subject I see.
I try to help, as we all do, but can get frustrated when good advise is ignored, as, I am sure you do to.
This message returns the number of characters copied, not including the terminating null character.
The call is terminated by the null character and if you have CR,LF they will count as characters
The return is a CHARACTER COUNT, if your edit box is unicode mode it still reflects the character NOT THE NUMBER OF BYTES.
Hence when providing a buffer you are best to use an array of TCHAR rather than a standard byte array to allow for size difference.
Also note when size a TCHAR array use _countof DO NOT use sizeof for the same reason. Standard unicode aware coding practice.
Several of the comments have confusion between CHARACTER and BYTE within the meaning of the windows API. No such confusion exists.
I had a confusion that why we can use :: sign in calling static member function of class.
while in the case of calling simple member function using :: sign shows error .. in c++.
Please explain .
Member functions need qualifiers in order for the compiler to know which function your code refers to. In the case of a static function the qualifer must be the class name, since static functions belong to the class: hence Class::Function(). For member functions the qualifer must be the instance reference, as non-static functions are attached to individual objects: hence object.Function() or objectpointer->Function().
Which line does it occur on when you step through it, and what is the assertion being hit?
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
I have a dialog based MFC application that I am rewriting in VS2010 from its original VC++ 6.0 source. Everything works fine in VC++ 6.0
The main dialog contains many child dialogs (not pop-ups) in which one child dialog is used to draw a plot based on the values sent from main dialog. The main dialog calls a function (Draw_Points) within the child dialog and the child dialog draws it and it does as long as the plot hits the edge and then it calls OnPaint message to refresh the dialog so that it can start afresh from left.
void CPlotDlg::Draw_Points(double value1, double value2)
if(m_LastPoint1.x < (m_time_rect.right-2))
// Store the data for later retrieval
m_CurrentPoint1.x = m_LastPoint1.x + 1;
m_CurrentPoint2.x = m_LastPoint2.x + 1;
// Do some calculations
m_Data1[m_DataCounter] = value1;
m_Data2[m_DataCounter++] = value2;
CWnd *Ctrl = GetDlgItem(IDE_PLOTS);
CDC *cdc = Ctrl->GetDC();
HGDIOBJ original = NULL;
original = cdc->SelectObject(GetStockObject(DC_PEN));
m_LastPoint1 = m_CurrentPoint1;
m_LastPoint2 = m_CurrentPoint2;
CPaintDC dc(this); // device context for painting
// TODO: Add your message handler code here
CWnd *Ctrl = GetDlgItem(IDE_PLOTS);
// Do not call CDialogEx::OnPaint() for painting messages
It crashes when the Draw_points function calls OnPaint function in its else section, and when OnPaint() function executes CPaintDC dc(this);
Well, you need to rethink your design. You should collect all the information related to the drawing as a result of user interaction, file processing etc. You then call InvalidateRect to tell Windows that your data has changed, and your window/client needs to be repainted. Then in the control you call your paint function in response to receiving a WM_PAINT message. It is at that point that you draw your lines, shapes, text etc.
Well, the first step is to create a query ( the easiest way would be to create it and test in the MS Access).
The second step - create the recordset that supports update and insert operations. See MSDN article [^] for details.