When the user opens a submenu containing items with the style `menu::checks::option` and clicks an option, the radio button logic doesn't work. This bug was discovered and fixed by nanapro.org forum user "huycan" (I'm just submitting the PR). See this forum post: http://nanapro.org/en-us/forum/index.php?u=/topic/1256/ggleave-a-menu-open
As mentioned in more detail in the forum post linked above, my understanding of why this happens is that `menu_builder::checked` fails because the `menu_window` of the submenu is created with the `menu_builder` object used by the parent menu.
This method incorrectly calculates the position of checkboxes in the listbox content area. It uses the formula `new_where.second * item_h + header_visible_px()` to calculate the number of pixels between the top of the viewport and a checkbox.
The problem is that when the first visible item is only partially visible, `new_where.second * item_h` produces an excess of pixels equal to the vertical segment of the first visible item that is not in the viewport. This excess value produces a downward displacement of the calculated checkbox position, so it must be accounted for in the aforementioned formula.
This problem occurs because at some point, the library switched from scrolling in item-sized increments to smooth scrolling (in older versions, it used to be that it was impossible for an item to be only partially visible).
Relevant thread: http://nanapro.org/en-us/forum/index.php?u=/topic/1227/ggnana-listbox-with-a-check-box-for-each-list-item#post-3359
A constructor and an overload of the assignment operator each have a forwarding reference as a parameter, but they don't actually forward the argument.
When a tab is deleted using `tabbar::erase`, `trigger::erase` is called. This function does not call `API::refresh_window` if the tab was erased successfully (unlike `trigger::tab_color`, `trigger::tab_image`, etc.), thus the tab is still visible until an interaction is made (like mouse click on `tabbar`).
fixed bug in dock_pane caption drawing function (used a workaround that hide the caption when the dock_pane width become too small)
fixed small bug in toolbar
When only one file is selected, the lpstrFile variable contains only the path to that file, without the parent path before that, thus, the targets vector is empty and the path variable contains the actual path to the file. This is inconsistent with the scenario where multiple files are selected, in which targets contains the file paths and path contains the parent directory path.
