MouseWheel error

I've got a deployed app that occasionally pops up an error box with the
error <some widget class> does not understand
#wmMouseWheel:wParam:lParam, where <some widget class> is whatever
widget is nearby. What is the trick again for causing a method NOT to be
stripped? I guess it gets removed during stripping and that's why it's
dying, but it is somewhat odd, I suppose.

Joey

--
-- Sun Certified Java2 Programmer
-- My Pocket Smalltalk Stuff: www.joeygibson.com/st
--
-- "We thought about killin' him, but we kinda
--  hated to go that far...." - Briscoe Darling



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

"Joey Gibson" <[hidden email]> wrote in message
news:[hidden email]...
> I've got a deployed app that occasionally pops up an error box with the
> error <some widget class> does not understand
> #wmMouseWheel:wParam:lParam, where <some widget class> is whatever
> widget is nearby. What is the trick again for causing a method NOT to be
> stripped? I guess it gets removed during stripping and that's why it's
> dying, but it is somewhat odd, I suppose.
>
> Joey
>

Sometimes I had a such error and resolved it by saving packages and loading
they in a clean image.

Dmitry

Joey,

> I've got a deployed app that occasionally pops up an error box with the
> error <some widget class> does not understand
> #wmMouseWheel:wParam:lParam, where <some widget class> is whatever
> widget is nearby. What is the trick again for causing a method NOT to be
> stripped? I guess it gets removed during stripping and that's why it's
> dying, but it is somewhat odd, I suppose.

Ummm, if you have any of my goodie packages loaded then this could my fault.
Dolphin as it stands does not support the mouse wheel as part of the
programming interface although, obviously, the wheel does work in normal
Windows widget views. To make the mouse wheel programmatically available in
my goodies I added some methods to the IDB Common package.  However I made a
mistake in adding the windows message definitions (setting up View's message
map) to the package's install script, so that any WM_MOUSEWHEEL messages
were always accepted by the view _even_ if the underlying handling methods
had been stripped.

There are a couple of ways to get around it -

The best method (and, I'm ashamed the say, the way I fixed this problem in
my image some time ago) is to add all the loose methods defined in the IDB
Common package to the "Must not strip" category. This prevents then being
stripped and means that the code is always there to handle the wheel and
middle button events, even if they subsequently do nothing.

If you don't want to programmatically manage the wheel and middle button
then you can just delete the pre-install script from "IDB Common" to prevent
the messages being added to View's message map. If you do this though you
will have to rebuild the image before redeploying your application.

Sorry for any problems this may cause. If you, or anyone else, wants further
details then please mail me.  I'll update the files on the web site, to make
the methods unstrippable, when I can remember what other changes I made to
my working versions of the goodies (over three months ago now - sigh)

Regards
    Ian

Ian and Joey,
"Ian Bartholomew" <[hidden email]> wrote in message
news:mtNj7.12311$NE.783908@wards...
[...]
> There are a couple of ways to get around it -
>
> The best method (and, I'm ashamed the say, the way I fixed this problem in
> my image some time ago) is to add all the loose methods defined in the IDB
> Common package to the "Must not strip" category. This prevents then being
> stripped and means that the code is always there to handle the wheel and
> middle button events, even if they subsequently do nothing.
[...]
One caveat about this approach: if the Goodies package isn't a prerequisite for
a particular application, it may get stripped out early on, so the fact that
loose methods are in the Must Not Strip category doesn't have an effect.  It's
not hard to fix, but it can be a bit confusing if you bump into it.  In my
case, I just made the IDB Common package a prerequisite for a generic
application package that I base things on.

Don

Don,

> One caveat about this approach: if the Goodies package isn't a
> prerequisite for a particular application, it may get stripped out
> early on, so the fact that loose methods are in the Must Not Strip
> category doesn't have an effect.

Thanks for that post. Reading it made me wonder why adding the methods to
the "must not strip" category had worked for me when, as you quite correctly
point out, it should not cure the problem as the package is going to be
stripped anyway. Upon investigation I find that it was not the category
change that cured it for me but a side effect that I introduced when making
the changes which resulted in the View's message map not being changed -
hence the missing methods didn't cause a walkback as they were never
actually needed. <sigh>

Anyway, I've uploaded a revised goodies package that fixes the problem in
the way I _should_ have done at the start, clearing out View's message map
if the package is uninstalled (either manually or as part of the stripping
process).

It does raise a question about whether it might be useful to have a way of
preventing the stripping of packages that doesn't require the addition of
odd references in other, unconnected, packages. Maybe a "Must not strip"
flag as part of the package properties or allowing the "Manual
prerequisites" property to reference itself?.

Ian

Ian

You wrote in message news:bVak7.12714$NE.833333@wards...
> ...
> It does raise a question about whether it might be useful to have a way of
> preventing the stripping of packages that doesn't require the addition of
> odd references in other, unconnected, packages. Maybe a "Must not strip"
> flag as part of the package properties or allowing the "Manual
> prerequisites" property to reference itself?.
>

While not wishing to micturate on your bonfire, I think that feature
suggestion smells of over-engineering. Either a package is needed by others
and should therefore be a pre-requisite of those other packages, or it is
not needed and should uninstall cleanly.

In other words (and I'm sure you know all this, but for the benefit of
others...),if a package A is required by another package, B, (and utlimately
in an applications that uses B or has it as a pre-requisite) then A ought to
be a pre-requisite of B. The packages are not 'unconnected'. Normally this
will be detected automatically, but in unusual cases (e.g. no globals from A
are referenced by B, the only cross-references being to methods, and/or when
some part of the package is installed by one of the scripts, which are not
visible to the pre-requisites tracing mechanism) manual pre-requisites may
need to be set up. It is the responsibility of the user of the package to
set up manual pre-requisites if required. If on the other hand A is not a
pre-requisite of B, then the Lagoon image stripper will rightly remove it.
In order that this can work successfully it is the original package author's
responsibility to make sure that their packages uninstall cleanly. Typical
actions required to assist clean uninstallation are implementing
#uninitialize methods in classes to complement class #initialize methods,
and occassionally reversing the effects of a package install script in the
uninstall script.

Regards

Blair

Blair,

> While not wishing to micturate on your bonfire, I think that feature
> suggestion smells of over-engineering. Either a package is needed by
> others and should therefore be a pre-requisite of those other packages, or
> it is not needed and should uninstall cleanly.

Agreed. I've already updated the package on the web site to uninstall
correctly, which is what I should have done in the first place!.

[with snips]
 > Normally this will be detected automatically, but in unusual cases (e.g.
> no globals from A are referenced by B, the only cross-references being to
> methods, and/or when some part of the package is installed by one of the
> scripts, which are notvisible to the pre-requisites tracing mechanism)
> manual pre-requisites may need to be set up. It is the responsibility of
> the user of the package to set up manual pre-requisites if required.

Again I agree, but I was thinking more of a hypothetical situation where
someone produces a package that contains only non-global objects as a
"general purpose" addition to the image - some methods to provide printing
support say.  At the moment, all you can do is _document the fact that if
anyone uses these methods in a deployed application then they must make sure
that the printing package is not stripped - probably by making it a manual
pre-requisite. Some sort of "Must not strip package" attribute would give
the _producer of the printing package the ability to protect it rather than
the user who may not realise, or remember, the reason for retaining the
package.

Not something to lose a lot of sleep over though.

Ian