On Fri, Oct 25, 2002 at 11:56:49AM -0700, Eric J Schwertfeger wrote: > > This is a known issue that I came across myself. The thing is that > > according to Palm, it's the volumeRef value that should be used to > > identify which VFS media a file lives on. Since the Handera 330 was > > developed before this rule was established, the device doesn't follow > > it. Infact, from a program level, if a file exists on either SD or CF, > > it'll always respond with the same volumeRef. > > Ick. I know, the HandEra (and TRGPro) broke a lot of ground, but they're > getting punished for it now.
Regardless, I think Handera did a MUCH better job than sony did on the hires api. > have preferred something closer to the HandEra API, hope that if/when Palm > adopts a jogwheel API that they at least don't take Sony's unaltered). OTOH, I think that sony did a better job than handera on the jogdial :) Partially because it supports more ways of interfacing with the program. Also, becuase they encoded the events as additional 'hardware buttons' and simply extended the api. Handera on the other hand started with the right idea, but the push-in and back buttons could have been clearer. Don't get my started on the Treo's pseudo-jogwheel. As far as I can tell, the up and down LITERALLY mimic the hardware up and down buttons, etc. > If it's not too much code-bloat, sure, but I honestly think that most > people with both slots in use are going to have one slot a > modem/WiFi/serial port, rather than having a memory card in both. Judging from Mike's proposed fix, in theory it should be fairly minor :) > I only know of one other PalmOS PDA that can have more than one > memory card, and that's the Dana AlphaSmart, which will probably > have an even smaller marketshare than the HandEra 330. Ofcourse, Alphasmart's Dana had a hand (from what I read) in development from the team that worked on Handera, so hopefully they followed a similar path. > > > Aside from these two quirks and a few forms that aren't getting rescaled, > > > > Another known issue. (See hires.plkr.org for a list of all known > > issues:) .. Part of the problem is that I didn't have time to go > > through and nativly port each form over to a 240-wide screen. I COULD > > use handera's built in app to resize forms properly, but that function > > isn't all that bright when it comes to images. > > So use it for the forms that don't use bitmaps :-) Well, personally I prefer consistency over convenience. If I were to use the function to resize a form, and an image is injected in there later it'll end up looking off/broken. I'd like to re-use as much code as I can, but I'm still debating with myself on how to do this. :) I would encourage you to checkout the cvs and have a whack at it. Having another developer with handera expereince would alteast get this issue resolved quicker. > I'm a firm believer in letting people that do good work know it. When I > get around to releasing the software I'm working on (yes, yet *ANOTHER* > calculator, among other things :-) I'd say that as long as I've got a > day-job that pays as well as the one I've got now, I'd rather know I'm > appreciated than get a trickle of extra money. Doesn't mean that I don't > register my software, but for Open Source stuff, the feedback is usually > the only compensation, and usually as well deserved. Oh, I completly agree. That's why I was a little dissapointed when slashdot didn't post the story of 1.2 being released. I was planning on taking a screenshot and framing it. Even if it didn't have my name _right_there_, atleast I can say that I had a part in it :) -- Adam McDaniel Array.org Calgary, AB, Canada
msg03787/pgp00000.pgp
Description: PGP signature
