SuperGouge / ChanThreadWatch

Fork of the original discontinued ChanThreadWatch.
90 stars 13 forks source link

mono compatibility broken since 1.9.0 #26

Closed wesleyp330 closed 10 years ago

wesleyp330 commented 10 years ago

As stated in title. ChanThreadWatch crashes when using mono as the runtime; seems most likely because of the saved column sizes. Stacktrace:

Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object
  at JDP.frmChanThreadWatch.lvThreads_ColumnWidthChanged (System.Object sender, System.Windows.Forms.ColumnWidthChangedEventArgs e) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.ListView.OnColumnWidthChanged (System.Windows.Forms.ColumnWidthChangedEventArgs e) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.ListView.RaiseColumnWidthChanged (Int32 resize_column) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.ListView.RaiseColumnWidthChanged (System.Windows.Forms.ColumnHeader column) [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.ListView:RaiseColumnWidthChanged (System.Windows.Forms.ColumnHeader)
  at System.Windows.Forms.ColumnHeader.set_Width (Int32 value) [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.ColumnHeader:set_Width (int)
  at JDP.frmChanThreadWatch.InitializeComponent () [0x00000] in <filename unknown>:0 
  at JDP.frmChanThreadWatch..ctor () [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) JDP.frmChanThreadWatch:.ctor ()
  at JDP.Program.Main () [0x00000] in <filename unknown>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object
  at JDP.frmChanThreadWatch.lvThreads_ColumnWidthChanged (System.Object sender, System.Windows.Forms.ColumnWidthChangedEventArgs e) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.ListView.OnColumnWidthChanged (System.Windows.Forms.ColumnWidthChangedEventArgs e) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.ListView.RaiseColumnWidthChanged (Int32 resize_column) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.ListView.RaiseColumnWidthChanged (System.Windows.Forms.ColumnHeader column) [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.ListView:RaiseColumnWidthChanged (System.Windows.Forms.ColumnHeader)
  at System.Windows.Forms.ColumnHeader.set_Width (Int32 value) [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.ColumnHeader:set_Width (int)
  at JDP.frmChanThreadWatch.InitializeComponent () [0x00000] in <filename unknown>:0 
  at JDP.frmChanThreadWatch..ctor () [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) JDP.frmChanThreadWatch:.ctor ()
  at JDP.Program.Main () [0x00000] in <filename unknown>:0 

When I get some time after finishing some projects (if this isn't fixed already it) I will take a look at it and maybe submit a pull request.

SuperGouge commented 10 years ago

Last commit should fix this. Since I do not use Mono, you can try the latest build and let me know if this is indeed fixed before I make a new release: https://www.mediafire.com/?hss105drwcesrqo

wesleyp330 commented 10 years ago

Launches, but the form's column headers are rendered invisible until you attempt to interact with them.

Additionally, if there is any configuration set for column sizes, it causes all the columns to be size zero; predictably, this is due to your commit just returning in the function when null. Precursory glance at the code says this shouldn't ever be null, but mono might be scoping or instancing differently. I might take a debugger to it a bit later this week.

SuperGouge commented 10 years ago

OK I actually took the time to run it with Mono on Ubuntu 14.04. You should consider updating or checking your Mono installation because it is working as intended for me with the build I provided you on Mono version 3.2.8 (Debian 3.2.8+dfsg-4ubuntu1). But let me know if there is any other problem (open another issue if it is unrelated).

Also, I don't know if I will take the time to maintain the Mono compatibility anymore. The fact that no one reported this since the 1.9.0 release (25th of April) tells you about how many people actually use this fork on Mono (maybe people aren't even aware of the fork yet). And I think Unix users prefer to run their little shell scripts and whatnot. I probably won't actually drop the compatibility anyway, but still it's kind of annoying and makes me think about it.