Searching \ for '[EE] Help debugging a C' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/language/index.htm?key=c
Search entire site for: 'Help debugging a C'.

No exact or substring matches. trying for part
PICList Thread
'[EE] Help debugging a C# program'
2008\06\02@084647 by Xiaofan Chen

face picon face
I admit I have not much ideas when it comes to C# and Windows GUI programming.
Now here is the problem, Jan Axelson has written the USB PIC firmware and
the host program (in C# and VB.net) as an example to test WinUSB.

I have tried the host software and the firmware and they seem to work
fine except one bug. If I do nothing and close the program, the program
will raise an unhandled exception.

Download:
http://www.lvr.com/winusb.htm

Detailed description of the problem:
http://forum.microchip.com/tm.aspx?m=339511

I suppose Jan Axelson will solve the problem sooner or later. But
I am thinking this must be not a complicated problem and I'd like
to solve it as a learning exercise. But it proved to be more difficult
than I thought. Any ideas?

By the way, I have written libusb based program to test the firmware
under Linux and the program runs fine.
http://forum.microchip.com/tm.aspx?m=340892


Regards,
Xiaofan

2008\06\02@090448 by cdb

flavicon
face


:: have tried the host software and the firmware and they seem to work
:: fine except one bug. If I do nothing and close the program, the
:: program
:: will raise an unhandled exception.

Is this the same bug that she mentions on her website?

I think unhandled exceptions can be avoided by a try -> catch clause
wrapped around the offending code - my C# isn't brilliant.

Which version of Express Studio are you using? Some 2006/7 code
versions need rewriting for 2008. In fact it does need tinkering with
for 2008 versions of Studio.

There is another USB c# visual basic code that might help from Joe
Padue's website  smileymicros.com.

Colin
--
cdb, spam_OUTcolinTakeThisOuTspambtech-online.co.uk on 2/06/2008

Web presence: http://www.btech-online.co.uk  

Hosted by:  http://www.1and1.co.uk/?k_id=7988359






2008\06\02@200451 by Xiaofan Chen

face picon face
On Mon, Jun 2, 2008 at 9:04 PM, cdb <.....colinKILLspamspam@spam@btech-online.co.uk> wrote:
>
>
> :: have tried the host software and the firmware and they seem to work
> :: fine except one bug. If I do nothing and close the program, the
> :: program will raise an unhandled exception.
>
> Is this the same bug that she mentions on her website?

No.

> I think unhandled exceptions can be avoided by a try -> catch clause
> wrapped around the offending code - my C# isn't brilliant.

It is wrapped by try-catch.

This unhandled exception has been solved by another forum user.
http://forum.microchip.com/tm.aspx?m=339511

> Which version of Express Studio are you using? Some 2006/7 code
> versions need rewriting for 2008. In fact it does need tinkering with
> for 2008 versions of Studio.

Hmm, I've never heard of VS2006/2007. There is VS2005 and VS2008.
Jan is using VS2005 and I am using the same VS2005.

Xiaofan

2008\06\02@203206 by cdb

flavicon
face


:: This unhandled exception has been solved by another forum user.
:: http://forum.microchip.com/tm.aspx?m=339511

I'll check that out.

:: This unhandled exception has been solved by another forum user.
:: http://forum.microchip.com/tm.aspx?m=339511

Well I've got 2007 and am now using 2008 (this is Studio Express, but
the Pro versions are the same I believe.)

Colin
--
cdb, colinspamKILLspambtech-online.co.uk on 3/06/2008

Web presence: http://www.btech-online.co.uk  

Hosted by:  http://www.1and1.co.uk/?k_id=7988359




2008\06\03@031928 by Ruben Jönsson

flavicon
face
Hi,

The problem is in WinUsbDevice.CloseDeviceHandle():

if (!(myDevInfo.deviceHandle.IsInvalid)){

since myDevInfo.deviceHandle is null. You can fix this by testing the
deviceHandle for null.

internal void CloseDeviceHandle()
{
       if (myDevInfo.deviceHandle != null) {
               try {
                       if (!(myDevInfo.deviceHandle.IsInvalid)) {
                               FileIO.CloseHandle(myDevInfo.deviceHandle);
                       }
                       //  Free resources.
                       WinUsb_Free(myDevInfo.winUsbHandle);
               } catch (Exception ex) {
                       throw;
               }
       }
}

The real problem is that the try/catch is rethrown without handling it which is
the same as not having any try/catch at all. Remove the throw and it will also
work. I am not sure why you would rethrow without doing anything with the
exception instead of not catching it at all.

/Ruben
<http://www.rjjournal.net>

{Quote hidden}

> -

2008\06\03@052716 by Xiaofan Chen

face picon face
On 6/3/08, Ruben Jönsson <.....rubenKILLspamspam.....pp.sbbs.se> wrote:
> The problem is in WinUsbDevice.CloseDeviceHandle():
>
> if (!(myDevInfo.deviceHandle.IsInvalid)){
>
> since myDevInfo.deviceHandle is null. You can fix this by testing the
> deviceHandle for null.
>
Thanks.

>
> The real problem is that the try/catch is rethrown without handling it which is
> the same as not having any try/catch at all. Remove the throw and it will also
> work. I am not sure why you would rethrow without doing anything with the
> exception instead of not catching it at all.

I also feel it is strange but I do not know how to fix it.

This is not my progrgam. It is written by the famous Jan Axelson, the
author of the famous "USB Complete" and other books.

Xiaofan

2008\06\03@150414 by Gerhard Fiedler

picon face
Ruben Jönsson wrote:

>                } catch (Exception ex) {
>                        throw;
>                }

> The real problem is that the try/catch is rethrown without handling it
> which is the same as not having any try/catch at all. Remove the throw
> and it will also work. I am not sure why you would rethrow without doing
> anything with the exception instead of not catching it at all.

You can put a breakpoint on it, or you can later add some code that does
something sensible :)

Gerhard

2008\06\04@032302 by Xiaofan Chen

face picon face
On 6/3/08, Xiaofan Chen <EraseMExiaofancspam_OUTspamTakeThisOuTgmail.com> wrote:

> This is not my progrgam. It is written by the famous Jan
> Axelson, the author of the famous "USB Complete" and
> other books.

She has since updated the program to fix this bug. She
has also tried to fix the two GUI bugs related to the
button focus but apparently the new version still has
the same GUI bugs.

http://forum.microchip.com/tm.aspx?m=339511&mpage=2

The program looks simple but somehow the GUI bugs
are really strange to me. I can understand the more
complex core WinUSB codes but I do not understand
why these two GUI bugs exist. It seems that GUI
programming is a can of worm...


Xiaofan

2008\06\04@040359 by Ruben Jönsson

flavicon
face
Could you quickly describe how to reproduce the bugs?

/Ruben

{Quote hidden}

==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
@spam@rubenKILLspamspampp.sbbs.se
==============================

2008\06\04@072740 by Xiaofan Chen

face picon face
On Wed, Jun 4, 2008 at 4:03 PM, Ruben Jönsson <KILLspamrubenKILLspamspampp.sbbs.se> wrote:
>> She has since updated the program to fix this bug. She
>> has also tried to fix the two GUI bugs related to the
>> button focus but apparently the new version still has
>> the same GUI bugs.
>>
>> forum.microchip.com/tm.aspx?m=339511&mpage=2
> Could you quickly describe how to reproduce the bugs?

Ok. There are 4 "Send" buttons in the application.

If you click the lower left "Send" button for the bulk transfer
test, the upper right "Send" button (for Control Read transfer)
will also change shape as if it were also clicked.

If you click the lower right "Send" button for the interrupt transfer
test, the text inside the lower left text box (for bulk transfer test
data) will also flashing.

If I look into the codes, there are no correlation between the
"Send" button event handler and the side effects. So this is
kind of strange, to me anyway.

Regards,
Xiaofan

2008\06\04@154019 by Ruben Jönsson

flavicon
face
{Quote hidden}

It is because the button is disabled in the click event and perhaps the way it
is reenabled again. When the button is disabled the focus is shifted to another
control and then it doesn't get it back in the AccesForm method. Perhaps
because this method is invoked from another thread. Normally this is done with
InvokeRequired and BeginInvoke to synch it to the GUI thread but another option
is used here.

Anyway, a workaraound can be done with two bool variables that gets set to
false when the button is clicked (the button is not disabled) and checked in
the click event so that a new send can't be started before the current is
finished. The bool varaible is reset to true when the operation is finished in
the AccessForm, cases EnableCmdSendandReceive...

One of the Click events: Note that the button isn't disabled.

private bool cmdSendAndReceiveViaBulkTransfersEnabled = true;
private void cmdSendAndReceiveViaBulkTransfers_Click( System.Object sender,
System.EventArgs e )
{            
   try
   {
       // Don't allow another transfer request until this one completes.
               if (cmdSendandReceiveViaBulkTransfersEnabled) {
                       cmdSendAndReceiveViaBulkTransfersEnabled = false;

                       SendAndReceiveViaBulkTransfers();
               }
   }
   catch ( Exception ex )
   {
       throw ;
   }
}

In AccessForm: Note that focus isn't changed.

case "EnableCmdSendandReceiveViaBulkTransfers":
   cmdSendandReceiveViaBulkTransfersEnabled = true;
   break;

The bool variables also have to be set to true in the FindMyDevice method.

Also note that I havn't tested with the Windows Driver Kit and the usb dll
installed and ofcourse not with a usb device.

/Ruben



==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
spamBeGonerubenspamBeGonespampp.sbbs.se
==============================

2008\06\07@081057 by Xiaofan Chen

face picon face
On Thu, Jun 5, 2008 at 3:40 AM, Ruben Jönsson <TakeThisOuTrubenEraseMEspamspam_OUTpp.sbbs.se> wrote:
> It is because the button is disabled in the click event and perhaps the way it
> is reenabled again. When the button is disabled the focus is shifted to another
> control and then it doesn't get it back in the AccesForm method. Perhaps
> because this method is invoked from another thread. Normally this is done with
> InvokeRequired and BeginInvoke to synch it to the GUI thread but another option
> is used here.
>
> Anyway, a workaraound can be done with two bool variables that gets set to
> false when the button is clicked (the button is not disabled) and checked in
> the click event so that a new send can't be started before the current is
> finished. The bool varaible is reset to true when the operation is finished in
> the AccessForm, cases EnableCmdSendandReceive...
>

Thanks a lot. Your solution works. I tested with the device plugged in and
unplugged.

I have posted the modified version here:
http://forum.microchip.com/tm.aspx?m=339511

Multi-threading and GUI are both not easy to be understood. ;-(
Even though this application seems to be a very basic program
in terms of the GUI part, I would never be able to solve the problem.

Thanks again.

Xiaofan

2008\06\07@081932 by Xiaofan Chen

face picon face
On Thu, Jun 5, 2008 at 3:40 AM, Ruben Jönsson <RemoveMErubenspamTakeThisOuTpp.sbbs.se> wrote:
> It is because the button is disabled in the click event and perhaps the way it
> is reenabled again. When the button is disabled the focus is shifted to another
> control and then it doesn't get it back in the AccesForm method. Perhaps
> because this method is invoked from another thread. Normally this is done with
> InvokeRequired and BeginInvoke to synch it to the GUI thread but another option
> is used here.
>

Actually the code is using this method.
>From the code:
///  For bulk and interrupt transfers, the application uses a Delegate
and the BeginInvoke
///  and EndInvoke methods to read data asynchronously, so the
application's main thread
///  doesn't have to wait for the device to return data. A callback
routine uses
///  marshaling to send data to the form, whose code runs in a
different thread.

Regards,
Xiaofan

2008\06\07@085748 by Ruben Jönsson

flavicon
face
{Quote hidden}

Note that Control.BeginInvoke and Delegate.BeginInvoke are quite different. The
first can be thought of a posting a message to the WndProc of the control or
form, which when received will run the method in the GUI thread and execute the
method from there, meaning that it will be synchronized with and thread safe
for the GUI thread. InvokeRequired can be used to test if the code needs to be
BeginInvoked...

The Delegate.BeginInvoke actually runs a method on a worker thread from the
thread pool in the background. This also requires the EndInvoke to release the
thread and get back any data the worker thread returns.

I am not quite sure why disabling the button doesn't work like it is supposed
to. I have done it many times in the button click event and then reenabled it
when an operation has finished somewhere else. The function MyMarshalToForm
also calls Invoke (instead of BeginInvoke) which means that it isn't done
asynchronously and perhaps that is the reason.

Anyway, glad the workaround fixed it.

/Ruben
==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
EraseMErubenspampp.sbbs.se
==============================

2008\06\07@093722 by Xiaofan Chen

face picon face
On Sat, Jun 7, 2008 at 8:57 PM, Ruben Jönsson <RemoveMErubenEraseMEspamEraseMEpp.sbbs.se> wrote:
> I am not quite sure why disabling the button doesn't work like it is supposed
> to. I have done it many times in the button click event and then reenabled it
> when an operation has finished somewhere else. The function MyMarshalToForm
> also calls Invoke (instead of BeginInvoke) which means that it isn't done
> asynchronously and perhaps that is the reason.
>

Could you be more specific here? Thanks.

Do you have some pointers showing your method?

Regards,
Xiaofan

2008\06\07@151746 by Ruben Jönsson

flavicon
face
Hi,

I did some more testing because I could not let this go :-)

I turns out that the application and its controls are behaving with its default
behavior. When the button is disabled (.Enable=false) and it also has focus,
the focus goes to the next control in the tabindex order (just like you would
have pressed the tab key on the keyboard). In this case it is either the
textbox or another button. In the textbox case the default behavior is also to
select all text in it (highlights it) and for the button it is to set it as the
default control (so pressing space activates it). In our case we don't want
this behavior but there is another even easier solution to fix it than what I
first gave you: Simply set the focus to another control that doesn't change
when it has focus before the button is disabled. In this case there are the two
group box controls (fraBulkTransfer and fraInterruptTransfer) that are ideal
for this. So just forget what I have said before and do like this instead :-)

For the cmdSendAndReceiveViaBulkTransfers_Click before the button is disabled:

 fraBulkTransfer.Focus(); // Set focus to the groupbox
 cmdSendandReceiveViaBulkTransfers.Enabled = false;

and for the other button:

 fraInterruptTransfer.Focus(); // set focus to the groupbox
 cmdSendAndReceiveViaInterruptTransfers.Enabled = false;

So you can either do it like this and get the visible feedback with the
disabled buttons (which I think is better) or as I suggested before.

/Ruben


{Quote hidden}

> -

2008\06\07@234139 by Xiaofan Chen

face picon face
On Sun, Jun 8, 2008 at 3:17 AM, Ruben Jönsson <RemoveMErubenTakeThisOuTspamspampp.sbbs.se> wrote:
> I turns out that the application and its controls are behaving with its default
> behavior. When the button is disabled (.Enable=false) and it also has focus,
> the focus goes to the next control in the tabindex order (just like you would
> have pressed the tab key on the keyboard). In this case it is either the
> textbox or another button. In the textbox case the default behavior is also to
> select all text in it (highlights it) and for the button it is to set it as the
> default control (so pressing space activates it). In our case we don't want
> this behavior but there is another even easier solution to fix it than what I
> first gave you: Simply set the focus to another control that doesn't change
> when it has focus before the button is disabled. In this case there are the two
> group box controls (fraBulkTransfer and fraInterruptTransfer) that are ideal
> for this. So just forget what I have said before and do like this instead :-)
>

Thanks a lot. This makes perfect sense and the fix is more elegant.

Xiaofan

2008\06\14@092452 by Xiaofan Chen

face picon face
On Sun, Jun 8, 2008 at 11:41 AM, Xiaofan Chen <EraseMExiaofancspamspamspamBeGonegmail.com> wrote:
> On Sun, Jun 8, 2008 at 3:17 AM, Ruben Jönsson <RemoveMErubenKILLspamspampp.sbbs.se> wrote:
>> I turns out that the application and its controls are behaving with its default
>> behavior. When the button is disabled (.Enable=false) and it also has focus,
>> the focus goes to the next control in the tabindex order (just like you would
>> have pressed the tab key on the keyboard). In this case it is either the
>> textbox or another button. In the textbox case the default behavior is also to
>> select all text in it (highlights it) and for the button it is to set it as the
>> default control (so pressing space activates it). In our case we don't want
>> this behavior but there is another even easier solution to fix it than what I
>> first gave you: Simply set the focus to another control that doesn't change
>> when it has focus before the button is disabled. In this case there are the two
>> group box controls (fraBulkTransfer and fraInterruptTransfer) that are ideal
>> for this. So just forget what I have said before and do like this instead :-)
>>
>
> Thanks a lot. This makes perfect sense and the fix is more elegant.
>

>From here I actually found out that similar problem exists in Jan Axelson's
generic HID host program as well. Your solution works perfectly there
as well. I've tested that program for so many times and today is the
first time I noticed this bug.

Thread about the Generic HID example:
http://forum.microchip.com/tm.aspx?m=337034

Thread about the WinUSB example:
http://forum.microchip.com/tm.aspx?m=339511


Xiaofan

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...