Recent changes to bugs

list_ctrl

Steven Weiss — Fri, 28 Jan 2005 09:28:20 -0000

Hi john,
the list_ctrl-class misses a function edit_label() like
the tree_ctrl

mfg steven

overload resolution failure

Steven Weiss — Sat, 15 Jan 2005 17:32:24 -0000

hi john,
your image_list-constructor cannot be resolved
correctly by the compiler:

image_list<shared> imgl_tree_;

base_message_dlg_handler() : imgl_tree_(IDB_TREEICONS,
16, 0, CLR_DEFAULT, LR_DEFAULTCOLOR)
{}

this could be either
'image_list<r_type>::image_list(int,int,int,color,UINT)'
or
'image_list<r_type>::image_list(int,int,UINT,int,int)'

(your color-class has a conversion constructor...)

spelling mistake of tree_ctrl::drop_highlighted()

Steven Weiss — Thu, 06 Jan 2005 11:44:37 -0000

hi john,
the drop_highlighted()-functions of the tree_ctrl are
misspelled. they are:

drop_hilighted()
and
drop_highlighed()

:-)

no real bug but annoying

Steven Weiss — Tue, 14 Dec 2004 11:42:09 -0000

hi john,
in win32gui/detail/general/defs.hpp you typedefed
std::basic_string<TCHAR> to string. this can affect
user code:

void func()
{
using namespace win32::gui;
using namespace std;

string str; // could be win32::gui::string or std::
string!
}

i know, developing the library with typing std::string
all the time is very annoying but you could do a final
"Search&Replace in Files" in your vc++ when a new
release is completed so this would only be a
measure of a minute

Difficult workaround for the user

Steven Weiss — Sat, 27 Nov 2004 12:46:29 -0000

Hi John,
few days ago i told you that i wanted to subclass the
menu's window. after some tries i realized that i have to
create a hook which monitors the creation of the window
for a correct subclassing. my first plan was to subclass
the window in response to a WM_ENTERMENULOOP,
WM_INITMENU or some other menu-related message but
that either wasn't possible (window has not been created
yet) or it turned out to be erroneous.

so i took the step with the hook. i created a CBT-hook
and wanted to remap the window in this hook ->

static LRESULT CALLBACK CBTHook(int nCode, WPARAM
wParam, LPARAM lParam)
{
HWND hWnd = 0;
if ( nCode == HCBT_CREATEWND) {
hWnd = reinterpret_cast<HWND>(wParam);
if (is_menu_hwnd(hWnd))
mapping::remap_wnd<menu_wnd> (hWnd);
}
return CallNextHookEx( g_cbt_hook_, nCode, wParam,
lParam);
}

but remap_wnd() throwed an exception. the location was
in get_window_anythread(). i analyzed your code and
came to the conclusion that you also have a cbt-hook
but the windows don't get subclassed immediately but
only after a message. so here's my workaround:

static LRESULT CALLBACK msg_window_hook(int nCode,
WPARAM wParam, LPARAM lParam)
{
static const int wm_register_internal =
get_wm_register_internal();

MSG * msg = reinterpret_cast<MSG*>(lParam);
if ( msg->message == wm_register_internal) {
HWND hWnd = reinterpret_cast<HWND>(msg-
>lParam);
if (is_menu_hwnd(hWnd)) {
bool create = msg->wParam != 0;
if (create)
mapping::remap_wnd<menu_wnd> (hWnd);
}
}
return CallNextHookEx(g_msg_hook_, nCode, wParam,
lParam);
}

i copied the get_wm_register_internal() function from
your code. my hook procedure is a WH_GETMESSAGE-
hook (like yours) and to make sure my hook procedure is
called AFTER win32gui's i have a static object so this
object will be created at program initialization and your
SetWindowsHookEx() will be called after mine -> correct
Hook-Chaining-Order.

you commented that this is necessary for correct
subclassing. but you could create a function which takes
the steps for correct hooking - or you mention the
correct procedure in the docs. it took some time for me
to solve the problem and i don't think unexperienced
programmers will find the solution by themselves

greetz steven

new version (1.6) doesn't compile

Steven Weiss — Thu, 18 Nov 2004 15:04:31 -0000

the version as it is now isn't compilable:

- in win32gui/events/wm/common.hpp it should be
#include <win32gui/events/wm/detail/common_draw.hpp>
#include <win32gui/events/wm/detail/common_keyb.hpp>
#include <win32gui/events/wm/detail/common_menu.
hpp>
#include <win32gui/events/wm/detail/common_mouse.
hpp>

you forgot the "detail"-folder

----------------------------------------------------

- strangely some WM_* defines in common_mouse.hpp
are undefined...although i include <windows.h> before
<win32gui/pch/pch.h> in my stdafx.h.

i added this lines to common_mouse.hpp:
#ifndef WM_MOUSEWHEEL
#define WM_MOUSEWHEEL 0x020A
#endif

#ifndef WM_XBUTTONDOWN
#define WM_XBUTTONDOWN 0x020B
#endif

#ifndef WM_XBUTTONUP
#define WM_XBUTTONUP 0x020C
#endif

#ifndef WM_XBUTTONDBLCLK
#define WM_XBUTTONDBLCLK 0x020D
#endif

#ifndef WM_NCXBUTTONDOWN
#define WM_NCXBUTTONDOWN 0x00AB
#endif

#ifndef WM_NCXBUTTONUP
#define WM_NCXBUTTONUP 0x00AC
#endif

#ifndef WM_NCXBUTTONDBLCLK
#define WM_NCXBUTTONDBLCLK 0x00AD
#endif

----------------------------------------------------

- win32gui/events/controls/check_box.hpp

wrong include path, should be:
#include <win32gui/events/extend/button.hpp>
(you forgot the extend subfolder)

----------------------------------------------------

- win32gui\events\extend\button.hpp
doesn't compile, various syntax errors

----------------------------------------------------

- ... there are a lot more but i have to go away from
work now. maybe tomorrow i'll post some more

Bug comparing signals...

Anonymous — Mon, 18 Oct 2004 02:56:06 -0000

The use of signal::result_signal() in combination with
signal::operator==() does not give the expected result.

The easiest way to reproduce the incorrect behavior is
to wait for the signal
"wait_for::key_pressed(VK_RETURN)" and then compare the
signal returned by wait() to
"wait_for::key_pressed(VK_RETURN)". The two will not
compare as equal even when the return key is pressed.

The method signal::result_signal() copies the internals
of the signal and then sets the various fields to the
values passed in (these come from the windows message
itself) including the lparam, which in the case of a
WM_KEYDOWN message will be some number based on the
repeat count of the keypress etc. signal::operator==()
compares the various fields of the two signals. The
predefined signal (key_pressed(VK_RETURN)) will have
m_lparam == 0 since this is a msg_w_param signal type,
and the signal returned by signal::result_signal() has
some other value for m_lparam, so the two do not
compare as equal.

The bug here is either the fact that
signal::result_signal() is altering unused fields (i.e.
changing the m_lparam member for a msg_w_param signal)
or that signal::operator==() is comparing unused
fields, or both.

my email is: squiremyrkle@fastmail.fm if you have any
questions.

Some more leaks...

Steven Weiss — Mon, 20 Sep 2004 19:09:57 -0000

hi,
i mentioned some more memleaks (v1.4.1b):

1.) win_tss & get_tss()
at tss = new win_tss;

2.) void dispatcher::add_signals( const signals_vector&
signals)
at m_signals_stack.push(signals);

3.) and some more, but when I try to get 'em Vc++ 2003
kicks me out...it hangs, ergh!

you can see the leaks by calling

int temp = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);
temp |= _CRTDBG_LEAK_CHECK_DF;
_CrtSetDbgFlag(temp);

in WinMain. with _CrtSetBreakAlloc(allocNum); you can
set a breakpoint at allocation number allocNum to trace
back to the memory allocation

(I'm sure you have already known this ;-) )

resizable_wnd bug - resizing turns into move

Anonymous — Sun, 29 Aug 2004 18:18:21 -0000

When a window extends resizable_wnd, resizing the
window using the top-left corner, the top border, or the
left border causes the window to move if the window
can not be resized any smaller.

Rather than using on_sizing to check for min/max,
handle the WM_GETMINMAXINFO message instead.