   Displaying bitmaps in a menu on a grid?
  In my level editor I'm writing, I want to have a tools menu that mimics the tools window. There are 10 tools, arranged in two columns of five tools. I want to write a custom menu definition to do this. I want the user to be able to drag the cursor outside of the menu and have the menu split off into the tools window.From my time doing Mac programming, menus had their own menu definition procedures. You could create a menu in anyway you saw fit. What I'm finding on MSDN is that menus in Windows are pretty much required to be a single column of text, icons, bitmaps, etc.I've looked into owner-drawn menus, but I am given a list of rectangles for the menu items that Windows arranges for me and I must draw the items in those rectangles. It appears that the programmer has no control over the placement of the items in the menu or the physical size of the menu.Is there a way around this?   
  You could just create your own borderless, top-most window with the items in it arranged as you like.   ;  So, basically fake the menu?   ;  Pretty much [smile]   ;  *SIGH*Seems like I'm doing more faking than actual GUI programming. I cannot believe how restrictive this OS is...   ;  To each his own, I guess; Cocoa/Carbon made me want to vomit [wink]   ;  I just like the flexibility. If I want a menu that is round and multi-colored, all I need to do is write the menu definition. Of course, Apple discourages odd UI elements, but the option is there.   ;  In fairness to MS, standardisation of interface has always been pretty important due to sheer majority of non-technical users and I guess the SDK is based upon this principle.As ApochPiQ suggests, you are able to override the normal behaviour so I wouldn't say that Windows is restrictive as such, just that the toolset is rooted in encouraging a consistent experience for users.Is a drop-down from the application menu really the most intuitive place for this feature?   ;Quote:Original post by AardvajkAs ApochPiQ suggests, you are able to override the normal behaviour so I wouldn't say that Windows is restrictive as such, just that the toolset is rooted in encouraging a consistent experience for users.Actually, what he suggests doesn't override the behavior. It just creates a window that pops up when the menu is selected. Not what I had in mind, but it will work.Quote:Original post by AardvajkIs a drop-down from the application menu really the most intuitive place for this feature?I was originally just going to have a standard menu with the names of the tools and icons next to the tools. However, it would appear that the icons next to menu items overrides the check mark images and I want the current tool to be checked. Since this wasn't going to work, I thought I would just copy the tool window in functionality. I've done this before on the Mac and it was very simple. The reason for this menu is to give the user the option to select tools without having the tool window open. This will save on screen real estate.   ;Quote:Original post by AardvajkIn fairness to MS, standardisation of interface has always been pretty important due to sheer majority of non-technical users and I guess the SDK is based upon this principle. [T]he toolset is rooted in encouraging a consistent experience for users.Is a drop-down from the application menu really the most intuitive place for this feature?This.The Windows API is largely engineered to make it hard(er) to do the "wrong" thing. If you want a UI that users will find familiar, intuitive, and standardized, just do things as the API encourages. (Within bounds of reason; I know some of you pedants out there will find ways to nitpick on that statement [wink])In general if you find something that is outright difficult to do, such as needing to owner-draw and replace an entire category of user interaction controls like a menu, you should think carefully about whether you're doing something that users will understand.Remember, an interface I already know how to use when I first see it is ten times better than a really clever interface that confuses me until I learn it.This is why I (in general) really hate custom-skinned applications, for what it's worth.[edit] You ninja'd me during my reply; the explanation makes sense, and in this case I think it's a legitimate use of the system. However, why not just use the same tool-window code for the fly-out menu as well as the floating window? That should save you a lot of headaches. Just tweak the menu styles according to which appearance you want when you spawn the tool window, and then pop it up in the correct location.   