C / C++ / MFC

17-Aug-13 10:43

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.

C++

// 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
::DeleteDC(hDCDest);

// as used GetDc must release it
::ReleaseDC(hWnd, hDCWindow);

// Create a structure that describes the change to make to the menu item
MENUITEMINFO MenuItemInfo;
::SecureZeroMemory(&MenuItemInfo, sizeof(MENUITEMINFO));
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.
::DrawMenuBar(hWnd);

modified 18-Aug-13 4:57am.

Richard MacCutchan18-Aug-13 1:25

Richard MacCutchan

18-Aug-13 1:25

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

Jonathan Davies18-Aug-13 5:20

18-Aug-13 5:20

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.

pasztorpisti18-Aug-13 4:36

18-Aug-13 4:36

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.

Jonathan Davies18-Aug-13 5:05

18-Aug-13 5:05

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.

pasztorpisti18-Aug-13 5:27

18-Aug-13 5:27

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... Smile | :)

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...

Jonathan Davies18-Aug-13 5:40

18-Aug-13 5:40

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.

pasztorpisti18-Aug-13 5:43

UDP sockets - not getting FD_READ after some time of activity on a socket

18-Aug-13 5:43

Thanks for the info! We learn something new every day... Smile | :)

csrss17-Aug-13 6:28

csrss

17-Aug-13 6:28

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:

1. Before any receiving, check if FD_READ is set

C++

DWORD dwResult = 
::WSAWaitForMultipleEvents(vecHandles.size(), &vecHandles[0], FALSE, dwTimeout, FALSE);

- vecHandles is a vector of event handles, which includes my WSAEVENT for triggering cancellation.
which is done like this:

C++

::WSASetEvent(hEvent);

So now ::WSAWaitForMultipleEvents will return with my event.

2. Check which event we got: if it is read event, then call recv.

C++

if( socket_event_read * pReadEvent = dynamic_cast<socket_event_read *>(pSocketEvent) )
{
    WSANETWORKEVENTS nt = { 0x00 };
    if( SOCKET_ERROR != ::WSAEnumNetworkEvents(pReadEvent->get_socket(), pSocketEvent, &nt) )
    {
        if( nt.lNetworkEvents & FD_READ && nt.iErrorCode[FD_READ_BIT] == false )
        {
            ::WSARecvFrom(...);
        }
    }
}

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

C++

::WSASetEvent(hEvent);

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 Frown | :(

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?

Thanks in advance.

011011010110000101100011011010000110100101101110
0110010101110011

Re: UDP sockets - not getting FD_READ after some time of activity on a socket

pasztorpisti17-Aug-13 7:01

Re: UDP sockets - not getting FD_READ after some time of activity on a socket

17-Aug-13 7:01

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?

modified 17-Aug-13 13:15pm.

csrss17-Aug-13 7:45

csrss

17-Aug-13 7:45

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 Frown | :(

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 Frown | :(

011011010110000101100011011010000110100101101110
0110010101110011

Re: UDP sockets - not getting FD_READ after some time of activity on a socket

pasztorpisti17-Aug-13 8:16

Re: UDP sockets - not getting FD_READ after some time of activity on a socket

17-Aug-13 8:16

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.

C++

if( socket_event_read * pReadEvent = dynamic_cast<socket_event_read *>(pSocketEvent) )
{
    WSANETWORKEVENTS nt = { 0x00 };
    if( SOCKET_ERROR != ::WSAEnumNetworkEvents(pReadEvent->get_socket(), pSocketEvent, &nt) )
    {
        if( nt.lNetworkEvents & FD_READ && nt.iErrorCode[FD_READ_BIT] == false )
        {
            ::WSARecvFrom(...);
        }
    }
}

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... Smile | :)

)

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.

modified 17-Aug-13 14:27pm.

csrss17-Aug-13 8:48

csrss

17-Aug-13 8:48

Thanks for your suggestions Smile | :)

Well, I knew about fd_write thing Wink | ;)

Part about critical section got me thinking for sure - that is something I haven't considered in current implementation.

Anyways, thanks very much, I need a moment to think about all this.

011011010110000101100011011010000110100101101110
0110010101110011

Re: UDP sockets - not getting FD_READ after some time of activity on a socket

pasztorpisti17-Aug-13 8:53