Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

Hi all,

I have a silly question ... if I clear the screen (e.g., using "IDISPLAY_ClearScreen"), is there anyway a control can draw to the screen without me explicitly calling "redraw" on that control? The reason I'm asking is that I was reading Ralph's book ("Wireless Game Development in C/C++ with BREW") and he has a section on the Static control in which he states:Quote:When an EVT_APP_SUSPEND event is received by your applet, you are to release the static control. Otherwise, it may draw on top of whatever event is interrupting your applet. When the applet is resumed, you must manually recreate the static control and redraw it. Not doing this will almost certainly cause your program to fail the True BREW test process.But, if I can guarantee that *my* code won't draw the static control while the applet is suspended, then am I safe? or am I (once again) missing something?

Thanks,

Paul

p.s., I understand that releasing the static control frees up resources ... for this question, I'm ignoring that benefit.

I believe one instance of this happening is if your static control auto-scrolls. (like on the Z800) If so, it wil redraw itself as it scrolls, I think. The problem is there's no way to set a static control to be inactive--unlike a Menu control.
I've had bugs in my programs before where the static control still draws or otherwise clutters the screen upon suspension when receiving an SMS message etc. So now I just destroy all statics and rebuild them upon resume.
Instances where a Static automatically redraws itself without you explicitly calling Draw may vary from handset to handset. So it's probably a good defensive technique to just destroy them upon suspension and recreate them on resume. If you *REALLY* want to be safe--destroy 'em. :)
Granted, the static control is pretty useless as it is, so I just wrote my own replacement control. Chances are, I won't use statics anymore in future projects.

I believe one instance of this happening is if your static control auto-scrolls. (like on the Z800) If so, it wil redraw itself as it scrolls, I think. The problem is there's no way to set a static control to be inactive--unlike a Menu control.
I've had bugs in my programs before where the static control still draws or otherwise clutters the screen upon suspension when receiving an SMS message etc. So now I just destroy all statics and rebuild them upon resume.
Instances where a Static automatically redraws itself without you explicitly calling Draw may vary from handset to handset. So it's probably a good defensive technique to just destroy them upon suspension and recreate them on resume. If you *REALLY* want to be safe--destroy 'em. :)
Granted, the static control is pretty useless as it is, so I just wrote my own replacement control. Chances are, I won't use statics anymore in future projects.

Quote:Originally posted by flarb
I believe one instance of this happening is if your static control auto-scrolls. (like on the Z800) If so, it wil redraw itself as it scrolls, I think. The problem is there's no way to set a static control to be inactive--unlike a Menu control.
Whatever flarb said is correct. Its the scrolling of text which causes the ISTATIC control to redraw itself. Its always safe to release the ISTATIC control during APP SUSPEND.

Quote:Originally posted by flarb
I believe one instance of this happening is if your static control auto-scrolls. (like on the Z800) If so, it wil redraw itself as it scrolls, I think. The problem is there's no way to set a static control to be inactive--unlike a Menu control.
Whatever flarb said is correct. Its the scrolling of text which causes the ISTATIC control to redraw itself. Its always safe to release the ISTATIC control during APP SUSPEND.

Thanks for the responses! I hadn't thought (naturally) about auto-scrolling. I guess I better let these puppies go free when I receive an EVT_APP_SUSPEND event.Quote:Originally posted by flarb
Granted, the static control is pretty useless as it is, so I just wrote my own replacement control. Chances are, I won't use statics anymore in future projects. hmm, that sounds interesting ... since my application just seems to keep growing and growing, I worry about "replacing" controls already provided by BREW (even when they suck). Just out of curiousity, how big is your replacement control, and does it provide all/most of the functionality of the original? Gee, maybe you could have a little side business selling replacement BREW controls :)

Thanks for the responses! I hadn't thought (naturally) about auto-scrolling. I guess I better let these puppies go free when I receive an EVT_APP_SUSPEND event.Quote:Originally posted by flarb
Granted, the static control is pretty useless as it is, so I just wrote my own replacement control. Chances are, I won't use statics anymore in future projects. hmm, that sounds interesting ... since my application just seems to keep growing and growing, I worry about "replacing" controls already provided by BREW (even when they suck). Just out of curiousity, how big is your replacement control, and does it provide all/most of the functionality of the original? Gee, maybe you could have a little side business selling replacement BREW controls :)

Quote:Originally posted by flarb
Granted, the static control is pretty useless as it is, so I just wrote my own replacement control. Chances are, I won't use statics anymore in future projects.
After seeing posts where people were using the static control, I was about to ask if anyone else wrote their own replacement. Glad to know i'm not the only one who thought it was worth the effort.
I recently noticed something odd about the static control. The docs for all versions of BREW say that ST_NOSCROLL does not yet enable manual scrolling, and the 2.0 emulator reflects this behavior (it doesn't allow manual scrolling). However, it does seem to work properly on the handsets. Am i hallucinating or can anyone else verify this?

Quote:Originally posted by flarb
Granted, the static control is pretty useless as it is, so I just wrote my own replacement control. Chances are, I won't use statics anymore in future projects.
After seeing posts where people were using the static control, I was about to ask if anyone else wrote their own replacement. Glad to know i'm not the only one who thought it was worth the effort.
I recently noticed something odd about the static control. The docs for all versions of BREW say that ST_NOSCROLL does not yet enable manual scrolling, and the 2.0 emulator reflects this behavior (it doesn't allow manual scrolling). However, it does seem to work properly on the handsets. Am i hallucinating or can anyone else verify this?

Yeah I'm pretty sure it works, you're not hallucinating.
Another good thing about writing your own GUI controls is that you can maintain a consistent look going from BREW to Java--that is, if you write the same controls for both.
J2ME is in more desperate need of new controls though--the rest of the BREW GUI isn't so bad. I'll probably replace the rest of the controls one by one with each project, though.
I just wish Qualcomm would make a useful and GOOD LOOKING GUI for the next release of BREW. It's just downright weird how you can change the colors and stuff on a menu, but not on a static. What, did they not think of it?

Yeah I'm pretty sure it works, you're not hallucinating.
Another good thing about writing your own GUI controls is that you can maintain a consistent look going from BREW to Java--that is, if you write the same controls for both.
J2ME is in more desperate need of new controls though--the rest of the BREW GUI isn't so bad. I'll probably replace the rest of the controls one by one with each project, though.
I just wish Qualcomm would make a useful and GOOD LOOKING GUI for the next release of BREW. It's just downright weird how you can change the colors and stuff on a menu, but not on a static. What, did they not think of it?

Yeah, it's unfortuate, but it doesn't bother me all that much... As you yourself know, game developers usually have to write a custom gui.
I remember a guy who insisted that his game gui be customized from Windows visual controls (i think left Microsoft to start this game company) and gave a talk at GDC about it. He went through a heckuva lot of contortions to make it work because Windows controls weren't designed to make a game gui. I thought it would have been faster to write one from scratch, but he was using this gui to differentiate his game from others ("overlapping windows!"). If you know who i'm talking about, you can google his name and find an interview with his blurb about it.
I wish there were better fonts available, but if i was using a bitmap font on J2ME and fitting it in a 50K jar, then i might as well use bitmaps on BREW. But I'm starting to wonder if the BREW handsets are a bit underpowered compared to the J2ME ones, so maybe it's less feasible.

Yeah, it's unfortuate, but it doesn't bother me all that much... As you yourself know, game developers usually have to write a custom gui.
I remember a guy who insisted that his game gui be customized from Windows visual controls (i think left Microsoft to start this game company) and gave a talk at GDC about it. He went through a heckuva lot of contortions to make it work because Windows controls weren't designed to make a game gui. I thought it would have been faster to write one from scratch, but he was using this gui to differentiate his game from others ("overlapping windows!"). If you know who i'm talking about, you can google his name and find an interview with his blurb about it.
I wish there were better fonts available, but if i was using a bitmap font on J2ME and fitting it in a 50K jar, then i might as well use bitmaps on BREW. But I'm starting to wonder if the BREW handsets are a bit underpowered compared to the J2ME ones, so maybe it's less feasible.

Well, I don't like to use bitmap fonts because it's harder to support other languages, namely Korean. If you don't care about foreign markets, then bitmap fonts are ok I guess. However, the blt speed on these phones is so slow, I wouldn't recommend it for performance-critical text.

Well, I don't like to use bitmap fonts because it's harder to support other languages, namely Korean. If you don't care about foreign markets, then bitmap fonts are ok I guess. However, the blt speed on these phones is so slow, I wouldn't recommend it for performance-critical text.