FrmCustomAlert calls FrmDoDialog, which has it's own event loop. You can set
up an event handler that gets first crack at all events, but I think you'd
need to call FrmDoDialog yourself rather than FrmCustomAlert.
The other alternative that comes to mind is to patch traps (on 68K based
devices) a
From: "John Crouch" <[EMAIL PROTECTED]>
> When an alert box is being displayed via the FrmCustomAlert() function
call,
> my app does not receive any events. We have a need to trap events during
> this time. Am I missing something or is this correct - we don't get
events
> when an alert box is up
> From: "John Crouch" <[EMAIL PROTECTED]>
> > When an alert box is being displayed via the
> > FrmCustomAlert() function call, my app does not
> > receive any events. We have a need to trap events
> > during this time. Am I missing something or is
> > this correct - we don't get events when an a
ur nilEvent handler.
--
Peter Epstein
-Original Message-
From: Blake Winton [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 11, 2002 8:48 AM
To: Palm Developer Forum
Cc: [EMAIL PROTECTED]
Subject: RE: Events during Alert Box
> From: "John Crouch" <[EMAIL PROTECTED]>
From: "Blake Winton" <[EMAIL PROTECTED]>
> > From: "John Crouch" <[EMAIL PROTECTED]>
> > > during this time. Am I missing something or is
> > > this correct - we don't get events when an alert
> > > box is up?
> > No. There are a surprisingly large number of
> > standard PalmOS functions that wi
Peter,
>My advice is to avoid using custom events for communicating information
>within your application. I think custom events may have some utility, but I
>do agree that they may do more harm than good because they sure seem more
>useful than they really are.
What brought me into the Palm prog
At 9:25 AM +1200 2002/04/12, Chris Tutty wrote:
>More importantly, why document them at all if an undocumented
>set of common operating system functions will throw them away.
>It's similar to having a function call mechanism that will
>randomly fail to action the function call. I really can't se
I would agree that Symbol probably should have used virtual character events
that go in the key queue rather than custom events that go in the general
event queue.
--
Peter Epstein
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/su
Peter,
I am trying to do something similar as well. In my case, my app is using
NetLib to connect to the net to send & receive stuff. The device my app is
running on is a Kyocera 6035 so my connectivity is spotty at best. What I
am trying to do is to either prevent or dismiss the NetLib error
Sorry, but I'm completely clueless when it comes to NetLib, so I really
can't answer your question. I'd try running the code in POSE and using the
event tracing capability of POSE to see what events are generated when you
manually dismiss the dialog. However, I'd first try to find a way to avoid
t
I am using the Symbol MSR (Magnetic Stripe Reader). This library runs in
two modes: buffered mode or unbuffered mode.
Buffered mode requires the app to issue an "arm to read" command to the MSR.
The app then sits waiting for the card to be swiped by the user. You cannot
do anything else while
ery annoying if you're trapping
something like the hardware keys (and I guess MSR events too).
- Original Message -
From: "John Crouch" <[EMAIL PROTECTED]>
Newsgroups: palm-dev-forum
To: "Palm Developer Forum" <[EMAIL PROTECTED]>
Sent: Monday, April 15
John,
As most people answered already, you are not using the right tool. That's
why you are in trouble. Custom Alerts are modal dialogs and yes they eat all
events. If you need to keep control other your events, then use something
else. Something more appropriate for your need. Many proposals hav
Thank you Peter and everybody else for their input. I think I am going to
create a replacement for my use of FrmCustomAlert and a keyboard replacement
function. Can anyone offer me tips or a starting point for either of these
two routines?
FrmCustomAlert Replacement:
Today I use a generic aler
I would agree that posting a vchr event into the key queue is not by itself
an appropriate notification mechanism. The key queue is good in that it
survives app switches and is thread safe. However, the event can be lost in
an event loop that is not in your control. While you can work hard to avoi
From: "John Crouch" <[EMAIL PROTECTED]>
> Thank you Peter and everybody else for their input. I think I am going to
> create a replacement for my use of FrmCustomAlert and a keyboard
replacement
> function. Can anyone offer me tips or a starting point for either of
these
> two routines?
>
The ma
16 matches
Mail list logo
