QUOTE:
if there is a way to automate this, so I can eliminate steps a & b above.
Of course your can automate this if your a programmer (Are you?) and have a couple weekends. Two suggestions have already been made:
1) Post# 3 suggests using ExcelDataReader to place the screener data in a System.Data.DataTable datatype, then move it out into your own custom C# struct where you can search that with Linq queries or something.
CODE:
Please log in to see this code.
So you're creating a List of Records (i.e., a database), which you are now going to search with Linq queries or List methods. In practice, you may want to use a Dictionary<string,Record> datatype over List<Record> where "string" is for the stock symbol (searchKey) you would be searching against. But that's another discussion.
I do Method 1 with a stand alone program my browser (which is
logged into Fidelity) calls automatically. But you could just have your browser save the search_results.xls file and have WL read it instead with the constructor of your WL screener.
2) Post# 4 suggests employing Microsoft's JET engine to do the same thing assuming you have MS Office installed. If you're good with SQL queries (Are you?), that might be a good option. Basically, you employ OLE DB queries to have the JET engine read the spreadsheet data into its database where you can then make SQL queries against it. Look at the solution
https://stackoverflow.com/questions/12996234/optimal-way-to-read-an-excel-file-xls-xlsx/12996544 that's employing the OleDbConnection approach for an example.
Method 1 is probably faster, but requires more low-level coding since you need to define a custom datatype (i.e. schema) with a C# struct. With Method 2, you skip that because you just put the entire spreadsheet into the JET database (MS Office) and employ SQL to get at it.
If you're not a programmer, or you don't have a couple weekends, then neither method is good. But if you are a programmer, then you can do this. You first need to decide which method, either 1 or 2, you want to use. The stackoverflow link (above) kind of covers both approaches, so pick one after studying those choices.
Except during development, I wouldn't expose your strategy code to all this database implementation stuff. Rather, I would encapsulate all this implementation stuff into its own fundamentals class and save it into a DLL library with Visual Studio. My strategies have about 350 lines of code, but they call my own DLLs, which hold the bulk of my WL utility coding (which doesn't change).
I can answer questions about ExcelDataReader, but I don't have experience with OLE, the JET engine, or SQL myself. Questions about either are probably better addressed on StackOverflow, not this forum. Happy coding.