Discussion:
[Bitpim-devel] PC Sync mode on Sanyo phones
Stephen Wood
2004-06-01 01:35:35 UTC
Permalink
Some of the older Sanyo phones require that the phone be manually put
into "PC Sync Mode" before ringers or wallpapers can be sent to it. I
would like to pop up a note telling the user to do this.

One way to do this seems to be define an empty method in
com_phone.Profile and add that to convertors in OnDataSendPhone. Then
in phones that need it, I put in a popup window for that method.

Stephen
Roger Binns
2004-06-02 04:48:15 UTC
Permalink
Post by Stephen Wood
Some of the older Sanyo phones require that the phone be manually put
into "PC Sync Mode" before ringers or wallpapers can be sent to it. I
would like to pop up a note telling the user to do this.
I take it there is no way of detecting if the mode is set, or actually
setting it via code?

There are two ways of handling the user interface. One is to detect
the issue while actually trying to write, and send a message to
the user at that point. (I could make specially formatted log
messages popup a dialog). The code could then keep checking every
second to see if the phone is now in that mode.

The other way is to do it after getfundamentals is called, but before
doing the actual round of writing to the phone.
Post by Stephen Wood
One way to do this seems to be define an empty method in
com_phone.Profile and add that to convertors in OnDataSendPhone. Then
in phones that need it, I put in a popup window for that method.
That creates linkage between the phone code and UI code. I don't
want any UI code at all in the phone code so that BitPim could be
used from the command line. But that can be solved by putting in
a data field instead and picking up on it later.

(And at some point I also need to do a per phone config infrastrcure
so you can get config information "properly" instead of via wx.GetApp :-)

Roger
Stephen Wood
2004-06-03 04:44:13 UTC
Permalink
Post by Roger Binns
Post by Stephen Wood
Some of the older Sanyo phones require that the phone be manually put
into "PC Sync Mode" before ringers or wallpapers can be sent to it. I
would like to pop up a note telling the user to do this.
I take it there is no way of detecting if the mode is set, or actually
setting it via code?
I don't know a way to set the mode. Putting the phone offline is not
good enough. Presumably, they wouldn't have a PC sync mode option on
the phone if software could put it in the right mode. (The more modern
Sanyo phones don't need to be put in PC sync mode to transfer media to
them.)

There does seem to be a distinct error code sent back when trying to
write media when not in this sync mode. So I can make the request of
the user only when the phone is not already in the correct mode.
Post by Roger Binns
There are two ways of handling the user interface. One is to detect
the issue while actually trying to write, and send a message to
the user at that point. (I could make specially formatted log
messages popup a dialog). The code could then keep checking every
second to see if the phone is now in that mode.
How about if I add a new method parallel to log and logdata, say
lograise that will pop up the request to put the phone in the right
mode. In guiwidgets it would look something like:

def lograise(self, str, nl=True):
self.log(str, nl)
dlg=wx.MessageDialog(self, str, wx.OK)
dlg.ShowModal()
dlg.Destroy()

Stephen
Roger Binns
2004-06-03 05:38:43 UTC
Permalink
Post by Stephen Wood
There does seem to be a distinct error code sent back when trying to
write media when not in this sync mode. So I can make the request of
the user only when the phone is not already in the correct mode.
That is cool. Can you do it in a busy loop? ie keep trying once
a second until the mode is set.
Post by Stephen Wood
How about if I add a new method parallel to log and logdata, say
lograise that will pop up the request to put the phone in the right
self.log(str, nl)
dlg=wx.MessageDialog(self, str, wx.OK)
dlg.ShowModal()
dlg.Destroy()
Adding extra stuff like that is actually very complicated since it
has to cross threads, and actually requires 3 or 4 method additions
to pass stuff on.

My preference is a magic marker in the log message, and then the
main thread code can decide what to do about it. This would
include different behaviour if it was running in gui vs command
line mode as an example.

I have just checked in what I mean. There is now an alert function
in com_phone which you can call. Make sure you supply the wait
parameter as False. The log function in the gui code then
handles displaying an alert. The code is also untested so you may need
to do some tweaks or bug fixes, or provide feedback that it is complete
crap :-)

Roger
Stephen Wood
2004-06-03 13:02:54 UTC
Permalink
Post by Roger Binns
That is cool. Can you do it in a busy loop? ie keep trying once
a second until the mode is set.
Sure. Do you think this loop should be in sendpbcommand, or the routine
above it (my writesanyofile routine)? I think it should go above
sendpbcommand.

I will need to rewrite sendpbcommand to deal with error codes. The
theme for Sanyo errors seems to be to send back a one byte error and a
fragment of the request packet. The current sendpbcommand interprets
these errors codes as junk, strips them and then gets a CRC error. I
need to first check if the CRC is good before stripping possible junk.

I guess sendpbcommand can throw exceptions for know errors itself (like
sendbrewcommand), but will need a new option to not throw the exception
and return the response packet as is. Of course I want to avoid adding
10,000 options to sendpbcommand. (I havn't forgotten my promise to
merge the common functionality of sendbrewcommand, and the LG and Sanyo
sendpbcommands)
Post by Roger Binns
My preference is a magic marker in the log message, and then the
main thread code can decide what to do about it. This would
include different behaviour if it was running in gui vs command
line mode as an example.
I have just checked in what I mean. There is now an alert function
in com_phone which you can call.
I didn't like the idea of a marker in the log message. But since it is
hidden by the alert function, that's fine. I'll give alerting and a
wait loop a try.

Stephen

Loading...