🚀 go-pugleaf

In article <3DBFC375.F79DF1D0@picsel.com>, donovan.winch@picsel.com 
says...
> Hey people,
> 
> I'm having some difficulty with trying to process events in the top left
> of the screen in a Palm OS 5 application.
> 
> The application doesn't have a Palm OS menu. I've removed the default
> one from the resource file, and tried commenting out the "if (!
> MenuHandleEvent(0, &event, &error))" line in the AppEventLoop()
> function, so events shouldn't even be passed to the menu event handler.

All you should really need to do is set the menu for your form to "0".  
This will remove the menu, and you shouldn't need to do anything else.

> I was hoping that this would allow me to use the whole screen (including
> the region usually used as the 'menu bar' at the top) for my own
> nefarious purposes, but any pen events in the top left (where the
> default menu is usually located) don't get passed to my main form as pen
> events (penDownEvent, penUpEvent, penMoveEvent, etc.).

This is really weird, as even with a menu, you usually get a pen event 
for a tap in the menu region, which MenuHandleEvent then turned into a 
menuEnterEvent, which then causes the menu to be displayed.

> Is there something else I should be doing to disable this area's use as
> a menu, or are there some 'special' events that I need to check for just
> in that area of the screen?

You seem to be doing things right... you might get better answers asking 
this on the palm-dev list, as its not a CodeWarrior specific question.
-- 
Ben Combee <bcombee@metrowerks.com>
CodeWarrior for Palm OS technical lead
Get help at http://palmoswerks.com/

I'm not sure if this is the best way to do it, but you might try
dispatching the event received from EvtGetEvent to your form before
calling SysHandleEvent. I believe the problem is that SysHandleEvent
is seeing the penDown event in the menu area, absorbing it, and
placing a menu event back on to the event queue. If you're using the
typical CW framework app event loop that looks like this:

	do {
		EvtGetEvent(&event, evtWaitForever);

		if (! SysHandleEvent(&event))
			if (! MenuHandleEvent(0, &event, &error))
				if (! AppHandleEvent(&event))
					FrmDispatchEvent(&event);

	} while (event.eType != appStopEvent);

then FrmDispatchEvent will never get called for a penDown in the menu
area.

In my program that uses the whole screen area, I process all events
that I want to see first, and if they're not on my list of events to
absorb, only then do I pass them on to SysHandleEvent.

-Robert Hildinger



Donovan Winch <donovan.winch@picsel.com> wrote in message news:<3DBFC375.F79DF1D0@picsel.com>...
> Hey people,
> 
> I'm having some difficulty with trying to process events in the top left
> of the screen in a Palm OS 5 application.
> 
> The application doesn't have a Palm OS menu. I've removed the default
> one from the resource file, and tried commenting out the "if (!
> MenuHandleEvent(0, &event, &error))" line in the AppEventLoop()
> function, so events shouldn't even be passed to the menu event handler.
> 
> I was hoping that this would allow me to use the whole screen (including
> the region usually used as the 'menu bar' at the top) for my own
> nefarious purposes, but any pen events in the top left (where the
> default menu is usually located) don't get passed to my main form as pen
> events (penDownEvent, penUpEvent, penMoveEvent, etc.).
> 
> Is there something else I should be doing to disable this area's use as
> a menu, or are there some 'special' events that I need to check for just
> in that area of the screen?
> 
> Thanks in advance for any advice.
> 
> Donovan Winch.
> (donovan_dot_winch_at_picsel_dot_com)

Thanks for the replies, Ben and Robert.

I got halfway through a reply better explaining everything that I've
tried and that, in fact, I was getting penDown and penUp events, but not
penMove events, when I noticed that I'd done something somewhat ... um
... stupid. :(

The handler for the form in question was returning true (i.e. "yes, I've
handled this event") on penUp and penMove events, but false on penDown
events. I'm not altogether sure why this was producing the results it
was for only that small section in the top left, since I'd completely
disabled the menu and menu handler, but returning true on a penDownEvent
in the form's handler fixed the problem.

Thanks again!

Donovan.