Menu gets disabled

I am experiencing a curious problem with an application's menu on a
Tablet PC.  The application displays a series of objects, represented by
images.  The application has a menu bar created with the View Composer.
  Each object has a context menu built in code when the object is created.

On my development machine, Compaq Deskpro XP Pro, everything works as
expected.  The app has been packaged and runs fine on several XP
machines and several win2k machines including laptops.

I put the application on a Tablet PC (XP Tablet edition) and after any
of the context menu options are executed, all of the main menu options
become disabled.  This happens in the packaged app as well as in
development.  I know the display on the Tablet is different, but I can't
see why that would effect the main menu.  The context menu is not
affected, it continues to work as expected.

I realize the Tablet is a new animal, and it's hard to avoid laying the
blame at it's feet.  I would like to figure this out, but I could use
some suggestions as to where to start.

Thanks
Dan
-----------
Dan Antion

Dan,

> I put the application on a Tablet PC (XP Tablet edition) and after any
> of the context menu options are executed, all of the main menu options
> become disabled.  This happens in the packaged app as well as in
> development.  I know the display on the Tablet is different, but I can't
> see why that would effect the main menu.

The OS could be either subclassing or covering windows, or perhaps just
their non-client areas.  That could be done incorrectly, or maybe Dolphin
isn't responding well to it.


> The context menu is not
> affected, it continues to work as expected.

Is it one context menu, or one per object?  When are the menu(s) created?
Is it one context menu, perhaps re-created as objects are created, therefore
masking any damage done to the older menus?

I'm blissfully unaware of the details of Dolphin's command routing, but
there might be an easy way to disable the disabling of commands - if so,
doing that would be an interesting test.  At least it would give you an idea
of whether the problem is that Dolphin thinks the commands should not be
available.

BLAMING IT ON MICROSOFT
========================
A gloomier thought would be that (IIRC) menu bars are often assigned in
window classes (WNDCLASS vs. OO stuff), and MS might not be correctly
handling "dynamic" menu bars.  One would hope that there are no messages
that need to be handled in order run on a tablet, but that's possible.

BLAMING IT ON OBJECT ARTS
=========================
One thing that has always scared the DLL out of me is the default window
procedure, and the business of returning zero or one or whatever it is to
invoke or override it.  It scares me only because it would be very easy to
miss an error.  Perhaps Dolphin does or does not call default handling when
the opposite is crucial, and it might be that it has gone unnoticed until
now.

Sorry I can't be of any real help.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Dan, Bill,
therefore
> masking any damage done to the older menus?
>
> I'm blissfully unaware of the details of Dolphin's command routing, but
> there might be an easy way to disable the disabling of commands - if so,
> doing that would be an interesting test.  At least it would give you an
idea
> of whether the problem is that Dolphin thinks the commands should not be
> available.

We haven't got a Tablet here (yet) but it seems to me that the first place
to start (before "blame" get apportioned either way) would be to analyze the
behaviour of the development system menus. Do you see the same effect in the
Dolphin IDE? i.e. If you use one of the context menus in the class browser
do the menu bar commands get disabled?

Could the problem be due to the change in focus or active window following
the use of the contect menu command? Can you get the menu bar commands to
work again by switching active window or focus a few times.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Thanks for some good suggestions, see below....

Bill Schwab wrote:
There is one context menu per object.  The obejects are in a grid
layout, and the context menu is added to the object viewer as they are
added to the container.

The only difference that I can see is the introduction of the pen. But I
would assume (dangerous) that for things like this, the pen mimics or
reuses the mouse. In any case, I would think by the time they got to
menus, the pen would be considered just another pointing device.
I appreciate your thoughts

Dan

See below

Andy Bower wrote:
I should have pointed this out earlier.  I do not see this problem with
the Dolphin IDE.  In fact, I don't see this in another part that I have
that has the default context menus provided with text boxes.  I added a
simple menu bar to this part, and it is not affected.


>
> Could the problem be due to the change in focus or active window following
> the use of the contect menu command? Can you get the menu bar commands to
> work again by switching active window or focus a few times.
>

Changing focus has no effect, in development or runtime.  Interacting
with the menu also has no effect (I added a test method to remove a menu
item and add an item)

I haven't had time to work up a more comprehensive test, but I am
planning to eliminate some of the complexities of this application and
gradually add them back in. The objects with the context menu are in a
grid layout in a contained in a scrollling window, so maybe there are
too many things for the tablet for some reason.  In the simpler part I
reference above, it's just text boxes in a single window.

Thanks for your help
Dan

Dan,

> I haven't had time to work up a more comprehensive test, but I am
> planning to eliminate some of the complexities of this application and
> gradually add them back in. The objects with the context menu are in a
> grid layout in a contained in a scrollling window, so maybe there are
> too many things for the tablet for some reason.  In the simpler part I
> reference above, it's just text boxes in a single window.

Scroller huh???  Combining that with Ian's recent report of mouse wheel woes
in a scroller has me wondering.  All it would take is an extraneous or
missing default proc call.  Ok, I'm sounding like a wav file caught in an
infinite loop (or a broken record for you well seasoned folks<g>), but
knowing what a pen system is likely to do, it seems suspicious, and it would
be an easy error to make, and a (potentially) very difficult error to
notice.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

It's the first thing I'm going to remove for testing.

I'll keep the group informed, FWIW

Dan

Bill Schwab wrote:

On Thu, 20 Mar 2003 20:54:58 -0500,
Bill Schwab <[hidden email]> wrote:
>   Ok, I'm sounding like a wav file caught in an
> infinite loop (or a broken record for you well seasoned folks<g>),

Did you know that you can also reproduce this effect with the
almost-latest high-tech means?

Install Sun JDK 1.4.1 on a box with one of several ATI Radeon
models, play some nice MP3s with WinAmp in the background and
then start and exit a Java application.

Because Sun chose to call some lowlevel graphics stuff in a
slightly non-standard way, which manages to crash the graphics
card, you'll have a dead box in front of you repeating the last
two seconds of MP3s over and over and over again. You can even
hear a slight click when the track "jumps back", just like with
a scratched record :-)

Oh, BTW, this is known for about a year now, but nobody wants
to fix it.

I am still waiting for any Smalltalk to crash my machine.

s.