#3 nasty l_param_lo, l_param_hi, ...

[Steven Weiss]

Hi John,
this example won't compile:

handle_event on_size(l_param_lo cx)
{
... // do some calculations
if (...)
cx += 100;

if (...)
cx = 50;

... // do something with the new cx

return event<WM_SIZE>.HANDLED_BY(&me::on_size);
}

because the l_param_XX and w_param_XX structs have a
const data member and the operator int() ist const. i
would have to create a new int-variable and copy cx to
it.

but i think this is nasty and not necessary: in the
constructor the int value will be copied anyway so this
shouldn't be any problem. and because a totally new
l_param_lo is constructed for every event-handler-
function the following code has no impact on following
event handlers of subclasses

handle_event on_size(l_param_lo& cx)
{
...
}

my solution looks like this:

struct l_param_hi {
l_param_hi(int val) : val(val) {}
operator int&() { return val; }
int val;
};

i would appreciate it if you would include this patch in
win32gui because it has only advantages and no
drawbacks.

[John Torjo]

Logged In: YES
user_id=1031729

Hi fotzor,

You're right. w_param_lo/etc. are kind of crappy.
You'll love the new structures that come with Resource Splitter.
(not sure I'll be able to make it into v1.6.2, but they
should be there for v1.6.3+).

You'll be able to say:
handle_event on_size(wm::size::arg a) {
a->left = 310;
a->bottom = 442;
...
return event_ex<wm::size>().HANDLED_BY(&me::on_size)
}

Best,
John

[Steven Weiss]

Logged In: YES
user_id=1124235

cool! i'm looking forward for resource splitter (although
the name had a totally different meaning to me before this
explanation)

[Steven Weiss]

Logged In: YES
user_id=1124235

another example is that result should have comparation
operators:

handle_event on_end_label_edit(l_param<LPNMTVDISPINFO>
ptvdi, result res)
{
res = FALSE;
.... // some code

if (res.type == FALSE)
tree_->del_item(hItem);

return notify<IDC_TREE_MESSAGES, TVN_ENDLABELEDIT>
().HANDLED_BY(&me::on_end_label_edit);
}

at the moment i have to use a temporary variable that i
compare instead of res and that i assign at the end. this
would be even more error-prone if you have some "return
event_handled_early'"s because it would require to be very
careful...

btw yesterday i read your article about resource splitter in
cuj and i think it's a great step towards more safety and
clearness. i had no time to try it yet but don't you think
the compile times will increase? i mean a lot more classes,
a lot more template instantiations. i'm sure you tested this ;-)

mfg steven