Ok, got the file thanks
Question, the field called rate which is of type char, it is just a char of
the exact rate right? So if the rate is 28.234 it will say "28.234" in
chars right?
what is the SecurityID?
How do I know the currency that this person is tracking securities in?
Chris
At 01:17 PM 9/7/1999 -0400, you wrote:
>While I agree with you in general, let me disagree on this particular one.
>ScrDisplayMode may have been put there with a good intention and for proper
>reasons, but while I have to do the rest of the job myself with the
>registers and *not* using the standard API it does not make much sense. I do
>not know if you should blame me for not using something that's done by half,
>but doing it from as low as I can myself. Either approach has its drawbacks.
>
>The example maybe isn't the best approach for display mode change, but it
>shows several things that I think may be useful, like where and how to
>allocate screen buffer.
>
>The upcoming grayscale API from Palm Computing is something different and
>good to hear about. I would gladly stick to it if it provides me with what I
>need for my projects.
>
>I only wonder what these of us who can't attend PalmSource (something makes
>me think this is the majority of the forum) should do...
>
>Just my two cents...
>Bobby
>
>-----Original Message-----
>From: David Fedor <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>Date: Tuesday, September 07, 1999 12:30 PM
>Subject: Re: EZ Grayscale Palette register
>
>
> >As I just now posted to a different thread, don't just go slamming the
> >processor around without doing OS and processor checks first. Otherwise
> >you risk looking silly when a future OS revision or new hardware
> >demonstrates problems with your method that you couldn't know about yet.
> >
> >The code you just posted to switch back to one-bit mode is particularly a
> >bad idea, since there's an OS trap to do it the right way:
> >ScrDisplayMode(). Less code, guaranteed compatibility, how can you lose?
> >
> >And what if the system doesn't support one-bit mode? Serious shooting
> >yourself in the foot if you use that hacky code. ScrDisplayMode lets you
> >just go back to the default mode - a much, much better idea.
> >
> >I wonder how many times I'll have to post things like this, before people
> >start remembering to do it. Perhaps some folks just will have to learn the
> >hard and embarassing way. Sigh.
> >
> >-David Fedor
> >Palm Developer Support
> >
> >
> >Here's the text from the Knowledgebase.
> >
> >
> > How do I determine which processor is on the device?
> >
> > The feature manager will tell you.
> >
> > Call FtrGet to get the sysFtrNumProcessorID feature. Mask the
> >returned value with
> > sysFtrNumProcessorMask, and the result will be any of
> >
> > sysFtrNumProcessor328 - the original Motorola 68328
>(Dragonball)
> > sysFtrNumProcessorEZ - the Motorola 68EZ328 (Dragonball EZ)
> > other values - for other processors which might be used in
> >Palm Computing platform
> > organizers in the future.
> >
> > These values are defined in the 3.1 SDK. In case you don't have the
> >3.1 sdk yet, here are the
> > definitions:
> >
> > #define sysFtrNumProcessorID 2 // 0xMMMMRRRR, where MMMM is the
> >processor model and
> > RRRR is the revision.
> > #define sysFtrNumProcessorMask 0xFFFF0000 // Mask to obtain
> >processor model
> > #define sysFtrNumProcessor328 0x00010000 // Motorola 68328
>(Dragonball)
> > #define sysFtrNumProcessorEZ 0x00020000 // Motorola 68EZ328
> >(Dragonball EZ)
> > #define sysFtrNumProductID sysFtrNumProcessorID // old (obsolete)
> >define
> >
> > You can ask the system for this feature on any version of Palm OS.
> >
> >
> >
---
Christian Vandendorpe ([EMAIL PROTECTED])
http://www.zorglub.com
