Community Documents
First Round:
Summary:
Like many others, I like the XKCD web comic (xkcd.com). A few years ago, when I first encountered it, I decided I wanted to read the old comics as well, but didn't want to go through every single one in my browser, because there were a couple of hundred of them. So I wrote a VI which parsed the HTML to get the comics (if you watched The Social Network, this was similar to the getting-the-pictures-of-all-the-girls-on-campus scene except without the beer or using words like "wget" or a multi-billion dollar company on the other side 
). This is the VI you see here, in a cleaned up form. Now that I had the comics, I was able to read them while on a trans-atlantic flight, which was my basic plan in the first place.
I personally don't like regular expressions, so I went for the simple parsing option: Search for the start of what you're looking for, then search for what comes next. Anything in between is what you're looking for.
Because XKCD comics are made up of three parts (the name, the comic itself and the title text which appears when you hover over the image and which enhances the comic) I then wrote another VI which would display all of these together, which is also included. To stay with the spirit of the challenge, I also used my previous submission to save the value of the control, so that you can continue reading from where you stopped.
I didn't add a lot of error handling, because these VIs do a very specific task at a specific point in a time, so any errors encountered here can usually be managed by the user. I did, however, add a basic example of how such errors can be handled - simply build a list with the relevant details of each error and keep going. In this case, the list is built inside the main VI. In real apps, it would be delegated to a general error logger.
This basic model can be used to download data from any source which serves it, and I actually used a modification of these VIs to download and read comics from other sites as well.
Retroactively, I realize that I probably don't strictly meet the first challenge rule, but since I can't ask either of my grandmas, I guess it will have to stand.
Function:
To have fun.
Second Round: Transferring the data to another VI
Luckily, my original submission already complied with the basic requirements for the second round, so it only has two singnificant modifications:
- The submission is now saved in LV 8.6 (saving back to earlier versions broke the event structure due to a known bug).
- When I opened the VI to clean it up for the challenge I saw that I used an ActiveX browser control to display the images and I couldn't figure out why, so I replaced it with a picture control for cross-platform compatibility. Now, after running through some of the comics in the new version, I realized why I did this - the picture control VIs can't read all of the images. So this version has a disable structure to use the picture VIs on non-Windows targets and to use the web browser on Windows. I couldn't test it on other platforms, but hopefully it should work.
Communication method details:
This submission uses files to transfer data from one program to the other. In this case, the use of files is the most natural choice for the task (saving images and other data for later viewing) since the images are already in that format and that format is easily readable, so there weren't really any other contenders in this case.
That said, here are some advantages of this method:
- Simplicity. Saving data to files is simple and almost any file will be readable from other programs if the format is standard. For example, just last month I needed to pass some data to an HMI program. HMI programs aren't very versatile when it comes to programming options, but they can read files, so all I needed to do was write the data to a file and let the HMI program read it. In our case, both the images and the text files can be read (and manipulated) by many programs.
An additional point in that regard is that writing to files is a lot less restrictive. You don't need to open ports and configure firewalls, etc. Just make sure you have write permissions. Zero configuration is a good thing. - Asynchronous and persistive - you can write a piece of data to a file and then you don't have to worry about whether whatever is on the other side got it or not. You know that the data is there and will remain there until deleted or overwritten. This also allows multiple parties to access the same data.
- If the location you're writing to is on a network drive, then you also get the ability to pass the data to other computers or even other platforms completely transparently. You don't care about where the file is, because the OS takes care of everything for you.
All that said, I very rarely use files as a real time communication method. I would only use it like that in cases like the one I described above, where there's something that can't really communicate using other methods. In most cases, it would be used as a way to save data, as it is used here.
Steps to execute code:
- Open and run the download VI to download the comics.
- When it's done (or, if you're impatient, you can even start before it's done) run the reading VI. The Space key serves as an easy shortcut to move to the next comic.
The VIs should work in any version of LV and on any operating system, as they use native LV functionality. It also uses some OpenG VIs, but those are included as copies in the file, so anyone can use it, whether they have OpenG installed or not.
Screenshots:
Main Front Panel (of the viewer):
Main Block Diagram (of the viewer):
Main Block Diagram (of the downloader):
VI Snippet:
VI attached below (LV 8.6)
