|
Have you called EnableToolTips(TRUE)? Do you have a handler for TTN_NEEDTEXTA and TTN_NEEDTEXTW?
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Thanks for you answer.
I decided to use a control from codeguru.com (http://www.codeguru.com/cpp/controls/combobox/tooltips/article.php/c4949/).
It works fine so far, but I have another Problem:
I want to have a multiline ToolTip Text ("line1 \n line2"). I read that I have to call SetMaxTipWidth() from the CToolTipCtrl class.
The Code of the codeguru control manipulates the ToolTip text in the function CTooltipListCtrl::OnToolTipText(...).
TOOLTIPTEXTA* pTTTA = (TOOLTIPTEXTA*)pNMHDR;
TOOLTIPTEXTW* pTTTW = (TOOLTIPTEXTW*)pNMHDR;
if (pNMHDR->code == TTN_NEEDTEXTA)
lstrcpyn(pTTTA->szText, sTipText, 80);
else
_mbstowcsz(pTTTW->szText, sTipText, 80);
Can someone tell me how to get the CToolTipCtrl pointer in the CTooltipListCtrl class(derived FROM CListCtrl), to call it's SetMaxTipWidth() function to get a Multiline ToolTipText?
Thanks for your help...
|
|
|
|
|
I am trying to create a progress dialog box in the below event. But Progress dialog box is not displayed, it is working fine when I comment th loop, I the lenthy operation is very much similar to the loop.
I want the progressbar to be initiated with thread,
Please advice.
void CTestDlg::OnStartPrg()
{
ThreadPrgIndiaction* pThread;
pThread = new ThreadPrgIndiaction();
pThread->CreateThread();
pThread->PostThreadMessage(WM_MYTHREADMESSAGE,NULL,NULL);
// My progress is similar to below loop
int j=1;
while(j<99)
{
j++;
Sleep(200);
}
}
THREAD
BEGIN_MESSAGE_MAP(ThreadPrgIndiaction, CWinThread)
//{{AFX_MSG_MAP(ThreadPrgIndiaction)
// NOTE - the ClassWizard will add and remove mapping macros here.
ON_THREAD_MESSAGE ( WM_MYTHREADMESSAGE, MyMessageHandler )
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
void ThreadPrgIndiaction::MyMessageHandler(WPARAM, LPARAM)
{
CPrgDlg *dlg;
dlg = new CPrgDlg;
dlg->Create(IDD_DIALOG2);
dlg->ShowWindow(1);
PrgDialog
BOOL CPrgDlg::OnInitDialog()
{
CDialog::OnInitDialog();
// TODO: Add extra initialization here
m_prg.SetStep(1);
m_prg.SetRange(0,60);
SetTimer(1, 60, NULL);
return TRUE; // return TRUE unless you set the focus to a control
// EXCEPTION: OCX Property Pages should return FALSE
}
void CPrgDlg::OnTimer(UINT nIDEvent)
{
// TODO: Add your message handler code here and/or call default
m_prg.SetPos(m_prg.GetPos()+1);
UpdateData(FALSE);
CDialog::OnTimer(nIDEvent);
}
}
|
|
|
|
|
ptr_Electron wrote: But Progress dialog box is not displayed...
Have you set a breakpoint in CPrgDlg::OnInitDialog() to verify that control is reaching that method?
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Yes, it is working fine in the absents of while loop, but it is not reach there when place whie loop
|
|
|
|
|
You should be using
CWinThread* AfxBeginThread(
CRuntimeClass* pThreadClass,
int nPriority = THREAD_PRIORITY_NORMAL,
UINT nStackSize = 0,
DWORD dwCreateFlags = 0,
LPSECURITY_ATTRIBUTES lpSecurityAttrs = NULL
);
instead of
pThread->CreateThread();
to create a UI thread. Otherwise, your thread won't get the
WM_MYTHREADMESSAGE you post to it.
*Edit*<br />
Actually you can leave your thread creation code the way it is as<br />
long as your ThreadPrgIndiaction class has an InitInstance() override<br />
that returns TRUE. That will cause the message queue to be created for <br />
the thread.<br />
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
modified on Thursday, July 17, 2008 3:19 PM
|
|
|
|
|
But the above code is working fine, with out the while loop. The problem, progress bar indication is shown on the dialog, when while loop is placed.
|
|
|
|
|
The problem is that the ui thread is creating a window that is a child of a main thread window . Windows communicate with their parent window, so the ui thread has to wait until the parent window's thread processes a message. I think thats y ur CPrgDlg is not displayed. It may display after completing the loop.
I think u can create a worker thread and can call CPrgDlg from the thread function.
aks
|
|
|
|
|
|
Hi All,
Is there a way to find out the time taken by a function to complete (in terms of nanoseconds) in my c++ code without using "Function Profiling" feature of the linker. I tried GetTickCount(), but it gives the time in milliseconds. It always returns 0 because my function completes its task less than in one millisecond.
Thanks in advance
|
|
|
|
|
You may use the QueryPerformanceFrequency [<a href="http://msdn.microsoft.com/en-us/library/ms644905.aspx" target="_blank" title="New Window">^</a>], QueryPerformanceCounter [^] pair.
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]
|
|
|
|
|
This can only be applied if there's thread switching: you are measuring the time before the function and then after the function and assume that the difference is the time spent in the function. While this might seem correct, it's not always the case: the scheduler can decide in the middle of your function to switch to another thread, which will 'pause' your function for a certain amount of time. Thus you will take that time into account also, which is wrong.
A better approach would be to measure the time really spent for this thread. But unfortunately, I don't know how to do this (but I guess it is possible).
|
|
|
|
|
I knew that. I provided only a way to measure time on a smaller scale.
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]
|
|
|
|
|
CPallini wrote: I knew that.
Yeah I guess so. I was mainly clarifying for the OP
|
|
|
|
|
Well, indeed your was a good point against profiling-do-it-yourself.
The OP should also be aware that between milli and nano there are micro seconds (i.e. pretending nano seconds accuracy it is at present, a bit Utopian!)
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]
|
|
|
|
|
I agree with you. There can be several downsides to any and every method that can be suggested here, but there's no single fool proof way of doing it, or at least that I don't know of one. What if the method which is supposed to measure the time elapsed takes more time to execute than the actual set of instructions whose execution time is to be measured? 
It becomes more bizarre as we go down to get more precision.
|
|
|
|
|
Rajesh R Subramanian wrote: What if the method which is supposed to measure the time elapsed takes more time to execute than the actual set of instructions whose execution time is to be measured?
A philosophical approach to quantum mechanics?
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]
|
|
|
|
|
I had to re-read my post to realise why did you make a comment like that. 
Sometimes, the philosopher in me wakes up. 
|
|
|
|
|
|
This blog post[^] may give you some insights.
I doubt if there's a ready made API that can give results at nano second precision. RDTSC[^] can be a good thing to bet upon, but don't take my word for it. 
|
|
|
|
|
Rajesh R Subramanian wrote: RDTSC[^] can be a good thing to bet upon, but don't take my word for it.
On old-fashioned-single-core-machines. 
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]
|
|
|
|
|
But does that apply only to RDTSC?
|
|
|
|
|
Yes, as far as this article [^] is correct, the QueryPerformanceFrequency,QueryPerformanceCounter pair is more robust (as Windows API is expected to be).
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]
|
|
|
|
|
I accept, I had not taken into account the fact that more than one processor core can exist, but:
What QueryPerformanceCounter actually does is up to the HAL (with some help from ACPI). The performance folks tell me that, in the worst case, you might get it from the rollover interrupt on the programmable interrupt timer. This in turn may require a PCI transaction, which is not exactly the fastest thing in the world. It's better than GetTickCount, but it's not going to win any speed contests. In the best case, the HAL may conclude that the RDTSC counter runs at a constant frequency, so it uses that instead.[^]
|
|
|
|
|
Rajesh R Subramanian wrote: In the best case, the HAL may conclude that the RDTSC counter runs at a constant frequency, so it uses that instead.
That's API robustness. You should make the (in)famous QueryPerformanceFrequency/QueryPerformanceCounter pair make the best (while still reliable) choiche for you.
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]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
