Mauricio Tavares wrote in message <34679@palm-dev-forum>...
>
...
>I was going to have my routine to draw the gadget directly here, but wanted
>first to understand GadgetTrap(), which is defined in the Evil O'Reilly
>book, p.112. One line in that code I do not understand (it may be that I
>do not know C enough =) is the one that goes like this
>
> *wPtr = !(*wPtr)
>
>Yes, it seems that there is a ";" missing, but there is way more to it. I
>asked some people and was told that could be a boolean flip. So, we would
>have something like *wPtr = !(true) => *wPtr = false, but it does not make
>sense to me. After all, isn't wPtr a normal memory pointer?
Yes. Given the name, I would guess that it is a pointer to a word value.
Now the important part here is that while "wPtr" is a pointer to a word
value, "*wPtr" is the word value that is being pointed to. Note that the
asterisks are present in that line. You are not inverting the pointer, you
are inverting the value being pointed to.
>
>Also in the same routine, he uses WinInverRectangle() to emulate a
>highlight. How could I do something similar to it, but only invert the
>bitmap inside it
Use a smaller rectangle ? If you know the size and position of your
bitmap (and since you drew it yourself, I am assuming that you do)
you should be able to come up with a rectangle that can invert it.
>(assume anything outside the bitmap is background and
>should be left alone)? Should I just give up and create an "inverted"
>bitmap and swap them?
Another fine option.
>Continuing with my easy questions, From what I
>understood, I should make the gadget be redrawn after the form is drawn in
>a frmOpenEvent and FrmUpdateEvent events. The routine to draw the bitmap
>is currently something like
...
>
>I hard coded the coordinate for now. Later on I can get it from the bounds
>for the gadget.
don't wait.
>
> Back to the events, I am confused about where the form gets a
>frmUpdateEvent.
In the event handling routine you register for the form.
>The way the code is shown in the book (since the original
>hello sample), ApplicationHandleEvent() is written to initialize the form
>and then feeds the events to the form handle event routine by setting the
>event handler using something like FrmSetEventHandler(pFrm,
>HandleFormEvents). Wouldn't then HandleFormEvents() be the most
>appropriate place to listen for frmUpdateEvent?
Exactly.
>That is where I placed it
>but it is not being updated.
Would have to see code to figure out why this isn't happening. It works
for me.
>I may try to make it beep so I have some
>feedback that the event is being detected (since dbx in unix, I have always
>avoided using debuggers as most of the time they just get me confused.
You're going to have to get over that. POSE & the CW debugger are
pretty much vital to figuring out what's going on inside your code. With
PC programs you can always dump trace statements to stdout, but you
cain't do that w/ a PDA.
>When doing stuff in Xwindows, I used to write my own debugging messages in
>a file that I would tail -rf then =)?
Well ... you could write to a notepad entry ... but that is probably
more trouble than it's worth.
>
> The big question of the day: am I in the right target here? Is this too
>slow? If I were to rewrite it in a 3.5 style, how much speed/code size
>would I gain/loose? Also, if I wanted to used some of that code to track
>down a moving image (think of a game), what to do then?
>
>
>
There are some games out there for which the source is available.
In particular I think the code for "reptoids" (an asteroids implementation)
is available. Check on PalmGear.
--
-Richard M. Hartman
[EMAIL PROTECTED]
186,000 mi/sec: not just a good idea, it's the LAW!
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
