Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
Subject: Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent From: Dr. Vesselin Bontchev [EMAIL PROTECTED] Date: Wed, 4 May 2005 14:02:19 - Again, you fail to understand what's going on and are trying to use your background in disk-based OS to understand Palm OS (and therefore mis-undertand) I understand it very well - and I insist that what I said is right and what you said is wrong. In PalmOS all programs DO NOT run in the background all the time. Yes they do. But apparently no one can tell you anything. Note: This statement only covers programs located in RAM. This are a lot more powerful as you receive these in background mode and can service them regardless of what the foreground program is doing. They are most definitely *not* more powerful. At best, they could be just as powerful, because they allow you to do essentially the same things. In practice, they are less powerful, because your background program cannot receive them until the foreground program allows it to; there is absolutely no support from the OS in that aspect. Foreground programs run using the event loop, and every time they pass around the event loop the OS gets control and can send launch codes and notifications to the other programs on the unit, all of which are running in background mode all the time. Note: This statement only covers programs located in RAM. In Palm OS, the vast majority of foreground programs are truly GUI based, and therefore have to keep the event loop going in order to service the GUI. While it is possible for a program to ignore the event loop, the reality of the need to service the GUI ensures that the vast majority of programs are actually well behaved in this respect. If you (or anyone else) are going to have a process that runs for any significant time (say more than 0.5 sec) you should either use the Progress Manager or build your own using a dialog screen, and either way cycle through the event loop on a frequent basis to maintain the GUI and let the OS handle whatever else it needs to handle. Roger Stringer Marietta Systems, Inc., P.O. Box 71506, Marietta, Georgia 30007, USA 770-565-1560 PDE, RF-TP and piDB are trademarks of Marietta Systems, Inc. http://www.rf-tp.com -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
All programs can run in Palm OS background all the time. Nope, they don't. They reside in memory all the time - but at any given time, only one of them is actually running. They aren't given timeshares or even timer tick interrupts by the OS, either - something which is used on many OSes to implement pseudo-concurrency. Again, you fail to understand what's going on and are trying to use your background in disk-based OS to understand Palm OS (and therefore mis-undertand) I understand it very well - and I insist that what I said is right and what you said is wrong. In PalmOS all programs DO NOT run in the background all the time. It is true that on any single processor system only one program is running at any one time So, what I said is correct. And I agree that one missing aspect of Palm OS is the lack of a clock time event or notification, which would allow background programs to get a little bit of processing time (say) 10 times a second. So, what I said it correct. But instead of this your program receives all system-level events and those notifications it has registered for. My point is that it receives them ONLY when the foreground program stops running and *allows* them to receive these notifications. Have the foreground program run in a loop and nothing else will reaceive any notifications until this loop terminates. In an interrupt-driven environment, the currently running program will be *interrupted* by the event, so that the program(s) that have registered to receive the event have their chance to run and process it. It PalmOS the background applications don't run all the time at all - they don't run until the forgeround application stops running (i.e., is idle or terminates). This are a lot more powerful as you receive these in background mode and can service them regardless of what the foreground program is doing. They are most definitely *not* more powerful. At best, they could be just as powerful, because they allow you to do essentially the same things. In practice, they are less powerful, because your background program cannot receive them until the foreground program allows it to; there is absolutely no support from the OS in that aspect. However, because the OS doesn't automatically take back control from a program after any specific period of time or after specific occasions, you have to be well behaved in your background processing and not do too much before handing control back to the OS by exiting your program. In other words, what I said is correct - the background programs are not running all the time - they are waiting for the well behaved foreground application to deigns to allow them to run. Given the nature of your software, I'd recommend you restrict it to Palm OS units running OS of 3.5 or greater, and perhaps you should restrict it to OS 4.1 or greater. Why? Currently I have restricted it to PalmOS 3.0 or later, but I disable parts of the user interface that are related to functionality not available to the current OS version. For instance, currently I disable the ability to scan on program launch in OS 6.x, the ability to scan on card insertion in OS before 4.0, and the ability to scan on HotSync completion in OS before 3.5. Originally I thought of allowing the program to run under PalmOS 2.0 or later, but there are several beaming-related features that I didn't want to disable. Regards, Vesselin -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
Despite the public documentation, Palm OS is a multi-tasking OS. I'm aware of that. I have myself posted here links to a program that demonstrates this: http://flippinbits.com/twiki/bin/view/FAQ/HowDoICreateAThread That program definitely works under PalmOS 3.5 - maybe even under some of the earlier versions. Still, I'd rather avoid such tricks, if possible. The following undocumented calls are identified in some of the information that I gathered about YAHM: KALTaskCreate, KALTaskDelay, KALTaskDelete, KALTaskGetCurrentID, KALTaskGetInfo, KALTaskResume, KALTaskSuspend, KALTaskStart, KALTaskSwitching, KALTaskWait, KALTaskWaitClr, KALTaskWake, KALTaskExit, SysTaskCreate, SysTaskDelay, SysTaskDelayV40, SysTaskDelete. There is also a bunch of stuff related to semaphores that have meaning only in multi-tasking control: MemSemaphoreReserve, MemSemaphoreRelease, SysSemaphoreCreate, SysSemaphoreDelete, SysSemaphoreWait, SysSemaphoreSignal, SysTaskID, SysTaskUserInfoPtr, SysTaskSetTermProc, SysSemaphoreSet, SysRestoreStatus, SysResSemaphoreCreate, SysResSemaphoreDelete, SysResSemaphoreReserve, SysResSemaphoreRelease, SysTaskSwitching, SysTaskWait, SysTaskWake, SysTaskWaitClr, SysTaskSuspend, SysTaskResume; probably others. There is very little documentation from Microsoft about how to write a MSDOS TSR. Certainly not enough to write one. TSRs were developed by the developer community, not by Microsoft. The Microsoft attitude toward TSRs was primarily silence, with occasional warnings and disclaimers. Not unlike what we're seeing now with Palm. Dunno about Microsoft but I definitely learned how to write a TSR program from a DOS programmer's reference - although it might have been from one of the clone DOSes (e.g., PC-DOS). A better example is the hacks in PalmOS - Palm kept mostly silent about them and they were developed by the user community - although eventually Palm *does* mention them glancingly in the official documentation. Not using undocumented facilities to detect viruses assumes that all viruses follow the same rules. No, it doesn't. Countrary to popular belief, anti-virus programs and viruses don't play by the same rules. I usually don't need to do undocumented tricks in order to detect a virus that uses some. Occasionally, the opposite is also true - I might have to use undocumented tricks in order to handle a virus that does everything by the book. The idea that using only documented facilities will protect you from changes in future OS versions is naive. Refraining from using undocumented features, of course, won't guarantee you a protection from quircks in futures versions of the OS. However, if you *do* rely on undocumented stuff, you're virtually guaranteed to have trouble with the new versions. This is exactly what YAHM does. Palm is not going to tell you how to do this without some legal leverage on how you use the information. First, I don't think that I need it. Second, I don't believe that the author of YAHM got this information from Palm under NDA, did he? :-) Regards, Vesselin -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
One undocumented feature that you should probably be interested in is the entry point for Arm native applications. Arm native applications have resources with names like ARMC, and do not have any CODE resources. In any case, it's the first instruction of the ARMC resource. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
Subject: re: Strange error when trying to intercept sysNotifyVolumeMountedEvent From: Dr. Vesselin Bontchev [EMAIL PROTECTED] Date: Sun, 1 May 2005 16:42:28 - All programs can run in Palm OS background all the time. Nope, they don't. They reside in memory all the time - but at any given time, only one of them is actually running. They aren't given timeshares or even timer tick interrupts by the OS, either - something which is used on many OSes to implement pseudo-concurrency. Again, you fail to understand what's going on and are trying to use your background in disk-based OS to understand Palm OS (and therefore mis-undertand) It is true that on any single processor system only one program is running at any one time, even with a multi-tasking OS running a thousand different tasks. And I agree that one missing aspect of Palm OS is the lack of a clock time event or notification, which would allow background programs to get a little bit of processing time (say) 10 times a second. If Palm had supported this then a lot of classic background processing could have been done a lot, lot easier. This is very high on my short-list of stuff Palm should have done, but didn't. But instead of this your program receives all system-level events and those notifications it has registered for. This are a lot more powerful as you receive these in background mode and can service them regardless of what the foreground program is doing. However, because the OS doesn't automatically take back control from a program after any specific period of time or after specific occasions, you have to be well behaved in your background processing and not do too much before handing control back to the OS by exiting your program. Or pop-up a progress window so the user knows you are doing some processing, which may involve a separate initiation of your program using one of the techniques described in earlier e-mails. The need for this separate initiation is driven by whether the event or notification requires you to handle it very, very quickly, as some do. PS: Given the nature of your software, I'd recommend you restrict it to Palm OS units running OS of 3.5 or greater, and perhaps you should restrict it to OS 4.1 or greater. Roger Stringer Marietta Systems, Inc. (www.rf-tp.com) -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
Despite the public documentation, Palm OS is a multi-tasking OS. The following undocumented calls are identified in some of the information that I gathered about YAHM: KALTaskCreate, KALTaskDelay, KALTaskDelete, KALTaskGetCurrentID, KALTaskGetInfo, KALTaskResume, KALTaskSuspend, KALTaskStart, KALTaskSwitching, KALTaskWait, KALTaskWaitClr, KALTaskWake, KALTaskExit, SysTaskCreate, SysTaskDelay, SysTaskDelayV40, SysTaskDelete. There is very little documentation from Microsoft about how to write a MSDOS TSR. Certainly not enough to write one. TSRs were developed by the developer community, not by Microsoft. The Microsoft attitude toward TSRs was primarily silence, with occasional warnings and disclaimers. Not unlike what we're seeing now with Palm. Not using undocumented facilities to detect viruses assumes that all viruses follow the same rules. Virus writers are not among the most pristine in their approach to rules. The idea that using only documented facilities will protect you from changes in future OS versions is naive. Witness the current problems with NVFS. Documented does not equate to stable, unchanging or even functional. Undocumented likewise does not equate to changeable or non-functional. It's like a log rolling contest, and only the alert and constantly involved have a chance at staying upright. The reason that SetTrapAddress is not available in OS/5 is that it doesn't make sense with an Arm device that is emulating a 68K. TRAP is a 68K instruction that transfers control from a 68K program to a 68K handler. In OS/5, the 68K TRAP instruction transfers control to an Arm handler. If you want to provide an alternate handler, then you need to intercept the call to the Arm handler and provide your own Arm handler. This is exactly what YAHM does. Palm is not going to tell you how to do this without some legal leverage on how you use the information. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
I think that is very undertandable given the memory footprint of the original device which ran in what, 128K of memory? Ah, that explains it. One can probably still fit an MS-DOS-like OS in such space - but that won't leave enough room for user applications and MS-DOS programs had to write their own user interface, because the only one provided by the OS was a string output. I've never seen a PalmOS device that had less than 2 Mb memory myself - but I guess lots of things have been set in stone for the early, limited devices and couldn't be changed later. Regards, Vesselin -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
All programs can run in Palm OS background all the time. Nope, they don't. They reside in memory all the time - but at any given time, only one of them is actually running. They aren't given timeshares or even timer tick interrupts by the OS, either - something which is used on many OSes to implement pseudo-concurrency. Whenever your program services a launch code without globals, it is running in background mode. If the foreground program is doing something in a loop, your background program won't ever get that special launch code before that look ends. Hell, even the *OS* won't be able to do its tasks before that loop ends. That's nothing even remotely similar to running in the background - it's more like not running in the background and waiting for the foreground application to deign to allow me to run. :-) It is in some respects related to the TSR mode you had on MS-DOS, except all Palm OS programs are automatically in this mode all the time without any special effort on the part of the programmer. Oh, no not at all! In MS-DOS, the foreground program was *interrupted* by the event meant for the background program. Consider how many times people have asked how do I put a running clock on a form - because the way one can implement this in PalmOS is highly counter-intuitive. Using a different timeout? Waiting for nil events? Come on! And just recently somebody asked how to display a running transparent analog clock in the background of the launcher - and the asnwer is you cannot. In MS-DOS, a TSR program would just hook the timer interrupt - similar to patching a system trap in PalmOS - except that there is no equivalent trap to patch there and you can't patch traps since version 5.0 anyway. As a result, approximately 18 times per second, whatever program was currently running would be automatically interrupted and control would be transferred to your code. You could count ticks, update the screen - whatever you feel necessary to provide the illusion of concurrency. You wanted to write a program that would provide some kind of help via a hot key? Trivial - just intercept the keyboard interrupt vector and your code will be invoked every time the user presses a key - no matter what else was currently running. You check whether the key pressed is the hotkey you're looking for and, if yes, you do your thing. You want an on-access virus scanner? Trivial! Just intercept the interrupt vectors for program execution and file opening and scan the corresponding file. You could even disinfect it or prevent it from running. True, it's somewhat possible to intercept normal application launching in PalmOS (and what about the zillion other ways in which an application could be run?) - but if you do this, have you tried to actually *prevent* an application that your scanner has determined to be infected from running?! There are no easy, elegant ways. :-( One anti-virus producer does it by setting the Recycle attribute and resetting the device. Another is doing it by overwriting programs with dummy, do-nothing applications (not sure whether this can really stop the execution of the original application and can't test easily). It truly sucks to have to resort to such stupid tricks... :-(( Your only problem in servicing without globals launch should be because you have a long process Oh, I could get rid of the globals relatively easily - although it pains me to resort to such ugly tricks... My problem was that, for some reason, my application couldn't service an event loop when started from a volume mounted notification. I still don't understand why. The problem was not the speed; the problem was not that I am using a user interface - the problem is that at the time of the notification, I just can't start an event loop. And I still don't see the reason for the you can't use globals limitation. Yes, I realize that it's probably in order to save some memory when processing special launch codes on the early devices. But, when you do stupid tricks in order to get around that limitation - like allocating your global variables and setting the ownership of the allocated block to the OS and saving a pointer to it in a feature - you waste exactly the same amound of memory (plus some code). So why doesn't the OS do it for you, if you need it? There could have easily been an API call for save the global variables of the previous application and give me access to my global variables... Regards, Vesselin -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
Has your organisation contacted PalmSource with a view to gaining access to their internal resources? No. Several reasons for that: 1) I don't want to use undocumented tricks in my application. What's the point of using them, if they stop working in the next OS version and I have to rewrite my whole program as a result - even if I am notified about that before the new? 2) I very much doubt that PalmOS has undocumented capabilities to do what I need. 3) I very much doubt that PalmSource would be willing to implement capabilities that I need, just because I need them. 4) I seem to remember that they wanted some huge amount of money (a million dollars, or something like that) for the kind of thing you describe. 5) We're a small company. I'm writing this application in my spare time. We'll give it out for free. It's just not *worthwhile* (in terms of money, time and efforts) to get involved in the process that you suggest. 6) We've had very bad experience with signing NDAs in order to get internal information with other companies (notably Microsoft) - and we'd rather avoid it, if we can. It's not the credibility of the company I work for that is the problem - it is just that we don't consider this worthwhile. Regards, Vesselin -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
Perhaps your memory is different to mine, but I remember all sorts of frustrating, nasty, undocumented problems with apps that just grabbed an interrupt ... and did what they wanted. Of course - but my point was that it *was* possible (and relatively easy) to do what you wanted in a well-behaved way. I've done a TSR virus scanner in MS-DOS - no problems and it wasn't causing trouble to anyone. Of course there were programs that were sloppily written - aren't there such programs in the PalmOS universe too? Yes, some TSR programs tried to be way too smart for their own good - I remember SideKick trying to be always the first on the chain of TSR programs; if you had another TSR program that tried to do the same, the two *really* disliked each other... :-) But it was easy to do things and it was easy to them properly - without any silly limitations, except the fact that you essentially had to write the whole user interface yourself. Yeah. With the emphasis on 'cooperative'. Anything that broke the rules even slightly brought the whole house of cards down on it's arse. Well PalmOS is no different - any badly written application can grab the device and crash it in various creative ways. Except that the word multitasking, cooperative or not, is somewhat missing... :-) (Unless we count version 6.x which currently doesn't run on anything but the simulator.) But forget multitasking. Even MS-DOS had the concept of shell to another program and when that one exits, return to the caller. You don't need multitasking for that. It's one program that's running at any given time. Yet PalmOS doesn't have even that... I'm not going to pretend that Palm OS was brilliantly designed It's just not designed at all with systems programming in mind. Anti-virus programs, device drivers, other deep stuff - hell, even writing libraries isn't exactly trivial there... It seems that all the design efforts have been concentrated on the user interface. It's quite good there - the API is very rich and one can do almost anything easily enough - although I wish it had Windows-style radio buttons instead of the pushbuttons it currently has and that implementing a tabbed form and scroll bars on lists and tables was a bit easier (I mean - supported by the API so that you didn't have to do everything manually yourself). Oh, and to answer one of my own questions - one reason for the difference between a Windows machine and a PalmOS machine is that the PalmOS machine doesn't have a hard disk. True, the CPU and 2 Mb RAM ought to be sufficient to implement a cooperative multitasking Windows 3.x-style OS - but there there won't be much space left for the user to put their applications. I have no experience whatsoever with Windows CE-based devices. Does that OS support multitasking? (And does it actually work?) Do these devices have a hard disk? (I know that Apple's iPod has one, so it's possible to put one in a PDA-like device.) Regards, Vesselin -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
Vesselin, It's just not designed at all with systems programming in mind. That is my impression as well. When I first started working on this platform, I quickly realized that terms like database or even operating system carried a different conotation than one might expect. In my view, Palm OS was evidently designed simply as a collection of useful service routines for performing UI and manipulating database records. It wasn't an operating system from the standpoint of really playing traffic cop for what occured on the system. It just provided common services. I think that is very undertandable given the memory footprint of the original device which ran in what, 128K of memory? And that is for *both* the dynamic heap and storage heap! (I don't know how much ROM it had for the OS and PIM apps -- I seem to remember hearing 512K?) Easy to see what it would be a very lightweight operating system at version 1. My first device was OS 3.1, so I'm not too familar with what was added in 2.x and 3.0 releases. I think it had likely come a long way already by that point compared to the original design. But I've always suspected many of the types of issues you are battling now can be traced to my suposition that it wasn't really designed as a true operating system at all. I think in OS 1.x to 4.x devices, the real operating system may be the underlying kernel licensed from Kadak but that we have no official way to interact with it directly. And while OS 5.x is a complete rewrite and doesn't utilize the Kadak core anymore, I think it was designed as a stepping stone transition phase while retaining as much compatibility as possible with m68k applications. And I don't know what has happened to Cobalt. :( Doug -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Strange error when trying to intercept sysNotifyVolumeMountedEvent
ubject: Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent From: Dr. Vesselin Bontchev [EMAIL PROTECTED] Date: Fri, 29 Apr 2005 12:48:57 - 2) Setup a notification, alarm or event to run your program (in background) Alas, I can't run anything in the background, sigh... But I know what you mean. Actually you do lots of things in background provided you understand how that concept works within the Palm OS, and don't try to impose some other OS model onto Palm OS. All programs can run in Palm OS background all the time. In fact they do. Whenever your program services a launch code without globals, it is running in background mode. You can view without globals as Palm OS background mode. It is in some respects related to the TSR mode you had on MS-DOS, except all Palm OS programs are automatically in this mode all the time without any special effort on the part of the programmer. Your only problem in servicing without globals launch should be because you have a long process, and as a consequence you must pop-up a progress window to the user so they know why the system suddenly isn't paying attention to them. If you'll observe the way Palm OS works, you'll notice this happens commonly such as when a unit connects to a remote system (dial-up or TCP/IP socket). Roger Stringer Marietta Systems, Inc. (www.rf-tp.com) -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
But forget multitasking. Even MS-DOS had the concept of shell to another program and when that one exits, return to the caller. You don't need multitasking for that. It's one program that's running at any given time. Yet PalmOS doesn't have even that... It does have that concept -- it's SysAppLaunch. However, it's a launch mechanism that's optimized for quickly calling a routine or small function from another execute-in-place program, which is why it doesn't setup the called program completely. On an OS 3.0 device, there may not be enough space in the dynamic heap for two programs to have their global variables available at the same time, since the dynamic heap was less than 64K large. However, the whole OS was designed to run on a slow 16MHz 68K processor with 128K of memory as the entire storage for both user data and runtime activity. That's the original Pilot 1000, and anything that wasn't needed to let you do four PIM applications wasn't considered for the original design. It seems that all the design efforts have been concentrated on the user interface. It's quite good there - the API is very rich and one can do almost anything easily enough - although I wish it had Windows-style radio buttons instead of the pushbuttons it currently has and that implementing a tabbed form and scroll bars on lists and tables was a bit easier (I mean - supported by the API so that you didn't have to do everything manually yourself). Pushbuttons were chosen because they effectively showed state and took up less screen real-estate, something important on a 160x160 BW screen. Many of the key design decisions go back to what do we need for this product. That continues through the whole evolution of the 68K versions of the OS, as it primarily changed based on direct needs of the next PDA that Palm was producing. It really wasn't until OS 4 that the system was actually viewed as a platform supporting a whole family of devices, and by that time, there was a huge legacy. -- Ben Combee, Senior Software Engineer, palmOne, Inc. Combee on Palm OS weblog: http://palmos.combee.net/ Developer Forum Archives: http://news.palmos.com/read/all_forums/ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
From: Dr. Vesselin Bontchev [EMAIL PROTECTED] It's just not designed at all with systems programming in mind. Anti-virus programs, device drivers, other deep stuff - hell, even writing libraries isn't exactly trivial there... Actually one of the things that occurred to me after writing that is that you're possibly missing what seems to be a base assumption to Palm OS development - that OS-level programming (which is what you're doing) will be done by licensees working with PalmSource. Much of this isn't documented simply because there are only a handful of apps that will ever be written at that level and the assumption is that those people approach PalmSource, demonstrate the usefulness of their application to the platform and gain NDA-protected access to internal information. I think you're feeling the pain of being isolated from that process, but your organisation certainly has the credibility to sign into an agreement with PalmSource. Now I've never done this, but I've worked with hardware developers for whom it's commonplace. Has your organisation contacted PalmSource with a view to gaining access to their internal resources? Chris Tutty -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
If I recall correctly, some apps handle notifications by setting an alarm that will launch their app normally in a second or so. Hmmm... That might work but it is... messy. Don't forget, the reason why I want to examine the card is in order to detect if there are any viruses on it - preferably, *before* they have infected the device; not in second or so after that. :-) One possibility would be to disable the execution of start.prc and set an alarm. Then, when the alarm triggers, scan the card and, if safe, execute start.prc myself. The reason why this is messy, is because the user might already be running an application that prevents the automatic execution of start.prc on the inserted cards. Since I have no way of determining whether this is the case, the behavior of my program would effectively disable that application - because my program would run start.prc anyway. :-( Sigh, this is an *awfuly designed* OS for anything related to systems programming... :-((( Not only it doesn't have any decent protection built-in - it basically makes it impossible to *add* proper protection. :-( If viruses ever become widespread for this platform, the user will suffer big time. :-(( Sigh... So, how do I execute start.prc manually? I guess I could copy it to the main memory with VFSImportDatabaseFromFile and then run it with SysUIAppSwitch - but that never returns to the caller, so how would I get control, in order to delete it from the main memory??? Again set an alarm to do that maybe some time later?? Then how do I find it? It's probably not reliable to pass its LocalID to the alarm - what if other databases have been created meanwhile? Remember its Type and CreatorID and find it with DmGetNextDatabaseByTypeCreator? Or is there a better way? Besides, I still don't understand why the program I posted above crashes if the notification arrives when the Launcher is running. OK, so for some bizarre reason the Launcher posts an appStopEvent (you know, the kind of thing all newbies are told *not* to do when trying to exit an application). So, my application's event loop terminates immediately. Fine, I would have understood if, as a result, my application did nothing. But why the crash?! And the crash happens *after* my application quits - it seems as if it is the Launcher itself that's crashing... It seems to me that in attempting to immediately transfer control to the same app you are setting yourself up for timing and event-queue issues Well, I thought that whe whole point of having notifications was so that your application could get control and do something useful AS SOON AS the respective event occurs, dammit! Not maybe some time later! Argh, this OS is *hell* for any kind of serious systems programming... :-((( In good old MS-DOS you just intercepted an interrupt vector and did whatever you wanted when the interrupt arrived - the lack of memory protection and the single-task-single-thread architecture were a help, not a hindrance... :-((( Regards, Vesselin -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
Subject: Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent From: Chris Tutty [EMAIL PROTECTED] Date: Fri, 29 Apr 2005 12:12:53 +1200 X-Message-Number: 31 From: Dr. Vesselin Bontchev [EMAIL PROTECTED] Help? Is this the correct way for an application to launch itself with a custom launch code and to check whether this is how it has been launched? If I recall correctly, some apps handle notifications by setting an alarm that will launch their app normally in a second or so. This gives the OS activity associated with the notification time to settle down. It seems to me that in attempting to immediately transfer control to the same app you are setting yourself up for timing and event-queue issues, although I've never attempted to do anything like this. Perhaps in response to the sysNotifyVolumeMountedEvent you need to do the following: 1) Disable the autorun of start.prc (as Ben already suggested) 2) Setup a notification, alarm or event to run your program (in background) 3) Exit When your program is subsequently called from the notification/event/alarm you generated: 1) Scan the start.prc program 2) If clean, run it by sending an appropriate notification. Some of the PalmOS events and notifications only support lightweight or minimal processing and expect you to delay anything more significant to a later time. I suspect your problems are caused by violating this rule. One useful Palm OS characteristic is that alarms are not responded to at certain points like this, so by setting an alarm for now during this period, the alarm will actually be called right after the OS processing has finished. A classic use of this is responding to the HotSync event, where the program receiving the event isn't supposed to do more than trivial processing and the common trick is to set an alarm, taking advantage of the suppression of alarms during HotSync, which ensures your program is called right after HotSync completes. Roger Stringer Marietta Systems, Inc. (www.rf-tp.com) -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
Perhaps in response to the sysNotifyVolumeMountedEvent you need to do the following: Yeah, I'm thinking of something like that - but there are still a lot of things that are not clear to me and it is messy, as I said above. 2) Setup a notification, alarm or event to run your program (in background) Alas, I can't run anything in the background, sigh... But I know what you mean. When your program is subsequently called from the notification/event/alarm you generated: 1) Scan the start.prc program No, not only that. I want to scan the whole card. If I scan the whole card, obviously start.prc would be scanned too. 2) If clean, run it by sending an appropriate notification. There *is* no notification for running it. :-( I have to copy it to the main memory and execute it from there myself. And then figure out how to delete it. And what to delete. And when. Arrggghh! And do I run it with SysUIAppSwitch or with SysAppLaunch? I'll post more questions relevant to this topic in a separate thread... Some of the PalmOS events and notifications only support lightweight or minimal processing and expect you to delay anything more significant to a later time. Well, why isn't the documentation stating clearly what you can and cannot do from any particular notification?! Oh, you can't use globals unless your're launched normally. Oh, but you can, if you've launched yourself. Oh, but you can't use the user interface when launched with some launch codes. Oh, but nothing in the documentation tells you which ones they are. Arrgghhh! Come on, folks, why is this stupid thing so *limiting*?! Even on the cheapest devices, you have a couple of megs of memory and a reasonably fast CPU. I'm not asking for a protected-mode preemptive multi-tasking OS - but even Windows 3.x could do cooperative multi-tasking while running over MS-DOS on a 640 Kb machine with a similar CPU... Sigh. I suspect your problems are caused by violating this rule. Yeah, well, you know who's going to have what kind of problems if reaction to security issues is delayed to a later time? :-) One useful Palm OS characteristic is that alarms are not responded to at certain points like this, so by setting an alarm for now during this period, the alarm will actually be called right after the OS processing has finished. A classic use of this is responding to the HotSync event, where the program receiving the event isn't supposed to do more than trivial processing and the common trick is to set an alarm, taking advantage of the suppression of alarms during HotSync, which ensures your program is called right after HotSync completes. Thanks for the hint - scanning of the device after HotSync completes is another thing I want to implement. Although you're probably thinking of the sysAppLaunchCmdSyncNotify launch code - while I'm talking about reacting to the sysNotifySyncFinishEvent event. I guess I'll have similar problems there? Sigh... Regards, Vesselin -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
Besides, I still don't understand why the program I posted above crashes if the notification arrives when the Launcher is running. OK, so for some bizarre reason the Launcher posts an appStopEvent (you know, the kind of thing all newbies are told *not* to do when trying to exit an application). So, my application's event loop terminates immediately. Fine, I would have understood if, as a result, my application did nothing. But why the crash?! And the crash happens *after* my application quits - it seems as if it is the Launcher itself that's crashing... Actually, Launcher doesn't directly post an appStopEvent. It just calls SysUIAppSwitch to relaunch itself with a custom launch code to tell it to refresh everything and show the launcher page for the just-inserted volume. SysUIAppSwitch posts the appStopEvent. When you call SysUIAppSwitch, a second appStopEvent is put in the queue, but there's only one system global to tell the OS what to launch next, so the launcher ends, your app starts, and it immediately has an appStopEvent to deal with. -- Ben Combee, Senior Software Engineer, palmOne, Inc. Combee on Palm OS weblog: http://palmos.combee.net/ Developer Forum Archives: http://news.palmos.com/read/all_forums/ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
When you call SysUIAppSwitch, a second appStopEvent is put in the queue But, Ben, look at the code I posted. I don't call SysUIAppSwitch from it - yet it still crashes the Launcher... Regards, Vesselin -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
From: Dr. Vesselin Bontchev [EMAIL PROTECTED] (yesterday) good old MS-DOS you just intercepted an interrupt vector and did whatever you wanted when the interrupt arrived - Perhaps your memory is different to mine, but I remember all sorts of frustrating, nasty, undocumented problems with apps that just grabbed an interrupt ... and did what they wanted. It was a support and maintenance jungle - but possibly you remember it differently to me. but even Windows 3.x could do cooperative multi-tasking while running over MS-DOS on a 640 Kb machine with a similar CPU... Sigh. Yeah. With the emphasis on 'cooperative'. Anything that broke the rules even slightly brought the whole house of cards down on it's arse. Or is this my memory failing me again :-). I'm not going to pretend that Palm OS was brilliantly designed, but I think your repeated howls to return to the good old days of DOS aren't taking into account that most of what you're working with is better designed and better documented than DOS ever was. I'm not disagreeing that you could do what you wanted in DOS and you can't in Palm OS, but that's life. I remember a huge mountain of things that just didn't work in DOS and do in Palm OS. Chris Tutty -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
OK, now that I can debug volume mounding (big thanks to Ben and Henk), I've found the following: 1) The crash of my original code occurs because the resource containing the form I want to display cannot be found. Apparently, for some reason, if the application hasn't been launched normally, it can't go to any of its forms. :-( I don't understand why this is the case - the path taken by my program on sysAppLaunchCmdNormalLaunch and on sysAppLaunchCmdNotify is essentially identical - the same variables are allocated and the same APIs are called in the same order. I guess, the startup code does something different in the two cases - and the difference is not limited to the availability of global/static variables; my current code doesn't use any. :-(( 2) My second code - the one that re-launches itself with a custom launch code - I can't figure out why it doesn't work. :-( The debugger shows that the registration for notifications works correctly and returns no errors. When a volume is mounted, my application *does* receive the notification. I've traced it to the point where it does SysUIAppSwitch to itself. The dbID and cardNo are correct - they are that of my application. I've looked at the disassembly - it indeed uses the 0x8001 launch code. I've checked the disassembly of PilotMain too - and the switch statement there indeed checks whether the launch code is 0x8001. Except that once I go past the SysUIAppSwitch point, I no longer receive control. :-(( Help? Is this the correct way for an application to launch itself with a custom launch code and to check whether this is how it has been launched? Regards, Vesselin -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
Subject: Re: Strange error when trying to intercept
sysNotifyVolumeMountedEvent
From: Dr. Vesselin Bontchev [EMAIL PROTECTED]
Date: Wed, 27 Apr 2005 15:45:18 -
X-Message-Number: 31
I can't figure it out. :-((
OK, so I tried a different approach. Instead of going to the proper form
and running the event loop when I get a notification, I decided to launch
myself with a custom launch code:
UInt32 PilotMain (UInt16 cmd, MemPtr cmdPBP, UInt16 launchFlags)
{
UInt16 cardNo;
LocalID dbID;
At no point did you initialize these two variables before using them in
your application, which may simply be a piece of code you left out to
simplify your sample code.
Roger Stringer
Marietta Systems, Inc. (www.rf-tp.com)
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
At no point did you initialize these two variables before using them in your application, which may simply be a piece of code you left out to simplify your sample code. Apologies; I forgot to include their initialization in the sample code I posted. But my real code they *are* initialized - and now that I can debug volume mounting, I have verified with the debugger that they are indeed initialized correctly - so, that's not the problem. Another thing. The documentation says that SysUIAppSwitch sends the current application an appStopEvent and then starts the specified application.. (Surprisingly, this interesting bit of information is in the description of SysAppLaunch - *not* in the description of SysUIAppSwitch, sigh.) But, I'm calling SysUIAppSwitch from a notification, when no application is displaying any user interface yet (that's the whole point - I couldn't make my application display its user interface when receiving the notification). It's the Launcher's user interface that is being displayed when the notification arrives. OK, so I tried using SysAppLaunch instead of SysUIAppSwitch. Yes, I know that an application launched via SysAppLaunch doesn't have access to its global variables - but it doesn't matter to me, because I've rewritten mine not to use any global variables. Now, after my application launches itself via SysAppLaunch, it *does* receive the custom launch code and starts acting on it, as the debugging shows. Unfortunately, as soon as I enter the event loop, I receive an appStopEvent (huh?!), so the loop terminates immediately and my application exits. *After* it has exited, I get a crash because of a null pointer reference. :-(( I really don't understand how this OS works. :-((( Can somebody point me to some sample code of an application launching itself with a custom launch code? When I receive control with the custom launch code from SysAppLaunch, do I have to eat events until the first appStopEven and only *then* enter my normal event loop?? Regards, Vesselin -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
When I receive control with the custom launch code from SysAppLaunch, do I have to eat events until the first appStopEvent and only *then* enter my normal event loop?? OK, the exit event apparently comes from the Launcher? I tried eating it. This works *if* it is the Launcher running when the volume mounting notification arrives. If it is some other application, I never get the exit event and the whole thing hangs. If I *don't* eat the exit event, everything works *if* some application other than the Launcher is running when the notification arrives. It doesn't have to be my application - it could be the Calculator or anything else. But if it is the Launcher that is running, I crash. I don't understand why this is happening. :-( But one way to solve it would be to determine whether it is the Launcher that is running when the notification arrives. How do I do that? And what about third-party launchers? Regards, Vesselin -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
Hi,
I'm not sure I understand your question correctly but form the docs:
To prevent the VFS Manager from activating the start.prc application, set
the vfsHandledStartPrc bit in the handled field. To prevent the VFS Manager
from switching applications, set the vfsHandledUIAppSwitch bit.
Code:
static unsigned short HandleNotification( SysNotifyParamType *np )
{
// VFSMgr activates volume start.prc and switches to the Launcher or to
start.prc if it has UI.
np-handled = 0 ;
np-handled |= vfsHandledStartPrc ; // prevent activating card start.prc
np-handled |= vfsHandledUIAppSwitch ; // prevent switching apps
// Do something usefull
return 0 ;
}
Regards,
Miro Pomsar
- Original Message -
From: Dr. Vesselin Bontchev [EMAIL PROTECTED]
To: Palm Developer Forum palm-dev-forum@news.palmos.com
Sent: Thursday, April 28, 2005 14:40
Subject: Re: Strange error when trying to intercept
sysNotifyVolumeMountedEvent
When I receive control with the custom launch code from
SysAppLaunch, do I have to eat events until the first
appStopEvent and only *then* enter my normal event loop??
OK, the exit event apparently comes from the Launcher? I tried eating it.
This works *if* it is the Launcher running when the volume mounting
notification arrives. If it is some other application, I never get the exit
event and the whole thing hangs.
If I *don't* eat the exit event, everything works *if* some application
other than the Launcher is running when the notification arrives. It doesn't
have to be my application - it could be the Calculator or anything else. But
if it is the Launcher that is running, I crash.
I don't understand why this is happening. :-( But one way to solve it
would be to determine whether it is the Launcher that is running when the
notification arrives.
How do I do that? And what about third-party launchers?
Regards,
Vesselin
--
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: Strange error when trying to intercept sysNotifyVolumeMountedEvent
I'm not sure I understand your question correctly but form the docs: To prevent the VFS Manager from activating the start.prc You don't understand my question correctly. I am not asking how to prevent start.prc from running. I am asking how to detect whether it is the Launcher that is currently running at the moment when I receive a notification. My application is registered to receive the sysNotifyVolumeMountedEvent notification with a sysNotifyNormalPriority priority - which is higher than that of the VFS Manager. My application is supposed to be notified about this even first and do its thing. Only then the VFS Manager gets the notification and I don't care if it runs start.prc or not. Nevertheless, grasping for straws, I tried setting the handled flag in the way you suggest. The problem remains exactly the same - a crash occurs if the card is inserted while the Launcher was running. Next idea, please? :-) BTW, folks, the problem definitely lies in the fact that I'm getting an unexpected appStopEvent event when the Launcher is running. Just as a test, I reverted to my old code - the one that doesn't try to launch itself but simply goes to the memory card scanning form and starts the event loop. That code shows exactly the same behavior - it works perfectly, if some application (not necessarily mine) was running when the notification about the sysNotifyVolumeMountedEvent event arrived. If, however, it was the Launcher that is running when the notification arrives, I get an unexpected appStopEvent, my event loop terminates early, and everything gets screwed up. :-(( Regards, Vesselin -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
At 09:38 AM 4/28/2005, you wrote: I'm not sure I understand your question correctly but form the docs: To prevent the VFS Manager from activating the start.prc You don't understand my question correctly. I am not asking how to prevent start.prc from running. I am asking how to detect whether it is the Launcher that is currently running at the moment when I receive a notification. My application is registered to receive the sysNotifyVolumeMountedEvent notification with a sysNotifyNormalPriority priority - which is higher than that of the VFS Manager. My application is supposed to be notified about this even first and do its thing. Only then the VFS Manager gets the notification and I don't care if it runs start.prc or not. Nevertheless, grasping for straws, I tried setting the handled flag in the way you suggest. The problem remains exactly the same - a crash occurs if the card is inserted while the Launcher was running. Next idea, please? :-) The reason why you're getting an extra appStopEvent when the launcher is running is because the launcher also registers for the sysNotifyVolumeMounted notification, and it uses that to relaunch itself (ultimately calling SysUIAppSwitch) with a custom code telling it to switch displaying programs from the just-launched volume. I expect there's a timing clash here, as the launcher is storing some values for its use, but its app switch is being eaten by your app switch, but it doesn't recover from that situation well. You may be able to fix this by registering for sysNotifyNormalPriority - 1, ensuring that you're notified just after the launcher, and your SysUIAppSwitch will override the launcher's. -- Ben Combee, Senior Software Engineer, palmOne, Inc. Combee on Palm OS weblog: http://palmos.combee.net/ Developer Forum Archives: http://news.palmos.com/read/all_forums/ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
You may be able to fix this by registering for
sysNotifyNormalPriority - 1, ensuring that you're notified just
after the launcher, and your SysUIAppSwitch will override the
launcher's.
Ben, that does not make sense. According to the documentation
http://www.palmos.com/dev/support/docs/palmos/PalmOSReference/NotifyMgr.html#1024486
the priority argument of SysNotifyRegister is of type Int8. According to the
include file Core/System/NotifyMgr.h, sysNotifyNormalPriority is defined as 0.
Therefore, the expression sysNotifyNormalPriority - 1 would evaluate to -1 or
0xFF, depending on how it is used later by the system. That's not just after
- that sounds more like either just before or as as late as possible to me
:-). In addition, the documentation says
In general, Palm recommends using a value whose least significant bits are
0 (such as 32, 64, 96, and so on).
Nevertheless, I tried using both sysNotifyNormalPriority - 1 and 240 and
the result is exactly the same - my application crashes if the notification
arrives while the Launcher is running - due to the unexpected appStopEvent. :-(
OK, perhaps I am blind and am not seeing something terribly obvious. Here, I
made a small illustrative application. It is supposed to allow the user to turn
on and off the monitoring of volume insertion (with a checkbox on its main
form). Then, if the monitoring is on and a card is inserted, the application
displays an information form. This application behaves pretty much like the
original I'm writing - in the sense that it crashes if the notification arrives
while the Launcher is running and doesn't crash otherwise.
Ben, could you or anyone please look at this and see whether I am making some
obvious mistake? Or is what I want to do impossible to do?!
Source code, Card.c:
--8Cut here-8
#include PalmOS.h
#include VfsMgr.h
#include CardRsc.h
#define appCreatorID'CrMn'
#define appVersionNum0x01
#define appPrefID0x00
#define appPrefVersionNum0x01
#define version40 (sysMakeROMVersion (4, 0, 0, sysROMStageRelease, 0))
Boolean MainFormHandleEvent (EventPtr pEvent)
{
Boolean handled;
FormPtr pForm;
UInt32 Monitor;
Err err;
UInt16 cardNo;
LocalID dbID;
handled = false;
switch (pEvent-eType)
{
case frmOpenEvent:
pForm = FrmGetActiveForm ();
FrmDrawForm (pForm);
if (FtrGet (appCreatorID, 1000, Monitor) != errNone)
Monitor = false;
FrmSetControlValue (pForm, FrmGetObjectIndex (pForm,
kMainFormMonitorVolumeMountingCheckbox), Monitor);
handled = true;
break;
case ctlSelectEvent:
switch (pEvent-data.ctlSelect.controlID)
{
case kMainFormMonitorVolumeMountingCheckbox:
pForm = FrmGetActiveForm ();
SysCurAppDatabase (cardNo, dbID);
if (FtrGet (appCreatorID, 1000, Monitor) != errNone)
Monitor = false;
if (FrmGetControlValue (pForm, FrmGetObjectIndex (pForm,
kMainFormMonitorVolumeMountingCheckbox)))
{
if (! Monitor)
{
Monitor = true;
err = SysNotifyRegister (cardNo, dbID,
sysNotifyVolumeMountedEvent, NULL, sysNotifyNormalPriority - 1, NULL);
}
}
else
{
if (Monitor)
{
Monitor = false;
err = SysNotifyUnregister (cardNo, dbID,
sysNotifyVolumeMountedEvent, sysNotifyNormalPriority - 1);
}
}
FrmSetControlValue (pForm, FrmGetObjectIndex (pForm,
kMainFormMonitorVolumeMountingCheckbox), Monitor);
FtrSet (appCreatorID, 1000, Monitor);
handled = true;
break;
default:
break;
}
break;
default:
break;
}
return handled;
}
Boolean InfoFormHandleEvent (EventPtr pEvent)
{
Boolean handled;
FormPtr pForm;
handled = false;
switch (pEvent-eType)
{
case frmOpenEvent:
pForm = FrmGetActiveForm ();
FrmDrawForm (pForm);
handled = true;
break;
default:
break;
}
return handled;
}
void AppStop (void)
{
FrmCloseAllForms ();
}
Boolean AppHandleEvent (EventPtr pEvent)
{
UInt16 formId;
FormPtrpForm;
Booleanhandled;
handled = false;
if (pEvent-eType == frmLoadEvent)
{
formId = pEvent-data.frmLoad.formID;
pForm = FrmInitForm (formId);
FrmSetActiveForm (pForm);
switch (formId)
{
case
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
From: Dr. Vesselin Bontchev [EMAIL PROTECTED] Help? Is this the correct way for an application to launch itself with a custom launch code and to check whether this is how it has been launched? If I recall correctly, some apps handle notifications by setting an alarm that will launch their app normally in a second or so. This gives the OS activity associated with the notification time to settle down. It seems to me that in attempting to immediately transfer control to the same app you are setting yourself up for timing and event-queue issues, although I've never attempted to do anything like this. Chris Tutty -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Strange error when trying to intercept sysNotifyVolumeMountedEvent
Hello folks,
I'm trying to intercept the insertion of a memory card and to scan its
contents. Here is what I'm doing:
1) On sysAppLaunchCmdSystemReset and sysAppLaunchCmdSyncNotify I register to
receive notifications about the sysNotifyVolumeMountedEvent event:
UInt32 PilotMain (UInt16 cmd, MemPtr cmdPBP, UInt16 launchFlags)
{
UInt16 cardNo;
LocalID dbID;
UInt32 romVersion;
switch (cmd)
{
case sysAppLaunchCmdNormalLaunch:
AppStart ();
FrmGotoForm (kMainForm);
AppEventLoop ();
AppStop ();
break;
case sysAppLaunchCmdSystemReset:
case sysAppLaunchCmdSyncNotify:
FtrGet (sysFtrCreator, sysFtrNumROMVersion, romVersion);
if (romVersion = version40)
SysNotifyRegister (cardNo, dbID, sysNotifyVolumeMountedEvent,
NULL, sysNotifyNormalPriority, NULL);
break;
case sysAppLaunchCmdNotify:
HandleNotification ((SysNotifyParamType *) cmdPBP);
break;
default:
break;
}
return 0;
}
2) When the notification arrives, I basically do
void HandleNotification (SysNotifyParamType *np)
{
switch (np-notifyType)
{
case sysNotifyVolumeMountedEvent:
AppStart ();
FrmGotoForm (kScanningMemoryCardForm);
AppEventLoop ();
AppStop ();
break;
default:
break;
}
}
The code is written so that it doesn't use any global or static variables. This
works fine on the Tungsten E simulator, using HostFS to simulate a card with a
directory on the PC. True, I can't insert a card in the simulator - but the
sysNotifyVolumeMountedEvent event is broadcast on soft reset too (makes sense -
the volume has to be mounted during reset), and when I reset the simulator, my
application is launched and it scans the card.
However, when I try it on a real device (Tungsten E), as soon as I insert a
card (or during reset, if a card is left in the slot) I get a system crash with
the memory manager complaining about a NULL pointer. I've been using a
FrmCustomAlert to display debugging messages and, interestingly, the custom
alert is flashed on the screen - but there is no waiting for the user to tap on
its button; instead I immediately get the message for the crash.
Another thing. The crash does not happen and the application scans the inserted
card properly, if the application was running at the moment when the card was
inserted.
Any hints what might be the problem? The documentation explicitly says that you
*can* use the user interface during notifications. Yet the program crashes as
if there is no current form or something. And why doesn't it crash under the
simulator? Is there anything obviuous that I might be missing?
Regards,
Vesselin
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
My *guess* is that the crash happens for the following reason:
According to the documentation, FrmGotoForm Sends a frmCloseEvent to the
current form - but if the application isn't running, it isn't showing a
current form.
If this is the reason for the problem, how should I fix it? How can I do the
rest of what FrmGotoForm does (send a frmLoadEvent and a frmOpenEvent to the
specified form) without sending a frmCloseEvent? I *do* call FrmInitForm in
AppEventLoop:
void AppEventLoop (void)
{
EventType event;
UInt16 event_error;
UInt16 formId;
FormPtr frmP;
GlobalsPtr myGlobals;
myGlobals = GetGlobals ();
do
{
EvtGetEvent (event, myGlobals-eventTimeout);
if (SysHandleEvent (event))
continue;
if (MenuHandleEvent (0, event, event_error))
continue;
switch (event.eType)
{
case frmLoadEvent:
formId = event.data.frmLoad.formID;
frmP = FrmInitForm (formId);
FrmSetActiveForm (frmP);
switch (formId)
{
case kScanningMemoryCardForm:
FrmSetEventHandler (frmP,
ScanningMemoryCardFormHandleEvent);
break;
default:
break;
}
default:
FrmDispatchEvent (event);
}
}
while (event.eType != appStopEvent);
}
Perhaps I should use FrmPopupForm instead of FrmGotoForm when receiving the
notification? But doesn't that work only for modal forms?
Regards,
Vesselin
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
Did you try FrmPopupForm() ?
You can then use FrmReturnToForm(). However this call will fail if there is
no form to return to. Then just send your form the frmCloseEvent (if
needed), and unload the form by FrmDeleteForm().
regards,
Miro Pomsar
- Original Message -
From: Dr. Vesselin Bontchev [EMAIL PROTECTED]
To: Palm Developer Forum palm-dev-forum@news.palmos.com
Sent: Wednesday, April 27, 2005 14:37
Subject: re: Strange error when trying to intercept
sysNotifyVolumeMountedEvent
My *guess* is that the crash happens for the following reason:
According to the documentation, FrmGotoForm Sends a frmCloseEvent to the
current form - but if the application isn't running, it isn't showing a
current form.
If this is the reason for the problem, how should I fix it? How can I do
the rest of what FrmGotoForm does (send a frmLoadEvent and a frmOpenEvent to
the specified form) without sending a frmCloseEvent? I *do* call FrmInitForm
in AppEventLoop:
void AppEventLoop (void)
{
EventType event;
UInt16 event_error;
UInt16 formId;
FormPtr frmP;
GlobalsPtr myGlobals;
myGlobals = GetGlobals ();
do
{
EvtGetEvent (event, myGlobals-eventTimeout);
if (SysHandleEvent (event))
continue;
if (MenuHandleEvent (0, event, event_error))
continue;
switch (event.eType)
{
case frmLoadEvent:
formId = event.data.frmLoad.formID;
frmP = FrmInitForm (formId);
FrmSetActiveForm (frmP);
switch (formId)
{
case kScanningMemoryCardForm:
FrmSetEventHandler (frmP,
ScanningMemoryCardFormHandleEvent);
break;
default:
break;
}
default:
FrmDispatchEvent (event);
}
}
while (event.eType != appStopEvent);
}
Perhaps I should use FrmPopupForm instead of FrmGotoForm when receiving
the notification? But doesn't that work only for modal forms?
Regards,
Vesselin
--
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: Strange error when trying to intercept sysNotifyVolumeMountedEvent
Did you try FrmPopupForm() ? Yes. That crashes much more reliably - even on the simulator. :-) You can then use FrmReturnToForm(). I'm not getting that far. The form isn't displayed before the crash occurs. Ideas, anyone? It ought to be possible to display a form from a notification... Regards, Vesselin -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Strange error when trying to intercept sysNotifyVolumeMountedEvent
I can't figure it out. :-((
OK, so I tried a different approach. Instead of going to the proper form and
running the event loop when I get a notification, I decided to launch myself
with a custom launch code:
UInt32 PilotMain (UInt16 cmd, MemPtr cmdPBP, UInt16 launchFlags)
{
UInt16 cardNo;
LocalID dbID;
UInt32 romVersion;
switch (cmd)
{
case sysAppLaunchCmdNormalLaunch:
case sysAppLaunchCmdCustomBase + 1:
AppStart ();
FrmGotoForm ((cmd == sysAppLaunchCmdNormalLaunch) ? kMainForm :
kScanningMemoryCardForm);
AppEventLoop ();
AppStop ();
break;
case sysAppLaunchCmdSystemReset:
case sysAppLaunchCmdSyncNotify:
FtrGet (sysFtrCreator, sysFtrNumROMVersion, romVersion);
if (romVersion = version40)
SysNotifyRegister (cardNo, dbID, sysNotifyVolumeMountedEvent,
NULL, sysNotifyNormalPriority, NULL);
break;
case sysAppLaunchCmdNotify:
HandleNotification ((SysNotifyParamType *) cmdPBP);
break;
default:
break;
}
return 0;
}
void HandleNotification (SysNotifyParamType *np)
{
DmSearchStateType stateInfo;
UInt16 cardNo;
LocalID dbID;
switch (np-notifyType)
{
case sysNotifyVolumeMountedEvent:
DmGetNextDatabaseByTypeCreator (true, stateInfo, 'appl',
appCreatorID, true, cardNo, dbID);
SysUIAppSwitch (cardNo, dbID, sysAppLaunchCmdCustomBase + 1, NULL);
break;
default:
break;
}
}
This doesn't crash. However:
1) When installed on the simulator and when the simulator is reset, my
application is started and it scans the memory card *twice*. Why twice?! OK,
currently I don't check which volume is being mounted and scan all the
available volumes. So, if a device had more than one card and both were mounted
on reset, my program would be run twice. However, the Tungsten E simulator with
HostFS does not have two cards; it has only one! And why the previous version
(that tried to do a FrmGotoForm) was run only once, implying that there is only
a single volume mounting event at reset??
2) When used on a real device, it doesn't crash, either. However, the card is
*not* scanned when it is inserted in the slot! Instead, the Launcher does its
usual thing - plays a sound, displays the applications in /PALM/Launcher, etc.
It's as if my application isn't getting a volume mounted event notification.
Why?!
And, if I reset the real device with the card left in the slot, my application
*is* launched - and scans the card. Once, not twice.
This thing is driving me nuts... :-((( Help?
Regards,
Vesselin
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
