After completing this article, I was sitting at lunch reading one of my favorite C# books, Professional C#, 2nd Edition, by Robinson et al. (WROX Press, 2002). Right there on page 963 ”it was a long lunch ”is Displaying Output as an HTML Page. They provided two patches of code to compare with mine above.
To launch a separate Internet Explorer, they recommend using the Process class in System.Diagnostics namespace, like this:
Process p = new Process();
p.StartInfo.FileName = "iexplore.exe";
p.StartInfo.Arguments = "http://www.XProgramming.com";
I haven t typed that in and tried it yet, but now I know a little more about how to do it when I need to. They then go on to talk about using the browser as a control. They put it in the toolbox just as we did in this chapter, and their code looks similar, but a little better than mine, like this:
int zero = 0;
object oZero = 0;
string emptyString = "";
object oEmptyString = emptyString;
They describe the five parameters as representing the URI, flags to modify browser behavior, the name of the target frame (if any), POST data to send with the request, and additional HTTP header information. I don t expect to need any of those things. And there s lots more material than I expect to need in the same chapter ( Accessing the Internet ). The book is like that. It has lots of material in its nearly 1200 pages, but it always seems to include some starting material that is enough to get me going.
It s good to have confirmation that we weren t completely off the rails with the ideas here. With the process idea, I m wondering if I can hold on to the process and send it more messages. But if not, I can surely do the same thing with my own little private browser window or a pane in the current XML Notepad. I m tempted to work on that a bit, since the customers really do want to see what they re getting. I ll do it as soon as they give me that story to work on. Right now, they would really like some file saving and loading and a few more tags in the notepad.
You bet there is, and it s an important one. When a problem looks tricky and difficult, this is more often due to our ignorance than it is to anything inherently tricky and difficult in the problem. We are well- served to step back, try to think about simple ways of solving the problem, and learn enough to estimate those simple ways. The desired solution might still require a lot of work, but more knowledge lets it be just work, not high- risk speculation.
And at the same time, our ability to estimate the cost of the alternatives makes it easier for our customer to decide what we should do. Instead of sounding like scared or recalcitrant programmers, with Ohh, that COM stuff is really difficult ”we would need a lot of time to work on that, we can approach the question professionally: We ve tried these alternatives. We can give you This right now. We can add That with two days work. If you want to go to This Big Thing, it will take another week or week and a half. Approaching the question professionally, we re more likely to get a professional answer, instead of Stop whining and program.