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>.
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?
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.
// Get a menu handle for the one to have an image added to it
HMENU hMenuMain = GetMenu(hWnd);
HMENU hTestMenu = GetSubMenu(hMenuMain, PORT_MENU_ID);
// Load the image i.e. a bitmap 'strip' that is actually a number of bitmaps
HIMAGELIST hImageList = ::ImageList_LoadImage(hInst, MAKEINTRESOURCE(IDB_BITMAP1), 16, 0,
RGB(255,0,255), IMAGE_BITMAP, LR_SHARED | LR_LOADTRANSPARENT);
// Get DC for Window client area
HDC hDCWindow = ::GetDC(hWnd);
// and create a compatibles DC im memory
HDC hDCDest = CreateCompatibleDC(hDCWindow);
// Create a bitmap compatible with the device associated with the DC
HBITMAP hComapatBitmap = CreateCompatibleBitmap(hDCWindow, 16, 16);
// Select the destination bitmap into the DC
HGDIOBJ hOldDestBmp = SelectObject(hDCDest, hComapatBitmap);
// Bitmap is already selected into a screen-compatible device context by the image list
BOOL bDrawn = ImageList_DrawEx(hImageList, 1, hDCDest, 0, 0, 16, 16, RGB(255, 0, 255),
CLR_NONE , ILD_TRANSPARENT);
// Select back old object back in retrieving returned drawn bitmap
HBITMAP hRetrievedBitmap = (HBITMAP)::SelectObject(hDCDest, hOldDestBmp);
// as used CreateCompatibleDC(...) must delete it
// as used GetDc must release it
// Create a structure that describes the change to make to the menu item
MenuItemInfo.cbSize = sizeof(MENUITEMINFO);
MenuItemInfo.fMask = MIIM_BITMAP;
MenuItemInfo.hbmpItem = hRetrievedBitmap;
// Make the change
::SetMenuItemInfo(hTestMenu, ID_PORT_EDIT, FALSE, &MenuItemInfo);
// Call as required by Windows.
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.
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.
Hi there everyone.
I have some pretty much basic UDP sockets scenario: my app requests data from server and receives requested data. There is a lot of data so there is a cancellation method as well. When I cancel data receiving and request data again, app not getting FD_READ events anymore. Strange thing is, it is not always the same - sometimes there are a couple of FD_READs, sometimes half of the data could be transmitted before it stops, sometimes - none.
Code itself is basically the same as anywhere on the net and goes like this:
3. Handle data.
That's it. It all works great if receiving is never cancelled. Otherwise it just stops at some point while waiting for multiple events (::WSAWaitForMultipleEvents) Again, what I mean is:
I hit cancel button and
is called, that causes ::WSAWaitForMultipleEvents to return with my cancel event (WSAWaitForMultipleEvents is called in a loop for every incoming data chunk - each one is about 512kb). And then app just stops receiving - it leaves socket as it is, socket is not closed and still alive. Then I hit a button again for app to begin download data again and that is when app stops receiving packets because WSAWaitForMultipleEvents is waiting for fd_read which is never signaled. Then I hit cancel again, - this is handled properly and then again download data - this time data is downloading ok.
This behavior occurs all the time.
I am struggling with this for a couple of days now and got completely no idea what is going on, have searched all the net with no result. I have tried checking, when cancellation is issued, if there is still any data pending on the socket and reading this data - all in vain - it is still remains stuck and not getting fd_read event
Maybe this issue is related to the fact that app is using one single socket all the time? Maybe it is because server fails and stops sending data? (I have to investigate server as well)
Maybe there is something that you may know and be able to help me with this?
Could you please post the code of the whole network loop? This info isn't enough. Send also the code/functions (like cancel) that are used to send signal to your network thread and indicate which thread calls what and what does the network thread does in case of a cancel.
BTW, why are you using UPD? You should use TCP to transfer data. In case of UDP you have to implement congestion control and reliability (defense against packet loss) yourself. Is it some kind of real-time data transfer (like audio/video streaming) where data loss is not a problem?
I think I am going to deal with it myself - code is too big and complicated to post it, or to even take one method from it - it is 1000+ lines custom network framework
I am using UDP for consistency with discovery mechanisms, which I am implementing in app - it should do a lot of networking, pretty fast, without any user intervention - tcp will not allow me to, - it will force a solution where app will have to be configured by user and I cannot allow it to.
I could do discovery only with UDP but I have written huge framework which actually implements TCP partially.
Basically, I am not sure when FD_READ gets signaled? When there is data available or when WSARecvFrom can perform read? This would explain why it is not raised...
I am going to deal with it on my own - it is too complicated
The main loop of your network thread that handles the send and receive should be relatively small and should be kept together in a small place separated from the other parts of the code. If this critical piece of code is not coupled well separated from your higher level logic, then you should refactor it. This piece of code should handle just raw outgoing and incoming packets on the network thread and all the logic should be implemented separately on top of this layer. A low-level data recv/send loop implementation should be around 100-200 lines of code and all it knows is sending bytes/packets from your send queue, receiving them into a recv queue (and notifying your high level handlers) and exiting when your application exits.
For example here your application logic and the a part of your raw network data receiver logic is already mixed that is bad and dynamic_cast is always the indicator of some hacks and bad OO design that needs refactoring. We don't even know when does that dynamic_cast result in a non-null pointer... It seems that you have a big bunch of refactorable code that you will be fixing till the end of your life without a rewrite (and it is worth rewriting stuff... )
BTW, there is another thing that came to my mind regarding WSAWaitForMultipleEvents: FD_READ is level triggered but FD_WRITE is edge triggered and many guys get confused of this. This means that waiting for an FD_READ is safe even if you wait for it twice without reading anything from the socket. The event isn't cleared until data is available for read in the recv buffer of the socket. But FD_WRITE is edge triggered: If you receive an FD_WRITE event then you must assume that FD_WRITE is set until your write fails with EWOULDBLOCK. Receiving an FD_WRITE event clears the FD_WRITE event immediately and it will be set again only when the send buffer of the socket transitions from full to non-full next time. If you try to wait for an FD_WRITE without writing all the available buffer space by receiving EWOULDBLOCK then you will wait for FD_WRITE forever! Depending on how you handle WSAEventSelect and WSAWaitForMultipleEvents your logic can get stuck in many different ways if you don't handle this well.
EDIT: Besides the wakeup event there should be a lock/critical_section as well and these should be used together well along with the shared data (like cancel flag). My loop often got stuck in initial/new network code by screwing up the usage of these or the communication between threads somehow.
I can use DirectShow to connect to a device ( source) , for example audio, I can process the audio “steam” , or not, and “render it to audio device (sink) or GUI.
Or I can use DirectSound to do the same.
So what are the relations between these DirectX “processes” , is one a subset of the other or what?
Thanks for educating me, even if this is not pure C / MFC question.