This file is something of a diary of what goes into creating this program. It contains musings not suitable for the regular program doc and version files. This may be of some interest to programmers and likely no interest to anyone else. If nothing else, this file has been useful for me to refer back to so that I can recall why I did things a certain way.
You can change the size of the print in most browsers by clicking the page, holding down the Ctrl button, and turning the wheel in the middle of the mouse, if any.
The OriginsI can't remember when I first started this program. In the 1980's, I wrote a Hearts card game program (CardShark Hearts), then a Spades card game program (CardShark Spades), then I started thinking about Bridge. Some of the hand evaluation routines and card display routines in the dealing module actually originated in CSHearts.
I originally called this program CardShark Bridge. I brought most of the card game interface routines and hand evaluation routines over from CSHearts and CSSpades, then started work on CSBridge's bidding routines. All these years later, I am still working on the bidding, so I have dropped any aspirations for a full bridge-playing program for the foreseeable future and now just plan on releasing a bidding program which could be used by any bridge program, as well as serving as a bidding reference source. As a result, I changed the name to CardShark BidBase.
The DatabaseIn CSHearts, my intention always was to add a database where algorithms for passing cards and playing would be stored. There would also be a database for keeping track of how human opponents passed and played.
Surprisingly, before I got to that point, the play of the game using just its hard-coded algorithms (within the program) got good enough that it seemed a waste of time to do any more. After all, nobody wants a Hearts game which they can never beat.
I think that the reason that it got so good is that in Hearts, you often get to the critical part of a game where you have to decide whether or not to take a trick or to decide which card to lead. Most people cannot remember the number of cards played from each suit. And even that is not enough. You have to remember the exact cards out because if you have a 5, say, and one card is out, you have to remember if it is higher or lower than your 5. The computer remembers this easily, but not most humans.
However, bridge bidding is so complex and the limitations of hard-coded algorithms in existing program so obvious that the database approach was used from the beginning. The problem was designing a database structure which would allow any and all types of bids/conventions to be coded in.
My intention was to have as many different hand definition fields as I could think of. Any which proved to be unnecessary could always be ignored or even removed.
Most of the hand definition fields you see today have been there since the beginning. I have added (and deleted) some of the fields which are there for solely for purposes of viewing and editing the database.
Hand-spec fields which have been added are KNR Points, Custom Points, and Intermediates.
I have played bridge off and on for over 40 years. Even when not playing during that time, I have almost always kept studying it. Nevertheless, I am not an expert and even if I were, a bidding database should not reflect the opinions of any single player, even an expert.
I have gone through many books, such as Mike Lawrence's books (Overcalls, Takeout Doubles, and Balancing) making entries for almost everything the books recommend. When experts disagree, whether in different books or in bidding panels in magazines, I make multiple entries so that the user can select the ones he prefers.
So far, the fields in BidBase have proven to be adequate for entering bid specifications to match specifications and test hands from all these books.
The Programming Language and Database FormatCSHearts and CSSpades were last coded in Visual Basic 3. After VB3, I quit updating to new versions of VB because the runtime module(s) got substantially bigger, and some of the routines and DLLs, including the freeware card-display DLL I was using, would no longer work in the newer VB versions.
I started CSBridge in VB3 using an old database engine by the name of Btrieve. I have written many, many applications with Btrieve since the early 1980's. It is fast, bulletproof, and has some great features such as being able to do alphabetical sorts in any order of the alphabet which you specify.
When WinXP came out, people using CSHearts and CSBridge had trouble getting those programs to work, so I converted CSBridge to VB6. Unfortunately, the price of the later versions of Btrieve has become astronomical and the older version does not work with VB6, so I had to pick a new database engine. I selected Microsoft Access.
Access is a lot easier to use than was the old version of Btrieve which I had been using, though the lack of a specifiable alphabetical sort proved to be a problem, as I'll discuss later.
The GridsOne nice thing about the newer database engines is the linked controls. I had written some business software in the 1990's with VB4 and VB5 and Access and used linked controls, so that made it easier for me to use them in what is now BidBase.
Bid Order Numbers("BON") As explained in the program docs, each bid entry is a filter for the entries which follow it (for the same set of Prior Bids). That is, it is implicit in the specs for each entry that the hand under consideration has already been deemed NOT to be of a type defined by earlier entries for the same set of Prior Bids. Therefore, it is essential that the program consider each entry in the correct order.
Originally, a 10-character field was set up to hold a number which would set the order in which entries were to be considered. As it evolved, I used the first digit in the number to indicate the round of bidding, starting with the first non-passing bid. The second number was the player number, starting with the first non-passing player.
That left 8 digits (characters, actually, since this was a string field) for encoding the order of the entries. This was plenty for the first round of bidding on which I was working, but it soon became apparent that it would not allow room for entries beyond the first or second round.
So a major change in the database (and the program) was made.
It had become obvious that since a bridge program would only be searching for a bid for one specific set of Prior Bids at a time, the Bid Order Numbers only had to keep in order the bids for a specific set of Prior Bids, rather than having one set of numbers to span the entire database.
Consequently, the Round and Player numbers were separated out into their own fields and a Bid Order Number field was added with only 6 digits/characters for use in keeping the entries in the desired order for the current set of Prior Bids.
The 6-character Bid Order Number field is much easier to work with than the original, longer field. It is also easier to give matching numbers to similar entries in different Prior Bid sets. For example, compare the entries for the same Bid Order Number for prior bids of 1C-D-1H and 1C-D-1S.
Bid Order Numbers for Conventions
Once the BONs were established, there was a tendency to keep bid entries together which had the same bids even though they had different specs and were even part of different conventions.
Conventions not being used have a 0 in the Selection or Subcategory fields and could easily be selected or deselected by double-clicking on the Sel field at the start of any one entry for the convention.
Standard American ("SA") entries are the default. If no conventional entries are activated for a set of prior bids before the program reaches a SA entry and the hand matches the specs for the entry, then the bid for that entry is used.
It soon became apparent that for this idea to work right, the SA entries must come last in each Prior Bids section. Some code was written to go through the database, pick out each entry without a "0" in the Sel and Sub fields (the lack of which meant they were SA entries) and renumber those entries to start with a "9".
The conventional entries were left with the numbers they already had.
This means that whenever new entries are added, if they are conventional entries, their BONs must not start with 9 and if they are SA entries, they must start with 9.
Display OrderWith the original, longer entry number, the sets of Prior Bids always displayed in the correct Bridge order because the order numbers incremented continuously across all Prior Bids.
With the new system of sorting by the combined fields of Round, Player, Prior_Bids and Bid Order Number, entries no longer displayed in Bridge order. In particular, when Prior Bids are sorted alphabetically, Notrump comes before Spades, and at the end of all the other bids come D(bl), P(ass), and R(edouble) -- none of which are in the order which we want in the database.
I spent a good bit of time searching through Access' docs to see if it were possible to specify a different alphabetic sort order as Btrieve allows. After all, this is a very simple idea. You just create a file with the letters of the alphabet in whatever order you prefer and tell Access to use that file, but Access doesn't allow it.
Okay, for display purposes, I was willing to live with Notrump coming before Spades since it didn't affect searching for bids. (Only one set of Prior Bids is searched for a bid, so the order of the sets of Prior Bids is irrelevant.) But when I added the feature of scrolling through sets of bids in the grid, I ran into a knotted ball of strings when trying to calculate the next or prior set of bids.
As much as I didn't want to add yet another field to the database, it seemed necessary. both to be able to display Prior Bids section in correct (Bridge) order and to be able to easily scroll back and forth through those sections.
A New Sort Field:
So I added the PB_Sort_Order field in which the Prior Bids were converted to a number. For example, 1S-2C would be 1421 where the bid level (1 or 2 in this example) translates straight through and the suits are numbered 1-4 and Notrump=5. This worked well, both for displaying bids in order and for easily scrolling through sets of bids.
Unfortunately, after working with it for a while, it dawned on me that merely 3 rounds of bidding would be 24 digits (12 bids at 2 digits per bid), while the highest level of precision (double precision) for computer numbers is only accurate to 16 digits. So back to the drawing board.
A New Sort Field, II:
For the next attempt, I wrote down all possible bids, from Pass to 7N. The total number of calls is 38 (1 C/D/H/S/N thru 7 C/D H/S/N plus D, R, P). To represent all the bids takes the digits 1-9, A-Z, then a-c. Okay, I created a 36-character field (to allow up to 9 rounds of bidding, 4 characters per round).
I was back to working away on the database when I noticed that codes with A-C were intermixed with those codes with a-c. I went back to Access' docs and discovered that if you wanted a-c sorted apart from A-C, you have to add an Option Binary statement to the program. Did that, but it didn't affect the Microsoft data grid which I was using - entries were still out of order. I wasted hours researching the problem but finally gave up.
A New Sort Field, III:
Instead of using a-c after running out of the uppercase alphabet, I used [\]. In other words, the one-digit codes for 7C, 7D, 7H, 7S, and 7N are Y, Z, [, \, and ], respectively.
Bid sort order codes:
I hate to complain (...but sometimes I still do - Joe Walsh), but the fact is that I wasted untold hours because (1) Microsoft Access doesn't have a very easy to implement feature that Btrieve has had for 25 years and (2) Microsoft's documentation for VB6 and Access are both needlessly difficult to follow.
Well, while I'm blowing off steam, I might as well get it all out:
I have also wasted more countless hours because of working away interactively on code (which means running the program and breaking it to make changes to the code). VB6 does not allow you to save such changes until you quit running your app. (How hard could that be to allow?) But replacing the Blue Screen Of Death in WinXP is the little white box of Sorry for the mild inconvenience, but we have to shut down your app and you are going to lose all your work, which isn't that much better.
Some will say that it's my fault for not stopping and saving more often, but sometimes it simply is not possible when trying to track down a problem.
I've also spent a lot of time on bizarre problems which eventually turned out to be caused by WinXP/VB6 and only rebooting solved the problems.
Microsoft has been producing Windows and VB for, what -- 20 years?? They have unlimited resources, more money than God, and millions of beta testers across the globe. They can't get the major bugs out? If I put out software this buggy, I would get ridden out of town on a virtual rail.
Now (October 2004), the latest "gift" from MS is the Service Pack 2 update to Windows to fix some of the major security holes. It also "fixed" my browser so that it is impossible to open a new window from inside another browser window, so none of my help/doc file links work any more. I've spent a couple of hours trying to fix this, but to no avail so far.
08-04-2004: A New File Edit BoxI just discovered that the standard text box that I was using as an HTML and text file editor in the help file viewer/editor would only hold up to 64k. It truncated the end of one of the BidBase doc files without any warning. (Thanks again, MS.) Fortunately, I was able to recover the truncated part from a backup.
I have never used the Rich Text Format control before. I remember looking at it when I started working on the help file viewer, but didn't use it for reasons I don't remember. I probably intended to use it as a WYSIWYG html editor, but it wasn't powerful enough, so I just used a regular Text box instead.
On the other hand, the RTF control does support files greater than 64k, so I experimented with it to make sure it would work and changed the program from the standard text boxes to the RTF boxes. Changes like this remind me of the movies where some chump gets three wishes from a genie, but everything he wishes for turns out badly because there's always a catch. Whenever I make a change, there always seems to be some problem waiting to jump up and bite me. Guess we'll just have to see.
Later: Well, it bit. All of my HTML code insertion routines had to be reworked because RTF adds a bunch of control codes of its own, messing up the INSTR pointers. Turn out that all I had to do was explicitly add .TEXT to the code insertion lines. I gave the RTF's the same "Text1()" names the old boxes had so that I wouldn't have to rewrite the code, but where I used something like "Mid$(Text1(1), xyz) = ...", I had to change it to "Mid$(Text1(1).Text, xyz=...".
08-07-2004: Combo Suit SpecI've been wishing for a long time for a way to specify card count and HCPs for multiple suits. (See the main docs for why.)
The main thing holding me back is that I just don't have the screen space. First I tried scrunching up the Other input boxes and adding the Combo boxes at the bottom, but I didn't like the idea of having suit spec fields in Other while Intermediates, which is really a Hand Strength field, was in the suit specs field, so I moved Intermediates to Other (no room for it in Hand Strength), but didn't like that either.
Then I had the idea that I could just increase the field sizes for the suit Num's and HCP's and combine suits there, so I undid the changes to Other, brought up Access, changed the field sizes, went back to VB6, and widened the suit Num and Points input boxes themselves.
The idea was that in, say, the Spades Num box, I could put something like "+H+D=>11" to say that Spades plus Hearts plus Diamonds must be a total of at least 11 cards. Then in the the Hearts and Diamonds Points boxes, I put 3-4. This was supposed to solve the problem that if I put "3-4" in all 3 boxes, I could end up with 3 in each. So by specifying at least 11 cards total, I figured that at worst, I would get 4-3-4. Ran the program, and got 5 Spades, 3 Hearts, and 3 Diamonds -- not what I had in mind.
After stewing awhile, I went back to the idea of having separate Combo boxes with something like S+H+D>10 (instead of "=>11" so that I could restrict the math symbol to one character), then put 3-4 in all three suits' Num boxes. Worked fine.
08-07-2004: Adjusting the Auto-Fill RoutineAfter adding the Combo spec boxes, I had to add new code to the routine that automatically creates the Test Hand to allow for the Combo specs. The Auto-Fill routine is very long and complex because you have to juggle so many specification variables for the 4 different suits at once, often adjusting a suit you've already set up in order to make the specs for another suit work.
Adding the Combo specs just added another layer of complexity. The code itself was one thing, then figuring out where to put it in relation to each of the other spec-filling routines was another problem. The routine works fairly well, but there are still some specs which are too complex to work out.
Adding this change got me to thinking about doing the code for Custom Points, which always has seemed too complex to be worth doing. I decided to just do Custom Points where A=2 and K=1, which is more common than others (at least right now it is). It took about 140 lines of code just for that. For a high-level language like VB, that is a lot of code for one little task. In contrast, inserting Intermediates for both suit and whole-hand specs took about 30 lines and the Combo specs routine for Auto-Fill was less than 35 lines.
It is worth noting that the Auto-Fill routine is by far the longest and most complex in the program, yet the Test Hand is not even an absolutely essential part of the program. It is not used by bridge programs at all when looking for a bid. Its sole purpose is to attempt to keep the database entries from conflicting with each other. I seriously doubt that any other bidding program or routine even has a Test Hand feature (unless they have subsequently copied the idea from this program, much less the complicated code to automate it to save the user from having to create the Test Hands manually.
08-15-2004: Comparing Similar EntriesSee the doc files for an explanation of this feature.
The Compare routine was more complex in the beginning than how it ended up because of the need for adjusting suit requirements for the differences in the suits bid. For example, comparing entries after Prior Bids of 1C-1D and 1C-1H, the specs for the Diamond suit after 1C-1D should be similar to the specs for the Heart suit after 1C-1H, and vice-versa.
Making those adjustments got complicated until I realized that the Use-Entry edit routine was doing all those adjustments already when loading an entry from, say, 1C-1H into the Input Boxes for use in creating an entry for 1C-1D.
Another complication was that I wanted a way to indicate in an entry that it should not be compared to some other specific suit, such as not comparing Michaels over 1C to Michaels over 1H. At first I added a new field called CompareTo for indicating suits which the current entry should be compared to, but then decided it would be easier to have the field indicate which suits the current entry should not be compared to.
After setting all this up and completing the compare routine to allow for the NoCompare field, I was updating the docs for this feature. I mentioned that the routine only compares entries which have the same Bid Order Number (else how would it know which entries to compare?), and it dawned on me that the NoCompare field was not needed. If you don't want entries for two different suits compared, all you had to do was give the two entries different numbers.
So I went back and deleted the NoCompare field and changed the compare routine. When I got back to work on comparing entries again, I realized that coming up with new, different numbers was creating other problems, but so far it hasn't been bad enough that I'm going back to the NoCompare field again.
Meanwhile, the Compare routine has proven good at rooting out errors and inconsistencies in the database.
09-01-2004I've spent the last couple of weeks going through Mike Lawrence's books, Balancing, Overcalling, and Takeout Doubles. He has a lot of sample hands. I enter them in the Ctrl-Y Enter Hands function to see if the bid in the database comes up the same as he recommends. If not, I add or revise entries, although apparent inconsistencies and a possible theoretical error in 'Overcalls' makes this task less than straightforward.
As to inconsistencies -- he may start off by saying such-and-such hand is the minimum with which he would make a particular bid, then later makes the same bid with an even weaker hand. Some inconsistencies and even outright errors are to be expected in anything, including BidBase, despite my best efforts to eliminate them. But in books such as ML's, they make it problematic to use these books as authoritative sources for how Bidbase should bid.
On the other hand, the purpose of BidBase has never been to create the perfect bidding system, It is to create a system which the user can modify to what he thinks are the best bids. The BidBase database should just be considered a starting point.
10-05-2004The last couple of weeks have been spent implementing a bidding simulator. I started with a subroutine in the deal generating program. I had to manually change the code for the subroutine when I wanted to run different simulations, but this gave me a chance to see how the code could be generalized.
The next step was to create a separate window for entering the specs for and viewing the results of bidding simulations. Entering hand and bidding specifications is pretty straightforward, but defining what results to look for and count is very complicated.
My first thought was to just have a text box where the user would use a relatively simple "simulation language" to specify things to count, but decided that left too much room for data entry and formatting error.
I ran through a couple of other ideas before settling on the format used in the BidSim window. As explained in the BidSim help file, correctly deciding how to specify hands, how to define what to look for and count, and then how to interpret the results is far from easy.
After I got BidSim working with just one round of bidding, a question came up about whether or not to open a particular hand in 4th seat (after 3 passes). This raised the question of how to let people specify opening passes. I haven't really had to allow this before, although in BidBase, the user is allowed to specify what seat a player or his partner has opened in.
For example, in the window for entering a hand to find a bid, there is no way to specify position, and the program would not accept Prior Bids starting with passes, so that had to change. (It now accepts opening passes.)
In BidSim, I started to add a box for entering position, like the one in the BidBase edit window, but I decided to allow entering passes in the bidding specs instead.
It took a LOT of work to change the bidding routines to allow for opening passes. The problem is that entries in the bidding database cannot have opening passes in Prior Bids because that could potentially quadruple the size and complexity of the database, although during this implementation, I began to question wonder if such an approach might be necessary.
BidSim was a problem, too, because I had started by only allowing one round of bidding (since that is all that is in the database at this time), and adding a second round screwed up most of the routines.
Anyway, after a lot of banging my head against the wall, I finally got opening passes to work, and now that the agony is behind me, it has turned out to be very useful.
Bidding After RHO's Artificial Bids
Another problem which has come up in BidSim was when a bid is used only if RHO's bid is artificial or promises a certain distribution or hand strength.
When you create an entry, you can specify these things (part of my shotgun approach to allowing specs to be entered), but I have never addressed the problem of how the program will know the meaning of RHO's bids when looking for a bid.
When entering a hand and prior bidding for the program to use in finding a bid, if the prior bidding is something like "1H-2N", there is no way to specify if "2N" is natural or Unusual Notrump.
I started to write some routines for the program to ask what RHO's bid means if a potential bid requires a special meaning (most do not), but this didn't seem reasonable (from a programming viewpoint).
I finally decided that it should be a fair assumption that a bid which requires a special meaning for RHO's bid, such as RHO's 2N being Unusual Notrump, should only be activated (by the user via the Pct Used field) if the opponents are, indeed, playing Unusual Notrump. Likewise, the user should have deactivated any entries which require RHO's 2N not to be Unusual.
Therefore, it is not necessary to test for the meaning of the opponents' bids. The meanings should be defined before the bidding starts by activating and deactivating entries. This is a definite nuisance if you want to make frequent changes to the conventions used by opponents, but you do have the option of saving a different database configuration for as many different combinations of conventions as you wish.
Testing The Database:
I have been spending a lot of time going through the output of BidSim, looking at the hands and their bids to see if they looked okay, resulting in a large number of refinements to the database.
For example, I just ran a sim with no specs other than "?" for hand 1 and entered all bids individually (e.g.: 1C, 1D, etc.) through 4S to be counted and generated a list of 10,000 bids which I sorted by HCPs and by bid.
One column in the list shows suit distribution for each hand in the format like "4332". I can quickly scroll through a range of points, looking for specific distributions such as 6-4 and see if any oddball distributions come up which need to be accounted for in the database.
These improvements alone have justified the time spent creating BidSim.
After a long time of mulling over the idea of duplicating a new or changed entry to other, similar Prior Bids sections in order to keep the database consistent, I have finally done something about it.
See the docs for a discussion of this features. It really wasn't that hard to do, but due to the scarcity of screen real estate, it did involve putting the Dupe input boxes in a far right corner of the Edit window which users without 1280x screen resolution may not be able to see. Which also brings us to...
Dual Monitor Support:
My wife's nephew has two computers, one with two monitors and another with three. Even his mother (my wife's sister) has two monitors on her little setup -- and she still has VHS (no DVD) in her living room, so she isn't exactly on the cutting edge of technology.
On each system, the 2 or 3 monitors share the same virtual desktop, allowing windows to be dragged to other displays and spreadsheets to span multiple monitors.
Okay, this has been around since Win98 and I never noticed. So sue me. There's too much dang technology to keep up with. Anyway, I rushed right out when I saw this setup and bought a 17" LCD display at Fry's for $250 (after $70 rebate) and hooked it up to my Dell Inspiron 8500 notebook with 15" 1280x800 widescreen display, clicked on the desktop, told it to extend the display to the new monitor, and there it was.
It was that easy, and it's wonderful. But I had to make a lot of code changes to support 2+ displays. (I actually would love to have 3 displays, but can't on the notebook.) VB6 doesn't support dual displays, so I had to search the web. I got a routine from Microsoft's forum (multimon.exe), but as is the way with MS, the code was needlessly complex and convoluted, and even buggy (wouldn't center a form on a 2nd display, typo's on the command buttons, etc.).
I found another set of routines on a non-MS web site. It was a less convoluted and not buggy. I was able to distill it down to some short, to-the-point routines and added it the program.
The most time-consuming part of adding it was modifying the File Viewing program, which has to automatically adjust for the viewing display width for displaying one file or two, with only one monitor active or two.
11-4-2004File Viewer Panel Resizer:
When I added the support for dual monitors, I spent a lot of time on resizing the File Viewing window (at the time, part of a single BidBase program, but subsequently made standalone), which included allowing the user to adjust the relative sizes of the two panels when two are visible.
Since the browser and text boxes don't allow click-and-drag resizing, I tried several ways of implementing that and settled on a horizontal scroll bar at the bottom of the screen, but that really looked kludgy.
The obvious way to handle it was to let the user click-and-drag between the two panels. Finally, someone on one of the VB6 newsgroups told me how to do it with a Picture control between the two with no borders, so it doesn't show up, but that is what the user is clicking on. See the pSplitterBar routines for details.
The Bidding DLL:
I have been programming in VB6 for WinXP compatibility reasons, but using only VB3 syntax (for the most part). I have never studied and learned all the new features in VB4, 5, and 6. So now I am light years behind.
I've spent the last two weeks trying to figure out how to write a DLL with VB6 so that I can give other programmers a DLL to add to their programs from which they can get a bid after passing it prior bids, current hand, and vulnerability.
I have finally figured it out and have just started working on it. (Not to harp on an old theme, but could MS's help files be any less helpful?)
11-8-2004File Viewer Made Stand-Alone:
The BidBase code is getting pretty large, and the notes file viewer really doesn't have to be part of the main app, so I split it off into a separate EXE. The good thing about this is that now you can have as many note viewing screens open at a time as you wish.
It took a few hours to fix up the code to work okay stand-alone, which is a lot more than I expected. Now I need to change BidBase to call the view through a Shell command instead of loading a form. (Later: Well, that was easy for a change. Only took a few minutes.)
I could just use the default browser to display the note files, but my program still has a few advantages, such as the built-in HTML, the ability to view two HTML files at once, and an easier way to search for local files to view.
After I get the DLL working, my next project will be to split the hand dealer and the bid simulator into separate EXEs as well.
11-16-2004Beefing Up Features In File Viewer:
Added quite a few features to the File Viewer
07-06-2005Wow, it's been quite a bit of time since my last entry.
Back in 11-04-2004, I said that I had figured out how to write a bidding DLL. I finished that project and now have a "Bidder" DLL which can be used by any Windows app to pass parameters to the Bidder and get back a bid.
I also split the practice dealer and the bidding simulator into stand-alone programs which use the Bidder. The practice dealer can also call up the BidBase Editor, pass it a hand, and bring up the bid in the editor for the user to view or change. Then when the user is done, the practice dealer will rebid with the new entry (or entries).
I added my own spelling checker to the File Viewer, as mentioned above, and it works very well. I had a great many problems in File Viewer because of the odd way the browser control works. One problem which seemed almost insurmountable was that it works one way when single-stepping and a different way when running full speed, making it almost impossible to find out why the program was not working right.
I have gone the last 2-3 months (maybe more) without working on the program. Something happened to dampen my enthusiasm, and to tell the truth, I don't even remember what it was. But I seem to have my enthusiasm back now, and I am currently working on the BidBase Editor to modify it to use the Bidder. This is a lot more complicated than modifying the Dealer and BidSim because the Editor uses bid look-up's for a number of different purposes.
08-08-2005Well, I guess what made me lose my enthusiasm was the amount of work it took to rewrite the BidBase Editor. I've about finished it, and I know the File Viewer is working fine, but I haven't looked at the Practice Dealer nor BidSim much. I think that the Dealer is okay, but that BidSim still needs a lot of work on its update.
I don't think that I mentioned here that part of the problem with rewriting the programs was changing the code from VB3 style to VB6 style, such as explicitly declaring all variables, structuring the code better, and adding lots more lines of comments.
In rewriting the Editor to split out the database lookup code, I was concerned because the Editor does things that a regular program does not have to worry about, such as testing new entries. I had to add a couple of new parameters to the BidBaseDB (DLL) program, and while the recoding was a headache, the actual getting the bid lookup to work was not a problem.
I added some drag-and-drop code to the Editor to allow a couple of the pop-up "windows" (frames, actually) to be moved out of the way. Once again, the VB6 help file was useless and I had to go online to find out how to make this work. It is relatively complicated for what is an intrinsic Windows function.
I don't think that I've mentioned this before, but the in-program Tutorial is a really nice feature, that I wish other people's programs had. It's been my experience (both as a programmer and as a user) that most users don't refer to Help files until there is a real problem, thus they may miss out on a lot of program features because they (like me) are too lazy to look them up in the docs.
In BidBase Editor, a first-time user is automatically shown the full tutorial. After that, the full tutorial or individual menu item tutorials can be invoked from the Help menu.
08-12-2005I've been working on entering data, but then I noticed that the routine that calculates the Prior Bids for the Dupe Entry boxes was not doing a good job of coming up with similar Prior Bids.
I tried improving the code, but it got to be too complicated. So I went to MS Access and created a new table with the idea of having all similar bids in one record. I had a column for each suit. Started entering Prior Bid sets (e.g.: 1C-1D, 1C-1H, 1C-1S), but then realized that several more Prior Bids would also be similar, such as 1D-1H, 1D-1S, 1H-1S, to continue the previous example. But at the time, I thought that the number of possible similar bids for each Prior Bid could be too large to handle this way, so I deleted the table and went back to coding.
The coding was working, and after writing out sets of similar Prior Bids (such as the example above) on paper, it appeared that 6 sets of Prior Bids would be sufficient.
So back to Access, created the table, and entered the sets of Prior Bids. I only put in about 3 dozen entries, but that is a very good starting point for the first round of bidding. I'll add more as needed.
Meanwhile, the code to display all similar Prior Bids in the Dupe boxes is very simple. See "Sub FillDupeBoxes". It's about 5 lines of code.
After working with the Dupe Entries a while, I figured out that it would be easier to work on them if the full Dupe Entries were displayed in a grid. I had to figure out the database call to accomplish that, but it wasn't very hard.
Having worked with the combination of the Dupe Entries boxes and the Dupes Grid for a while, I have come to the conclusion that other than accomplishing the programming of the basic concept of the program itself, this is the most important feature of the program. It allows new entries to be made while keeping the specifications of similar entries consistent. Plus, it is fast and easy to add multiple similar entries at the same time. As many as 8 or 9 entries can be made in under a minute.
I've done a lot of work lately reworking the Edit - Compare Entries routine. This was a very complex routine because of needing to compare specs for entries which should be similar, but which should not be exactly the same, such as raising 1H versus raising 1S. One requires 3+ Hearts and the other, 3+ Spades, so we want to ignore this correct difference while flagging incorrect differences, such as if one specified 5+ HCPs while the other said 6+ HCPs.
I finally realized that when the comparison is easy if you use Edit - Use Entry to mock up a new entry for one grid using the data from the other grid, and compare the entry in the second grid to the data in the Input Boxes. For example, if you do an Edit - Use Entry on the raise-1H entry to mock up a raise-1S entry, it will automatically convert the 3+H spec to 3+S in the Input Boxes. Then when we compare the Input Boxes to the raise-1S entry we already have, the two sets of specs should match.
If the specs in the Input Box are wrong, then the Edit - Use Entry routine is wrong and must be fixed, which I have spent a good bit of time doing. (And it's still not perfect. It remains to be seen if every possible combination of specs can be automatically converted for "similar" prior bids. The problem is: if there is an error in the conversion, the user probably won't notice it because he is so used to the conversion being correct.)
At the same time, I junked the old Compare Entries routine for a much simpler routine with code much easier for other programmers to follow. Basically, suit-specific specs, such as suit quantities and HCPs, test hand, and distribution disclosure, are compared to the Input Boxes. Other specs, such as hand HCPs, hand shape, etc., are still compared grid-to-grid because it is easier to loop through the grid columns than to have to name each Input Box one field at a time to compare.
I've invested all this time on the Compare routines because I've come to realize how important it is for keeping the database consistent. I also added a lot of text to the docs to stress this.
I also replaced a complex VB InputBox with the box above. This was pretty complicated because we recommend to users that they put the "master" set of Prior Bids in the top grid ("Grid 1") and the entries to be changed in the bottom grid ("Grid 2"), and then we load the Grid 1 entry into the Input Boxes to compare to Grid 2, but sometimes the user may want to change the Grid 1 entry, meaning everything in the box above must be changed around.
It was also hard to work out the least confusing way to present this data, since for suit-specific fields, you can copy specs from Grid 1 to Grid 2 by actually copying the data from the Input Boxes, you cannot copy Grid 2 data to Grid 1 unless you first mock up an entry for Grid 1 in the Input Boxes using Grid 2's data, then copy the data from the Input Boxes to Grid 1.
If this is confusing to read, then you understand why it was so difficult to present it in a way that the user could grasp it.
On a side note -- the last 3 option buttons on the bottom-left actually work like buttons, in that when you click on one, some code is executed and the window closes. I thought about changing them to buttons, but I think the window looks better as-is (better balanced and not overwhelmed with command buttons), plus it is more logically consistent to have them appear as alternatives to the first two option buttons.
I've mostly been working on data entry the last month, making only minor mods to the program. I think the only new feature added this month was the Google button.
Meanw hile, I have worked through Mike Lawrence's books Takeout Doubles and Overcalls, entering every example hand and its specs. I am currently working on finishing up his book on Balancing.
It is often difficult to come up with general specs based on his comments and a sample hand. Often, a later example will necessitate modification of an earlier entry, which means that when there were not additional examples, the specs may not be as good as they could be. There is no way around this. Even experts disagree about bidding. At least I am getting a foundation laid upon which a more precise database can be built.
Meanwhile, I continue to create entries based on the daily newspaper column by Bobby Wolff, as well as from the monthly ACBL and Bridge World magazines.
In the course of making these new entries, I have increased the number of similar Prior Bids sections in the database to over 150.
Major Remaining Problem With BidBase
The Dupe Entries boxes and Dupe Grids went a long way to making BidBase more easily useable by the average user. However, at least one major problem remains to be solved before BidBase is ready for prime time -- an easy way to select and deselect systems, conventions, and even different bidding styles or judgments.
Once I tried to develop BidBase in cooperation with a software company who was trying to create a bridge playing program. We finally broke it off because of too many differences of opinions, one of which was that they insisted that each system had to be in its own database, while I insisted that all bids needed to be in the same database.
Here are my reasons:
1. Most systems share many, many bids. It is difficult enough to try to maintain consistency of bids in the same database. Doing so for bids in different databases would be - if not virtually impossible - a major headache.
2. The nature of BidBase is that every entry in a Prior Bids section is a filter for every entry which comes after it. (See the doc files for more explanantion of this.) So it is also not possible to keep the common types of bid entries in one file and system-specific entries in separate files.
When I started BidBase, I created a set of system- and convention-selection windows. The user would be able to select a convention by clicking on its name, then the program would activate and deactivate entires as needed. This would be ideal, if it can be made to work.
For this to work, a data file would have to be created for keeping track of which entries are needed for each convention, keeping in mind that the same entry can be used by many different conventions (or bidding styles).
The BidBase editor would also have to be modified to allow the user to select which convention(s) an entry is for. It may be possible for the Convention Name field to be used for that.
As mentioned above, making it easier to select and deselect systems, conventions, and methods is a major problem which would have to be solved before BidBase could be released to the public.
I could not expect the user to go through each of thousand of entries in BidBase to select/deselect individual entries.
For example, to deselect Jacoby Transfers, he would have to bring up the entries for responses after 1N-P, 1N-D, 1N-2C, etc., then go through each of those sections looking for Jacoby Transfer entries, then enter "0" in the Pct field for each one.
Then he would have to bring up each section of continuation bids, such as 1N-P-2D-P, 1N-P-2H-P, 1N-2C-2H-P, 1N-2C-2H-3C, etc., looking for and deselecting follow-up bids to Jacoby Transfers, as well as opponents' bids based on JT's. That's a lot of work.
This problem has always been in the back of my mind. Then the other day, it came to me that all I needed to do to simplify things was to add a Selected field to the BidNames table so that the user could select or deselect a convention from a convention name list (which includes the names of all bids, not just "conventions").
So continuing the last example, now all the user has to do is go to the conventions names list and deselect the Jacoby Transfer entry. This may seem obvious, but things usually are once you've worked out a solution to a problem which has just evolved over time.
Getting in my way of seeing this earlier was that (1) I didn't even have the BidNames table at the beginning, and (2) I was already using a method (the Pct field) of selecting and deselecting entries before I came up with the BidNames table.
The existing Pct field will still be used, but only for entries belonging to selected conventions, where you select or deselect specific entries within a convention, as well as setting percentages for alternative bids with the same specs.
Before I could implement this convention selection system, I had to improve the way convention names are handled. I already had set up a BidNames table in the database in which the convention names were all supposed to be stored, but in the bidding entries table, in the field for convention name and the field for the convention to use an entry against, the full names were stored rather than just the convention's ID# from the convention names table.
This was a waste of space, but not critically so in these days of huge hard drives. The real problem was that I didn't know how to store just the convention name's ID# in entries and still get the grids to show the name rather than the number. (I had done this type of thing in some programs many years ago, but couldn't remember how.)
I spent most of a couple of days reading help files, searching the Internet, and experimenting. Not even the gurus on the Microsoft VB6 newsgroups could tell me how to solve the problem. But I finally worked it out, so for future reference, here's how to do it:
New And Improved:
Now you can see why I didn't handle Bid Names this way to start with!
The above is a lot of programming detail to have written up here, but if someone (including myself) ever has to try to follow my work, this detail is probably essential. After all, I was not able to remember how I had done this years earlier, and it took many, many hours to figure it all out again.
Still to resolve --
Now that BidBase has this much easier way to choose conventions, still to be resolved is the interface to use.
The simplest would be to let users bring up a grid of the Bid Names, but the names would not be grouped by category, making it more of a problem to choose among alternative treatments.
I'm considering adding a Category field to the BidNames table so that each convention could be assigned to something like Opening Bids, Overcalls, Responses To Opener, Rebids By Opener, Responses By Advancer, Balancing, etc., then the grid could be sorted by Category.
Also, I still have the forms I made up years ago for selecting conventions, etc. These would be even easier for the user, though not as flexible in terms of showing all the conventions since forms are "hard-coded". A combination of a grid and these forms will probably be best.
In 2006, I quit working on BidBase for several reasons. The main was that the idea behind BB was to allow users to enter whatever conventions/bids they wanted, but the number of serious bridge players who study and work at improving their bridge games and knowledge is extremely small. Very possibly less than a few hundred in the U.S.
This raises the question of how many people would even be interested in BidBase and would take the time to learn to use it much less expend the effort to use it.
Another problem is that just entering data for BidBase (specifications needed to make each possible bid) is an enormous task which is unlikely to get finished in my lifetime.
Another project that I had in the backgrond in the early 2000s was writing code for natural language processing for artificial intelligence. The demand for such a program would be astronomical. So from 2006 to date (August 2018), I've spent my programming time on that project. As with BidBase, I have gotten the AI-NLP code working and am spending most of my time entering data for it.
Recently something made me want to take a look at the bridge programs again, but when I did, nothing wanted to work right, mostly due to the fact that the code was written in Visual Basic 6 which Microsoft quit supporting ages ago. For example, the Microsoft grid control used to display data from the databases would not even load. And a DLL which I created to do bidding said that a file (form) was missing despite the fact that the form was compiled into the DLL. To make matters worse, I spent hours locating and scouring backups and could find no trace of such a file.
Grid Control Files:
The big problem with the Grid control is that VB6 couldn't find the file for it even though it was there. Making it hard to find the solution was that there are several grid controls for VB6 and I was experimenting with each and getting nowhere.
I also spent a lot of time Googling and reading about other people's efforts with the same problem, finally coming across GridFix.exe which fixes the Register. After running that, Dbgrid32.ocx would load, but then it turned out that when I had loaded program code without the Grid control, VB6 substituted a Picture control for it (??) and I lost everything I had assigned to the grids and had no idea what they were.
My code showed that the Grids in the BB Editor used Splits and I could not find ANY information on the Web about how to implement those in Dbgrid.
The Bids table in the BidBase.mdb database has 59 columns in it but when I finally got DBGrid32 to load and deleted the Picture controls and tried to set up the grid controls, they only had 2 columns. Some people on the Web were saying how to programmatically add columns, but their solutions didn't work for me. For example, some people said that when you assign the database to a Data control then assign the Data control to a grid, it automatically added the columns and headings, but not for me.
Ultimately, I had to manually add one column at a time, then go through and enter the column headings (field names) for each one. Then I removed the other 3 grid controls in the BB Editor and copied the one that I had fixed up to make 3 more grids with the columns and headings. There must be an easier way, but none surfaced in response to my research and efforts.
When I tried to load BidBaseDB.vbp, it gave an error message that frmBidBaseAnalysis.frm was missing. Even the compiled BidBaseDB.DLL gave the same message, yet the DLL worked back in 2006. Searching my multiple backups on all my hard drives and old computers did not turn up any trace of the file nor was in mentioned in any of my doc files.
Fortunately, the form was not that complicated - just a list control and a couple of buttons - so I was able to reproduce it, but how it disappeared remains a huge mystery.
After getting the grids set up, I was able to get the program running, but got the above error message on the code below:
PB_Sort_Order Between ' 5' AND ' 5' _
ORDER BY Bids.Round, Bids.Player, Bids.PB_Sort_Order, Bids.Bid_Order_Number, _
BidNames.Selected, BidNames.SubCat_Selected, Bids.Pct_Used;"
The odd thing is that qSel is empty. In fact, when this error happens, the database has not been initialized yet because LoadConfig comes first in Form.Load. This is due to the line mTwoGrids_Click which is in Sub LoadConfig which, in turn, calls b_Show_Click which tries to display the grids which, as said, have not been initialized yet.
Removing the m_TwoGrids_Click line fixes that problem, but then the program advances and gets the message --
Microsoft Jet database engine cannot find the input table or query 'HandVal'.
The code creating this error is:
Set NewBid = New BidBaseDB.Bidder With NewBid .DBPathAndName = App.Path & "\" & str_Database ... ' Get bid: ' b = .Bid
The BB Editor project needs the BidBaseDB.DLL or .VBP to look up bids, and it also requires you to explicitly select whichever one you want to use in the Projects - References menu list.
I already had a BidBase_Editor.VBG, which is a VB Group which includes the BidBase_Editor.VBP (Project) and the BidBaseDB.VBP (Project). When loaded, the Bidbase_Editor line was in bold, indicating the when run, the program would start with that project, so everything looke fine, except when I tried to run the program.
So I checked the References (in the Project menu) and BidBaseDB.VBP didn't appear. I browsed for it, but References would not allow adding a file with a VBP extension, despite the fact that it's been in the References list before. Another mystery brought to you by MS.
So I Referenced BidBaseDB.DLL instead, but when the code reached b = .Bid, which is a call to the DLL, it bombed.
So I unchecked the DLL, clicked VB6's File menu and Add Project, then loaded BidBaseDB.VBP. When I clicked on Project - References again, the VBP file was in the list. I checked it, ran the program, and everything worked and it made a bid on a Test hand.
I clicked X on the Editor program to end it, but the program did not unload. I eventually had to use Task Manager to end it, and when I restarted VB6 and the program, the VBP file was no longer in the References list and nothing I could do got it there.
When all else fails, reboot. Did that. Loaded BidBase_Editor.VBP into VB6. Clicked File-Add Project and could not get the BidBaseDB.VBP in the list. Then came the dawn...
BidBaseDB.VBP was still highlighted because I had just loaded it. I had always assumed that the References loaded were for the whole project group, but what if they were just for the last project clicked on. So I clicked on the Editor project, clicked Projects and References, and there in the list was BidBaseDB.VBP. I put a check mark on it and the program ran fine.
BUT... The next time I quit the Editor, once again the END never came about. However, this time I was able to close VB6 and it gave me a chance to save. When I restarted VB6 with the BidBaseEditor.VBG group which includes both the Editor and the BidBaseDB projects, and looked in Resources - no BidBaseDB,VBJ. I panicked for a couple of minutes and then remembered that I needed to click on the Editor.VBP name in the Project box, then checked Resources and BidBaseDB.VBP was there. Whew!
Final Note: You may see two BidBaseDB lines in References. Click on them and see which is the DLL and which is the VBP. It also shows the complete path for the file in case you have multiple copies around.
By the way... You cannot have two instances of the same Project loaded at the same time, and since most of the BB programs use the BidBaseDB.vbp project, only one of those programs can be loaded with that project. The other(s) must use the BidBaseDB.DLL in the Resources menu.
I haven't needed to use SendKeys in the last dozen years, but the BB Editor Tutorial uses SendKeys a lot and it is no longer supported in Win10 (for security reasons, I am told).
Supposedly, there are some fixes, but these seem to have been written in the days of Windows Vista and, let's face it, not many people are still programming in VB6, it appears. Personally, I just can't justify the time it would take to learn a new language to the level of expertise I have in VB6 and then rewrite all my programs, some of which are extremely large and complex.
So I'm just going to do without SendKeys.
I've mostly been running the Practice program and fixing and entering bids via the Editor.
One significant new feature is the ability to manually enter deals in the Practice program. This is handy for working on problem hands from books, magazines, newspaper columns, the Internet, etc.
The user can enter as many hands as he wants and let the program randomly deal the remaining cards to the other hands. When entering a complete deal, the user can stop after the 3rd hand since the remaining card must all go to the 4th hand.
After bidding the hands, the user can elect to have the cards in selected hands (normally the opponents' or partner's or both) reshuffled and dealt to those hands to see how the distribution of those cards affects the bidding.
The BidBase Bidding Simulator can go even further by entering hands in it and letting it generate thousands of deals to see how the cards are distributed on average and thus what the hands are likely to bid.
While I could have just used Text control boxes for entering hands, I'm using what I did in CardShark Spades for Android - displaying the whole deck spread out and letting the user click on the desired cards. This eliminates the need to check input for validity.
To display the hands which are dealt by the program, I use the DrawCard function in the Qcard32.DLL that is included with the program. (I did not create the DLL; it is public domain.) Each card is drawn in the same Picture control and positioned in the DrawCard command where it needs to go.
Rather than using that procedure for displaying the cards for the user to select when entering hands, I put 4 rows (1 for each suit) of 13 picture controls [Card(1)-Card(52)] in a Frame control (f_CardDeck). So I'm using 52 Picture controls when probably none are necessary, but the program doesn't use many resoources and I thought it would make the code simpler.
A "Enter Hands" button was added. When clicked, it disappears and four buttons below it show up for indicating which hands are being given cards. See the Practice doc file for more info.
09-07-2018:I have been working daily on the programs but putting my notes in the individual documentation files or in this file.
I was using the Practice program to bone up on 2-Over-1 to play with a friend and was making changes to that program at the same time.
RKCB 1430 Entered:
I also wanted to review Roman Key Card Blackwood 1430 but the way BidBase was designed, to create a new entry, you have to enter all the bids leading up to it. Long story, short: I simply made a prior bid of "4NT" and carried on from there. My assumption is that in the course of a regular bidding sequence, when 4NT is bid, software using BidBase will know how to call for the bid.
While I was at it, I made entries from DOPI and ROPI.
The same idea can be used for any other ace-asking or high cue-bidding/doubling sequence.
Dec. 2020 update: I eventually used a bid format of "4N@##" for ace asking. This is explained in the doc file for the Editor - Entry Boxes.
Database Updated from .MDB to .ACCDB:
During my break in working on BidBase between 2006 and 2018, new releases of Access came out and in 2007, I upgraded. I was afraid that if I did this, it would break my programs which were working fine with the old format.
BidBase was created with Access 1997 with the .MDB extension. I could load the database into Access 2007, but it would not allow me to change the database unless I let it update the format to .ACCDB format.
I needed to make some small changes to the database structure to let me record RKCB 1430 bid entries, so I had no choice but to let Access 2007 update it. Sure enough, my worst fears were more than realized and I've spent weeks trying to get the programs to work again.
In fact, it was only today that I got the Editor program to even start to run when using the new database. It kept giving me cryptic and even bogus error messages (e.g.: No SELECT [etc.] given in the RecordSource.
Eventually, I created a simple test project with a single form, a grid, and a data object. I got it to work, but when I copied the RecordSource specification into the Editor properties, it would still give the same bogus errors.
Next I copied the test form from into the Editor project and made it the starting form. It worked. Again, plugged its code into the Editor's form's properties, it wouldn't work. Eventually, I deleted the 5 grids and 5 data controls from the Editor's form, copied and pasted the controls from the test onto the Editor's form, and it finally worked.
I'm still getting error messages related to the database later in the Editor's code, none of which make sense (telling me a table in a database is not there when it is), so it's not working yet.
In the middle of this, I tried finishing up the CardShark BidBase HTML File Viewer/Editor to work with a bunch of specific bridge writing features to work, such as inserting suit symbols.
Again I was running into problems which made no sense, such as two lines of HTML/CSS code which looked identical but one instance would work and the other wouldn't. This turned out in one case to be that some CSS (I think) is case-sensitive. Specifically, STYLE=... will not work. It has to be lowercase.
In 30 years of making Web pages (admittedly mainly for my own use) and even longer of using programming languages, I had never (that I can recall) run into a situation where case mattered in the code itself.
In another situation, it turned out a problem was caused by the order in which Project - References were listed. Again, something I had never run into or heard of before.
Then after I got everything working in the HTML Editor/Viewer, I opened the Editor/Viewer's documentation file in Chrome and it didn't work. Turns out that new browsers support all of the old HTML.
I finally got the HTML Editor/Viewer working, which is nice for the BidBase project which has dozens of files explaining systems, conventions, etc.
All the BidBase documentation files have been uploaded to www.aeyec.com/BidBase, and as of today, I'm working full-time on trying to get the BidBase database editor to work.
09-06-2019:Wow! I really haven't been keeping up with these notes. I have mostly been making new bidding entries, but lately have made some significant changes.
Bidding Practice Program:
A new feature added at the bottom of the window shows the Double Dummy Analysis of the hand shown. This can be helpful in deciding how to bid and how to make entries in BidBase.
The DDA was written by Bo Haglund and can be used by programmers without charge. At first I couldn't find it on his web site, but when I emailed Bo about it, he sent me a link for downloading it.
The next problem was that I could not get it to work with Visual Basic 6 which BidBase is written in.
A few weeks later I stumbled across a programming blog by Tim Anderson who had the same problem but he had been able to modify the files to make it work with VB6. I posted a mesage on his blog asking about getting the fix and he sent me a link to get it.
Happily, it was easy to implement and as you can see, it works fine.
A long-term goal for the practice program has been to let the user choose a convention to practice rather than just going through random deals. Many conventions come up only rarely which can make it hard to remember the bids when the need does arise. Practicing such conventions could be done in an hour or less a week.
One way to do that would be to list the conventions in a menu and have a bunch of deals created for the purpose of practicing the selected convention. At least one bridge program works this way.
The problems with this approach are (1) deals which are designed just for that purpose do not provide the variety of realism of randomly generated files and (2) only the conventions which are hard-coded into the program are supported.
The method adopted for BidBase is to create files for conventions in which the database is searched for deals which match the auction specifications for a convention. Obviously, this does away with the disadvantages mentioned above.
The first step was to provide a means for entering the auctions to search for. The combo list box shown above was actually added for that purpose and is used for DDA when not needed for finding deals.
These are all the possible starting bids for New Minor Forcing. Because it can take minutes (or longer) between deals to find the next matching deal, an alternative is offered for the user to create the specified auctions and run a search during which the deal number for each matching file is saved in a file for the convention.
Each stored convention has two files. The first gives the convention name followed by the specified auctions, just as they appear above.
The second file contains the deal number and dealer number (S=1) for each matching deal. The first test run came up with 120 deals out of 10,000 deals checked or 1.2%, illustrating why it is better to find the matching deals in advance of using them.
The reason for saving the dealer number is that a specified auction could start with any player as dealer, so we need to know who to make dealer when displaying the deal.
On the other hand, it makes more sense to always have a specified auction end with East so that the user (South) is the next to bid.
At first only the bidding with South as declarer was used for testing deals, but the numbers between matching files were even huger. So then a somewhat complex method was used to start with South, testing all the auctions specified, and if no matches were found, move to West as declarer, then North, and then East. This quadruples the chances of finding a matching auction in each deal. (Maybe... Math isn't my strong point.)
The reason for having two files is to allow making the deal number list a random access file to make it easier when a user wants to stop after a certain deal and next time start with that deal.
Each record in the file is 6 bytes - 4 for the deal number stored in n long integer and 2 for the dealer number stored as an integer.
The file record in the Deals file contains the deal number in the long integer field and the record number in the 2-byte field. The two fields should point to the same deal, but it gives us something to check against.
Files are given names indicating the convention, such as "New Minor Forcing", "Drury", "Bergen Raises", etc.
For more information about how the practice system works, see the BB Practice documentation.
Problems Referencing BidBaseDB.vbp
Sometimes I have a problem with BidBaseDB while in the Editor program and sometimes while in the Practice program. In order to debug it, the program being run must Reference the .vbd file, not the .DLL file.
However, the .vbd file cannot be referenced by to programs at the same time, so when it is referenced by one, the other program has to reference the .DLL file.
Win10 recently did an update and that always leads to all sorts of problems in all sorts of programs, so I wasn't too surprised on 12-05-19 when was having a problem with the DB program while running the Practice program which was using the DLL.
So I stopped the Editor program and quit that instance of VB6, then stopped the Practice program, quit that instance of VB6, and restarted it with the Practice program along with the DB.vbp program (rather than the DB.DLL). After doing that, you always have to go Project - Reference menu in VB6, uncheck the DLL and check the VBD, but VB6 told me the VBD file was missing.
This was the same file at the same location. In all these decades, I've never had this happen before. I spent a lot of time browsing and trying and checking different setups, but to no avail.
When I quit the Practice program and loaded the Editor, the same menu loaded it fine.
But after closing the References windows, I got this...:
I next tried the old standby of rebooting Windows. and trying again. At first it didn't work, but after trying it again, it did work, so I still don't know what caused it or what fixed it.
On a side note, piece of crap that VB6 is, it does not allow you to delete a line from the "Available Resources". A year or so ago when I was having an "impossible" problem, I had copied the VBP file to a temporary backup drive. After fixing the problem, I deleted the temporary backup file, yet to this day it still appears in the list and cannot be deleted.
So when I got the bogus "MISSING" message, I could not delete that line either.
Changes to DB in Practice not showing on Editor grids:
Actually, the changes are in the Bidder DLL in Practice.
The new entry shows up in Access 2007 and in the bidding in Practice, but I cannot get it to show up in Editor grid(s) when I import the same hand from Practice, even though it makes the new bid for the imported hand.
Things I've tried:
It makes no sense that even restarting VB6 would not cause the entry to show in the grid.
The only way I can get it to show in the grid in the Editor is to search for the new ID#, copy the entry to the Input Boxes, then save it:
May 2020: Auto-Generating BidsI've always known that I could not make a database entry for every possible bid and that whatever methods which bridge game programmers are using to generate bids would have to be used for bids which cannot be found in BidBase.
A year or so ago I finished making entries for over 75 conventions, which was my initial goal for BidBase, and since then I've mostly been getting the Practice program to generate bids and trying to get entries for all the bids for each deal.
This is a very slow process, so recently I've been thinking about using the DDA analyzer to help compute the bidding for deals.
When the Practice program generates a random deal, it computes the 10-deal DDA to determine the optimum contract for each side. It then starts calling up the bidding for each hand in order. If CSBB doesn't have a bid, the program computes one which will result in the optimum contract.
I thought that if an OCR program was available, I could cut-and-paste hands and bidding from graphical displays, such as ACBL's Bulleting online and bridge columns in online newspapers.