Re: unsupported international call
I am developing an application and testing it on the emulator. I am getting the weird (at least to me) error message "unsupported international call" when executing: err =3D TxtConvertEncoding( true, NULL, (Char*)s, &lenSrc, //CHAR_ENCODING_VALUE(encoding), LmGlueGetSystemLocale(NULL), NULL, // just return the size &lenDst, charEncodingUTF8, "?", 1 ); Has anybody a clue on what it could be due and how fix it? What version of the OS are you running with the Emulator? It sounds like something < 4.0. TxtConvertEncoding was added in Palm OS 4.0. If you use TxtGlueConvertEncoding then you still do conversions on Sony Japanese devices built with Palm OS 3.5, but only between Shift-JIS and UCS-2, not UTF-8. If you need to run on Latin-based pre-4.0 devices, I'd suggest creating your own hard-coded conversion from CP1252 to UTF-8, which wouldn't be hard. If you also have to work with Japanese & 3.5, then you could use the glue and subsequently convert UCS-2 to UTF-8, which is easy. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: FEP problem
I am writing custom text control and I want to use FEP in it. But I think I found a problem with APIs. First I call TsmLibFepOpen to get pointer to TsmFepStatusType structure. Then I can use that pointer normally. But when FEP library decide to show popup list it stops working normally, items in list are not drawn correctly. FEP library has its own event loop and call SysHandleEvent in it. Then SysHandleEvent calls TsmHandleEvent which call TsmLibFepMapEvent. That's ok but TsmLibFepMapEvent wants TsmFepStatusType as parameter and TsmHandleEvent gets one from system globals to call TsmLibFepMapEvent. And this is the problem. FEP library is trying to handle event with TsmFepStatusType structure that is in system globals, but not with mine structure. Any suggestions for workaround this problem. Or may be there is some useful API that solves it. What version(s) of the OS are you targeting? -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: overlay spec, SDK-4
1. Where in the docs is the format for the overlay headers documented?
Don't know what you mean by "overlay header". Overlays are regular
PRCs with a specific type ('ovly') and a special resource
('ovly'=1000). The creator for the overlay PRC has to match the base
PRC, and the contents of the 'ovly'=1000 resouce need to be in sync
with the resources found in the base PRC.
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
Re: DataMgr.c, Line:7649, Overlay without a base
i am using metrowerks codewarrior 9.3 and palmos emulator 3.5 with debug rom of m505 sometimes when i want to debug my application the emulator crashes immediately with following error The Emulator crashes, or just logs a fatal alert? There's a big difference. 0.000: === WARNING: 0.000: === WARNING: Date & Time (4.0) called SysFatalAlert with the message: "DataMgr.c, Line:7649, Overlay without a base". 0.000: === WARNING: the mentioned application is built-in. but i would like to know if this can be caused by my application or if it is any known problem with m505rom and/or emulator? and if it is my error, can someone point me to possible cause? I haven't heard of this error showing up before, which makes it more likely that it's a problem triggered by your application. This non-fatal alert is displayed if DmGet1Resource is called, it's searching the list of open resource databases, and it finds an auto-opened overlay PRC in the list without a base PRC immediately following it. I don't see any obvious way this could happen, other than the typical hand-waving explanation of "memory got munged". -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Converting a string into UTF-8
I need to convert a string from the default encoding used by the OS to UTF-8 for delivering to the external. How can I do it? Is there a system API for it (sorry, but I could not find it)? If not, is there any code snippet for it? First, a general comment that most routines for direct text manipulation are either in the String Mgr or the Text Mgr, so that's where you'd want to start looking. Second, a comment on the code Greg posted...you'll need to use LmGlueGetSystemLocale(), since LmGetSystemLocale was added in 6.0. Finally, there are two other reasons for the existence of TxtGlueConvertEncoding beyond backwards compatibility to 3.5. It also works around a bug in the Sony 3.5 implementation of this routine, and it allows you to pass the charEncodingDstBestFitFlag in with the destination encoding without having to check which OS version supports this flag. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Using Hebrew fonts on Palm Os Developer suite
I believe that you have to do nothing, just enter the Hebrew text. Since the Palm device has Hebrew support, the default fonts should be able to show Hebrew. A problem here is that PORE & PalmRC don't "know" about the character encoding used by 3rd party hacks to support Hebrew. So PORE can't be used to do WYSIWYG editing, and PalmRC can't calculate menu and popup trigger widths correctly. I believe Pilrc has some support for Hebrew. -- Ken "Udi Kobi" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >I need to know how to use hebrew fonts for buttons, menues, etc. under the Palm Os Developer suite, so once I installed the complied application to the already hebrew installed Palm device, > I will be able to view those fonts. -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: How To Make A Custom Japanese Font?
I was already thinking about this after
examining the Font.c and the private header.
Here is what I think:
1. The fontMap is contracted on the fly.
2. A fake subfont featuring few unused
"character codes" is added to the system.
3. On a first run we run a "calibration loop"
- set the starting subfont index to 0 and create
the master font and the subfont; call
CharWidth() for say 3 or 30 (no matter) of the
unused chars; on !=expected widths - undefined
the two fonts, increase the subfont index; do it
again until success.
Should take a up to a second to calibrate the
font. May even calibrate it on every run if this
is fast enough.
What do you think about this?
If you are trying to determine the maximum in use
subfont index, then (if I understand your code
correctly) you are relying on the OS handing an
invalid subfont index properly. I don't know
whether this is true for all versions of the OS.
Another approach (I think) would be to call
FntGetFontPtr for the four standard fonts. By
checking the bits in the header, you can verify
that it's a font map. If so, you can walk the
data to determine the subfont indexes that are
actually in use, and thus determine the maximum
value. And then continue with your idea for
creating the font map on the fly.
I have one more question Äì is there a decent
way to extract all the printable char codes on a
Japanese device? To clarify Äúall the
printableÄù I mean all the char codes that are
in the hierarchical ÄústdFontÄù and need to be
in my replacement font for the replacement to be
valid?
There's not an existing API, unfortunately.
One approach I've used is to first draw (to an
offscreen bitmap) a character that I know is
undefined (but valid), and record the resulting
bits. Then go into a loop like:
for (uint16_t i = 0; i < 0x; i++)
{
if (TxtCharIsValid(i))
{
Draw the character into another offscreen bitmap
Compare to the "known" undefined bitmap
}
}
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
Re: How To Make A Custom Japanese Font?
As the title says - the need is to make a custom Japanese font, just for with smaller characters then the std one in the CLIEs. The ideal case will be to be able to install it in the device and activate it with FntSetFont() and use it like a custom font on a Latin based device. The worst scenario will be total custom drawing, which considered that the whole app is a total custom drawing is not that bad. But if the overhead can be avoided, I'd gladly do so. A little help in the structure of the main font if the hiearchy and how is a sub-font accessed, at least? Unfortunately there's no reliable way to use FntDefineFont to define a Japanese (ie hierarchical) font. The problem is that sub-fonts are referenced from the top-level font (which is actually a font map) via absolute subfont indexes. So the correct index to use depends on what's been previously installed by the OS. Which means your most compatible approach is to define your own set of "sub-fonts", where you parse the text and select the appropriate sub-font to use using the high byte of the double-byte character, and then you draw the low byte. This does mean that you'll have to manage dynamically installing the required sub-font(s) yourself. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: multilizer - localization
Thanks, Ken. One more thing i am wondering is: when multilizer do translation directly in PRC file, is it also smart enough to re-size and re-position UI controls (like button) if the translated string/label is too long to fit the original control? Their latest version has some support for UI resizing, but I don't know if it's automatic or not. I just downloaded 6.1, but I haven't tried it out yet. What strategy you recommend for localization? Depends on lots of factors. If Multilizer really worked, and you could afford it, then that would be my recommendation. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: SMS & Unicode
Does PalmOS phone library support unicode SMS messages? Does PalmOne SMS libray support them? I tried to use the SMS bundled application on a T|T to receive a message that is known to be in unicode from an GSM phone and it just ignored it! The 5.x platform telephony libraries do support Unicode (UCS-2) in SMS messages. I don't know if these libraries are used by the T|T, or if it has a replacement set from a 3rd party. Also note that any non-convertible Unicode character (ie anything not found in Windows code page 1252) will get mapped to either a '?' or perhaps nothing, depending on the version of the library. So if you received a Chinese message, for example, on an English T|T then you might not wind up with anything being displayed. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: multilizer - localization
i know multilizer can do the translation inside PRC file. Does anybody know if multilizer can also do the translation for .rcp file? I don't believe so. They can handle XML (XRD) files, from what I've heard. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Date formats
I was just wondering how most Palm developers deal with formatting dates. I know PalmSource suggests using the user's choice from the Preference panel for date format, Yes - I'd say "strongly suggests". but I don't think that is an option as it is missing ISO format By this you mean -MM-DD, right? As in 2004-12-24. and thus the locale defaults are thus bunk in a lot of cases. You mean for many locales the preferred date format for most people is ISO? I hadn't heard that...could you point me to some place that documents this? Thanks, -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: fonts txt
with much luck i was able to compile the app but the fonts are not anti aliased any 1 knows any fonts program that allows anti alias? i tried xFont and piBuilder already, any others? Anti-aliased fonts aren't supported directly by Palm OS. When you see various programs such as book readers displaying anti-aliased text, they are using their own private drawing routines. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: TxtCharIsHardKey - Error in Palm OS Reference.pdf?
The Palm OS Reference states that; "TxtCharIsHardKey Macro is valid only if International Feature Set is present". I believe that is incorrect, and causes confusion. It is a simple macro that does not use any TxtManager function, and works with any OS. I believe I once saw a Post about this. Please correct me if I am wrong. I agree that the documentation is wrong. This macro was added to the headers when international support was added to the OS, way back in Palm OS 3.1 days, so that's why I think it was flagged as such, since all of the new TxtXXX functions did in fact need this warning. Note that the TxtCharIsVirtual() macro is different, in that you need to use the glue version on versions of the OS < 3.5. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Graffite gets locked
I am facing one issue in my Palm App. I am working with Palm Zire 72 (simplified Chinese version). I have one edit box on my screen, which takes input as integer only(0,9). After using the application extensively , my graffiti area is getting locked, I am not able to enter any character's any more. Note: I have tried adding character by writing on the display area also. Can any body please give me any clue , why it is behaving so. Is their any feature which does that. I don't believe palmOne released a Chinese Zire 72 device. Which means that you're using an English Zire 72 with a 3rd party hack to support Simplified Chinese. I would contact the maker of this software to find out if they know of any such problems. Also, you asked: I had observed one feature in chinese devices " it allows to write on the screen area along with the numpad(grapffite area for writing no and characters.) i.e. like a touch pad i can directly go to the editboc in the screen and start writing. applciation displays some chinese characters in the box. I do not want to allow user to write directly on the screen area. I want to support grffite feature only in the area below the screen. (Input Area from where num pad can be opened) If you can write Chinese characters on the screen, then this is also something added by the 3rd party hack, so you'd also want to ask them this question directly. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: How can I force Palm OS to use single byte text encoding?
Hi Clive, > But I'm curious why an assumption like this (1 byte =3D=3D 1 character) > would simplify your record packing problem. It is not the "coding" that concerns me, it is the storage. I have to pack a huge amount of data into the Palm. Unless I am= fundamentally mistaken, double byte characters will require twice as much storage per string as single byte= characters. I think maybe there is a fundamental misconception here. A "double-byte" encoding such as Shift-JIS is more accurately described as a "mixed-width" encoding, where every character occupies either one OR two bytes in a string. So the "twice as much storage" requirement only exists if the character in fact actually needs two bytes to represent it (as is the case for Kanji, Hiragana, full-width Katakana, etc). -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: How can I force Palm OS to use single byte text encoding?
Hi Clive, From Manual: "Because you do not know which character encoding is used until runtime, you should never make an assumption about the size of a character." I am developing an application that will require me to pack a lot of data into a Palm. I will have to pack multiple custom records inside each Palm record. Both for overall storage data packing and for setting custom record offsets etc. how can I force the Palm (Zire 31) to use single byte characters? It is a custom "read only"/"U.S. only" application. If you only have low-ASCII text, then you can assume that each character will occupy only a single byte, even on non-US devices. If you have to handle accented characters, for example, then currently on a US-device the same will be true, but this isn't a safe assumption to make in the future. But I'm curious why an assumption like this (1 byte == 1 character) would simplify your record packing problem. Even for multi-byte characters, lengths of strings are still in terms of bytes, and typically field lengths (or fixed sizes) are in terms of bytes, so where is the win? Thanks, -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Incorrect PRC file ?
With PRC explorer (v1.0.19.1), I clearly see the 24 bitmaps that I declared in my app. They are named Tbmp 9 to Tbmp 32. They can be displayed => ok. I have 2 additional Tbmps, named Tbmp 1 and Tbmp 2. Tbmp 1 : when I click on it, I get message "TBitmap parsing error - unknown version", and it displays "Resource size 72292 bytes" Tbmp 2 : when I click on it, I get another message "TBitmap parsing error - wrong size", and it displays "Resource size 19266 bytes" Wild guess - these aren't actually bitmaps, but rather code/data. I don't know anything about CaslSoft, though, so I couldn't guess at how this might be happening. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Chinese Character Recognition
See if you can help me out with this one. I need to write an application (its like a form) where the user will type in Chinese and the characters need to be displayed in the text fields of the form. Basically I am looking at Chinese handwriting recognition. All Chinese solutions for Palm OS have methods for entering Chinese text. The base platform from PalmSource (for Simplified Chinese) has a pinyin FEP, which converts ASCII text into Hanzi. Other 3rd party solutions (overlays) typically have both FEPs and handwriting recognizers. This should be all you need, unless your application needs to be able to enter/edit/display Chinese on an English device, which is a very different kind of problem. Even then, some 3rd party hacks support running the device w/an English UI, while still supporting Chinese text. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Unicode on palm
Robert asked: Does palm OS support Unicode, if not is there a patch for this. and Ben Combee replied with: Palm OS supports multibyte characters sets on devices with the appropriate locale, such as Japanese and Chinese devices. There's an extensive Text Manager API for handling this. However, the OS doesn't natively use double-byte characters, although there is a transcoding function. Actually the OS does natively use double-byte characters, when the device character encoding is Shift-JIS (Japanese), GB (Simplified Chinese), Big-5 (Taiwan), or EUC-KR (Korean). Robert's question could be answered two different ways. Without any additional context, it's hard to provide a useful response. But... No, Palm OS does not support using any Unicode transformation (UTF-8, UTF-16, etc) as the device encoding. Yes, Palm OS does support convert text to/from Unicode via the TxtConvertEncoding API. If the goal of using Unicode is to support multi-lingual display, then there are several options that have been discussed on this list in the past - Robert should search the archives. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: TxtGlueParamString on Sony S300
Hi Tom,
Thanks a lot for taking the time to reply, I really appreciate it.
The really strange thing is that on the S300 emlulator, simply
calling TxtParamString seems to work. It's only the Glue version
that crashes. So, based on that, and the information in your post,
this is what I came up with:
Boolean sony_os_35_glue_bug (void) {
Err error;
UInt32 result;
Boolean answer = false;
error = FtrGet(sysFtrCreator, sysFtrNumOEMCompanyID, &result);
if ((error == 0) && (result == hwrOEMCompanyIDSony)) {
error = FtrGet(sysFtrCreator, sysFtrNumROMVersion, &result);
if ((result >= palmos_35) && (result < palmos_40))
answer = true;
}
return answer;
}
Then in my code, I just do this:
if (sony_os_35_glue_bug())
p = TxtParamString(temp, sub[0], sub[1], sub[2], sub[3]);
else
p = TxtGlueParamString(temp, sub[0], sub[1], sub[2], sub[3]);
This seems to work with all the ROMs I can find. Does it make sense
and look OK to you? I'm going to ask the customer to test this
version for me, and if it works OK for him, I'll go ahead and
release it.
Actually all you need is to check if the OS version is less than 3.5,
and if so, call the glue code, otherwise call the routine directly.
It turns out there's a bug in the glue code, where it uses the
(Latin) glue version if the OS version is < 4.0, but the check should
be < 3.5. That's why I thought you needed to handle the Sony/3.5 case
specially, but you don't.
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
Re: TxtGlueParamString on Sony S300
One of our applications needs to use TxtParamString. Since it wasn't
available until OS 3.5, and our app runs on 3.0 or later, we use
TxtGlueParamString instead. It's always worked perfectly, and we've never
had a complaint about it, until yesterday. A customer is running our app on
a Sony S300, which he says is running 3.5.2. When it gets to the
TxtGlueParamString call, it crashes his handheld. Running this in the
CLIEpose emulator (which reports the OS version to be 3.5.1), I am told that
our application:
... is close to overflowing the stack. The functions currently using the
stack are: IntlGetRoutineAddressPatch(0), IntlGetRoutineAddressPatch(10),
IntlGetRoutineAddressPatch(10), IntlGetRoutineAddressPatch(10)
This does not happen on the Palm OS 3.0 or 3.5 emulator, so it seems to
somehow be specific to the S300. If I change the code to call TxtParamString
instead of TxtGlueParamString, it works just fine. But of course, I can't
leave it that way, because we need to support older devices.
The problem is that Sony's 3.5.x ROM has a bug in it. They patched
IntlDisplatch to support the TxtConvertEncoding call needed by their
early release of VFS, but when this patched version is called to
handle IntlGetRoutineAddress(), it calls IntlGetRoutineAddress()
versus the pre-patched version. So you wind up in an infinite loop,
with the patch code calling back into itself, and eventually (OK,
pretty quickly) you wind up overflowing the stack.
We fixed this in TxtGlueConvertEncoding by calling
FtrGet(sysFtrCreator, sysFtrNumOEMCompanyID) when the OS version was
<= 3.5 and < 4.0. If the result is hwrOEMCompanyIDSony, then we know
they did in fact implement TxtConvertEncoding, otherwise it doesn't
exist.
For your case, it's a bit harder if you want to still be able to use
the current glue code. Here's one approach:
#typedef Char* _TxtParamStringF(const Char* iTemplateP, const Char* iParam0,
const Char* iParam1, const Char* iParam2,
const Char* iParam3);
typedef _TxtParamStringF * TxtParamStringF;
MyTxtParamString(const Char* iTemplateP, const Char* iParam0,
const Char* iParam1, const Char* iParam2,
const Char* iParam3)
{
If (BuggySonyV35())
{
TxtParamStringF* procP;
procP = (TxtParamStringF*)TxtLatinParamString;
return(proc(const Char* iTemplateP, const Char* iParam0,
const Char* iParam1, const Char* iParam2,
const Char* iParam3));
}
else
{
return(TxtGlueParamString(const Char* iTemplateP,
const Char* iParam0,
const Char* iParam1, const Char* iParam2,
const Char* iParam3);
}
}
I found this post in the archives, from April 2000:
http://news.palmos.com/read/messages?id=7599#7599
which mentions problems with PalmOSGlue, though not exactly the same issue,
so I'm not sure it's relevant. (Ken Krugler, if you're reading this, did
this problem ever get resolved?)
I'll check. But I don't believe it's related.
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
Re: database sorting is wrong
i'm writing a simple application that inserts records into a
database, sorted according to date (a UInt32). my compare function
is simple:
static Int16 mycompare(dbrecord *dbr1, dbrecord *dbr2, Int16
arbitrary, SortRecordInfoPtr r1info, SortRecordInfoPtr r2info,
MemHandle appinfo)
{
return (dbr1->date - dbr2->date);
}
My guess is that something else is going wrong, but you also need to
fix your comparison code. Whenever you're sorting unsigned values,
you don't want to rely on straight subtraction. Instead you'd do
something like:
if (dbr1->date < dbr2->date) {
return(-1);
} else if (dbr1->date > dbr2->date) {
return(1);
} else {
return(0);
}
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
Re: T5 memory leak in FntDefineFont
the crash happens with FntDefineFont(id, NULL) in the 5.4 simulator from palmsource.com OK, I'll look into that. You should also report it as a bug to PalmSource. the leak is in the real T5 unit being sold and this simulator. By "this simulator" I assume you mean the 5.4 version from PalmSource, not the T5 version from palmOne. If so, then also report this as a bug to PalmSource. Thanks, -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: T5 memory leak in FntDefineFont
so to whom do I report the leak since its in the T5 device being sold in stores ? Since you haven't narrowed down whether it's a bug in the palmOne modified OS, or the base 5.4, then I guess you need to report it to both palmOne and PalmSource. If you get a leak with the standard 5.4 Simulator then you'd only report it to PalmSource. If the leak doesn't happen in this version of PalmSim, but only with the special T5 version, then you'd only report it to palmOne. Also, I'm still interested in an answer to my question about a better description of the crash that occurs when you call FntDefineFont(id, NULL). Thanks, -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: T5 memory leak in FntDefineFont
I tried this, but it crashes, How does it crash? Is this on the T5 simulator? and the manual says: ""Palm OS 4.0 and later do not allow a NULL value for the fontP parameter"" That's because of a bug in FntDefineFont, which was introduced in Palm OS 5.0, and fixed in Palm OS 5.3 (or maybe earlier...the bug fix was made on 1/15/03). So you should be able to safely call it when running with Palm OS 5.4/T5. I took at look at the source, and didn't see any obvious problems. I'll need to check if palmOne is patching this routine for some reason, as that could be where it's crashing. -- Ken - Original Message - From: "Ken Krugler" <[EMAIL PROTECTED]> To: "Palm Developer Forum" <[EMAIL PROTECTED]> Sent: Friday, November 05, 2004 9:46 AM Subject: Re: T5 memory leak in FntDefineFont >Has anyone found a work around for this memory leak ? > >In the T5 simulator and the actual unit, the function: >void FntDefineFont(fontID id, FontTag *pTag) >appears to have a memory leak, about 80% of the size of the >font being passed in, who should I report this to ?I'm not aware of any >API to >recover this, it is not a leak in any other OS 3.0, 4.0 or 5.0 units or >emulators/simulators. What happens if you call FntDefineFont(id, NULL) to clear out the font? I know that PACE used to have some code to release the shadow of the font when you did this. One warning is that passing NULL would trigger an error (and potentially give you invalid results) on Palm OS 4.0, 4.1, and perhaps early 5.x releases. > -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: T5 memory leak in FntDefineFont
Has anyone found a work around for this memory leak ? In the T5 simulator and the actual unit, the function: void FntDefineFont(fontID id, FontTag *pTag) appears to have a memory leak, about 80% of the size of the font being passed in, who should I report this to ?I'm not aware of any API to recover this, it is not a leak in any other OS 3.0, 4.0 or 5.0 units or emulators/simulators. What happens if you call FntDefineFont(id, NULL) to clear out the font? I know that PACE used to have some code to release the shadow of the font when you did this. One warning is that passing NULL would trigger an error (and potentially give you invalid results) on Palm OS 4.0, 4.1, and perhaps early 5.x releases. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: problem in displaying chinese characters correctly
Now that I am able to copy and paste Chinese text from Notepad into constructor 1.9 on Windows Xp. When I run the Chinese prc on a Palm Zire 71 with CKJ OS Ver 4.61 installed, on some of the buttons on the forms I see correct Chinese text but on some other buttons I see wierd latin characters. Palm is not able to display these chinese characters correctly. I have also verfied the hex codes for all the characters, the hex codes are correct. On CJKOS I have set Char Set to "Chinese BIG5" and display to "Auto". Should the Palm be told how to correctly display these characters? I am not sure how to do that. Given below are examples of text which are displayed correctly and some text which is not displayed correctly. and also... Does any one know how to force Palm OS not to use single byte encoding. It is displaying Chinese characters incorrectly if the hex value of any of two bytes is less than A0, in this case it is displaying latin characters equivalent of the hex value. If both the bytes have a hex value greater than A0, then the chinese character is displayed correctly. Does any body know more or how to resolve this. The first problem you've got is a conceptual one. The device you're using (the palmOne Zire 71) has a ROM that only supports the Latin character encoding. You've installed a 3rd party hack (CJKOS) that patches the OS so that the device encoding can now be set to Big-5 (for Traditional Chinese text). So any issues with Chinese text processing need to be directed to the makers of CJKOS. The second problem is that CJKOS apparently only supports Big-5, and not the Hong Kong Supplemental Character Set (HKSCS). Double-byte character codes less than 0xA140 are all part of HKSCS, not the core Big-5 set. I believe the reason why you're seeing Latin characters is that CJKOS (like many other multi-byte hacks) tries to interpret what it considers to be invalid multi-byte sequences as Latin, which improves compatibility with English applications. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Change database name of overlay
1. I have created a French Overlays from a Base English Prc using the following command "PRC2ovl.exe CONFIG.prc -locale frFR -o CONFIG_frFR.prc" 2. After all the changes in french Overlay I have modified the base english PRC database name from CONFIG to PDApp. I have used the following command to change the output file name of french overlay from CONFIG_frFR.prc to PDApp_frFR.prc. "Prc2Ovl CONFIG_frFR.prc -p PDApp.prc -o PDApp_frFR.prc" The above command only changes the file name and not the database name. Is there any command to change the french overlay data base name same as english PRC database name without losing the changes done in french overlay? I don't know of any such command, but it's easy enough to fix up the name of the overlay PRC. Just open it using a binary editor and replace the existing "CONFIG_frFR" with "PDApp_frFR" + a null to keep the name field the same length. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: StrPrintF for wide characters
Is there an equivalent of "StrPrintF" function for wide characters? StrPrintF has supported %lc (and %C) for printing wide characters for quite a long time. Note that it assumes the character uses the device encoding, not Unicode. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Zire 72 sim in chinese
Is simulator for Zire 72 is available in chinese.
I don't think palmOne has released a fully localized Zire 72 for the
Chinese market, so then the answer would be no. If the 3rd party
hacks ("overlays") used to support Chinese on the Z72 were all
written in 68K, then you could just load them onto PalmSim, but I
believe they use ARM code, and thus wouldn't work.
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: Chinese on POSE
Does anybody know how to display chinese on POSE or if there is a
chinese rom file available that I can run on POSE.
I downloaded the ROM from a Chinese Palm to run on POSE, but it doesnot
work on POSE.
I don't believe there's a PalmSource-provided Chinese ROM that you
can use with POSE, since the first platform release w/Chinese support
was 5.3, and POSE only works with 4.x (and older) ROMs.
You didn't say which device you used to download the ROM, but even if
it's based on Palm OS 4.x, if POSE doesn't "know" about that device
then it won't be able to use that ROM for emulation.
You can install 3rd party RAM-based Chinese solutions ("overlays") on
a stock English 4.x ROM, or you can use Simplified Chinese Palm OS
5.3/5.4 with PalmSim.
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: Info reqd regarding creating a chinese prc using Constructor
Hi Chandra, I found your message on the net regarding problems developing a Chinese prc. I am having a similar problem. I have a created a prc file which contains only resource files of my application. I need to create a chinese version of these resources. When I use Constructor 1.9 and Select PRC Text Encoding as (Chinese Simplied) and copy and paste chinese text into forms. All I see are ???s. Are you using the Windows or Mac version? If Windows, what platform (XP, 2000, etc)? I just tried this on Mac OS X 10.3 with Constructor 1.9.1X (from the CodeWarrior 8.3 package) and it worked fine. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: looking for a case-insensitive string search algorithm
Hi Stephen,
Does anyone know of a good way to perform a case-insensitive
search of a large text string for the first occurrence of a small
text string - using code that supports non-ASCII character encodings
(possibly multiple bytes per character) - and which doesn't restrict
matches to beginning at the beginning of a word? (I.e. something
just like TxtFindString() except allowing matches that start one or
more characters past the beginning of a word)
Alternatively, even a case-insensitive version of StrChr() would
be helpful...
Thanks in advance,
Stephen
p.s. no need to point me to approaches that assume ASCII characters,
since I understand case-insensitivity in that context - it's when we
get into alternate character encodings that I don't have a good
grasp of what 'case insensitivity' (or accent insensitivity) might
mean(!).
Normally the default behavior for case-insensitive ("weakly equal" is
a better term) string matching is to treat two characters as being
equal if their primary sort value is the same.
Unfortunately there's no easy way for a Palm application to implement
this, for various reasons. For example, in Japanese you can get
multiple characters (not just multiple bytes) combining to form a
single "sort value" that is then used for comparison purposes. So
even if you wrote code to call TxtCaselessCompare with every valid
code point, and used the resulting ordering, it wouldn't be correct.
If this is critical, then I'd look at the ICU open source code/data
as a starting point, as they've implemented this kind of search
support. But you'd have to convert it to work with device encoding,
as otherwise converting all of the data to Unicode during a search
would make things very slow (unless you can store the data being
searched as UTF-16).
At 12:00am -0700 9/16/04, Veronica Loell wrote:
I can't really see how the meaning of 'case insensitivity' can be
dependent on the character encoding. No matter how an alphabeth is
encoded the mathing characters will be the same. What does make a
difference here is the locale/language, unless you assume that is
decided by the encoding used?
As you move beyond ASCII, the meaning of "weakly equal" expands
significantly. For example, in Japanese you can have a base Hiragana
character such a "ha" followed by a sign-extension (chou-on)
character. This changes the sound of the vowel (makes it long), but
the resulting two characters combine to form a single unit that is
weakly equal to just the base "ha" character, as well as the Katakana
"ha" character, and the single-byte (half-width) "ha" character, etc.
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: CHineese PRC does not work - Urgent Please Help
I have created a sample application, for which i had generated a chinese overlay. Using PRC2OVL? I have added chinese labels in GBK encoding to my PRC, How? By directly editing the Chinese overlay using Constructor? When i am running my application using Chineese Simulator. What version of the Chinese Simulator? 5.3/5.4? It is not showing the chineese Text. What does it show? Are you sure the overlay is getting used? I had also changed PRC encoding option in Constructor to Simplified chineese. Can any body please let me know where i a going wrong. or steps to create Chineese Overlay will also Help. It would be useful to first know what steps you followed to create the overlay that's not working. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
re: Error In TextMgr
thanks, but I not pass 0,
Actually you are passing in 0...see below.
the code is:
//Function search string in description of DB (internal, not GlobalFind )
FilterStock(char * SearchString)
{
char
theSearcht[16]={'\0','\0','\0','\0','\0','\0','\0','\0','\0','\0','\0','\0','\0','\0','\0','\0'};
As Matt noted in his response, this isn't necessary.
int i=0, j=0;
UInt32 posP;
UInt16 length;
Int16 tam;
MemHandle myRecord;
Boolean match=false;
ListType *pList = (ListType*) GetObjectPtr(ConsulStockList);
tam=DmNumRecordsInCategory(ProductosDB,dmAllCategories);
tamliststkfil=0;
StrCopy(theSearch, SearchString); //In the api doc say "The same
text as in inSource ...", its ok?
TxtGluePrepFindString ( SearchString, theSearch, StrLen(theSearch) );
Since you've set theSearch[0] to 0, StrLen(theSearch) is going to return 0.
I believe you want:
TxtGluePrepFindString(SearchString, theSearch, sizeof(theSearch));
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: SysStringByIndex
Hanumanth Rao wrote:
I am using SysStringByIndex()api to get the string from StringList.
>>It is required to give Max string length as a parameter to this.
As Lengths of my string vcaries so much ,I do not want to specify a maximum
length for my destination string.
Can any body please tell me any APi which can be used to get the length of
the string at run time.
You can find this out by parsing the string list yourself. The first 2
bytes of a locked string list resource hold the # of strings in the
list. The remaining bytes hold the list of null terminated strings.
Parsing the string list is a good idea. Note, however, that the very
first thing in the string list resource ('tSTL') is a null-terminated
"prefix" string, followed by the string count. So you have to skip
over the prefix string first, and then the next two bytes (which
contain the count) might not be on a word boundary.
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: Error in TextMgr
I want to find one substring in other, i use TxtFindString, but before i use TxtGluePrepFindString to set the search, the 2 string are same Not sure what this means. but inSource not are the same address as inSource. Same comment as above. When i run with the emulator say this: Filtra (1.0) called SysFatalAlert with the message: "TextMgr.c, Line:945, Dest buffer too small". Any idea? First, whenever you post an error message generated by the OS, it's very useful to include the OS version number, the device's locale (language), and whether you're encountering this with a real device (if so, which one) or POSE/PalmSim. Second, as Gavin noted in his response you'll get this error from Txt[Glue]PrepFindString if the last parameter (iDstSize) is zero. One clarification to what Gavin said - the iDstSize parameter is actually the size of your destination buffer, not the length of the destination string. In other words, the value you pass in should include space for the byte at the end of the destination buffer string. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Unicode
At 12:00am -0700 8/27/04, [EMAIL PROTECTED] wrote: If you want the converted string in any of the formats other than UTF-8, UCS-2, UTF-16LE, or UTF-16BE, you have to do the conversion yourself. Lots of free conversion algorithms are available in the web which can be used for the conversion. At 12:00am -0700 8/27/04, [EMAIL PROTECTED] wrote: I have seen following #defines in Palm Locale.h // Unicode character encodings #define charEncodingUCS2 CHAR_ENCODING_VALUE(9) #define charEncodingUTF8 CHAR_ENCODING_VALUE(6) #define charEncodingUTF7 CHAR_ENCODING_VALUE(24) #define charEncodingUTF16 CHAR_ENCODING_VALUE(75) #define charEncodingUTF16BE CHAR_ENCODING_VALUE(76) #define charEncodingUTF16LE CHAR_ENCODING_VALUE(77) #define charEncodingUTF32 CHAR_ENCODING_VALUE(84) #define charEncodingUTF32BE CHAR_ENCODING_VALUE(85) #define charEncodingUTF32LE CHAR_ENCODING_VALUE(86) #define charEncodingUTF7_IMAP CHAR_ENCODING_VALUE(87) #define charEncodingUCS4 CHAR_ENCODING_VALUE(88) Does this means All theabove types arenot be supported by TxtConvertEncoding Correct - the charEncodingXXX values defined in PalmLocale.h are a larger set than the encodings supported by the device. However Y Rekha's response to your first email was slightly in error. Starting with Palm OS 5.3, the following Unicode encodings are supported: charEncodingUCS2 charEncodingUTF8 UTF16 UTF16LE UTF16BE UTF32 UTF32BE UTF32LE charEncodingUCS4 Also note that the additional encodings (beyond Unicode) supported by a device depend both on the OS version and the device's character encoding. For example, a Japanese device using the PalmShiftJIS character encoding will support conversion to/from Shift-JIS, but that won't be the case for an English device using the PalmLatin character encoding. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strings are always maintained in UTF-8 format while characters are always in 2 bytes?
I read the following on Text Manager and just wondering if this means that "strings are always mainteained in UTF-8 format while characters are always in 2 bytes". No. The encoding for characters in a string is based on the device's character encoding. Currently no device is based on UTF-8 - the set of officially supported character encodings is Latin, Shift-JIS, and EUC-CN (aka GB). "Character variables are always two bytes long. However, when you add a character to a string, the operating system may shrink it down to a single byte if it's a low ASCII character. Thus, any string that you work with may contain a mix of single-byte and multi-byte characters, up to four bytes." Here's an example from what happens on a Japanese device that uses the Shift-JIS character encoding, first using the character 'A' (0x41): WChar myChar = 0x0041; // sizeof(myChar) == 2. UInt16 charSize = TxtSetNextChar(buffer, 0, myChar);// charSize = 1 After the call to TxtSetNextChar, buffer[0] will contain 0x41. Now an example (also using Japanese) of what happens when you set the first character in the buffer string to be a full-width (double-byte) space (0x8140): WChar myChar = 0x8140; // sizeof(myChar) == 2. UInt16 charSize = TxtSetNextChar(buffer, 0, myChar);// charSize = 2 After this call, buffer[0] will contain 0x81, and buffer[1] will contain 0x40. So in a string, a single "character" can occupy one or two bytes when the device's character encoding is Shift-JIS. If and when a device is released that uses UTF-8, each character will occupy between one and four bytes in the string. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: How to display into Uppercase
Iam sorry that not given complate information from my side
earlier .
Iam using PalmOS V5.2 software.
My application is keyboard driver.
This application iam developing for Samsung I530 smart phone.
The driver receives the packet from the Serial port when the key is pressed.
In The packet Specific byte contains the Character to be displayed .
Iam retrieving the character and enqueing in the queue with
EvtEnqueueKey(keyCode,0,0) .
This is displaying the character well on the Memopad in lowercase.
when i select the CAPS key in order to display in Uppercase
iam setting the state with
GrfSetState(capsLock,numLock,tempShift)
capsLock = true
and then enqueing the Characters , but it is not
displaying in the uppercase , it is displaying
in lower case only.
Setting Graffiti flags will normally only affect
the character that Graffiti generates when the
user writes in the input area. Though most
keyboard drivers read these flags to ensure
they're responsive to apps that set these flags
explicitly.
If i set the shift flag then it is displaying in uppercase , with
SHIFT key selection it is displaying in uppercase well.
Iam handing CAPS key also same as like SHIFT key only , but it is
not displaying in uppercase .
Where as if i run the application on Tungsten T2 PDA it is
displaying well in the uppercases .
Samsung I530 & Tungsten T2 PDA are using the same OS version only .
With some apps such as Memo, a keydown event will
be upper-cased if this event causes a new record
to be created. I don't know if this is what
you're seeing when you say that there's a
difference between the Samsung and palmOne
devices. Or maybe Samsung is playing some
interesting games with these flags.
Could you pls help me how to rectify this problem so that i can
display in Uppercase !
I need to display the data in device specific application only
like Memopad or Notepad ...etc .
Is there any special flags to set ?
You need to upper-case the character yourself
before you enqueue it. The right way to handle
this would be something like:
Char srcBuffer[maxCharBytes];
Char dstBuffer[50];
UInt16 offset = 0;
UInt16 srcLength;
UInt16 dstLength = sizeof(dstBuffer);
Err result;
srcLength = TxtSetNextChar(srcBuffer, 0, keyCode);
result = TxtTransliterate(srcBuffer, srcLength,
dstBuffer, &dstLength,
translitOpUpperCase);
ErrNonFatalDisplayIf(result != errNone, "Can't upper-case");
offset = 0;
while (offset < dstLength)
{
WChar curChar;
offset += TxtGetNextChar(dstBuffer, offset, &curChar);
EvtEnqueueKey(curChar, 0, 0);
}
This works even if the result of upper-casing the
text causes expansion, as would be the case (if
this ever gets fixed) of upper-casing a letter
such as ß in Germany (becomes "SS").
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: Is StrCopy Localisation safe?
> >My application will be localized to Spanish, German, French, Simp Chinese >and Italian. >I don't know whether these languages use NUL character or not? > > >Is it optional to use this NUL character or any string in above localized >languages will definately contain NUL character. >I hope u can clear my doubt. You won't have a problem with Spanish, German, French, or Italian. Those all use the standard Latin character set. For Simplified Chinese, the encoding used by Palm OS also doesn't use embedded NUL characters. For more details on character encodings, go to kb.palmsource.com and search > for "encoding". Any character encoding supported by the existing Palm OS API will always treat a NULL byte as an end-of-string. There are wide character encodings, such as UTF-16, where the end-of-string is a 16-bit NULL word, but such an encoding would never work as the device encoding, since all of the existing Palm OS APIs are "narrow" in the sense that they expect a byte stream, versus a 16-bit word stream. The only current Palm OS function that will correctly process a wide encoding is TxtConvertEncoding. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: using a string resource
Use SysStringByIndex() function. The Maximum length of the string that can be stored is 255 characters. If you want to store more than that break it into multiple strings, fetch the strings from the resource using above function and concatenate programmatically. No, the maximum length of any one string in the string list resource is 32767 or 65535 bytes (not characters), depending on whether all of the routines that SysStringByIndex correctly handle UInt16 string lengths. Though you'd also hit the limit of 64K bytes minus a bit for the maximum size of a resource. But in double-checking the code, I noticed there's a separate issue, where the number of strings in a string list resource (modulo 256) must be less than 128 for the routine to work properly. Otherwise the code in SysStringByIndex that calculates the string count won't generate the correct result, due to sign extending the low-order byte. Though this bug will only cause the routine to fail with more than 127 strings if (a) you pass an out-of-bounds index, in which case you'll get back a garbage result versus an empty string, or (b) if you've got more than 255 strings, then the calculated count would wrap around, and you can get an empty string returned even with a valid string index. But having more than 127 strings in a resource is not a great idea anyway. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: TxtConvertEncoding Failing on Cobalt
I am using TxtConvertEncoding function to convert my text buffer from charEncodingUCS2 to system encoding ( ISO-8859-1) on Cobalt. While doing this, sometimes the encoding fails and returns the error value txtErrNoCharMapping. I ORed destination encoding value with charEncodingDstBestFitFlag while calling TxtConvertEncoding, but still that problem is there. Can anyone tell me why I am getting this problem on Cobalt? Thanking you in advance. If your input stream (of UCS-2 encoded Unicode text) contains a character that can't be mapped to the device character encoding, then you'll get the txtErrNoCharMapping result. This will happen even if you specify the best fit flag, as that merely "tries harder" to find an approximate mapping to something in the device encoding (versus an exact, round-trippable mapping). So, for example, if you input text contains a Kanji character, and you're converting to PalmLatin, then there's going to be no possible mapping. Note that when this error is returned, the source offset (an in/out parameter) should be set to the offset of the unmappable character. Also note that if you pass in a substitution string, then you would still get an error returned, but all of the input text will be processed, and any unmappable character will be replaced by the substitution string. And finally, all of this is, or should be, explained by the documentation that is part of the SDK. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Displaying Unicode characters
Where I can find information on how to display/handle unicode characters on Palm OS 5.0+. I know this sounds stupid, but I did not find any useful discussion about this. There was just a thread on this very topic, from about a week ago. Search the archives at the PalmSource web site. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: More font questions
I've written a little Hiragana/Katakana flashcard app and created my own custom kana fonts (from the PD Kana/Kanji fonts used by JWPce, etc). However, I'm looking to add some more functionality and am reworking my character/font processing. I'm a little confused by the Palm (and tools) font support. Rather than do something arbitrary, I'd like to create a Unicode font that contains the Latin and kana codepoints (maybe adding some kanji later). However, it doesn't look practical to do this as the Palm font format doesn't support sparse fonts (yes, I know it allows for sparse glyphs/images, but the font bitmap and offset tables are dense) The glyph offset and width tables are dense, but only within a min/max character code range. and the kana are up at 0x3000 - alot of table entries which could quickly get me to the record size limit (this applies for resources as well as pdbs, doesn't it?) If you mean resource databases (.prc) versus .pdb record databases, then yes. Palm OS supports Japanese. How do they deal with the large font issue? Via a hierarchical font structure, where the top-most font maps a potentially wide (> 255) character code to a sub-font (referenced via an index) and a glyph index. I don't see any Palm support for aggregating fonts that cover different regions of the codepoint space. There's no documented support for user-defined hierarchical fonts. So, the only solution I see right now is creating fonts with an arbitrary dense glyph mapping and have my app convert between UCS2 and that mapping before drawing the chars via WinDrawChars. This is basically how my app works now, anyway. It's just a little annoying that I can't leverage standards more and other apps can't leverage my fonts without explicit support added. You can easily apply the same approach as Palm OS, where the high (most-significant) byte of the 16-bit UCS-2 character code is used as a font resource ID offset, and the low byte is the glyph index. So all of the Hiragana & Katakana characters would fit into a single sub-font, with a resource ID of +0x30, as these characters are all 0x3041...0x30FE. Final thing, Pilrc only supports creating font resources with < 256 glyphs and doesn't support codepoints greater than 255 even though the Palm format does. The Palm format doesn't really support glyph indexes > 255, which is why the hierarchical font format is used for Japanese/Chinese/Korean. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Displaying Unicode
I have run into a situation where I need to display unicode characters not in the 1252 code page. From what I've been reading, it would appear that I need to make my own custom font to do this. Is that correct? Yes. Also, depending on the characters, you might need to do additional processing of the text before you display it (e.g. if it's bi-directional or contextual). Are there any commercial fonts folks can recommend that are made for this kind of problem, or does everyone just roll their own? There are some public-domain fonts for other platforms that can be adapted, but it will take a bit of work. The biggest issue is how many non-1252 characters you need to be able to handle. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: what is the hexadecimal code for right arrow symbol
> the repeating buttons used to represent scrolls
have hexadecimal code of "\x01" & "\x02", likewise
what are the hexadecimal codes for right & left
> arrows?plz help me,
I would assume "\x04" for left and "\x08" for right..
as the definitions from keymgr.h is as below:
#define keyBitRockerLeft0x0004 // 5-way rocker left
#define keyBitRockerRight 0x0008 // 5-way rocker right
correct me if otherwise..
I believe the question was what character codes need to be used for
the right and left arrow glyphs in the 7pt symbol font used to draw
the up and down scroll arrows. From Chars.h:
enum symbol7Chars {
symbol7ScrollUp = 1,
symbol7ScrollDown,
symbol7ScrollUpDisabled,
symbol7ScrollDownDisabled
};
I don't believe there are left/right arrows that are the same size as
these small scrollbar glyphs. There are bigger arrows found in the
9pt symbol font at code points 0x05 and 0x06. See Chars.h for a
complete list.
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: TsmLib.c Line448
It crash,and tell me "TsmLib.c Line448". How do I correct it? Whenever you post information about a crash, it's critical that you include the exact OS version and device model (or simulator) that you're using. You should also include the language/locale. For the case above, since you noted in a separate email that you're working on a PNO, I assume you're running Palm OS 5.2. This particular source file is part of the platform Japanese FEP, so I'm guessing it's on a Japanese version of PalmSim, since Sony ships with a different FEP (ATOK). If all of the above is correct, then the full text for this error message says "Unknown Fep mode". This would happen if somebody calls TsmSetFepMode with a value that the Japanese FEP does not understand. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Working with time zones
I want to make a popup list that lets the user select a time zone. What I did is that I made a list with 24 items. The minutes value that i pass to TimeZoneToAscii is equal to ((itemNum - 12) * 60). Therefore, the list items range from -720 (-12 hours) to 660 (+11 hours). Is this the correct way to list every time zone? No. There are many time zones that don't fall on exact hour boundaries. Also, most users want to see a list of cities, where there are multiple cities in each time zone, as that provides a better chance of the user seeing a city that they know is in their same time zone. Finally, if you want to use time zone information to also help specify daylight savings rules, then you'll need to be even more precise in defining a region with the same time zone & DST settings. Using the existing OS support for picking a time zone would be the best option, unless you need functionality that it doesn't provide. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: about input mode on clie
I input 'a' on Japanese mode,then do the same as 1.jpg of the attachment.You will see the 2.jpg of the attachment. Attention:It is different between it and selected state. 3.jpg of the attachment is the selected state. What you are seeing here is Japanese text entry using a FEP (front end processor). When you tapped the top button, that told the FEP to convert the character you'd just entered. In 2.jpg,How do I get the state? What do you mean by "...get the state"? The field selection in the second image is from 0 to 2, the same as in the 3rd image. The reason it looks different in the second image is that the field code is receiving information from the FEP that tells it to highlight the Hiragana "a" character as converted text. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: No of pixels in a character string
> Is this method Localization safe? If my application is in multiple languages, will method FntCharsWidth() work safely??? I could not find this method in Localization Guildelines. FntCharsWidth *IS* safe to use on a device, regardless of the character encoding or "localization" of the text. In fact you can assume that all of the FntXXX and StrXXX routines are safe to use with any text that's encoded using the device's character set, unless the documentation explicitly states otherwise. Note that this is not the case for Palm OS 6 strXXX routines, most of which are designed to work properly only with unlocalized 7-bit ASCII text. FntWCharWidth() - you'll need to write your own wrapper for multichars If you wanted to measure the width of an array of WChar characters, then yes, you would have to write your own cover routine. But Palm OS never stores text in this format, so there isn't much reason to do so. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Finding overlay database
Is there an easy way to get access to a particular resource database's current overlay? If I have a database, what's the best way to get a DmOpenRef or LocalID for the currently used overlay database? It's not easy, but you can do the following: 1. Get the creator and name for the target database. 2. Call OmGetCurrentLocale to get the overlay locale. 3. Call OmLocaleToOverlayDBName to get the overlay DB name. Now you can either open the overlay DB directly, or you can loop over the open resource databases using DmNextOpenResDatabase (starting w/NULL) until you find a database with the same creator, the type = 'ovly', and the name = to result of calling OmLocaleToOverlayDBName. Is there a way other than using OmGetCurrentLocale to determine the current language & country Calling OmGetCurrentLocale is the right way to determine the overlay locale. and figure the name of the overlay database from that info? See above. If I do end up using OmGetCurrentLocale, does that work okay with EFIGS devices where the locale is not stamped directly into the ROM? Yes. Though even on an EFIGS device, there is a ROM locale, which is currently always enUS for all devices I know of. This ROM locale is used to initialize the system and overlay (current) locales. Then the user can pick a different system/overlay locale using the Language Picker app, which is automatically run following a hard reset. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: truncate a string
rua17 schrieb:
> I want to display in a list the name and the last name of my
clients, but in
some cases the string is to long, is there any function to truncate the
strings?
You can simply write a Null-terminator at the desired cutoff position:
string[max_length] = chrNull;
It looks nice to cut off with an ellipsis ("..."):
string[max_length - 1] = 0x85;
This will not work on multi-byte character codings of course (Japanese
etc.).
The safe way to do this is:
UInt32 truncOffset = TxtGlueGetTruncationOffset(string, max_length);
WChar ellipsis = TxtGlueGetHorizEllipsisChar();
TxtGlueSetNextChar(string, truncOffset, ellipsis);
or for the one-line-of-code-does-it-all fans out there:
TxtGlueSetNextChar(string, TxtGlueGetTruncationOffset(string,
max_length), TxtGlueGetHorizEllipsisChar());
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: Localization for Strings
Hi Ritu, "If you want to provide language support for you app but you don't want to use any of the localization techniques " Does this means any standard technique is available for achieving this? If yes please let me know what it is ? The various techniques we've been telling you about recently. One more thing is now simplified for me.Now requirment is "The Application will automatically detect the language of the Palm device and display the appropriate localized text." i.e. i can use the overlays technique for static text. Great. Still the problem persists for dynamic strings (I will get list of english string from the server, which needs to converted according to current locale.) Is their any standard Api available which can give me string version specific to the locale. Uhm, no. Since Palm devices don't yet provide built-in machine translation. Or if i can get some sample code to achieve this That will be help full to me. This sounds like a general programming problem to me. But what I would do is: a. Have a stable list of English strings in a resource (a string list, for example, if the list is short). Store this resource in your core app. b. In each overlay, have a corresponding resource with the localized versions. c. When you get a string from the server, look it up in the English list, and load the same indexed string from the overlay. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: overlays
can someone help me with overlays? It is no problem for me to create an overlay for example to Contacts. Then I upload my csCZ overlay to device (with palmos 5) and use OmSetSystemLocale function to set system locale to csCZ. But the function fails because of unknown locale. What I should do to make it function??? Thanks for any suggestions. Jirik You'll first need to implement a character encoding that supports Czech (e.g. CP1250/8859-2), then localize at least the key device overlays, and then you'll be able to change the system locale to csCZ. But it would be easier to get an existing Czech solution from a third party (maybe Paragon?) versus rolling your own. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: palmos 5 localization
Hi Karel, I found you as an well skilled palm os developer. Please can you help me with palm os 5 localization? I'm trying to make overlays for standard palm applications which are stored in ROM. These things I have done (for example for calculator): - downloaded .prc - made overlay with prc2ovl -- Calculator_csCZ.prc - edited some string in it -- current size is about 2KB But when I'm trying to HotSync it there is error in log -- ReadOnly, Not sure what this means. Did you perhaps have the PRC still open on the desktop when you tried to HotSync it? What tool did you use to edit the string? but file something is copied on device. File Calculator_csCZ is present on device but with the length of 84 bytes This sounds like either the PRC was damaged when you edited it. and when I'm trying to set system locale to csCZ an error is present -- Unknown Locale (but when I try to set it to e.g. German, everything works fine, therefore I think I must have made some mistake in the time of overlay creation). No. What's confusing you is the difference between the system locale (the locale being used by the device) and the locale of an overlay PRC. In order to change the system locale to csCZ, you MUST have, at a minimum, both a Boot_csCZ overlay PRC that's the localized version of the Boot_enUS overlay PRC, and you must also have a Palm OS Data_csCZ that's the localized version of the Palm OS Data_enS overlay PRC. Boot_enUS is the PRC that contains all of the system resources. Palm OS Data_enUS is the PRC that contains the splash screen (the Palm OS logo) and the hard reset confirmation screen. Other thing is that I can't find something how to set system font -- on Palm OS 4 it was made by direct access to the memory, but it doesn't work here. Unfortunately, to properly support Czech you'll need a different character encoding (Latin-2/8859-2/CP1250), not PalmLatin (CP1252). So that means you really need to create a new locale module. You can't just localize the two existing overlays I mentioned above. Your best bet is to find an existing 3rd party solution (maybe from Paragon?), and hope that they did it right and set the system locale properly. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Localization Overlays and Address App
Please help me out by answering the following queries. a) What should be the most efficient way to achieve localization b) can you please give me some more details about the following technique:-- sample code will help ... Not using overlays. There are various techniques for doing thus, such as using resource ID offsets based on the locale. But you'd have to write this yourself. There are three approaches that you need to decide between: 1. A fully localized app. You release a different PRC for each target locale. 2. An English app with overlays, either using the OS support or Scott Maxwell's technique. 3. A "combo" app that contains the localized data for all of your target locales. I'm not going to comment on #1 and #2, as there is plenty of documentation available for each. One approach you could use for #3 that makes it easier is to include each overlay PRC inside your app as a resource, which you then turn into a separate PRC via DmCreateDatabaseFromImage. So you could still leverage overlays, but not have to ship multiple PRCs as part of your product. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Localization Overlays and Address App
I have started working on Overlays to create a localized application. Can any body please answer the following queries for me a) What i could i understand about overlays is "for every locale a different PRC file will be created". Which will be loaded on the device. Is their any way to create only one PRC file for all the locales. Not using overlays. There are various techniques for doing thus, such as using resource ID offsets based on the locale. But you'd have to write this yourself. Can i do this localization stuff at run time. If yes then how? In the past some 3rd party localization hacks did this by patching out low level resource loading calls, and then swapping in the "right" resource based on the target locale. But this is harder to get working on Palm OS 5, requires patching, and won't work on Palm OS 6 or later. b) I have gone through the sample code for SDk5(r3). It contains a sample App saying Address which has following directory in it's resource folder C:\Palm OS 5 SDK (68K) R3\(CodeWarrior Examples)\Palm OS 5 SDK (68K) R3 Examples\Address\Rsc\Localized which contains resources for Italian, French and other languages. I am unable to find the way of creating the resources like this.(Overlays utility generates only PRC file) Is their any other way to achieve localization. I believe this sample is set up with different targets such that you build a full PRC with either English, French, Italian, German or Spanish resource data. To create overlays, the hOverlay tool can be used if you've got an English PRC and a localized PRC. But you first have to create these PRCs yourself. Read the hOverlay documentation for details. c) Is their any way to replicate the changes of base overlay to the new overlays ,without creating them again. Not using PalmSource tools. Multilizer is a high end solution. Paragon has some tools for building their own form of overlays. Scott Maxwell has yet another solution, see <http://www.pocketpurchase.com/tools/PalmOS_Foreign_Language_Plug-ins.htm>. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Crash within WinCopyRectangle
Ken Krugler a Ècrit : > >When running my program on a OS 3.5 IIIc, the map pan feature based on >WinCopyRectangle (following stylus moves) often crashes with the > >following stack crawl (seen in the CW 8.3 debugger): > > >MapHandleEvent( EventType* ) >0x10C55E52( WinCopyRectangle ) >0x10C4E0D2( BltCopyRectangle ) >0x10C4E0D2( BltCopyRectangle ) >0x10C51E32( PrvMisAlignedBackwardInnerBitBlt¡ ) > > >What can I do about this (other than telling my user to ditch his IIIc)? >I never saw this occur on another device, monochrome or color. I ran into the same problem with some picture pan code. From an old post... > At 12:25 PM -0800 2/17/01, Ken Krugler wrote: >2. When calling WinCopyRectangle(screen, >off-screen) and the off-screen window uses a >bitmap without a color table, then Palm OS 3.5 >will accidentally dispose of the system color >table, and a subsequent call will die in Poser. >I think this same situation might occur in the >inverse case as well. The full post is at <http://www.escribe.com/computing/pcpqa/m34989.html> I fixed it in my code by making sure the off-screen bitmap had a color table. In my case, I'm just moving the screen window onto itself, drawing from screen to screen: WinCopyRectangle( NULL, NULL, &bounds, newX - screenX, newY - screenY, winPaint ); How could the screen window not have a color table? It should. But the specific bug was in the low-level blitter code, where it was incorrectly disposing of a color table that it _thought_ it had allocated, but was in fact (in my case) the system color table that's used when the destination bitmap doesn't have a color table. So there may be other ways in which the same bug could be triggered. However rectangle to rectangle copying from the screen is something that gets used a lot, which makes me suspect something in your code that's trashing memory. Have you been running on POSER with a IIIc debug ROM and all debug checks turned on? -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Crash within WinCopyRectangle
When running my program on a OS 3.5 IIIc, the map pan feature based on WinCopyRectangle (following stylus moves) often crashes with the following stack crawl (seen in the CW 8.3 debugger): MapHandleEvent( EventType* ) 0x10C55E52( WinCopyRectangle ) 0x10C4E0D2( BltCopyRectangle ) 0x10C4E0D2( BltCopyRectangle ) 0x10C51E32( PrvMisAlignedBackwardInnerBitBltÁ ) What can I do about this (other than telling my user to ditch his IIIc)? I never saw this occur on another device, monochrome or color. I ran into the same problem with some picture pan code. From an old post... At 12:25 PM -0800 2/17/01, Ken Krugler wrote: 2. When calling WinCopyRectangle(screen, off-screen) and the off-screen window uses a bitmap without a color table, then Palm OS 3.5 will accidentally dispose of the system color table, and a subsequent call will die in Poser. I think this same situation might occur in the inverse case as well. The full post is at <http://www.escribe.com/computing/pcpqa/m34989.html> I fixed it in my code by making sure the off-screen bitmap had a color table. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Supplying a '\0' for StrNCompare on not null-terminated strings
Hi Luc,
If you were going to write your own version of StrNCaselessCompare to
avoid the problems that you've run into, it could look something like
this (danger - untested/uncompiled code ahead):
Int16 MyStrNCaselessCompare(const Char* s1, const Char* s2, UInt16 n)
{
// Assumes you've pre-cached the os version numbers someplace. If
// you're running on pre-3.1 or Cobalt then you don't need to
// worry about calls to StrLen.
if ((palmOSVersion < 3.1) || (palmOSVersion >= 6.0))
{
return(StrNCompare(s1, s2, n))
}
else
{
UInt32 len1, len2;
len1 = StrNLen(s1, n);
len2 = StrNLen(s2, n);
return(TxtCaselessCompare(s1, len1, NULL, s2, len2, NULL));
}
} // MyStrNCaselessCompare
// if < length of , return starting offset of character
// that contains the byte at offset , otherwise return
// the length of .
UInt32 StrNLen(const Char*s, UInt32 n)
{
UInt32 i = 0;
while(*s++)
{
i++;
if (n < i)
break;
}
if (n < i)
{
UInt32 charStart, charEnd;
TxtCharBounds(s, n, &charStart, &charEnd);
return(charStart);
}
else
{
return(i);
}
} // StrNLen
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: How to determine if an app is running on the Simulator?
Does anyone know a way to determine programmatically whether or not an app is running on the Simulator? I'd like to know this so I can avoid calling SysGlueTrapExists() when running on the Simulator. (Calling SysGlueTrapExists() on the Simulator causes a debugger break.) By "the Simulator" I assume you mean PalmSim, not the old Mac Simulator, right? If so, then it seems like maybe you're linking against the Mac Simulator version of the PalmOSGlue library, when in fact you should be linking with the regular (device) version. Or at least I didn't see any other obvious way to trigger a fatal error/debugger break. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Japanese fonts on an English Palm Device
Thanks in advance, is there a page somewhere that describes how to put Japanese fonts on an English-only Palm Device? Not that I know of. And I don't think you could legally extract the fonts from a Japanese device and then re-install them (along with your app) on an English device. One option is to work out a deal with Hacker Dude-san, who has previously created a Japanese locale solution for English Palm devices. Though this probably won't work with Palm OS 5. Or you could create your own fonts using one of the public-domain bitmap Japanese fonts, as long as all that you needed was the ability to draw Japanese text (versus wrapping/editing/sorting/etc). -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: How to share fonts among apps ?
To save space, I would like to share a big set of fonts (a precedent set I build were around 1.5Mb, and I expect the next to go up to 3-4Mb) among many applications. Ideally I would like to end up with a separate font database, but I could go with a "master" app. All the font in the database have to be accessible at the same time. The goal is to display multilingual text, thus my need of a huge font set. I'm using PRC tools and Pilrc. On the net I found some articles to share forms and strings, but it was only for CodeWarrior. So : - How to build such database with my tools ? - I would like a sample code showing how to use such db. Since you just want to share the data, all you need to do is put the font resources into a single PRC. Then each app would open this font PRC read-only, and use regular DmGetResource calls to load the font resources. As far as how to create the PRC from resources, I assume that it's easy to do this with PilRC, but I don't use it as a stand-alone tool. If you wanted to compress the resource data to save space, then it might make sense to create a shared library, but that would be significantly more work. To start with I'd suggest just trying out the uncompressed font PRC approach. Another alternative that might work is to leverage FontBucket. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: find offset of character in string
> I had done a Google search on "StrStr" and found a little example like
what
Vu Pham posted.
Thanks for the help,
D. Kirker
P.S. How could I delete the character at the offset found with StrStr and
all the characters to the end of the string?
If you search for a char, then it is better to use StrChr. If you search for
a str, then use StrStr.
If pend points to the found offset, then *(pend+1) will "delete" the rest of
the string.
If you really want to clear all chars after pend, then put 0x0 to each char
since pend+1 until the end of the original str.
Except that this won't work for multi-byte characters. To handle that
correctly, assuming a FindCharOffset routine that returns the offset,
then you'd do something like:
offset = FindCharOffset(buffer, someChar);
if (offset != -1)
{
offset += TxtGetNextChar(buffer, offset, NULL);
buffer[offset] = '\0';
}
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: overlays
I know that such question was posted many times before, but I guess I'm still missing something. I'd like to localize my app to e.g. Russian or Hebrew or Arabic. I'm creating overlays with PRC2OVL and translate them. But when I'm installing them, nothing is changing. Overlay's locales are correct. prc-files have correct names etc. I've also installed some apps to see localized text on Palm. Since you can see localized text, I'm assuming you've installed some 3rd party locale solution. In that case, the two most likely problems are a. You're using a pre-4.0 ROM. Overlay support was added in Palm OS 3.5, but only for the platform (EFIGS+J) locales. b. The 3rd party locale solution isn't setting up the overlay locale properly. If you call OmGetCurrentLocale, it should return Russian/Hebrew/Arabic. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: TxtFindString question
Like FindStrInStr, it seems that TxtFindString only matches the beginning of words only - not documented in PalmRef doc. That's the current behavior on all Latin-based devices. On Japanese & Chinese devices it matches anywhere in the word. The behavior is locale-sensitive. Finding "ased" in "based" doesn't work whereas finding "bas" in "based" works fine. To me, this makes this function quite useless. Is there any real usable Palm text find function I've missed, or do I need to write it myself ? If you need to do a caseless match anywhere (and thus StrStr won't work) then yes, you'll have to write your own. There might be a really old thread on this in the archives, when Paul Nevai asked the same question. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Text manager and International manager
Can any one please tell me following things. 1.How can i write my code for supporting unicode languages. I'm not sure what you mean by "unicode languages". Currently Palm OS supports several different legacy character encodings, which in turn are used by a number of different languages. If you use the Text Mgr appropriately, your code should work with any character encoding, though there is still missing support for contextual and bidi writing systems. 2.Is there something similar to Unicode support like TCHAR(supported in windows) in Palm OS, so that it does not always take a single character as 2 bytes(1 Byte for non unicode languages and 2 bytes for unicode languages).This is because i don't want to use WCHAR(2 bytes) always and make my application use more memory. Palm OS currently does not support Unicode. When it does, it will use the UTF-8 encoding, where every character is represented in a string by one to four bytes. Even today, though, Palm OS supports mixed-width encodings. For example, Shift-JIS (for Japanese) is a mix of one and two bytes per character in a string. The same is true for Simplified Chinese, Traditional Chinese, and Korean. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: system keyboard
well, What I need is not a special keyboard function. I only want to show= the keyboard perse...is there a function which shows the keyboard rather= than the whole frame. No. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Inserting the shortcut (ribbon) character
"RaNo" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
Hi All!
> When I try to insert the shortcut character with either EvtAddEventToQueue
or EvtEnqueueKey, it gets inserted in a field, but it is POWERLESS for
expanding the shortcut's text.
Is there any way to give it the power?
This is the same thing I have found. Seems like the graffiti processing is
doing something special when you draw and it interprets it is the shortcut
symbol, that it will then do the lookup. I have even tried enqueuing the
full shortcut dt to test and it does nothing.
Graffiti/Graffiti 2 needs to be in shortcut ("macro") mode for
shortcut matching to work. This happens automatically when it
recognizes the shortcut stroke. Unfortunately I don't see any
straightforward way to set the internal macro mode flag used by the
Graffiti glue code.
So the only approach I see now is to replicate what the Graffiti glue
code does, which is a bit challenging if you want to handle all of
the special cases.
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: Font families with Pilrc
Alexander Lange wrote:
> if (densityCount < 2)
> Error("FontFamily must have 2 fonts with density 72 and 144.");
So obviously it is not possible at the moment to create a font family with
only a high-res member. Too bad. Maybe the Pilrc designers could rethink
this in the future.
If you read the font family specification [1], I think you'll agree that
it requires the family to contain a low-density font. Thus if there is
any rethinking to be done, it really ought to be PalmSource issuing a
clarification of this specification.
John
[1] http://www.palmos.com/dev/support/docs/palmos/Font.html#1000390
An extended font can contain any mix of 72/108/144dpi glyph bitmaps.
Where the specification referenced by John says "Tables for the
low-density font", it means the bitmap location table and the
offset/width table, which have to be created with correct values for
single-density glyph & character data, even if the font doesn't
contain a single-density glyph bitmap.
The diagram in the documentation shows a typical extended font, which
would have both single and double-density glyph bitmaps.
The reason most extended fonts have both single and double-density
glyph bitmaps (even if they're found in a ROM on a double-density
device) is that an app can still create and draw text in a
single-density offscreen bitmap. The Palm OS 5 blitter can only
up-sample (use single-density glyph data at double density), it can't
down-sample.
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: Detect ROM language
Is there a way to find (by code) what is the language of the PDA? For example, if the PDA is in Hebrew, I need to know it to change some layouts on the screen. and Answering to my own question ;-) Look for LmGetLocaleSetting Unfortunately that's not the right answer :) What you need is the system locale. On devices from Palm OS 3.5 through Palm OS 5, you'd call OmGetSystemLocale. For Palm OS 6 you call LmGetSystemLocale. On pre-3.5 devices you'd use FtrGet(sysFtrCreator, sysFtrNumLanguage) and FtrGet(sysFtrCreator, sysFtrNumCountry). The above assumes that if you're using a 3rd party locale solution, they've correctly set up these values. LmGetLocaleSetting returns default settings for a given locale (e.g. what is the default short date format for frFR). -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Japanese
> I'm guessing that the strings you're referring to are being displayed in a dialog by POSE - No, the text was drawn to the screen using WinPaintChars. Then it should work, if you're using a Japanese ROM, as there's no desktop OS support involved. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re[2]: Base PRC and Overlay localization
Thanks for this info. Could you tell me where in constructor I can check the PRC's DB header? In constructor, in the project settings, there is a button "Auto Generate Header file" if I click on it, I can provide a header file name. Do I have to use that ? As the original program is not one of mines, I can't change anything in the code. It's not a Constructor setting. How the DB header name gets set depends on what tool chain you're using to generate the final PRC. If you were using CodeWarrior and PalmRez, for example, then you'd need to change the PalmRez prefs setting for your project. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Base PRC and Overlay localization
I've made localized overlays using PRC2OVL for the creation of the overlay,
and Constructor for the translations.
Constructor opens the overlay file, I can translate and save, but when I
hotsync the overlay file, it is still the base version of the prc which
runs. The overlay is correctly loaded, but is not used.
Any idea of what I could have missed ?
The base program has for name Prog3.prc, and the ovelay is named
Prog3_frFR.prc as stated in prc2ovl guide.
But if I check the infos on the palm, the base program's name is Prog3.prec,
and the overlay's name is completed by the version number
(Prog3_3.10_frFR.prc)
Is it possible that the overlay could not work if the name is not the same
one than the name of the base (except the frFR extension) ?
Yes. The name of the overlay (in the PRC's DB header) must be the
same as the base PRC's DB header name, plus the appropriate locale
suffix.
The name of the overlay file on your desktop ("Prog3_frFR.prc", in
your example above) doesn't matter.
Neither does the name of overlay PRC as displayed by the Launcher, as
this should be coming from the tAIN resource inside of your overlay.
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
RE: Language Support in Cobalt
What about Language Support in Cobalt, is it going to be limited to the five Languages Six currently: EFIGS + Japanese. and the rest will be created by developers, or is it going to be part of the OS or created by PalmSource. Additional locales can be created by 3rd parties, though support for patched-based solutions is much more limited in Cobalt. So it would be very difficult to create a Hebrew or Arabic locale, for example. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Japanese
Could you please explain what do you mean by Japanese support installed? Acc. to my own experience Japanese emulator is not enough. Once I got screenshots from our app taken on some Japanese Clie emulator by a Japanese user. I was not able to display the same strings as he saw (I got just some junk characters) despite using the same prc, the same emulator, the same rom - the only difference was that I used English Windows. My conclusion was that the emulator probably relies on some Windows services (maybe fonts) that are available on Japanese systems only. I suppose that you refer to the same thing. I'm guessing that the strings you're referring to are being displayed in a dialog by POSE - for example, if it's a fatal alert that POSE has intercepted. In that case, yes, the OS needs to have Japanese support installed. What this means varies by platform/version. In Mac OS 9 and earlier, you had to install the appropriate language kit. In Mac OS X, you have the option of installing the required fonts when you install the OS - it's not a separate product/package. On Windows 2000/XP I believe you only need to have an appropriate Japanese font installed, but I haven't had to do much configuration here - it's just worked for me in the past. One final note is that POSE has to do some special processing to pick the correct font to use when displaying text that comes from the ROM. It could be that this is broken in the Clie emulator. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Japanese port
Yes, thats part of it. I need a japaneese GUI but I am also sending down pdb files that I assume need to be converted to widechar? If you have text in a PDB that you're creating on the desktop, then it needs to be encoded using Shift-JIS. This is a mixed one- and two-byte encoding. When you say "widechar" it sounds like you're thinking about Windows (and Mac) support for Unicode. is widechar supported in code warrior? Not sure what this means. How is CodeWarrior involved in the creation of a PDB? I am also considering moving to the pilrc format. Not sure if that helps or hurts. For the GUI resources it's another option to Constructor. For me, running Constructor on an English Mac with Japanese support installed has been the easiest approach, but if you need to send text to a 3rd party localization company, then being able to send out a PilRC text file can work better. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Question about FntCharWidth
> I am building a character mapping that will map Unicode to the correct
glyph
(like TxtConvertEncoding).
I'm doing this because there are many glyphs that I need that do not exist
in the Palm fonts (primarily italic but also greek etc.).
> Sine the API doesn't support custom fonts,
But there is a FntDefineFont call, which lets you install a custom
font. What's the problem with that?
I'm stuck writing this code.
> (unless someone knows another way).
I've posted answers to similar questions in the past, so checking the
archives would potentially be useful. The general technique (assuming
you've got a stream of UTF-16 code points) is to use the most
significant byte to map to a custom font ID (which has to be in the
range of 128...255), and then use the low order byte as the
"character code" to draw, once you've switched to that font.
Something like:
void DrawCustomChars(const WChar* iBuffer, UInt16 iCharCount, Coord x, Coord y)
{
FontID curFont = FntGetFont();
UInt16 curOffset;
for (curOffset = 0; curOffset < iCharChar; curOffset++)
{
WChar curChar = iBuffer[curOffset];
UInt8 fontID = kHighByteToFontIdTable[curChar >> 8];
if (fontID != curFont)
{
FntSetFont(fontID);
curFont = fontID;
}
WinDrawChar(curChar & 0x00FF, x, y);
x += FntCharWidth(curChar & 0x00FF);
}
}
This assumes you've called FntDefineFont for all of your custom
fonts, and there's a kHighByteToFontIdTable static table that is used
to map from the high byte to the font ID.
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: Finding undisplayable characters in current font
> When copying a string into a field, is there a quick and simple way to determine whether the copied string can actually be displayed in the current field font? e.g. letters produce a hollow rectangle when displayed in the LED font. I would like to exclude those undisplayable characters that shouldn't be in the source string. Unfortunately there's no API for querying a given font's set of defined glyphs. On pre-Palm OS 5 you could roll your own by inspecting the font data, though I don't think that would work any longer when you're running under PACE, and it wouldn't work for Japanese, Chinese, or other non-Latin locales that use complex fonts. OTOH, the set of defined glyphs in the LED font hasn't changed much over time (maybe since 3.5?), so if that's the specific font that you need to deal with then that's a pretty simple check. Or, if you really needed a general solution, you could craft your own by drawing both a known invalid character and the target character to off-screen bitmaps and comparing the bits. Ugly, I know. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: International Feature Set
Am I correct in assuming that any OS after 3.1 has the International Feature Set. My program anyways cannot run on less than OS3.5, so I want to know if I have to use the PalmOSGlue version at all. The core Text Mgr routines exist on 3.1 or later. But note that the glue code implements support for new routines added after 3.1 (and 3.5, in some cases), as well as fixing some known bugs, so you still might want or need to link with it. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: regionalized version of __DATE__
Is there a slick way of getting a regionalized version of the __DATE__ macro? Note that "regionalized" isn't sufficient if you're displaying dates to the user. You want to convert to the format that the user has selected in the prefs panel. I am thinking that I am going to have to parse the string and convert it to DateType. Does anybody have any better ideas? If you're using CodeWarrior, you could create a Rez (.r) file that uses $$Month, $$Day and $$Year to create numeric values in a resource that can then be used to fill in a DateType structure. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Unicode Programming
Can someone tell me in some C/C++ code language how can I set a label or a button caption in Palm OS 5.0 to a unicode string which is in either Italian language or Spanish language? Call TxtConvertEncoding to convert from Unicode (UTF-8, UTF-16, UCS-2, etc) into the device encoding, then use the result to set the label/button. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: OS 5 Simulator, FrmCustomAlert(), "text can't end with blank line" error
"Brian Preston" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] The Palm OS Reference (which I did read before posting this, btw) that I've been using says that is only required for OS 2.0 and below. I was testing 5.0, so I didn't think I needed to do that. However, that solved the problem! So thanks. I wonder if the Reference is wrong, or the Simulator? Methinks the simulator is just being "helpful" by doing extra checks. Nothing bad will happen on a device if you don't put a space, but since the simulator debug rom complains, methinks the reference should just say "always put a space". No, come to think of it my vote would be to drop this check from the simulator. Who's still using a 2.0 device anyway? I've never even seen one. Actually this warning is displayed whenever the text being displayed in an alert ends with a linefeed character. Maybe your message looks like "blah^2", thus setting the second parameter to " " (versus NULL) would suppress the warning. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: TxtFind and International Feature Manager brain dead?
I'm struggeling to get global search working on strings that may (!) contain Japanese kanji characters that are represented as double-byte Shift-JIS characters. The API documentation of FindStrInStr suggests to use TxtFindString if the International Feature Set is supported. While the API says that it matters for some strange reason that both pointers point to the start of a valid character, Some strange reason? If your text pointer is referencing the second byte of a double byte character then it would be rather difficult for the routine to correctly process the text. the function seems to perform just the usual case-insensitive one-byte comparasion. So it happens that if a double-byte character 0x215L is to be searched also 0x215l is found which sucks quite hard because since there just is not such a concept like "capital letters" in Japanese I have to filter all found results based on whether they found a Shift-JIS character through an own (3 line) function. This shouldn't be necessary. Or am I missing something? I'm assuming you're running your code on a Japanese ROM, right? Otherwise the device character encoding is Latin (PalmLatin, basically CP1252) and the various text related routines throughout the OS assume that they're getting passed single-byte text. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Who sets prefMeasurementSystem?
> >> >is there a >> >system or pref dialog that changes it? >> > > No. It gets initialized at hard reset time to match the measuremen= t > >> setting for the system locale, as provided by the Locale Mgr, which= > >> in turn is read from the 'locs' (68K) or 'alcs' (ARM) system resour= ce. > > >You mean the country choice? > No, the country/language pair (the locale) that's burned into the ROM when it's built by a licensee. So there's only one locale per device, There is one ROM locale per device. The system locale is set to be the ROM locale at hard reset time. It can be changed via calls to OmSetSystemLocale (or now LmSetSystemLocale), which will trigger a soft reset. You can have multiple possible system locales installed on a device. For example, the Tungsten|T3 (among others) has five in ROM (EFIGS), and it's possible to add more in RAM. no matter the country setting made= after a hard reset? Or is it set by the country choice among many possibilities? The Formats panel and Welcome app let you set the formats locale, which is completely separate (in meaning) from the ROM or system locale. The only connection is that after a hard reset the formats locale is set to be the same as the system locale. The set of countries displayed in the Formats panel and Welcome app are based on the set of locales that the Locale Mgr "knows" about, which is derived from the contents of the 'locs' (or 'alcs' in ARM-land) system resource. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Key Q size
At 9:05am -0800 2003-12-24, Ken Krugler wrote: 1) What is the total size(in bytes) of the system Key Queue in Palm OS 4.1 and above ? Call EvtKeyQueueSize() to find out. 2) In what conditions do we get this error "Bus Error-Connect to Debugger" Got me. It's useful to provide more context when asking this type of question. For example, what device were you using when this happened, the OS version number, etc. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Who sets prefMeasurementSystem?
> >I see there is a prefMeasurementSystem system preference that seems to= be set >to unitsEnglish if the OS language is English, metric otherwise. But >is there a >system or pref dialog that changes it? > No. It gets initialized at hard reset time to match the measurement setting for the system locale, as provided by the Locale Mgr, which in turn is read from the 'locs' (68K) or 'alcs' (ARM) system resource. You mean the country choice? No, the country/language pair (the locale) that's burned into the ROM when it's built by a licensee. Canada went metric almost 20 years ago, yet = my Cli=E9 offers me feet as a default. The Canadian entry in the 4.0 (and later) locale settings resource is for metric. What version of the ROM are you using? I think there was a change that went in between 3.5 and 4.0, where the Welcome app and the Formats panel would set the measurement system (in prefs) to match the selected locale. So if you're running on 4.0 or later, and have selected "Canada" in the popup list, then the prefs setting should be metric. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Who sets prefMeasurementSystem?
I see there is a prefMeasurementSystem system preference that seems to be set to unitsEnglish if the OS language is English, metric otherwise. But is there a system or pref dialog that changes it? No. It gets initialized at hard reset time to match the measurement setting for the system locale, as provided by the Locale Mgr, which in turn is read from the 'locs' (68K) or 'alcs' (ARM) system resource. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Adding a scrollbar dynamically
I am writing an application that is launched through the command bar. It starts on top of other applications (for looking up something), so I don't have global variables nor can I open resources. I'm curious as to why you can't get access to resource data. Anyway, as you've discovered, without being able to load a form resource you really don't have a good alternative to implementing it yourself. Though if you signed the NDA and have access to the source code, you'll see that it wouldn't be all that hard if it turns out that's your only option. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Multibyte strings
Can we safely assume that the length of the ASCII 32-128 on non-ASCII encodings is always 1? Palm OS Programmer Companion says that all ASCII chars 0-0x7F) are the same in all encodings. Not exactly true. 0x5C has different meanings depending on the encoding - for example, with ShiftJIS (Japanese) it's a yen character. However the other statement is "Never make any assumption about the size of a character". For example Unicode is an example of the encoding (not supported on Palm?), where low range ASCII values are preserved, but the length of a character is (always) 2. This isn't really correct either. The Unicode character set is just an ordered list of characters, where each character has a scalar value associated with it. There are many encodings for Unicode, one of which (UCS-2) uses two bytes for every character. But the existing Palm OS APIs will never work with such a wide encoding. The only encoding of Unicode you're going to see with the existing APIs is UTF-8. For UTF-8, each character occupies one to three (or four, in Palm OS 6) bytes in a string. If we could assume 1 By length of ASCII 0-128, then the code could be a bit smaller and faster. There are two separate issues here. The first is how many bytes are required to represent a character in a string. The second is whether an individual byte in a string can safely be treated as a single character, depending on its value. For the first, the documentation should be pretty clear that the number of bytes required for a character varies depending on the character set encoding and the specific character. For PalmLatin (basically CP1252) it's always one byte for each character, but PalmSJIS (basically CP932, for Japanese) uses one or two bytes per character, and UTF-8 uses one, two, or three bytes (currently) per character. For the second issue, if you're looking at individual bytes then the only thing you can safely assume is that any byte value < 0x40 is a single character. Note that you can check the encoding flags feature to see if the device's character encoding only contains single byte characters. If so then you could use your optimized code, otherwise fall back to something more general. If you were parsing text left-to-right then you could also use the TxtByteAttr function to create a table that would let you do a faster job of parsing, if necessary. -- Ken -- Ken Krugler +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Multibyte strings
Can we safely assume that the length of the ASCII 32-128 on non-ASCII encodings is always 1? Palm OS Programmer Companion says that all ASCII chars 0-0x7F) are the same in all encodings. Not exactly true. 0x5C has different meanings depending on the encoding - for example, with ShiftJIS (Japanese) it's a yen character. However the other statement is "Never make any assumption about the size of a character". For example Unicode is an example of the encoding (not supported on Palm?), where low range ASCII values are preserved, but the length of a character is (always) 2. This isn't really correct either. The Unicode character set is just an ordered list of characters, where each character has a scalar value associated with it. There are many encodings for Unicode, one of which (UCS-2) uses two bytes for every character. But the existing Palm OS APIs will never work with such a wide encoding. The only encoding of Unicode you're going to see with the existing APIs is UTF-8. For UTF-8, each character occupies one to three (or four, in Palm OS 6) bytes in a string. If we could assume 1 By length of ASCII 0-128, then the code could be a bit smaller and faster. There are two separate issues here. The first is how many bytes are required to represent a character in a string. The second is whether an individual byte in a string can safely be treated as a single character, depending on its value. For the first, the documentation should be pretty clear that the number of bytes required for a character varies depending on the character set encoding and the specific character. For PalmLatin (basically CP1252) it's always one byte for each character, but PalmSJIS (basically CP932, for Japanese) uses one or two bytes per character, and UTF-8 uses one, two, or three bytes (currently) per character. For the second issue, if you're looking at individual bytes then the only thing you can safely assume is that any byte value < 0x40 is a single character. Note that you can check the encoding flags feature to see if the device's character encoding only contains single byte characters. If so then you could use your optimized code, otherwise fall back to something more general. If you were parsing text left-to-right then you could also use the TxtByteAttr function to create a table that would let you do a faster job of parsing, if necessary. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Add a menu item to system menu
According to your way,I find the new meun item only appear on my application. I want to let it appear on all palm application installed in the palm machine. Thanks again. You'll have to install a resident patch to SysHandleEvent, not just something that's active when your application is running. Check the archives for information on writing patches (especially references to HackMaster). -- Ken > >Hi~,all!I want to add "mail" menu item under "GraffitiHelp".Please see the >attachment. >"mail" menu item appear if the user hit "Edit" system menu.I get highlighted >text,and do relevant operation. > Patch SysHandleEvent. When you see a menuOpenEvent, call MenuAddItem with sysEditMenuGraffitiCmd as the positionId parameter, and your own (hopefully unique) command id. When your SysHandleEvent sees a menuEvent, and the id == your unique command id, call FrmGetActiveField to get the field, and then do your mail thing. > -- Ken -- Ken Krugler +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Add a menu item to system menu
Hi~,all!I want to add "mail" menu item under "GraffitiHelp".Please see the attachment. "mail" menu item appear if the user hit "Edit" system menu.I get highlighted text,and do relevant operation. Patch SysHandleEvent. When you see a menuOpenEvent, call MenuAddItem with sysEditMenuGraffitiCmd as the positionId parameter, and your own (hopefully unique) command id. When your SysHandleEvent sees a menuEvent, and the id == your unique command id, call FrmGetActiveField to get the field, and then do your mail thing. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Determining areas of the screen
Is there an API or other means to determine areas of the screen for things like the four soft buttons (on Vx these are "home," "calculator," "find," and "menu")? Such an API might include the ability to get the screen area for the drawable screen, the silkscreen, and alphabetic part of the Graffiti area, the numeric part, the "abc" and "123" areas, and so on. I know that all these areas are rectangles (despite whatever curvy our round shape is there), so it would seem natural that there might be an easy way to get those rectangles. Anybody know? Thanks in advance. EvtGetSilkscreenAreaList(). -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: May be a silly question...converting string to uppercase
Alternatively, test each character in your string, if it's >=3D 'a' and =
<=3D
'z', simply add ('A' - 'a') to it.
Except that this won't work with multi-byte encodings, unless you're
using TxtGetNextChar to walk the string, in which case you might as
well use TxtTransliterate, and it doesn't upper-case high-ASCII, or
double-byte ASCII, etc.
So you'd want to use TxtTransliterate unless you need to run on an
old (pre-3.1) version of Palm OS, in which case there's always
TxtGlueTransliterate.
-- Ken
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Markus
Dresch
Sent: Thursday, December 04, 2003 1:26 PM
To: Palm Developer Forum
Subject: Re: May be a silly question...converting string to uppercase
I was just wondering, how does one convert a string to uppercase,
there
doesn't seem to be a StrToUpper function along with the StrToLower
function
in the Palm OS String API.
maybe TxtTransliterate(..., translitOpUpperCase) is what you are looking
for?
markus dresch (www.palmside.com)
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: chrDelete in palm
Is chrDelete command char disfunctional in palm os 4.1 & 5.0 ? We enqueued it as follows : EvtEnqueueKey(chrDelete,0,0); But it does not act upon it . The OS simply ignores this char . Is something missing here ? Use chrBackspace, not chrDelete. -- Ken -- Ken Krugler +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Retrieving text (as a string) from middle of a string
Why not use the StrNCopy function and just get a pointer (char*) to the string position you want to start at then specify from that point the number of characters you want. Don't forget that bytes != chars. So you'd want to use TxtGetTruncationOffset (aka TxtTruncate) or TxtCharBounds to convert your byte offset to a character offset, before advancing the pointer. After that StrNCopy will take care of not copying partial characters. -- Ken --- "D. Kirker" <[EMAIL PROTECTED]> wrote: How do I retrieve text (as a string) from the middle of a string? Similar to the substr, strleft, strright functions. Is there anything like it for > PalmOS? -- Ken Krugler +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: WinDrawChar problem with
At 05:51 AM 11/24/2003, Jeremy wrote: I'm having a strange problem with WinDrawChar. It works fine with other characters in stdFont, but with some of the less common characters such as '=B5' and '=BC', I get the following error: called SysFatalAlert with the message: "TextMgr.cpp, Line 2723, Sign-extended char passed to TxtSetNextChar WinDrawChar (c, position + bounds.topLeft.x, y); your 'c' variable is a Char. Make it a WChar instead, or cast it to WChar= =20 in the call, i.e. WinDrawChar ((WChar)c, position + bounds.topLeft.x, y); Unfortunately this doesn't work, as the 8-bit value is still sign-extended to 16-bits. What you need is: WinDrawChar((UInt8)c, position + bounds.topLeft.x, y); -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
