|
Create a "number box" that has 10 compartments, one for each digit 0-9.
For each number in your list
Check the first digit.
If it is a 0, increment the "0" compartment in the above-mentioned box.
If it is a 1, increment the "1" compartment in the above-mentioned box.
If it is a 2, increment the "2" compartment in the above-mentioned box.
...
Next
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
I'm updating an existing MFC project from VC6 into VC2010, and adding dockable window functionality. In doing so, I've recreated some CDialog-based windows as CPaneDialogs. In general, this works well, but there's a visual anomaly with CTabCtrls: the unpopulated portion of the tab bar is a different colour from the CPaneDialog background.
This can be seen be tweaking the SetPaneSize example in the 2008 Feature Pack to add a CTabCtrl to the IDD_DLG_BAR dialog. Derive from CPaneDialog and then add something like:
BEGIN_MESSAGE_MAP(CMyPaneDialog, CPaneDialog)
ON_MESSAGE(WM_INITDIALOG, HandleInitDialog)
END_MESSAGE_MAP()
LRESULT CMyPaneDialog::HandleInitDialog(WPARAM wParam, LPARAM lParam)
{
VERIFY(m_tabCtrl.SubclassDlgItem(IDC_TAB1, this));
TC_ITEM tci;
tci.mask = TCIF_TEXT;
tci.pszText = _T("A");
m_tabCtrl.InsertItem(0, &tci);
tci.pszText = _T("B");
m_tabCtrl.InsertItem(1, &tci);
m_tabCtrl.SetCurSel(0);
return CPaneDialog::HandleInitDialog(wParam, lParam);
}
Searching for solutions to this issue comes up with a lot of suggestions about the CTabCtrl background as a whole, but nothing seems to work. I've tried overriding OnCtlColor, OnEraseBkgnd, etc, but the header steadfastly refuses to change colour. I don't see owner drawing as an option, since theme support would be difficult to replicate.
Even more annoyingly, if I place the same CTabCtrl in SetPaneSize's CFormView, it renders perfectly!
Does anyone have any suggestions I could try? My one thought is that perhaps I'm looking at the problem from the wrong perspective: is the CTabCtrl correct, but the CPaneDialog ignoring theme instructions?
|
|
|
|
|
|
I created at run time window using below styles and left =0
WS_CHILD|WS_VISIBLE|WS_BORDER|WS_THICKFRAME
when I am trying to get windows position
pSrcWnd->GetWindowRect(&rtOriginal);
pSrcWnd->ScreenToClient(&rtOriginal);
I am getting left = -7 but It should be 0.
I investigate the problem I found it because of
WS_THICKFRAME proerty.
How can I get exact position?
|
|
|
|
|
Your conversion makes no sense. You are taking the screen coordinates of your window and converting it to client coordinates relative to itself.
Use the best guess
|
|
|
|
|
what I need to do to get position of window?
|
|
|
|
|
You had the position with pSrcWnd->GetWindowRect(&rtOriginal);, as described in the documentation[^]
Use the best guess
|
|
|
|
|
Relative to what? Child window positions in WinAPI are expressed in the client coordinates of its parent while GetWindowPos always returns screen coordinates. For this reason after getting the screen coordinates of the child control you probably want to transform them into the client coordinate space of the parent control.
pChild->GetWindowRect(&rt);
pParent->ScreenToClient(&rt);
In contrast to this MoveWindow() and SetWindowPos() expect coordinates that are in the client coordinates of the parent window (that is the screen for top level windows). Always read the docs about the expression of coordinates. For example in case of mouse messages you always receive mouse pos in client coordinates of the control that receives the message but there is one exception: WM_MOUSEWHEEL returns screen coordinates. So: Read docs!!!
modified 19-Aug-13 12:20pm.
|
|
|
|
|
pasztorpisti wrote: So: Read docs!!
What, when you can post a question at CodeProject? 
Use the best guess
|
|
|
|
|
 I should have asked it from someone else (maybe on codeproject) before answering this question!
|
|
|
|
|
Do you know what is a client area/coordinate and have you read the documentation of GetWindowRect and ScreenToClient? Calling these functions in this order is not very useful...
|
|
|
|
|
I wrote a mfc interface to draw graph and show calculated result. The calculated result is right.It can be showed on the interface everytime. But the graph can not show normally.Under the same condition, sometimes the graph is showed and sometimes it not. I have no idear why it happens. The code about drawing is as follows:
CDC* pDC;
CRect rectPic;
void f_curve();
void CAISIDlg::OnBnClickedButton1()
{
BeginWaitCursor();
UpdateData(TRUE);
width=m_width;
... UpdateData(FALSE);
if( Read_data(FolderPath,dhPath)!=0 )
{
m_picDraw.GetClientRect(&rectPic);
pDC = m_picDraw.GetDC();
f_curve();
m_transmisivity = ((long int)(transmisivity*1e5))/1e5; m_BSE = BSE; UpdateData(FALSE);
}
EndWaitCursor();
}
the f_curve() function is called to draw graph,key code as follow:
void f_curve()
{
...
pDC->SelectObject(PenRed);
pDC->MoveTo( (int)( (db_jinyan[0][0]-minX)*itlX ),
(int)( (db_jinyan[1][0]-minY)*itlY )
);
for(int i=0;i<Len;i++)
pDC->LineTo(
(int)( (db_jinyan[0][i]-minX)*itlX ),
(int)( (db_jinyan[1][i]-minY)*itlY )
);
...
}
why the grapy can not be draw out everytime while the calculated result could?
|
|
|
|
|
You are doing the drawing in the wrong place. Drawing should only be done in response to a WM_PAINT message. In MFC that is in the OnPaint()[^] member function.
Use the best guess
|
|
|
|
|
I wonder why was your answer down-voted.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
Thanks for the counter vote. As to why: who knows, there are strange people around in all walks of life.
Use the best guess
|
|
|
|
|
IMHO the OP wanted to know why his code does not work, and you did not help in that aspect, just suggested a different approach.
My vote of 2
Now you should have better idea why. Or not.
One of the strange people here.
|
|
|
|
|
Vaclav_Sal wrote: the OP wanted to know why his code does not work, and you did not help in that aspect, just suggested a different approach.
No, I explained exactly why his code does not work, because he is painting to the screen in the wrong place. Spending more time reading the available documentation would have also helped.
Use the best guess
|
|
|
|
|
Hi,
I am getting an exception on a WaitForSingleObject
Below is the code the Security events parameter of the CreateEvent is NULL I am Wondering if that might be the issue
Event_Handle = ::CreateEvent(NULL, FALSE, FALSE, NULL);
int i;
UINT start_port;
for (i = 0, start_port = 11007; i < 4; start_port++, i++)
{
threadptr[i] = NULL;
threadptr[i] = new SockCLeintThread(start_port);
threadptr[i]->m_pActiveWnd = m_pMainWnd;
threadptr[i]->m_pMainWnd = m_pMainWnd;
if (threadptr[i] == NULL)
m_pMainWnd->MessageBox((LPCTSTR)"SockClientThreadFail",NULL,MB_ICONERROR);
threadptr[i]->CreateThread(CREATE_SUSPENDED,0,NULL);
threadptr[i]->flags.is_connected = 0;
threadptr[i]->ipaddr = (LPCTSTR)"192.168.1.4";
threadptr[i]->flags.busy = 0;
SetThreadName(threadptr[i]->m_nThreadID,thread[i]);
threadptr[i]->ResumeThread();
DWORD return_value = ::WaitForSingleObject(Event_Handle,INFINITE);
|
|
|
|
|
ForNow wrote: (LPCTSTR)"SockClientThreadFail"
ForNow wrote: (LPCTSTR)"192.168.1.4"
This is probably not the answer you're looking for, but it's more important. What the hell are you catting to LPCTSTR for? This is at best pointless and at worst a runtime error that would be a compile time one without the cast. You can cast all you like but it will not make it walk like a duck. If your compiling for ANSI then the cast does nothing except look stupid. If your compiling for UNICODE you're effectively telling to compiler to shut up and not issue an error (and you've made one) and just pretend that the ANSI string is a UNICODE one. Best case is a garbled string, worst a buffer overrun. Use the _T macro from <tchar.h>.
Steve
|
|
|
|
|
Well your code logic is all over the place. If 'new' throws an exception, which it does on later C++ then you dont need the check for NULL, if not, that check needs to come directly after the 'new' and the loop needs to continue or exit.
Also what s threadptr? Is it a static, heap or stack array, is it big wnough?
Also dont you want to set the thread name before crating it?
How is the handle passed t the thread,, I assume it has to be, and waits for the thread to run?
But look at the exception, what does it say, what line of code is it saying is bad?
|
|
|
|
|
I changed all the casts to _T the exceptions says unhandled exception at 7FE6D3C9B5 MFC100.DLL access violation reading location 25e5b80 This is right at the call for WiatForSingleObject
|
|
|
|
|
The exception occurs in the MFC DLL. So you have an invalid member in one of your MFC classes. WaitForSingleObject() is a Windows API function that has nothing to do with MFC.
Before that call you are starting a thread. Assuming that the thread is derived from the MFC CWinThread class, you should check your thread class.
|
|
|
|
|
Event_handle is a member of CHecmd CLASS so in otherword I mixing MFC with win32
I think I got it
|
|
|
|
|
Whenever you get a crash provide:
- The exception info
- The source around the problem with the line highlighted
- The values of any variables of interest (used in the crashing line)
- A stack trace
This is the bare minimum. I also like the some dissassembly around:
- The crash site
- The last transition from your code.
I suggest you post as much of this as you can manage.
Steve
|
|
|
|
|
m_pMainWnd->MessageBox((LPCTSTR)"SockClientThreadFail",NULL,MB_ICONERROR);
threadptr[i]->ipaddr = (LPCTSTR)"192.168.1.4";
Despite numerous explanations that using casts in this way is totally wrong you still use them. You seem determined to ensure that your code will not work.
Use the best guess
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
