|
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
|
|
|
|
|
Using an ImageList to load 16 x 16 bitmaps into a toolbar I've been trying to use the bitmaps from that same ImageList for corresponding menu items but I can't get rid of a whiteness around the images. The main code block code below gives the best I can get. Though I can use a IMAGELISTDRAWPARAMS setting the ilDrawParams.rgbBk = GetSysColor(COLOR_MENU) and using ImageList_DrawIndirect which does get rid of the whiteness though the background is then wrong again if the menu item is highlighted - this also seems to be missing the point when is seems the bitmaps can supposedly be drawn transparently anyway. Any suggestions appreciated.
HMENU hMenuMain = GetMenu(hWnd);
HMENU hTestMenu = GetSubMenu(hMenuMain, PORT_MENU_ID);
HIMAGELIST hImageList = ::ImageList_LoadImage(hInst, MAKEINTRESOURCE(IDB_BITMAP1), 16, 0,
RGB(255,0,255), IMAGE_BITMAP, LR_SHARED | LR_LOADTRANSPARENT);
HDC hDCWindow = ::GetDC(hWnd);
HDC hDCDest = CreateCompatibleDC(hDCWindow);
HBITMAP hComapatBitmap = CreateCompatibleBitmap(hDCWindow, 16, 16);
HGDIOBJ hOldDestBmp = SelectObject(hDCDest, hComapatBitmap);
BOOL bDrawn = ImageList_DrawEx(hImageList, 1, hDCDest, 0, 0, 16, 16, RGB(255, 0, 255),
CLR_NONE , ILD_TRANSPARENT);
HBITMAP hRetrievedBitmap = (HBITMAP)::SelectObject(hDCDest, hOldDestBmp);
::DeleteDC(hDCDest);
::ReleaseDC(hWnd, hDCWindow);
MENUITEMINFO MenuItemInfo;
::SecureZeroMemory(&MenuItemInfo, sizeof(MENUITEMINFO));
MenuItemInfo.cbSize = sizeof(MENUITEMINFO);
MenuItemInfo.fMask = MIIM_BITMAP;
MenuItemInfo.hbmpItem = hRetrievedBitmap;
::SetMenuItemInfo(hTestMenu, ID_PORT_EDIT, FALSE, &MenuItemInfo);
::DrawMenuBar(hWnd);
modified 18-Aug-13 4:57am.
|
|
|
|
|
The bitmap needs to contain some indication of transparent background to avoid this problem. I cannot remember exactly how it is identified, but I have a feeling it is some "key" pixel. MSDN or Google may have more information.
Use the best guess
|
|
|
|
|
Richard,
Thanks for the hint, but (as explained below) the problem seems to be with the obtained menu background (white)not being the same colour as the menu (light blue/grey). Thanks anyway.
|
|
|
|
|
I've never found a good solution to this problem. Maybe the HBMMENU_CALLBACK of Vista solves this (I havent tried it) but even in that case it would push up the minimum OS version requirement of your program without any particular reason. I've solved this problem a few times by using ownerdraw menu items but in that case you have to take care a lot of things even if you ignore the look and feel of the OS: like font sizes, underlining the hotkeys in menu item text... Customizing menu items and rawing their icons nicely is a pain in the ass.
I would go with ilDrawParams.rgbBk = GetSysColor(COLOR_MENU) . It is not perfect but I wouldn't invest time in owner draw items again for a small cosmetic bug.
|
|
|
|
|
The problem seems to be that the Menu background as obtained by getting MENUINFO.hbrBack isn't the same colour as the menus. I filled my bitmaps that go on the menus with that colour without any icons to see if it all matched. It doesn't, I can see white squares where the icons go against the light blue/grey of the menu (on Windows 8) That white, as seen behind the drawn bitmaps, is presumably what I was trying to remove.
I think I'll take your advice leave it as it is. Thanks.
|
|
|
|
|
I'm still stuck on win7 but I guess what you mean. Since WinXP there are several window managers (like aero, xp-style, old-school,...) and some of these are using extra colors besides the old-school window manager for which the old API was engineered. Sometimes the api lies to your program depending on windows version compatibility settings and the manifest you put into your program. I wouldn't be surprised if there were some fancy APIs to query the REAL colors in another way or with different constants from a newer SDK but I avoided making headaches for myself by polishing GUIs with WinAPI in the last few years... I guess you have better things to do and customizing the menus is one particular thing that really sucks. In my opinion most of the winapi controls, especially the older ones (including menus) are not good candidates for customization. Things could be worse only if you wanted to customize the menu borders: I've seen code that handled undocumented mouse messages and installed cbt hooks - made me sick and I always started vomiting while reading it... Once I was dreaming about creating a gui skinner lib but I got bored of it halfway when I got to know the sad truth and the mountain of hacks involved...
|
|
|
|
|
Read the MSDN stuff again and found I should have been using GetSysColorBrush(COLOR_MENU); rather then the GetSysColor(COLOR_MENU); I was using which apparently 'returns a cached brush, instead of allocating a new one'. This now does the correct menu background colour.
Could explain why GetSysColor(COLOR_MENU); worked yesterday and not today.
|
|
|
|
|
Thanks for the info! We learn something new every day...
|
|
|
|