C / C++ / MFC

Re: problem with device context (and some other bad things)

4-Mar-11 9:50

What is

csrss wrote:
case wm_paint:

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

[My articles]

csrss4-Mar-11 9:56

csrss

4-Mar-11 9:56

Thats a quick typing, WM_PAINT ofcourse. Basically after some time i came with an idea of passing separate functions to a class, like: OnPaint, OnDestroy, etc Big Grin | :-D

Seems like my window class will grow to 10000 lines xD

011011010110000101100011011010000110100101101110
0110010101110011

Re: problem with device context (and some other bad things)

Ozer Karaagac4-Mar-11 14:17

Ozer Karaagac

4-Mar-11 14:17

If you are using CPaintDC in your first OnPaint() function like below;

void CSomeClass::OnPaint()
{
    CPaintDC dc(this); // device context for painting

    ...
}

EndPaint() is called automatically in CPaintDC's destructor while going out of scope. EndPaint() marks the end of painting. If so, you can try using GetDC() to get device context in second.

I think, the best is that all painting stuff should be between ::BeginPaint() and ::EndPaint() calls within a WM_PAINT message.

Re: problem with device context (and some other bad things)

csrss4-Mar-11 15:40

csrss

4-Mar-11 15:40

No no, i am not using MFC, - this OnPaint() thing is my small custom function (like other small funcs), which i am passing to a class as callbacks, well, passing now, because like you've said, all stuff totally goes between BeginPaint and EndPaint in only 1st WM_PAINT. In fact, there should be no 2nd client paint handler, - that was my little experiment , which proved that a coder should stick to the rules Poke tongue | ;-P

011011010110000101100011011010000110100101101110
0110010101110011

Re: problem with device context (and some other bad things)

Richard MacCutchan4-Mar-11 22:17

Richard MacCutchan

4-Mar-11 22:17

csrss wrote:
Maybe after 1'st WM_PAINT handle to device context becomes invalid

Impossible to tell without seeing what is going on inside your OnPaint() function. Do you call BeginPaint() and EndPaint() correctly, and at the appropriate times? In your second paint handler you have not checked the return status of your call to graphics.DrawLine() which may give some useful information. Did you initialise GDI+ correctly at the start of your program?

I must get a clever new signature for 2011.

Re: problem with device context (and some other bad things)

csrss5-Mar-11 0:53

csrss

5-Mar-11 0:53

Yup, GDI+ was initialized, actually in my OnPaint() it was doing same (after painting bkg image) - just drawing a line (thats just a testing functionality). While it could do so in class it couldnt outside the class. But thats a good point, i did not check the status of drawline(). However, code now is completely reorganized to do all painting in class so there is no quick way to rollback to its initial state and do a checking so... Thanks anyway Smile | :)

011011010110000101100011011010000110100101101110
0110010101110011

Sending windows message from worker thread

GC1044-Mar-11 0:41

GC104

4-Mar-11 0:41

Hello,

I am currently getting to grips with MFC, VC++, VS2010 and threading. In particular I am trying to start a thread from a CMainFrame object, then post a windows message from the thread back to he CMainFrame object such that a messagebox can be displayed indicating the progress of the thread.

In this example the uses starts the thread from a drop-down menu item (CreateWorkerThread function is called) the thread code executes and sends a single windows message towards the end of the thread. The problem I have is that CMainFrame doesn't seem to respond to the message unless the function that starts the thread uses a ::WaitForSingleObject() call. Why do I need to effectively pause the execution of the function creating the thread?

Mayby naively, I assumed the following actions:

-User selects Menu item
-CreateWorkerThread() is called
-Thread executes in parallel with the remains of CreateWorkerThread()
-Worker thread generates a windows message (using ::PostMessage())
-By now CreateWorkerThread() would have completed.
-CMainFrame Message map processes Worker Thread' message 'WM_THREAD1MSG'
-Messagebox created and presented to user.

void CMainFrame::CreateWorkerThread(void)
// Created 25FEB2011
{


	HWND hWnd = GetSafeHwnd();
	if (hWnd == NULL)
	{
		TRACE0("Window pointer is invalid!");
	}
	

	hWnd = GetSafeHwnd();	//hWnd has been made a 'public' member

	pThread1 = AfxBeginThread(mcProc, static_cast<LPVOID>(&hWnd), THREAD_PRIORITY_NORMAL, 0, CREATE_SUSPENDED);	
	pThread1 ->ResumeThread(); 

	DWORD ThreadExitCodeValue = 0;
	LPDWORD pDWord = NULL;
	pDWord = &ThreadExitCodeValue;

	//Need a handle for the thread:
	HANDLE pThreadHandle = pThread1->m_hThread;


	::WaitForSingleObject(pThreadHandle,INFINITE); //stops this 'thread' until worker thread exits.


}


BEGIN_MESSAGE_MAP(CMainFrame, CFrameWndEx)
	ON_WM_CREATE()

	ON_MESSAGE(WM_THREAD1MSG, Respond2ThreadMsg)  //#define WM_THREAD1MSG WM_APP + 0x10 <- this line included in stdafx.h

	ON_COMMAND(ID_VIEW_CUSTOMIZE, &CMainFrame::OnViewCustomize)
	ON_REGISTERED_MESSAGE(AFX_WM_CREATETOOLBAR, &CMainFrame::OnToolbarCreateNew)
	ON_COMMAND_RANGE(ID_VIEW_APPLOOK_WIN_2000, ID_VIEW_APPLOOK_WINDOWS_7, &CMainFrame::OnApplicationLook)
	ON_UPDATE_COMMAND_UI_RANGE(ID_VIEW_APPLOOK_WIN_2000, ID_VIEW_APPLOOK_WINDOWS_7, &CMainFrame::OnUpdateApplicationLook)

	ON_COMMAND(ID_GCCODEDVMT_TESTCOMMAND, TestCommand)		//GC added 23FEB2011
	ON_COMMAND(ID_GCCODEDVMT_CREATEWORKERTHREAD, CreateWorkerThread)	//GC Added 25FEB2011
	ON_COMMAND(ID_GCCODEDVMT_TERMINATEWORKERTHREAD, TerminateWorkerThread)	//GC added 28FEB2011
	


	ON_WM_SETTINGCHANGE()
END_MESSAGE_MAP()


UINT mcProc(LPVOID param)
// Last edited 2MAR2011
{
	//This is the worker thread function...
	CString TempString;
	CString TempString2;
	int i = 0;
	int y = 0;

	HWND *pHandle = static_cast<HWND*>(param);	//for benefit of sending windows message from thread
	//static_cast works in the same way asordianry casting but considered to be restrictive(safer) and 'noticeable'...


	for (i=0; i<10; i++)
	{
		TempString.Format(_T("index counter: %d, \n"), i); 
		TempString2 = _T("Thread 1 Started... ");
		TempString2 += TempString;

		TRACE(TempString2);
		::Sleep(1000);
		
	}


	
	
	//send message from this thread...

	y = ::PostMessage(*pHandle, WM_THREAD1MSG, 0, 0);
	

	Sleep(1000);
	
	return 0;
}


LRESULT CMainFrame::Respond2ThreadMsg(WPARAM xParam, LPARAM lParam)
// Created 25FEB2011
{
	AfxMessageBox(_T("Thread message received"));
	TRACE(_T("Thread message received /n"));
	return 0;
}

Opinions greatfully received.

regards

Geoff

CPallini4-Mar-11 1:47

4-Mar-11 1:47

You're passing the address of a temporary variable to the thread: when CreateWorkerThread exits, hWnd goes out of scope.
BTW: There is really no need to pass a pointer to the HWND, just pass the HWND value.
Smile | :)

GC1044-Mar-11 2:29

GC104

4-Mar-11 2:29

Many thanks for feedback Smile | :)

Since posting this message I realised that I have been using the WINAPI PostMessage() function call rather than the MFC wrapper CWnd::PostMessage(). Which is the preferred method?

regards

Geoff

prasad_som4-Mar-11 2:33

prasad_som

4-Mar-11 2:33

CWnd::PostMessage internally calls win32 ::PostMessage.
I'll use CWnd::PostMessage, if I've CWnd object(no need to wrap window handle, specially to use this version), and ::PostMessage, if I've window handle.

CPallini4-Mar-11 3:05

4-Mar-11 3:05

prasad_som wrote:
I'll use CWnd::PostMessage, if I've CWnd object(no need to wrap window handle, specially to use this version), and ::PostMessage, if I've window handle.

So you'll use both at the same time when you have a CWnd object... Roll eyes | :rolleyes:

Pardon the silly humour...

CPallini4-Mar-11 2:36

4-Mar-11 2:36

GC104 wrote:
I have been using the WINAPI PostMessage() function call rather than the MFC wrapper CWnd::PostMessage()

You have to use the Windows API function. Worker threads aren't CWnd.
Smile | :)

Getting Time Difference [modified]

prasad_som4-Mar-11 2:30

prasad_som

4-Mar-11 2:30

You already got answer in earlier post. If you want to pass pointer to handle, use address of m_hHandle member variable, which is handle of CMainFrame. No need to call GetSafeHwnd.

AmbiguousName3-Mar-11 22:29

AmbiguousName

3-Mar-11 22:29

hello guys...I made this small console app inwhich I can get the difference (duration) between two times. I then store them into database as string. But the problem is that sometimes it shows some weird difference which I am unable to trace. Here is what I have

    SYSTEMTIME t,t2,t3;

    GetSystemTime(&t);  //gets current time on button click
    GetSystemTime(&t2);  //gets current time on second button click after some time

    //Get the difference between two times
    t3.wHour = t2.wHour - t.wHour;
    t3.wMinute = t2.wMinute - t.wMinute;
t3.wSecond = t2.wSecond - t.wSecond;

    //function to store time in SqlServer Database, inwhich I do some concatination and store time in DB
    //omitting those to keep things simple
GetMyDateTime2(t,t2,t3);

But here is one of the durations that I got from this calculation

2	3/3/2011 21:57:57	3/3/2011 21:58:3	0:1:65482(duration)	D:\Recordings\SecondRec.wav

what can be the problem?? thnx

modified on Friday, March 4, 2011 5:08 AM

CPallini3-Mar-11 22:46

3-Mar-11 22:46

The problem is your calculations are wrong (do you remember 'carry'?) and the SYSTEMTIME fields are 16 bit WORDS.

Try

WORD wCarry;
if (t2.wSecond >= t1.wSecond )
{
  wCarry = 0;
  t3.wSecond = t2.wSecond - t1.wSecond;
}
else
{
  wCarry = 1;
  t3.wSecond = 60 + t2.wSecond - t1.wSecond;
}
if (t2.wMinute >= t1.wMinute + wCarry)
{
  wCarry = 0;
  t3.wMinute = t2.wMinute - t1.wMinute;
}
else
{
  wCarry = 1;
  t3.wMinute = 60 + t2.wMinute - t1.wMinute;
}
if (t2.wHour >= t1.wHour + wCarry)
{
  t3.wHour = t2.wHour - t1.wHour;
}
else
{
  // handle error.
}

Please note the above code would have troubles on button clicks crossing the date boundary...
Smile | :)

Cool_Dev3-Mar-11 23:40

Cool_Dev

3-Mar-11 23:40

If you can use CTime and CTimeSpan MFC classes, no need to bother about calculations.

David Crow4-Mar-11 2:07

David Crow

4-Mar-11 2:07

overloaded Name wrote:
hello guys...I made this small console app inwhich I can get the difference
(duration) between two times.

You might also check out difftime().

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather