This is a link to an awesome resource: a "rosetta stone" comparing VB and C#. Totally useful as a general reference, too. One of these days, we need columns for PHP, D, C++, Javascript, etc.
The first computer book I read was "Teach Yourself Basic" by Bob Albrecht. It wasn't a really good book - at least not for a child - but there it was. Mr.
Rlib is a report writing engine that takes report specifications in an XML language. It emits reports in several formats including HTML and PDF.
I stumbled across RLIB while figuring out how to implement some MS Access report writing features in PHP. MSA users will know what writing a report is, but PHP coders probably don't, so I'll explain.
I wanted to print a report that indicated the first and last item on each page, just like a dictionary has. You know: "Azeri - Babcock", "Milk - Minder". It makes it easier to flip through printouts.
This is how to do it. It will put the range in the footer. I haven't figured out how to do one in the header, which is what I originally wanted, but found too difficult to do. (There is probably a way.)
First, take your report, and add an unbound field to your report. Rename it to "Range". See the picture below.
Then, set up event handlers for the On Print event of each section. An explanation follows the picture. Here's my code:
Option Compare Database Option Explicit Public FirstRow As String Public CurrentRow As String
This is a way to insert empty or empty-like rows into a list of "seats" that contains not only reservations, but a number saying how many seats a group of people have.
This is a repository of "novice" articles, written with the intent of driving more traffic to the site, and getting more ad clicks. It's pretty crass, I know, but the information may be very useful.
This is a class that will help you find files on the disk, without hitting the disk too much. It's a simplified unix "slocate" library. The first time you use it, it creates an index of all the files on the drive. (Subsequent uses update the file when a day passes.) The index is loaded into memory, and searched with regular expressions.
On an AMD Sempron 2000, the first search on 200,000+ files takes around 11 minutes. The second search takes around 2 seconds, and subsequent searches during a single run take around 1 second each. The first run builds the database, and the subsequent searches use it.
This blog entry doesn't discuss any code, because I ended up doing very little work on the software. I was busy running it, and the app tends to take over the UI, making programing difficult. For the most part, it functioned as expected, but a couple things changed in how I actually used it.
I added a text box to restrict scanning for MXD files to a subdirectory. This new feature allowed me to set the source root and destination root directories, and then type the subdirectory to be processed. The text box could also be left blank.
I used this feature a lot.
The main feature I stopped using was the scheduler. The software was so slow that it failed to use the network 100%. The point of having the program pause at night was to let backups happen faster, to avoid competing for the network.... but since the job appeared to be CPU-bound, I had was a big disincentive to be a good network citizen. The most efficient thing to do was let the app run all the time, even if it impacted the network -- every time the app was "nice" to the network, the length of time to complete it's task would grow by that amount plus the additional CPU time it took to complete the task.
It was looking pretty grim for the file copier. The main problems were twofold:
First, the app sometimes crashed on bad data. The Windows crash-reporting dialog box came up, and all work stopped until it was dismissed.
Second, after dismissing the dialog box, the app looped furiously, failing to process the remaining files, but marked them as completed (that's a little design bug there). The problem was that the COM server was returning an exception, and it was being trapped and effectively ignored. I say "effectively" because a special call to kill the app, via WMI, didn't clear the problem -- the underlying COM server didn't get stopped and unloaded.
The error could be cleared if I paused the batch job, and restarted it. That caused the thread that communicated with the COM server to abort, thus (probably) releasing the COM server. If only this could be automated.
I'm finally running that program I've been writing. For the most part, it was "bug free" inasmuch as the different parts ran their test cases correctly, and it runs fine on a small subset of data. Of course, it's not like I ever really learned the system completely, so there are a lot of situations that I'm not handling (or even aware of). Moreover, because the users probably don't use all the features of the software, it's not likely that a complete solution is necessary. No project is debugged "enough" until it operates on real data, in a real situation. Fortunately, my first iterations were done in Perl and VBA, in a scripting environment, on real data, so my experiences debugging those determined the overall structure of the code -- that is, the code deals with messy situations.
It's going to be a lesson about recursion. It's strictly beginner level.
This article discusses debugging a function by rewriting the code.
I'm not sure what I did wrong here, but, my first version of this function didn't work. The function returns true if the current time is withing two time spans. This code was written in a rush, without really thinking about how to do it, because it seemed pretty straightforward. The code, however, was a mess (and embarassing).
Private Function itIsTimeToWork() As Boolean
' Get the two start and end times, and determine if we're within
' the intervals.
Dim now, start1, start2, end1, end2 As DateTime
now = DateTime.Now
start1 = DateTime.Parse(My.Settings.StartWorkAt1)
end1 = DateTime.Parse(My.Settings.EndWorkAt1)
If end1 < start1 Then For some reason or other, I didn't get an email response from the client on this gig*, and the week was hectic, so instead, I just worked on making the UI a little nicer. VB has a lot of controls, including a background threader, some standard dialogs, and a serial port. This is giving me a real "Rip Van Winkle" feeling, having been over in Unixville for a while.
(* It was lost in my huge email pile. My bad. No matters... the program got a nice facelift.)
I downloaded a bunch of code examples, and started looking through them. The second volume had some interesting programs. One thing hasn't changed about VB - you have to type a lot of code to get a little done. At least that's still true if you're writing algorithmic code... and clearly, C#'s job is to write that algorithmic code.
This document explains some terminology used on other pags.
Spending most of the evening thinking about ways to test OLE timeout code (and figuring out how to do it in .NET). The issue is simple: the server app isn't super-reliable when it handles bad data.