Closed GoogleCodeExporter closed 8 years ago
the reason standard .net library was abandoned was due to it not supporting a
blackberry serial port properly (although it would enumerate it, when a
connection was attempted it would report a type of handle which .net did not
believe was a port and refuse connection)
are you a developer? it would be brilliant if you have the know-how and would
like the contribute any of these things :)
perhaps a backgroundworker could be used in CommandQueue.Run() or something
Original comment by chromableedstudios
on 12 Nov 2012 at 1:42
I see, I must say I am very impressed with your work, and have been trying to
chop a few bits to implement into a project I have been working on.
I am no expert and my skills only stretch as far as vb.net but I hope we could
try and help each other out.
I can send you the solution I created for my project if you would like to take
a look.
I would like to implement the original .NET SerialPort class as I only need to
communicate with a Qualcomm device (Samsung Galaxy S III LTE GT-I9305).
I am trying to backup and restore NV Items in a separate thread so the UI
doesnt lock up but when I tried implementing the background worker it always
returned an error that there was no device connected.
There are also a few cool functions I added which you could add to your library
regarding IMEI repair.
Ive attached the Solution for your reference. :)
Original comment by gaz2...@gmail.com
on 12 Nov 2012 at 1:53
hmm.. that is a very interesting project indeed. I am located within US and am
cagey about including IMEI/esn/meid repair support in cdmaDevTerm, but quite an
interesting project nonetheless(I hope it is GPL ;)).
So// the issue is/was still present in .2.8(the latest as of writing) but it
seems it can be(at least under this code base version) prevented by using a bgw
as demonstrated below
private void DoNVRead(string fileName,string nvList)
{
BackgroundWorker bw = new BackgroundWorker();
bw.DoWork += (sender, args) => {
// do your lengthy stuff here -- this will happen in a separate thread
cdmaTerm.ReadNvList(nvList, fileName);
};
bw.RunWorkerCompleted += (sender, args) => {
if (args.Error != null) // if an exception occurred during DoWork,
MessageBox.Show(args.Error.ToString()); // do your error handling here
// do any UI stuff after the long operation here
Logger.Add("NV Read - long operation done");
};
bw.RunWorkerAsync(); // start the background worker
}
(granted this is c# as the new cdmaDevTerm GUI is WPF/C#, but there are sites
online that could probably convert it to vb .net for you--or sharpdevelop has
it built in I think)
Would you mind if I consider merging some of your changes upstream into
cdmaDevTerm?(mostly a couple of the code organization ideas im thinking about)
I'm changing the status to fixed(although there is still the possibility it
would make sense to move the bgw closer to the Q.Run call) although this patch
only fixes the blocking for Nv Read from list at present...
Original comment by chromableedstudios
on 12 Nov 2012 at 5:19
Thanks for that ill give it a try and post my results here.
Take anything you need for cdmaDevTerm, anything to help make an awesome
project better! :)
Original comment by gaz2...@gmail.com
on 12 Nov 2012 at 1:31
Hi I have tried to implement various methods of asynchronous techniques to get
the necessary functions to run on a separate thread with no success.
The problem lies with the custom SerialCOM class. This also needs to be
multithreadded.
Can you be so kind to modify the VB Solution I sent you to use the .NET
implementation of the SerialPort class rather than the custom SerialCOM class
as the .NET implementation supports events which are multithreadded.
Thank you so much! :)
Original comment by gaz2...@gmail.com
on 12 Nov 2012 at 5:26
"Can you be so kind to modify the VB Solution I sent you to use the .NET
implementation of the SerialPort class rather than the custom SerialCOM class
as the .NET implementation supports events which are multithreadded."
This is the type of request that would be better served at
http://stackoverflow.com/ or http://www.vworker.com/
I appreciate your reporting the issue, but I have incredibly limited free time
to do anything, let alone code someone elses project(my time is better served
developing the main branch and trying to learn enough to contribute to projects
like nmap)...
As demonstrated above: The UI blocking has nothing to do with the custom
serialPort(don't belive me? check out the latest code from source and
build--you can watch the nv read happen in the log tab now)
Original comment by chromableedstudios
on 12 Nov 2012 at 6:30
Okay well thanks for your time and if theres anyhing I can help with then ill
try my best where time permits. :)
Original comment by gaz2...@gmail.com
on 12 Nov 2012 at 7:55
well, thank you for the offer. my suggestion for your project would be to maybe
see if the new cdmaDevLib would fill your needs--as the code you have forked
from is dated(and some of it a bit buggy)... that way if I do end up moving the
'threading fix' closer to the Q, then by using the library packaged version you
will automatically get all the latest fixes when you update(hopefully without
causing too much to change in your qcn related code)
also re: your project, it seems you may be in violation of the GPL v3 and my
copyright on some of the code... the gpl allows you to fork the project as you
have--but original copyright and licensing must remain in place
see:
http://www.gnu.org/licenses/quick-guide-gplv3.html
http://opensource.org/faq#preserve-copyright-notices
"Can I strip out the copyrights on Open Source code and put in my own?
Definitely not! This isn't even about Open Source, really: in general, you should not remove a valid copyright notice, no matter what license it specifies. Copyright notices are legal notices; they are also a source of information about the provenance of source code, and if that information is stripped out, recipients of downstream copies have no easy way to rediscover it."
... I believe the accepted practice is for you to add your additional copyright after the original, but it might be easier license/copyright wise too if you just link against cdmaDevLib(although I understand this doesn't give you back the standard .net serial port--I've honestly never run into a phone that didn't work with the included winApiCom and I'm much more likely to fix the threading in cdmaDevLib than in any code that's not current)
Original comment by chromableedstudios
on 13 Nov 2012 at 2:51
Hi thank you for quick reply I will use your library instead as it is more upto
date and sorry for copyright removal as I'm still novice I wanted to make the
code as easy a possible to look at to try and understand it better. Didn't mean
to breach GPL. As said I will just use your library in future and base my code
on that.
Original comment by gaz2...@gmail.com
on 13 Nov 2012 at 8:48
this perhaps is close, but using this cdmaDevLib in the main branch WPF
interface is still buggy/quirky.... not sure if its ready for the main branch
Original comment by chromableedstudios
on 16 Nov 2012 at 2:11
Attachments:
Hi your implementation is working great for my needs, I am just having a go at
tidying up code and making data from sending commands easier to retrieve to
update to a textbox for example. I noticed too that you have an ADB
implementation. I have created an excellent ADB communication framework which I
would be happy to share with you for your project. It can handle temp/perm
root, issue root and non root commands, it supports asynchronous operations so
it doesn't lock up the UI and can gather device details and much more. :) I
will sort out the code and let you take a look.
Original comment by gaz2...@gmail.com
on 18 Nov 2012 at 4:23
Since commands are sent by ref now it is possible to do something like
Dim cmd = New Command(Qcdm.Cmd.DIAG_NV_READ_F, i, New Byte() {}, debugString)
cdmaTerm.Q.Add(cmd)
cdmaTerm.Q.Run()
Dim result = cmd.bytesRxd()
.. do somethng with result
However the basic idea with cdmaDevLib is vaguely a MVVM pattern with
cdmaTerm.thePhone being the view model and cdmaTerm.thePhoneRxd
cdmaTerm.thePhone implements inotifypropertychanged which allows the form
elements to use binding to the properties to have them getting updated
automagicly
Original comment by chromableedstudios
on 19 Nov 2012 at 12:02
Original issue reported on code.google.com by
gaz2...@gmail.com
on 12 Nov 2012 at 1:16