Yes, it's frustrating. Especially if you're trying to add compatibility between Sony/Palm and orientation support. It seems like there was a lack of communication when all these hi-res devices started coming out.
What I don't understand about you code is when you say "My app doesn't use forms, well not really at least." If you aren't initializing and drawing a form to begin with I'm not sure how FrmSetDIAPolicyAttr will act. Even if the form is 100% blank, you should initialize and draw one. Not doing so should cause errors on the Simulator. Also, when you're using a form, be sure to catch the winDisplayChangedEvent and update the bounds of the form to the extent of the display. If you don't use forms, it's likely that this is what is causing the funny behavior of the input area. -- Tim Kostka http://www.nuprograms.com "Caspar Heiden, vd" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] I've been using the code of SampleCollapse (don't even remember where I got it from, PalmOne, PalmSource, ...) in my own project and it's driving me insane. _Insane_, I tell you. I don't even think I can describe everything in one post. But let's get started by explaining a few things. My app doesn't use forms, well not really at least. Originally a single form was made at runtime with FrmNewForm. We have our own graphics buffer that we blit to the screen with WinDrawBitmap every N ticks. I want the Input Area to 'go down' when the app starts and the slider is down but then, when the user chooses to make the input area go back up again, he or she should be able to. Now, making the Input Area go down is no problem, I call CollapseSetState with collapseStateDown as the second argument, and the screen gets it's maximum size. But whenever I push the 'pinInputTrigger' to make it go back up again, it goes up only to go back down immediately afterwards. I tried putting another call to CollapseSetState (with collapseStateUser as the second argument) at different places in my code, but to no avail. Somehow, I got it to work in the SampleCollapse code by calling CollapseSetState after a frmOpenEvent. First time with collapseStateDown, next times with collapseStateUser. But in my code I don't really have frmOpenEvents... I tried to change the situation by working with two different screens, a Splashscreen (which simply has a FRMBITMAP on it) and a main form in which all the blitting is done. Both forms were 'prefabricated' in PilRC and are initiated in the 'proper' way with FrmGotoForm and 'proper' event handlers, in which I respond to the frmOpenEvents with calls to CollapseSetState as described above. With the Splash screen all is OK (Screen gets maxed / Input Area goes down) but with the Main Form a lot goes wrong. Now I have to say, I'm working with existing code that is quite complex (read: messy) but one thing I can't explain is that the 'pinInputTrigger' is 'greyed out', while during the call to CollapseSetState, API function PINSetInputTriggerState is called with argument pinInputTriggerEnabled. Could someone shine some light on this? Thanks & regards, Caspar -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
