Palingro just goes away!

There isn't a current beta version available, and beta-testers will automatically get test versions rolled out to them.

This is indeed a strange problem, since a message would definitely get displayed if there was a memory error or similar.

Have you got the setting enabled so that Palringo will try and prompt you Yes/No when you select exit?  If not, please could you enable that and see if it appears when it would normally disappear.  This will help us understand if it is another program requesting that Palringo shutdown for some reason.

Is there a consistent time period between when you leave it running and it disappearing?  Is it of the order of a few minutes or a few hours?  Does it vary a lot?

Thanks.

Thanks for the information, we'll see if we can get a TouchFlo3D phone here in the office to test on.

I can also vouch for this issue happening on my Tilt 2 (Touch Pro 2). I have not updated any software on my phone for some time, but the last few days I've had the above issue where Palringo just isn't running anymore.

Any thoughts on why Palringo closes itself?

My guess it's the HTC Task Manager running on Windows Mobile 6.5, correct?  Either WM6.5 or HTC Task Manager seems to be auto killing applications whenever the 'memory is full' or something. It'd be nice if PalRingo would be able to write a log file, so that when people enable this logging feature and PalRingo crashes, the log can be examined further. Log information could range from calling PalRingo features (open message dialog, sending message, receiving message) to reporting the actual amount of memory being used by both PalRingo and by WM applications in general.

WM may close any open application if it is running low on memory and Palringo has no contorl over this.

We are currently investigating work-arounds in the way our architecture is designed, that may allow us to have a push notification system on WM later in the year which would mitigate this problem.

Perhaps the following information might be helpful for the developers. Taken from http://www.modaco.com/index.php?s=&showtopic=289394&view=findpost&p=1049970 :

WM6.5 kills top-level window applications unexpectedly, violently and with (apparently) plenty of RAM available. It's like a more malevolent version of the HTC task manager task killer.

I've tried every reg hack I could come across / think of, and none of them worked. This includes...

Setting all the OOM reg values to zero
The DorkMemory/WM5 hack
The AutoOOM hack

I don't think it's a process count issue, because I can load up on startup apps and they all run without issue. I also don't think it's purely a window count issue, because early after boot I can run 3-4 windowed apps concurrently without issue, but after a while I'm down to 1-2.

I also don't see this is a classic OOM condition, because the WM messages aren't firing according to spec (that is, no WM_HIBERNATE is sent). Perhaps MS changed the spec on OOM conditions.... but I'll be damned if 50MB free is an "out of memory" condition.

I also tested the notion of available RAM after bootup being some sort of threshold for this behavior. I added a startup app that reserved 20MB, and then killed it after a couple minutes. The problem persisted... so it doesn't seem to care about available RAM (I noticed the Available RAM at Boot Time registry entry *did* include my artifical 20MB consumption).

So I'm back to EverApp... the utility I'm writing that re-casts an apps window as a child of a ToolWindow app (which is immune from the window killer). It's just very kludgy right now... may not be something I can do in managed code... we'll see.The other option is to decompile shell32.exe and/or coredll.dll and nuke whatever subroutine is responsible for this, but my skills at decompiling in the CF world aren't that great (and the subsequent fix would require re-packaging into cooked ROMs, which I'm trying to avoid if possible).

Thanks for the information :)