Jim Turtora
2009-07-04 22:23:48 UTC
can someone make me a test build where
_max_id_index=8000
in file sms.py?
thank you for your time,
Jim
----- Original Message -----
From: Jim Turtora
To: bitpim-***@lists.sourceforge.net
Sent: Sunday, May 24, 2009 7:50 PM
Subject: Fw: _max_id_index=999 in sms.py
----- Original Message -----
From: Jim Turtora
To: bitpim-***@lists.sourceforge.net
Sent: Tuesday, November 04, 2008 3:35 PM
Subject: _max_id_index=999 in sms.py
for Joe Pham??
This is my first posting. I'm not sure this doesn't belong in the developer group. Please inform me.
I am working with a verizon razr v3m with nearly 3,000 sms messages total in the inbox and outbox.
I have been trying to use bitpim to archive the text messages. I'm not able to do very much. The best I seem to be able to do is to go to the folders in /brew/mod/syncom2/msging/d,i,o and save the .att and .env files from there to my drive one at a time.
At this point, I haven't looked through much code and I haven't looked to see if there is code to interpret these files, but that's something I hope to do soon. For starters, I was trying to figure out why I can't collect messages to the bitpim program or save groups or zip sets to the drive, as the bitpim program interface implies I should be able to do.
So, I was looking through code and particularly sms.py. In "class SMSEntry(object):", I found the following of interest:
_id_index=0
_max_id_index=999
I immediately wondered if I didn't need something more like 9,999? Or, at least 3,000.
A little further down in the code I found this:
if SMSEntry._id_index<SMSEntry._max_id_index:
SMSEntry._id_index+=1
else:
SMSEntry._id_index=0
Am I way off base here, or... shouldn't this "else:" throw an error or warning and handle this overflow in another way?
As an aside, the phone is about 95% full. Performance of this phone suffers as the messages add up. It doesn't take many messages for this phone to show performance problems, but once it gets to about 80% plus, it becomes extremely tedious to use. Other bugs crop up, but this is for another posting.
Thank you for your time,
Jim
_max_id_index=8000
in file sms.py?
thank you for your time,
Jim
----- Original Message -----
From: Jim Turtora
To: bitpim-***@lists.sourceforge.net
Sent: Sunday, May 24, 2009 7:50 PM
Subject: Fw: _max_id_index=999 in sms.py
----- Original Message -----
From: Jim Turtora
To: bitpim-***@lists.sourceforge.net
Sent: Tuesday, November 04, 2008 3:35 PM
Subject: _max_id_index=999 in sms.py
for Joe Pham??
This is my first posting. I'm not sure this doesn't belong in the developer group. Please inform me.
I am working with a verizon razr v3m with nearly 3,000 sms messages total in the inbox and outbox.
I have been trying to use bitpim to archive the text messages. I'm not able to do very much. The best I seem to be able to do is to go to the folders in /brew/mod/syncom2/msging/d,i,o and save the .att and .env files from there to my drive one at a time.
At this point, I haven't looked through much code and I haven't looked to see if there is code to interpret these files, but that's something I hope to do soon. For starters, I was trying to figure out why I can't collect messages to the bitpim program or save groups or zip sets to the drive, as the bitpim program interface implies I should be able to do.
So, I was looking through code and particularly sms.py. In "class SMSEntry(object):", I found the following of interest:
_id_index=0
_max_id_index=999
I immediately wondered if I didn't need something more like 9,999? Or, at least 3,000.
A little further down in the code I found this:
if SMSEntry._id_index<SMSEntry._max_id_index:
SMSEntry._id_index+=1
else:
SMSEntry._id_index=0
Am I way off base here, or... shouldn't this "else:" throw an error or warning and handle this overflow in another way?
As an aside, the phone is about 95% full. Performance of this phone suffers as the messages add up. It doesn't take many messages for this phone to show performance problems, but once it gets to about 80% plus, it becomes extremely tedious to use. Other bugs crop up, but this is for another posting.
Thank you for your time,
Jim