However I was plagued with device specific issues for other machines (Garmin, Clie, ...)
As the DIA support is a minor part of the application I decided to use someone else
code to handle the multi device issues and went to palmresize.
The problem is always present and I do know that it is caused by palmresize initialization
of hires support for clie. What happens is that lines (as drawn by standard WinDrawLine) are drawn
in the correct coordinate system (standard) but with half width (half coordinate width == 1 pixel)
which means that lines that should be adjacent are separated by one blank pixel.
I assume I have to use some sony API or other to correct this but as I cannot read the sdk doc
I am stuck. It looks like the hires support in sony machine is quite different from what is implemented
in later standard palm APIs
Benoit
Brandon Roberson wrote:
On Thu, 24 Feb 2005 22:34:44 +0900, Benoit Cerrina <[EMAIL PROTECTED]> wrote:
When I use the palmresize code I can see that the DIA area is drawn in
higher resolution and so are the standard buttons. But also my lines
which are drawn with pixel which are half a coordinate wide.
This means that I now see 4 different lines instead of one thicker line.
Is this something that occurs during a redraw when the DIA is raised and lowered, or is this the effect of merely having the palmresize code present in the application?
If it's a problem all the time, related to the presence of palmresize, its likely that palmresize is doing something odd with the hi-res mode initialization (possibly telling Sony devices to use the wrong coordinate system or something).
If its only present during DIA/Virtual Silk Screen manipulation, then you might want to dig deeper into what happens when the resize code redraws/moves a bitmap.
I'm using my own set of code that's structured more like the SampleCollapse demo from the PalmSource knowledge base -- specifically, I provide my library a callback function to handle resizing/relocating form elements as needed, using functions provided by the library to simpify things, and offsets that the library calculates for me. That sort of architecture would give you the ability to define a custom function for resizing your bitmap that could process the bitmap stroke by stroke, working from the information used to create the on-screen display of the character, rather than simply manipulating the display. If you ever decide to anti-alias these strokes, you'll need something like that in place anyway.
The most likely scenario, however, is that you're not resizing anything - you're just making the bitmap "canvas" bigger, but not stretching/shrinking the image its displaying. In that case, I don't see any reason for the display to get messed up on resize. If you're just relocating the bitmap on the form, not resizing it, the same should apply.
I don't know if these musings help at all... Maybe more info about when the problem shows up would help? *shrug*
Good luck! Brandon
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
