RE: Trouble dismissing dialog
Two basic approaches come to mind. One is to write your own event loop for your popup. That way, you can react to taps in any way you like. This isn't that hard, but it's a little scary in that you might miss something that FrmDoDialog does for you. The alternative I would consider is to use FrmDoDialog, but to assign your own event handler. This handler gets first crack at all events. By making it detect taps outside the bounds, it should be easy enough to make them effectively press the cancel button. I'd go for this approach since your code is already set up to use FrmDoDialog with your own event handler. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Crashes on Alarm
The display alarm launch code of the alarm manager is supposed to be used to display an alarm dialog. This is how it used to work in PalmOS 3.5 and earlier. In PalmOS 4.0, the attention manager was added, so rather than presenting your own dialog, you now call AttnGetAttention. This is done in your alarm trigger launch code. You also set the purgeAlarm bit so that the alarm manager knows that you don't need to display anything. One key advantage of the attention manager is that you no longer have a sequence of alarm dialogs. This means you can have a goto button and it will work even if there are other alarms that have gone off. Perhaps for your purposes the attention manager is not appropriate (as your app will be the sole app of interest on the device). But don't present your non-modal UI during the display launch code. Instead, present a modal dialog which asks the user the questions. When the dialog is closed, you return to whatever application the user was running. This might be your application, but it need not be. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: ticks time vs. secs time
The tick clock stops while the device is off, whereas the real-time clock obviously keeps going. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: ticks time vs. secs time
I think you're asking whether the tick clock stays in sync with the time of day clock while the device is on. In other words, if you poll the time of day clock until it rolls over to the next second and then sample the tick clock, can you simply add SysTicksPerSecond() to the tick clock to determine when the time of day clock will roll over again? I think the answer is yes, assuming the device stays on during that entire time. However, I'm not sure. I'm also not sure I understand your question ;-) -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: ticks time vs. secs time
I don't think you'd want the tick clock to be reset when you set the time of day clock. Applications can rely on the fact that the tick clock only ever increases (although it will eventually wrap around). I don't even think you'd want to tweak the duration of one of the ticks in order to align the tick clock with the time of day clock (so the tick clock advances every time the time of day clock advances, and at precisely the same moment). So, you're stuck with independent clocks that advance at the same rate assuming the time of day is not set and assuming the device stays on. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: ticks time vs. secs time
From Danny's comments I think even this might not be safe. In other words, one clock might drift relative to the other. Perhaps the amount of drift will be small enough in practice to be of no consequence. I don't know. An approximate correlation is probably all you really need if you always have the option of querying your own real time clock (the GPS). -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Right justified; custom loading
The phone numbers in the address list are right justified. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Can you disable build in keyboard?
Catch these virtual characters: vchrKeyboard, vchrKeyboardAlpha, and vchrKeyboardNumeric. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Adding an Address record from my application?
You have the source code to the Address application, so I think you can answer this question for yourself. You can also try entering text into the various fields in an address record on the device, and beam the record to a PC or Mac laptop. Open the vcard using a text editor and see what you get. For the most part, the mapping is pretty obvious, and follows the vcard standard. However, there are some oddities, as always happens when using standards. The vcard standard is defined by these guys: http://www.imc.org/ -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Truncated chars in table cell
FntCharsWidth takes as input the current font. You should switch to the font you plan to use for drawing the characters before measuring the characters. Perhaps that is your problem? If so, the amount of text clipped would vary, with longer strings getting more pixels clipped than shorter strings. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: CtlSetLabel on label failing on debug ROM
A label is not a control, so it isn't appropriate to use control APIs on a label. Use FrmCopyLabel to set the text of a label. Make sure your new label fits in the space available. In other words, make sure the label you set in Constructor is at least as big as any label you ever set using FrmCopyLabel. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Events during Alert Box
I would agree that posting a vchr event into the key queue is not by itself an appropriate notification mechanism. The key queue is good in that it survives app switches and is thread safe. However, the event can be lost in an event loop that is not in your control. While you can work hard to avoid most of these, there will always be one or two dialogs that are still causing problems, such as the low battery dialog and the attention manager dialog. An API you can call to poll the MSR library would be appropriate. Other alternatives: callback or sub-launch. With a callback, you'd pass the address of a routine in your app to a setup API, and it would call the routine when data was ready. This requires the routine to stay locked and loaded, which is a bit of a pain. With a sub-launch, the setup API would be given the info needed to identify your application, and it would sub-launch the app with a specific launch code to inform you that data was ready. Of course, none of this makes your job any easier -- unless you can convince the authors of the MSR library to update it. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Looking for an application that ...
HandyShopper? -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Adding an Address record from my application?
I'd say the exchange manager is the elegant solution. It requires using a wire line format (vcard), which is then parsed by the Address application. This means it'll be relatively slow, but it also means it'll keep working even if the format of the Address database changes. The obvious alternative is to use the source code provided to directly write to the Address database. Be careful not to call EvtGetEvent while you've got the Address database open, or you could have trouble receiving a beamed vcard while your app is adding the Address record. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Events during Alert Box
Sorry, but I'm completely clueless when it comes to NetLib, so I really can't answer your question. I'd try running the code in POSE and using the event tracing capability of POSE to see what events are generated when you manually dismiss the dialog. However, I'd first try to find a way to avoid the dialog altogether. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: ? about fldSetText edit in place
a) True, as far as I know - the record will grow as needed. b) I don't think so. It should work even if there is more stuff after the field text in the record. c) See FldCompactText API in the docs. It will shrink the record so it doesn't waste any extra space. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: ? about fldSetText edit in place
I would agree that the docs for FldSetText and FldSetTextHandle should refer to FldCompactText. At a minimum, that API should be included in the see also list. Remember to look at the available sample code too, as it will often get you unstuck when the documentation doesn't. -- Peter Epstein Palm, Inc. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Events during Alert Box
If you call an OS API that presents a modal dialog and blocks until that dialog is closed, you're effectively asking the OS to run it's own event loop for that dialog. It can't very well run your event loop if it's not going to return until the dialog closes. If you use FrmDoDialog to present the dialog, you even have the option of setting up your own event handler that gets first crack at every event precessed by the dialog's event loop. You also have the option of writing the entire event loop for the dialog from scratch. Or, you can use a non-blocking approach with FrmPopupForm, so that your main event loop continues to run while the dialog is open. I do agree that it would be nice if you could set up your own event handler that gets first crack at every event processed by FrmCustomAlert. Because the event queue refers to forms and form objects by ID, these events can't stick around when you switch applications. So, the OS flushes the main event queue when switching apps. Only the key queue survives the switch. The key queue is also thread safe, whereas the main event queue is not. My advice is to avoid using custom events for communicating information within your application. I think custom events may have some utility, but I do agree that they may do more harm than good because they sure seem more useful than they really are. So, what do you do instead? Well, there are probably lots of good alternatives. One approach to consider: Set globals that indicate that the app needs to do something. In your main event loop, before processing an event, check the globals, and in a suitable priority order, take the necessary actions. For low priority actions that should occur after processing all other events, check the globals in your nilEvent handler. -- Peter Epstein -Original Message- From: Blake Winton [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 8:48 AM To: Palm Developer Forum Cc: [EMAIL PROTECTED] Subject: RE: Events during Alert Box From: John Crouch [EMAIL PROTECTED] When an alert box is being displayed via the FrmCustomAlert() function call, my app does not receive any events. We have a need to trap events during this time. Am I missing something or is this correct - we don't get events when an alert box is up? No. There are a surprisingly large number of standard PalmOS functions that will shut your app out. This is ridiculous. I put up with, and even defend a large number of Palm's fairly obviously wrong decisions, (multiple-select lists, for example,) but this is the straw that broke the camel's back. Why even add user events, if we are going to lose them at random intervals? The alternative I employed was to write replacement functions for the Palm alert functions and to pray that people wouldn't bring up the keyboard and leave it there. If your only problem is with alert boxes then the replacement code isn't too hard to write. This was what we started doing, with our EventSafeFrmCustomAlert method, but after we found out that the keyboard dialog would eat all our events as well, we decided that we just can't go down that road. As Peter's reply indicated, the other answer to this is to implement low-level mechanisms at OS level to trap events below the interface. Doing this in a robust manner on a variety of PalmOS versions is a task I'm really not looking forward to. As a third alternative, we're looking into creating our own event queue which slurps up all the standard events whenever it gets called, and we would ask for events from it. That way any random Palm function could suck all the events off of the Palm event queue, and not cause the rest of our programs to fail. Has anyone done that before, and are there any obvious pitfalls I should avoid? The rest of the rant deleted here... Thanks, Blake. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Are background appliations supported in palm?
Using the procedural alarms feature of the alarm manager, it is possible to set up an application so that it gets a chance to run once a minute, even when the device is off. You can run even more often while the device is on. This is still just a single thread, but you're given a chance to do something on a periodic basis, which may be all you need? -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Events during Alert Box
I would agree that Symbol probably should have used virtual character events that go in the key queue rather than custom events that go in the general event queue. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: High density screens / Palm OS 5
The problem with winLockDontCare is that it doesn't just flip back and forth between two buffers, but rather allocates and then frees the second video buffer repeatedly. Since you have no guarantee of getting the same chunk of memory, you can't assume anything about the image data in the buffer. For example, parts of the memory could have been allocated as another chunk of memory that was used and then freed. So, even if the address of the buffer is the same as last time around, the actual content of the buffer may not be. This means you really can't use winLockDontCare unless you truly don't care. So much for updating the n-1 frame to get the n+1 frame. The net result is that very few game developers do hardware page flipping. Instead, they tend to leave the screen pointing to the same chunk of memory, and update that memory using either the OS blitter or their own custom blitter. This works, but it limits the frame rate you can achieve. What is needed is a way to use WinScreenLock/Unlock in which the video buffer is not copied and not freed/allocated every other frame. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: High density screens / Palm OS 5
Aaron Ardiri wrote: if your running on a device with VRAM - it does alternate :) but, looking closer at the code on devices that dont have VRAM, its a horrid mess.. badly written.. All true. So, I suppose if you know the device has VRAM, you can use the API for hardware page flipping. no, what we really need is a feature that lets us know what the display hardware is and the address of the controller register memory. people doing hardware flipping will take the time and write this code themselves. I think in fact we agree here. I definitely agree with you that PalmOS should define standard features that are set appropriately on each device to allow third party developers to test the hardware. This is critical to allow developers to safely talk directly to the hardware. And I'm sure you wouldn't also mind it if the OS provided an API for hardware page flipping. palm already does this with the CPU type (feature to let us know which CPU is there)... it'll be a very easy addition.. could even release patches that fix it for older units.. its just setting a feature.. not rocket science.. You'll get no argument from me! as a game programmer, i dont trust some college graduate that has zero knowledge of game programming to write a system level API routine like that.. anyone with any game programming knowledge would never have written the WinScreenLock() API's as they are written.. The API wasn't written for hardware page flipping. It's just that the API looks like it could support this, when in fact it doesn't. if you want something done right, you do it yourself :) a good programmer would check that the hardware exists before they start poking at it.. however, there are people out there that will ask how to do page flipping - and, palmsource can suggest the WinScreenLock() API's to get them started. Over time, it's natural to have the OS do more. And yes, that means putting up with problems. I think I'd rather have the OS provide a TCP/IP stack for me ;-) -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Mult Tables
Some form objects support a usable bit. If a form object isn't usable, it won't accept any events, and it won't appear on the screen. This is conceptually quite different than simply erasing and drawing a form object. Erasing the object will make it disappear from the screen, but it won't keep it from accepting and processing events. Tables don't have a usable bit. However, each row in a table has a usable bit, so if you set every row to be not usable, you should be able to effectively have two overlapping tables on the same form and switch between the two. Have a look at TblSetRowUsable in the docs. The other option is simply to have one table and to reload the table when necessary. You might also need to adjust the bounds of the table. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: LSSA Problem
You can NOT safely assume that color devices use a specific SED chip. New devices are constantly coming to market, from Palm, Sony, and others. The rule should always be that you first check out what you're running on, and only if you KNOW you've got a specific kind of hardware do you start poking around with it. Otherwise, you fall back to a slower but safe solution that uses the existing Palm OS APIs. When a new device comes along, you may have to update your app in order to get your app to take advantage of it's graphics hardware. Better that than the alternative: your app assumes the new device has some hardware that it in fact doesn't have, so it crashes. The question then becomes how to test various aspects of the hardware. This has been discussed on the forum before, and the answers aren't always as good as I think they could be. The Astraware folks gave an excellent presentation at the last PalmSource conference in San Jose that covered this topic. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: winEnter/winExit don't work properly with FrmDoDialog?
I tried the approach of watching the characters, and it was indeed a pain to maintain. The worst cases are the characters that sometimes bring up dialogs and sometimes don't. I recall two such characters. One is a low battery character that only sometimes presents a low battery dialog. Another is an attention manager character that only sometimes brings up the attention manager dialog. I agree that the winEnter and winExit event problem is indeed a flaw, and a fairly serious one. Somehow I don't think it's very easy to fix. If you can't rely on getting an event to notify you of something, you really can't do much with the event, and the whole thing has very little value. More than anything, it tempts you down a dead-end. One strategy I've tried is to read the tick clock before sending any event to SysHandleEvent, and then to check how much time has passed. If it's been too long, assume a dialog has been presented, and retroactively pause everything as of the time when the event was sent to SysHandleEvent. I can't say this strategy worked, but I think it can be made to work ;-) Sadly, there are no easy answers here. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: LSSA Problem
I work for the other half of Palm, so I really can't answer your question. I too would love to hear more details on how the Astraware guys detect the various hardware features and generally on how they do game development. Their games have a consistent polished quality that is quite impressive. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Palm OS 5 Simulator - Mac
From what I've heard (and believe me, I'm no expert on this stuff), the PowerPC supports giving each process it's own endianness. This should make it possible to implement a Mac simulator for Palm OS 5 that is little-endian. Byte-swapping would have to be done when moving data between the simulator process and any of the normal processes used by the OS, which would slow things down somewhat. I have no idea if this is really practical, but even if it is, I can understand the bias towards the PC. After all, there are so many more of them out there. Emulating an ARM processor on a Mac is practical, but the performance you can expect will be so much slower than any real ARM based device that using it for debugging applications might not be very practical. It sure looks like a PC is in my (and your) future. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Events during Alert Box
FrmCustomAlert calls FrmDoDialog, which has it's own event loop. You can set up an event handler that gets first crack at all events, but I think you'd need to call FrmDoDialog yourself rather than FrmCustomAlert. The other alternative that comes to mind is to patch traps (on 68K based devices) and use the new notifications provided in Palm OS 5 (on newer ARM based devices) to detect the events you need to. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: [OT] RE: LSSA Problem
Yeah, we're being split in two. At least we're not siamese twins ;-) -- Peter Epstein Palm, Inc. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: LSSA Problem
Some Astraware games definitely do detect hardware and use custom blitters tuned for that particular hardware (eg. Zap 2000 and 2016). I know lots of other game developers do the same thing. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Preference corruption caused by the Address application
One possible explanation is that you're using the same creator code and ID for your preferences as Address is using for it's preferences. When you call PrefSetAppPreferences, the first parameter is a creator code (it uses 'addr') and the second is an ID (it uses zero). You typically use the creator code of your own application, which is presumably different than the creator code of Address. Another possible explanation is that the preferences database got corrupted so badly that messing with one record is affecting another. You should try to reproduce this problem in the emulator. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Basic C question
Actually, this is a PalmOS specific programming issue, if I understand your problem correctly. You want to copy a string into a database record. To write to a database record, you have to use specific APIs that check to make sure you don't write outside the record you're intending to modify. That helps make the database more secure against data loss from a bug in an application. Normally, you used DmWrite to copy a specific number of bytes into a database record, but to copy a null terminated string, you use DmStrCopy. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Fixing 16-bit reference out of range errors
Re: the #pragma segment call Thanks. I guess this is one of those things that was added in the last century - uh - few years ;-) -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Fixing 16-bit reference out of range errors
If you use the small code model for your multi-segment app, and you arrange your code into segments in a logical way, the number of slow calls from one segment to another will be low, and the performance will be good. A large single segment application that uses the smart or large code model will be slower. Sharing global variables between segments doesn't require anything special on your part. However, if you break your code up into multiple compilation units, you have to get the compiler and linker to share global variables between compilation units (.c files). Any good book on C will explain how to do this. See, for example, page 103 of C: A reference manual by Harbison and Steele. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Debugging multiple segment application
Make sure the dot is there in the debug column for each of your .c files in your project window. Look for the little green bug, then scan down that column. Click where the dot should be to add a dot. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Debugging multiple segment application
I've never had any problem with this. I've done lots of multi-segment app debugging on Macs, but all using the old R6 version of CodeWarrior (don't ask). Sorry, I know that's little help. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Generate a particulat even
Add: MemSet(newEvent, sizeof(newEvent), 0); before setting up the event. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Generate a particulat even
In this one case, it probably doesn't matter, as the rest of the event is ignored. I found other instances where the MemSet was included in the sample code. In general, it's a good thing to do when setting up an event to be posted to the event queue, but in many cases, the attributes that aren't being set won't be read. It's just that if for any reason there is code that depends on one of the values not set, the value it gets will be quite unpredictable, leading to bugs that are tricky to track down. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Dialog to Capture Key Pressed
I didn't read you sample code, but here is one idea to consider: Add a second button to your form that is not usable. When you want to close the dialog after a key is pressed, generate a ctlSelectEvent for this button. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Dialog to Capture Key Pressed
Definitely set the pControl in the event. Also initialize the event with a MemSet call to clear out all the unused portions of the structure. I used this approach in the attention manager dialog, so I know it works. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Dialog to Capture Key Pressed
Get the pControl using the available APIs: First, get the pointer to the form. This can be done with FrmGetActiveForm or FrmGetFormPtr. Then, use FrmGetObjectIndex and FrmGetObjectPtr to convert the ID of the control to an index and then to a pointer. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: StrAToI
Try a string that reads like a number? -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: StrAToI
As others have already said, it isn't clear what number you're looking for. The routine you're using is for parsing base 10 integers. There is a corresponding routine for parsing hexadecimal integers. Apparently, what you want to do is something entirely different. If you're trying to convert a 4 character creator code to a UInt32, then you want what might be called base 256. This can easily be coded up, but there is no OS support for it. Read one digit at a time. Start with a zero result. Before adding in the next digit, shift the result by 8 (multiplying it by 256). Then add in the next digit. Repeat 4 times and you've filled your UInt32. Of course, that will only handle a 4 character string, but that's the way it goes. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Dialog to Capture Key Pressed
If you want the DMSPopupDialog routine to block, returning only when the user closes the dialog, I'd use FrmDoDialog rather than FrmPopupForm. You can still set up your own event handler for the dialog, and you can prepare the dialog and draw it before calling FrmDoDialog. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Misc Dm record questions
1) DmFindRecordByID does a linear scan, so it's not that fast. 2) Yup, all correct. The only caveat is that unique IDs aren't 100% absolutely positively guaranteed to be unique. There are some probabilistic strategies used here, so if you want to be safe, you can create your own unique ID and store it within the record. 3) The record header is currently 8 bytes (4 bytes for the handle, 3 bytes for the unique ID, 4 bits for the category, and 4 bits for flags such as the dirty bit. This may change. Then there is the chunk overhead of the memory manager. I don't know that off the top of my head. 4) There are a few helper routines such as DmStrCopy, but you can also use DmWrite directly to move parts of a record around before or after resizing the handle. You can also allocated a new chunk using DmNewHandle, fill it all in, and then use DmAttachRecord to detach the old handle and attach the new one in it's place. Finally, you have to free the old handle. This is a bit safer if you're worried about the user hitting the reset button during a long operation that involves lots of such record resizes. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Fixing 16-bit reference out of range errors
Smart code model isn't actually very smart. It results in a performance and space penalty, but it does let your app grow right up to the 64K limit of a single segment without any extra work on your part. Changing the link order is really easy, and often works to solve your immediate problem, but as the app continues to grow, it gets harder to find a link order that works. At some point, it's worth the work to switch to multiple segments just to avoid this headache. If you have one monolithic .c file, then changing the link order is a much bigger job, as CodeWarrior doesn't support specifying the link order within a compilation unit. Breaking a .c file into pieces is a nice thing to do anyway, but it does require some C language skills that you can get by without when you've got just one big file. Jump islands just seem like too much of a hack to me, but I've seen code that uses them, and it does let you continue to use the small code model without having to break up your code into multiple files in order to let you specify the link order. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: sysNotifyEvtGotEvent
If I recall correctly, that notification was added in PalmOS 4.0 and removed in PalmOS 4.1. My advice is not to use it. Check out the new notifications in PalmOS 5. There are some that have a narrower scope that makes them less of a performance bottleneck. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Locking the Device at a Preset Time or after being inActive f or xx duration?
If I recall, this capability is built into PalmOS 4.0. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Multiple Resource Files
We're getting around to upgrading. Really we are ;-) Anyway, that's just one more reason that using multiple resource files is just fine. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: What prevents draw APIs from working?
Well, a few things comes to mind: 1) WinDrawChars uses the textColor rather than the foreColor. Have you called WinSetForeColor? Perhaps the foreColor is the same as the backColor? 2) What is rP? If the extent is zero or negative in either x or y, then it may not draw. 3) Verify your clipping bounds. This would affect both text and rectangles, but best to be sure. Call WinGetClip and use the debugger to verify that the resulting rectangle covers the region you're drawing on. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Beaming app deletes data
I remember hitting this same bug a couple of years ago. Annoying one isn't it? When the Launcher asks the user whether it's okay to replace the existing app, and the user says yeah, go ahead, the Launcher was deleting not just the app, but all associated databases as well. This means a user who upgrades by accepting a new version beamed from someone else's device ends up losing all their data. Not good. Work-arounds exist, but they have their problems. For example, you could give the new version of your app a new creator. That would let it coexist on a device with the old version, and it would mean the user would have to delete the old version. They might delete the old version before running the new one. So, to be sure you transfer their data in time, you'd catch both the reset and sync notify launch codes, and check for old data at that time, moving the data into a database with the new creator. You could go a step further and automatically delete the old version of the app. Or you could document the problem and hope it doesn't catch too many users off guard. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Tables, example?
The sample code for the built in applications is a very valuable resource. Just think for a moment about where you've seen the behavior you want in your application, then go find the source code and see how it was done. For example, you say you'd like to use dates and checkboxes in tables. Well, the To Do application uses check-boxes and dates. The checkboxes are obvious. To see dates, hit the Show... button and turn on Show Due Dates. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Multiple Resource Files
I like to use one file per form, but I think either way works fine. If you use Constructor to edit your resource files, and you have more than one, you will get warnings about duplicate uMWC resources (at least this is the case on the Mac). These resources are used only by Constructor, and so there really is no problem. If you're on a Mac, you can create a resource merge target to work around this problem. Or you can just live with the warnings and disregard them. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: TblGetItemBounds not reflect row height change?
I agree that the PalmOS tables are weak in this area. But I don't see it the way you do. The row height need not match the item heights. Each item can have it's own height. What would be nice is a TblSetItemHeight function that applies to some item styles such as custom, that don't have any obvious item height of their own. Item styles such as label, check-box, and field would give errors if this function was called on them. If you want to work with pre-4.0 devices, you can't use my new item style. I'm not the best person to answer the question of how to do it. The authors of apps like AsciiChart that were fixed to work properly on the older OS versions could answer better than I. However, here is my best guess. Get access to the OS source code. Look at table.c and see how you can override it's behavior by catching events and processing them yourself. For example, instead of letting the table deal with highlighting the row as you drag the stylus around, do it yourself with your own EvtGetPen loop. Start this up on a TblEnterEvent, and if the pen is inside the row when it is released, generate a TblSelectEvent, just like the code it table.c does. In short, use tables but override some of the table logic to get the correct behavior. I'm sorry I don't have a more detailed answer. One other thought: there may very well be an application out there that has had to solve this problem, and whose source code is available. Perhaps a bit of time spent on this might be well rewarded. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: TblGetItemBounds not reflect row height change?
Good point about using a gadget. In your case, all your table items are custom. So the table isn't really doing that much work for you. When a table really comes in handy is with editable fields within the table. Either way should work. The advantage of sticking with tables is that you can simplify your code more easily in the future once you no longer need to support pre-4.0 devices. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: TblGetItemBounds not reflect row height change?
The row height is used properly in all cases, as far as I know. Tables don't require all (or in fact any) of the items in a row to use the entire height of the row. The row height is used correctly to determine how much further down the next row starts. You have pointed out a bug in the table code (as well as the obvious annoying limitation that was fixed in 4.0). A custom table item is given the full row height when it is asked to draw itself, but only highlights itself if the tap is within the top 11 pixels. That inconsistency should be corrected. Also, the documentation is lacking in that it doesn't spell out what the height of each item style is. The problem with making all custom table items take the full height of the row they are in is that it can break compatibitily of old applications. That's why I created a new custom item style with the new semantics in Palm OS 4.0. It could be argued that the old item style is really a bit silly, and should be deprecated so that it can eventually be removed from the OS source code after application developers have been given a chance to switch to the new item style. Of course, none of this will help you in your immediate problem. For that, you need to write your own EvtGetPen loop. I think you'll find this isn't actually that hard once you've seen how the table code does it. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: TblGetItemBounds not reflect row height change?
I don't think we can fix this inconsistency by changing the highlight logic to highlight the entire row height for custom table items. There will be apps out there that have custom table items and don't want such a large highlighted area. Take, for example, the times shown in the Datebook day view. These are custom items, and they're in rows that also contain text items. These text items can span multiple lines, making the row height much greater than 11 pixels. Tap on a time to change the event time (or create a new event at a nearby time), and while the pen is down, the time is highlighted. You wouldn't want the entire row to be highlighted. It would look funny. Even changing the bounds passed to the draw callback might break some code. The safest strategy is to leave it inconsistent, but create a new item style or styles that have a consistent behavior. Then the old item style can be deprecated. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: TblGetItemBounds not reflect row height change?
I'm not saying that apps can't control row heights. The APIs let you set the height of each row, and they work fine. What I'm saying is that table items don't always consume all the height available in the row they are in. You have some control over how much of the row height is used by an item via the itemStyle. In other words, it's not enough to set the row height to something more than 11. You also have to use an item style that uses the extra height available in the row. Since you're using customTableItem for all your table items, it should be easy to do this: just use the new tallCustomTableItem instead. This should work for PalmOS 4 and newer. To support older OS versions, you'll need to do a bit more work. To be sure, the inflexibility of some table item styles to support different heights is annoying. I remember running an early version of an ASCII chart that didn't work when you tapped on the bottom portion of an item. You're not the first person to run into this problem. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: TblGetItemBounds not reflect row height change?
The row height need not be the same as the item heights. Sure, the item heights can't be any larger than the row height, but there is no reason all (or even any) items in a row have to take all the height available. Each item style has it's own rules for determining the item height. Many are by definition one line in a specific font (11 pixels). In Palm OS 4.0, I added a new item style called tallCustomTableItem that uses the row height rather than the font line height. Just change your item style from customTableItem to tallCustomTableItem and you should be all set, assuming you limit your application to run on Palm OS 4.0 and later. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Thousands separator
Don't forget to get the user preference for the decimal and thousand separator characters rather than hard coding the characters used where you live. Note that the characters used for thousand separator can also be a space or appostrophe (or a comma or period). PalmOS 4.0 added these two extra characters to the LED font for this very reason. - Peter -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: FATAL EXCEPTION after syncing
Temporarily hack your code so that it does absolutely nothing on the sync notify or reset launch codes. That includes commenting out code that runs on all launch codes! Be thorough. Then see if it still crashes when installed via HotSync. If not, you can easily isolate the cause of the problem. It could be code that's accessing globals when it shouldn't (e.g. putting the min OS version for the OS version check in a global). It could be code that needs to be in the first segment but isn't. - Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: Finding problems with Gremlins and solving them
You should be able to source level debug a POSE gremlins session. Before starting the gremlins running, build your app, enable debugging, and run it from CodeWarrior. Step past the initial breakpoint and then go to the POSE window and start Gremlins. I don't think you want to use the hordes or Gremlins minimization. Instead, when you get an error, just hit the debug button on the dialog and you should break into the CodeWarrior debugger with your stack and other state ready to analyse. PalmDebugger can also be used. You don't have to connect it up to POSE in advance. Just leave the error dialog from POSE on the screen, go start PalmDebugger and set it up to talk to POSE, and you're all set. All comments above are based on working with a Mac, although I don't see why PC would be any different. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE: using DmQuickSort
If you want examples, see the source code for the example applications included with the SDK. For example, Memo Pad keeps it's records in alphabetic order if the user chooses that option in the preferences. Since the conduit places new memos at the end, Memo Pad must sort the database when HotSync has finished. If you look at the source code for Memo Pad, you should be able to find where it catches the sync notify launch code. This will lead you to an example of using quicksort with a very simple comparison function. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: PalmOS 4.0: blank screen after time change?
I would suggest doing your time updating on the trigger launch code and setting the purgeAlarm flag within the launch parameters, so you never get the display launch code from the alarm manager. What you're trying to do is a background action that doesn't present any user interface. For that kind of thing, the trigger launch code is appropriate. The vchrAlarm event that the alarm manager generates in order to do the display launch code can have unwanted side effects. That said, I don't see how this would cause the behavior you're seeing. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: Clearing a WinDrawChars
WinEraseRectangle -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: vchrPageUpWhenOff
Ignoring the twisted history for the moment, it's clear that developers writing for specific Palm branded devices such as the m100 or m500 series may very well want to take advantage of device specific features just as people do with Sony's jog dial and high resolution APIs. I would hope that Palm's SG business would eventually release it's own header files just as Sony does. These header files would supplement rather than replace the PalmOS SDK header files. It makes sense for Palm device specific characters to be removed from Chars.h. In an ideal world, the SG specific definitions would have been provided at the same time as the new version of the SDK, but things aren't nearly that organized yet ;-) The virtual character range reserved for Palm branded device specific features has been corrected in the PalmOS 4.0 update 1 header files. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: vchrPageUpWhenOff
The m100 series devices have a feature that when the device is off, the up button can be pressed to turn on the device briefly and show a popup clock dialog. Holding down the up button will also activate the backlight. When the up button is pressed while the device is off, a different character is generated than when the same button is pressed while the device is on. This character causes another character to be generated that in turn pops up the clock. At least I think that's how it works ;-) Tapping on the clock silk-screen button should not generate the first event in the sequence. If you want to write code that does stuff like this, just make sure you're running on an m100 series device in order to avoid problems with Sony devices that ended up using the same range of character codes due to the mixup. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: digitizer information
I don't think the hardware is capable of sensing pressure. I think the best you can do is to determine whether the pen is up or down, and if down, where. That can easily be done using the PenGetPoint routine. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: 4.1 or i705 Bug
As far as I know, a vchrAlarm event will close a popup list on any version of PalmOS. I believe the problem here is not that this event closes the popup list, but that this event is being generated in the first place. This event occurs when the alarm manager wants to send the display launch code to an application. If you're using the alarm manager for background tasks, you need to avoid sending this event by telling the alarm manager not to do the display launch code. I know you'd think you could just let the launch occur and ignore it, but for this very reason you can't. So, when you get the trigger launch code, set the purgeAlarm flag. Now, it may very well be the case that an i705 generates these events even if no software has been installed (just after a hard reset). If that is the case, it's a bug. The cause would be one of the built in applications using the alarm manager incorrectly. If that is indeed the case, please let us know so that we can track down the culprit. Thanks! -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: lightweight sorted containers
If the data you want to keep sorted is large or needs to persist across runs of your application, you'll want it to live in the storage heap. That complicates things when it comes to using data structures that are designed for random access memory. Just something to think about. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: 4.1 or i705 Bug
Yeah, that's what I was thinking too [email polling]. Probably a bug in the ROM. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: When will they realize they are providing an operating system ? (was: Re: Inconsistency in the SDK docs?)
I can't comment on what the future holds, as I really don't know. What I will say is that you're quite right when you describe how the OS and applications were originally developed. There was no wall between the two, and the OS really was just enough to get the job done for the applications that shipped on the ROM. This was probably the right thing to do at the time. A huge amount of progress has been made towards turning Palm OS into a real operating system over the years, and I too hope that the split will lead to further improvements in this area. With Palm OS 5, remember that the decision to hide internals is a technical one rather than some new philosophy. In the end, I hope that it helps make Palm OS more of a real OS, but I don't think that's the driving force behind it. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: When will they realize they are providing an operating system
I'm really not the right person to answer your questions, and I'm sure I'll make some mistakes, but here goes anyway... The decision to disallow access to internals of some structures was made because those structures have a different layout in memory on an ARM than they do on a 68K. The differences are caused by two things: endianness and packing rules. The result is that in order to expose such a structure, the operating system would need to maintain a shodow structure that is arranged as the 68K would expect it to be, and deal with propagating changes between these two structures whenever either one was changed. Such shadow structures are used in PalmOS 5, but adding a bunch more is best avoided. That is what little I think I might know ;-) Hopefully others will correct me if I'm wrong. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: SDK 4.0 Update... where?
As far as I can tell, that URL gets you the 4.0 SDK, not the new update 1 SDK. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: i705 ROM available?
I agree that it's a pity the way the LED ended up being handled differently on our devices. Vibrate is at least consistent across all the devices, stopping on it's own after a little while. As I understand it, the reason the m500 series LED stops blinking after a little while is that leaving it going would consume too much power. So, I'd expect future non-wireless devices to continue this trend (as they don't have a radio that sucks lots of power, and therefore can afford to use smaller and lighter power sources). If you override the resources used by the attention manager to specify the LED blinking pattern, you should be able to make the LED stop blinking after a while, just as it does on the m500 series. If the user dismisses all the requests, the attention manager will stop the LED for you, assuming it is still blinking. In short, you should be able to make the LED behave as it does on the m500 series by just overriding some resources. The question of how to detect the device you're running on has come up many times on this forum. I'm not familiar with the techniques, as I work mostly with apps that live in ROM. It should be possible to detect whether you're running on the i705 easily enough, but that's not really what you want to do. You want to know whether the LED will continue to blink indefinitely. This can be determined by getting the values of the resources used to specify the LED blink pattern. I'd verify this by testing it on an m500 series device and an i705 (using POSE), but I think you can read the 'tint' resource with ID 13503 to determine the repeat count. If this is zero, it repeats forever. If it's any other number (eg 3), then it repeats that many times and then stops on it's own. This is how I'd decide whether to use the LED or not. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: what is the correct generic term for a PalmOS device?
I've heard several variations over the years, but most recently it's been either PalmOS device or Palm Powered device. I don't like the sound of the latter, so I use the former. I have no idea what the official policy is, but I do know that simply Palm is not considered acceptable. For end user documentation and tip text in the application, if it's been stated elsewhere that the product is for PalmOS devices, I like to use the term handheld to refer to the device. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: POSE 3.4 memory leak question
If I recall correctly, POSE was changed recently so that when running Gremlins with just your application checked off (no other apps allowed to run), you now get app stop events every once in a while. I think this explains why the memory leak was being reported as early as it was. And just because it's so appreciated, I'd like to thank Keith for implementing this feature! -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: Pop-up lists close when alarm is triggered
The alarm manager generates a vchrAlarm character when it is triggered in order to arrange for the display launch code that follows the trigger launch code. This character is what is causing the popup lists to close. Since the vchrAlarm typically opens a dialog, this makes sense (we don't want a dialog to open on top of a popup list). Since you're not presenting a dialog (or doing anything else when you get the display launch code), you can tell the alarm manager not to send you a display launch code. This will eliminate the vchrAlarm, and your problem should be solved. The launch parameters for the trigger launch code include a purgeAlarm boolean that you can set to true. This should do the trick. See the AlarmMgr.h header file and/or the documentation for more details. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: Cmd System Reset problem
Ouch! Modifying a collection while iterating over it is a classic no-no. Unless this is changed, the documentation for this launch code should forbid database creation or deletion. To work around this limitation, you could use the alarm manager to delay the action you wish to take. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: POSE 3.4
Based on your description, I'd suggest you switch from using buttons to using one or more gadgets. That way you can make it look and feel exactly as you like. It's a bit more work, but perhaps it's worth it? -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: Multiple database
One thing that's a bit tricky is implementing global find support over multiple databases. The APIs don't really give you much of a place to specify which database the various hits are located in. Feature manager can help you store extra information. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: Palm Simulator / POSE : accessing video RAM
First of all, the new Palm simulator for Windows simply can't report as many errors as POSE can. It's an inherent limitation of the approach used. Just because this simulator doesn't complain about something doesn't mean a thing. If POSE complains, you probably want to change your code to avoid the problem. Secondly, WinScreenLock, as currently implemented, does not support hardware page flipping for double buffered animation. The problem is that in order to do proper double buffering, you need the display address to jump back and forth between two fixed buffers. Then, when the screen is looking at one, you can update the other. This is hard for the developer because it means the update logic has to jump two frames at a time instead of just one. The advantage is that you do less copying. Today, there is no guarantee that you'll get the same address every other time you call WinScreenLock. I too would like to see true double buffering support in Palm OS. Until the day that happens (and even then, you'll want to support older devices that don't have it), here is what I suggest: Do single buffering. Maintain your own off-screen window. Draw the next frame on that window. When it's ready, copy it onto the screen. To make it faster, keep track of one or more damage regions, and copy only the damaged (dirty) portions. The address of video memory is not changed in this scheme. This approach isn't as fast as true double buffering, but many game developers have been quite successful using this approach. Astraware gave an excellent talk at PalmSource on this topic. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: segments in OS 5
Regis Nicolas wrote: ... But since it's not possible to develop ARM native code for Palm OS 5.0, I am not sure of how much an issue this is. While it isn't possible to develop ARM native applications in Palm OS 5.0, it is possible to develop ARM native code that gets invoked by a 68K application on that OS. As a PalmSource programming contest entry, John Marshall used this approach to implement a Mandelbrot Set viewer that ran very nicely on ARM hardware. I'm sure you know all about the ARM native support in Palm OS 5.0. I just want to clarify so that others don't think we're leaving them out in the cold with no way to take advantage of the extra horsepower that ARM native code provides. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: Multi-CPU Compilers and OS
The key is to profile your application to find the bottlenecks. Look for bits of code that do a lot of heavy computation with as few OS calls as possible. These are your candidates for porting to ARM native code. Of course, optimizing your code without reverting to ARM native code is also a valuable alternative. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: Multi-CPU Compilers and OS
I'm a little confused by your comments. I'd expect a custom optimized blitter you wrote for a 68K based Palm device to be slower than the OS blitter in Palm OS 5 because the former will be emulated while the latter will be ARM native. What was once faster is now slower. The reason the emulator is indeed fast is that most of the time an application is running it's in an OS routine. All the OS routines are now ARM native, so they run nice and fast. If you've got a processing bottleneck in your application (such as computing values in the Mandelbrot Set, as John Marshall did), these will have enough work to do that even when running ARM native, they'll still swamp the overhead of getting to and from ARM native code. If instead you have something that gets run a huge number of times, and is a bottleneck only because of that, then porting it to ARM won't help you. You need to get that inner loop into ARM native code! Don't trust your intuition when it comes to optimizing code. Run a profiler such as the one provided in POSE, and examine the results carefully. When you do find a bottleneck and optimize it, another bottleneck will be exposed. You can keep doing this, but after a few iterations you'll tend to have no one big bottleneck, but rather a bunch of separate things that each take 20% of the time. That's a good time to stop ;-) -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: Multi-CPU Compilers and OS
I'm impressed that you've managed to outperform the OS APIs even when they're ARM native and you're emulated. Porting your custom blitter to ARM native code will really fly! -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: Multiple database
I'm not sure what you mean by sections. There is no reason to use multiple databases just because your code is divided into multiple code segments or multiple compilation units (.c files). Code segments are primarily a way of creating an application that's bigger than 64K without breaking the 64K per record/resource limit imposed by HotSync. Multiple compilation units are a way of organizing your source code. It is also easier to associate functions with code segments in some development environments if you split the functions into several compilation units, and assign each compilation unit to one segment. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: Multiple database
Using one database for each type of record can make things easier, since it means all the records have the same format, and you don't have to worry about skipping over records of the wrong type. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: Palm OS 5 and built-in apps database access
Note that if all you want to do is add records to a PIM database, you can use the exchange manager's local send capability that was introduced in PalmOS 4.0. For queries or edits of existing records, you'll have no choice but to continue directly accessing the databases in PalmOS 5.0, despite the fact that this will almost surely fail in the next OS release after that. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: i705 ROM available?
The LED will indeed continue to blink red on the i705. The AttnDoSpecialEffects API just invokes the same blink pattern that the attention manager itself uses. On the m500 series, this pattern terminates after a set number of iterations. On the i705, this pattern continues indefinitely. There is no API available within the PalmOS SDK for turning off the LED. There is an API in the hardware access layer, but it's not part of the SDK. Since the attention manager fetches this blink pattern from a resource, you can change the behavior of both the attention manager and those applications that use AttnDoSpecialEffects by creating your own version of this resource in your own resource database that you open on device reset and sync notify, and that you set to stay open even after your application exits. This takes advantage of the fact that when the OS tries to get the value of a resource, it looks through the chain of open resource databases, starting with the database that was opened most recently, until a resource with the specified type and ID are found. By comparing the resources of an m500 series device with those of the i705, you should be able to figure out what resources you need to include in this database. Look at 'tint' resources in the range from 13500 to 13512. I wish all this was in the public headers of the SDK. Remember to check the device ID to make sure you're on an i705 before hacking these resources! An alternative simpler approach is to just use the attention manager rather than AttnDoSpecialEffects. That way, the attention manager will take care of turning off the LED when there are no more attention requests pending. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: invert color for a particular object
You can use the swap mode of the blitter to swap any two colors. It's not the fastest graphic mode, but it will let you swap any two colors within a specified region (such as a rectangle). In general, it's best to just redraw things using the desired colors, but swapping can be a quick and dirty solution if used with care. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: OS 5 == High Development Cost?
From what little I know, the new simulator is in many ways like the old one: The old one took advantage of the fact that Macs used to have 68K processors, and therefore could at least emulator one. It also took advantage of the fact that PalmOS resources were stored as MacOS resources. The result was something that ran much faster than the emulator, ran only on the Mac, and acted like one generic device rather than emulating all the details of any one specific real device. The new one takes advantage of the fact that the CPUs used in PCs have the same endianness as the ARM. Because the actual processors are different, the entire OS ends up being compiled into a different instruction set, but the packing rules and endianness mean you can still access data in the same way. The result is once again something that runs much faster than the emulator, but this time it's only on the PC. Sad for us Mac-heads, but all smiles for the Windows crowd. Again, the simulator acts like one generic device rather than emulating all the details of any one specific real device. Because of the approach taken in implementing the new simulator, the code involved in much more cleanly separated from the core OS. Another advantage of the new simulator over the old is that it can run multiple applications rather than being stuck in one. This is a major improvement. You also get visual tools instead of command line tools for viewing memory and such. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: Bitmap Animation - Clarification?
The OS supports switching the display between two different chunks of video memory using the WinScreenLock and WinScreenUnlock APIs. This API isn't supported by all devices. Also, the only way that this API can really be used for double buffering is to have the OS copy the entire screen every time. This is too slow to be useful for game animation. This API wasn't designed for double buffering, so it isn't actually surprising that it doesn't work out. The important thing is to understand the limitations of this API so you don't get fooled into thinking it can do something it really can't. So, the result is that you generate the next frame of the animation in an off screen window and then copy the necessary portion of that window to the screen, just as Tilo explained so well. There is another way that's based on exclusive ORing to draw and then erase the car. This can be made to work with a multicolor car on a white background, but if the car overlaps anything, the resulting colors will be all mixed up. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: Creator ID
Try this link: http://dev.palmos.com/creatorid/ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: Continuous Fatal Excpt on Install, fine on Pose others...
If it crashes on a soft reset, it's probably the code that runs when your app receives the reset launch code. If it also crashes on an install, it's probably the code that runs on a sync notify launc code. That tells me the most likely cause is some code that runs on all launch codes, probably outside the switch statement for the launch code. Try commenting out all code that runs outside of that switch statement as well as any code that runs on sync notify and reset launch codes. If it no longer crashes on install or on a soft reset after the install, then you've narrowed down the problem. Perhaps you're accessing globals or code in other segments. You might try an up arrow reset rather than a hard reset. This will avoid sending the sync notify launch code to the applications. This will almost surely let you keep the app on the device even if it misbehaves. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: Continuous Fatal Excpt on Install, fine on Pose others...
As usual, Bob comes through with an excellent practical approach to debugging a problem! I'll try your approach the next time the opportunity presents itself. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: Raw Data Date Representation
By my calculation, the difference in the binary values is 30 while the difference in dates is 28 days. That implies the representation used is not simply a day count from some baseline date. I suspect it's a bit field that has bits for day, month, and year. I assume you've checked and found it doesn't match our DateType (7 bits for year, 4 for month, and 5 for day)? If not, I'd take more samples, choosing samples that vary in only one way (day month or year) and see if you can determine the bit field used. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: Yikes!! Syntax errors after multi segmenting app to large mod el
Are you switching from the small memory model to the large memory model, or from a single segment to multiple segments? If the latter, you probably want to use the small memory model, as it will produce a smaller PRC that runs faster. As for your syntax error, you can use the compile command to compile any given .c file. If they all give syntax errors, check your prefix file. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: A bunch of new questions
You shouldn't need to do anything special before or after accessing a global variable. There are times when you're not allowed to access your globals. Somehow, I don't think this is one of those times. Perhaps you're just going outside the bounds of the array? -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
RE: Launch self on sync notify?
Since the sync notify launch code is sent to multiple applications after a HotSync, it would be a bad thing if your application responded to it before all applications were notified and given a chance to react. I suggest setting up a timer (using the alarm manager) to launch yourself in a little while. Instead of immediately switching to your application when the timer expires, I suggest waiting for the display sub-launch from the alarm manager and presenting a dialog at this time. If the user chooses to decompress the application and run it at this time, he can tap the corresponding button. If not, he can tap the Cancel button. This puts the user in control of app switching, and that's a good thing. -- Peter Epstein -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
