gistfile1.txt

[22:09] <cacodaemon> Why there is no exception information in frontend selection error in sdr#?   Maybe catch(Exception e) and showing e.ToString() or e.Message would be better?
[22:10] <prog> have you tested your installation with rtl_test ?
[22:10] <cacodaemon> for example: RTL-SDR / USB is either not connected or its driver is not working properly.
[22:10] <cacodaemon> Unable to find an entry point named 'rtlsdr_set_offset_tuning' in DLL 'rtlsdr'.
[22:10] <cacodaemon> old version of rtlsdr :)
[22:11] <prog> that shouldn't happen if you followed the installation guide
[22:11] <cacodaemon> without exception information find out the reason for error somehow impossible :)
[22:11] <cacodaemon> no, i`m building from source
[22:11] <prog> there are only two cases
[22:11] <cacodaemon> and exception catching without logs or other means for user to fix it - not a good practice
[22:12] <prog> either you messed the installation
[22:12] <prog> or
[22:12] <cacodaemon> i know :)
[22:12] <prog> you failed your zadig registration
[22:12] <prog> both are external to the program
[22:13] <cacodaemon> anti-patterns in exceptions processing is very internal to program, imho
[22:13] <prog> prove it
[22:13] <prog> do we use generic exceptions ?
[22:13] <prog> no
[22:14] <prog> don't we handle the IO exceptions?
[22:14] <prog> no
[22:14] <cacodaemon> what do you mean by 'generic' in this case?
[22:14] <prog> do we use exceptions to replace "normal" flow control
[22:14] <prog> neither...
[22:14] <prog> google exception handling anti-patterns
[22:16] <prog> http://www.rrelos.net/blog/?p=199
[22:16] <prog> we do none of these
[22:16] <cacodaemon> yes :) there are no mention of "exception information hiding"
[22:17] <prog> just remember that sdr# is a generic sdr application
[22:18] <prog> it's not designed specifically for rtlsdr
[22:18] <prog> if the driver is not working, then it's not working. period.
[22:18] <cacodaemon> well, if you think so, then no problem. I suppose you have more interesting parts to work on :)
[22:18] <prog> well
[22:22] <cacodaemon> I should humbly apply my patches against upstream version :)
[22:22] <cacodaemon> catch(Exception ee)
[22:22] <cacodaemon> frontendName + " is either not connected or its driver is not working properly.\r\n"+ee.Message,
[22:22] <cacodaemon> something like this
[22:23] <prog> you're putting a technical message in the GUI ?
[22:23] <cacodaemon> it`s no good for users, yes
[22:23] <cacodaemon> for end-users
[22:23] <prog> may be a log file at most
[22:24] <cacodaemon> but for tech types or admins - maybe its better than nothing
[22:24] <cacodaemon> i my own programs i usually use log4net
[22:24] <cacodaemon> *in
[22:24] <prog> i use log4net too
[22:25] <prog> apart from the not working drivers, the app is checked everywhere
[22:25] <cacodaemon> yes
[22:25] <cacodaemon> i am using it for last 8 months
[22:26] <prog> ever crashed of its own?
[22:26] <cacodaemon> It somehow most usable from all SDR apps
[22:26] <cacodaemon> one time - there was strange bug in libusb
[22:26] <cacodaemon> not in app
[22:27] <prog> I'm afraid this will change with third party plugins...
[22:28] <cacodaemon> Are you willfully leave implementation of all "extended" functions (like scanning/trunking/autotuning/etc) in other branches or third party plugins?
[22:29] <cacodaemon> I see there are many branches in svn
[22:30] <cacodaemon> Some look interesting but I`m not sure if I have time to tinker with all of them :)
[22:30] <prog> this needs a lot of time
[22:30] <prog> I try to concentrate on the DSP part
[22:42] <prog> have you run rtl_test N
[22:42] <prog> what does it say?
[22:44] <cacodaemon> Found 1 device(s):
[22:44] <cacodaemon>   0:  ezcap USB 2.0 DVB-T/DAB/FM dongle
[22:44] <cacodaemon> etc
[22:44] <prog> ok so it's working
[22:45] <prog> have you updated rtlsdr.dll ?
[22:45] <cacodaemon> all is working, I have built new rtlsdr