CardShark BidBase
Programming Notes

The Origins

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 Database

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 Format

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 Grids

Bid Order Numbers

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 Order

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:

Bid

Code

Bid

Code

Bid

Code

Bid

Code

Bid

Code

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 Box

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 Spec

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 Routine

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 Entries

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-2004

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-2004

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.

Opening Passes:

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.

10-14-2004

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-2004

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-2004

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-2004

Added quite a few features to the File Viewer

• Adding the Table Specs Window was like writing a whole new program. The window has its own little browser so that the user can immediately see the results of changes to the specs. Several new Table options were added.

  The Color Picker was the hardest part because it was difficult to figure out how to translate the HTML color codes (e.g.: "#1300A7") to the Color Picker codes (e.g.: "&H08F235"). Same old story -- nothing in VB Help nor anything I could find on the web explained the difference.

  Finally figured out that both are 3 sets of 2-character Hex codes representing Red, Green, and Blue colors, but while HTML expects them in RGB order, VB/Windows expects them in BGR order, so a little conversion routine solved the problem.
  
  

• Added some more List options, but I still don't understand why sometimes <UL> skips a line (as it does above) and sometimes it doesn't (as in the File Viewer doc file).
  
  
• Broke the HTML menu down into main categories with submenus.
  
  
• Added Spell Checking using MS Word, but it is slow, so I'm looking into coding my own spell checker. I downloaded a routine which uses Soundex to provide suggested spelling corrections, and got some really good word lists from the Web to use as dictionaries.

  The only problem is that loading a large dictionary takes even longer than Word. Part of that time is calculating the Soundex code for each word. I would create an Access database to hold the words, calculate the Soundex code for each word as added, and not load the words all into memory at once.

07-06-2005

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-2005

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-2005

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.

09-2005

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.

10-2005

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.

11-2005

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:

Background:

• Originally, I set up the database in the MS Access database program setting up the fields in the Bids table.

• In VB6, the main form had a Data Control and a couple of data-bound grids.

• In VB6 ("design time"), in the Properties window for the DC, I set the database to BidBase.mdb and the RecordSource to the Bids table.

• Right-clicking on the grid and selecting Properties brought up a window where I could assign Bids fields to columns via a drop-down list.

  At the time, I could see no way to set up a column for non-field data, such as displaying convention names if all I had was convention name ID#'s in the table assigned as RecordSource.

  I didn't have a data table for BidNames (convention names) to start with. Names were entered in the individual entries. Eventually, I made the input box for entering bid names into a drop-down list (combo box, actually) to make it easier to see what names had already been entered.

  Despite the use of the combo box for entering names, several problems ensued. One was that I often added names in the grid, where a new name entered didn't make it into the BidNames table. Another was that many names were used in entries prior to the combo box and thus were also not in the BidNames table. Finally, if I wanted to change a bid name a little (or a lot), if there were 50 entries with that bid name, I had to change them all individually.

New And Improved:

1. First, I backed up the database file, BidBase.mdb. (Actually, all my files are backed up to an external hard drive every night.)

2. In Access, I brought up BidBase and opened the Bids table in Design mode. I inserted a field in front of the existing Conv_Name field and made it a Number field type. I gave it the name ConvID. I did the same for AgainstID in front of the existing Against (convention) field.

3. On one half of the screen, I opened the Bids table in the edit mode and on the right have, the BidNames table, sorting them both by (bid) name.

4. I went down the list, getting the ID# from the BidNames table for each matching name and putting it into the ConvID field in the Bids table. I did the same for the AgainstID field. (With over 5000 bidding entries at the time, this one "little" step took two long days to complete. I could have written code to do it, but I really needed to look at each entry to make sure each was right.)

5. I clicked the Query tab to create a new Query (using the Simple Query Wizard) to include the Selected and Bid_Name fields from BidNames and all fields from Bids table. This has the effect of creating a new table with the selected fields from two different tables. However, the Number field from BidNames can only link to one Bid Name ID# field in the Bids table.

6. To link the Against ID# field to the Bids table, I opened the Query in the Design mode, right clicked on the Design window, and a menu came up. I clicked on Show Table and a list of the Tables came up. I dragged the BidNames table to the Design window, which created a second instance of that table in the Query.

7. I clicked on the Number field in the new instance of the BidNames table and dragged it to the AgainstID field in the Bids field list.

8. I dragged the Selected and Bid_Name fields from the same BidNames box down to the table of fields to show. It added them to the end, so I highlighted the two columns and dragged them back to be next to the AgainstID column.

9. I checked the table to make sure that the Bid_Name field from BidNames matched the Conv_Name field from Bids. When it did, I quit Query, saving the Query as BidNames_Query. I clicked the Tables tab, opened the Bids table in the Design mode, and deleted the Conv_Name and Against fields from the Bids table, leaving their ID# fields.

10. I deleted the old Garbage table, opened the Bids table in Design mode, clicked on File - Save-As, and saved the data structure as the new Garbage table. Opened the Garbage table and changed the Auto-Number field name to GarbageID and added a new field in front of it for the original Bids ID.

11. I closed Access and went back to the BidBase form in VB6, clicked on the Data Control, and clicked on the drop-down list for RecordSource. The list now showed the Query in addition to the tables, so I changed from using the Bids table as the RecordSource to using the Query. I repeated this for each Data Control using the Bids table.

12. I right-clicked on the Grids, clicked Properties, Columns, and the Conv_Name column and changed it to the Bid_Names column from BidNames and likewise for the Against column.

13. I did have a field for Team, which was to allow the user to specify if a bid was to be used by E-W, N-S or both. I decided that the Selected field could be used for that purpose, so I changed that column from Team to Selected. (I had already deleted the Team field before closing Access.) The Selected field is not needed for the Against. The program deselects those entries via the Pct field.

14. I then went into the program code and changed it so that when saving an entry, the BidNames and Against ID numbers are saved instead of the name. The changes actually took quite a bit more worked than anticipated, but it would have been worth 10 times the effort for the improvement in ease of use of BidBase.

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.

08-01-2018:

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.

Missing .FRM:

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.

Microsoft Jet database engine cannot find the input table or query

After getting the grids set up, I was able to get the program running, but got the above error message on the code below:

Data1(0).RecordSource = "qSel _
      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;"
Data1(0).Refresh

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.

SendKeys Is No More:

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.

08-11-2018:

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 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:

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.

Creating Practice Files:

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.

Example:

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.

Normal:

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.

Looks okay:

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:

• Executed Data1(0).Refresh and Grid1(0).Refresh.
• Used the Show feature to change the range of bids shown and changed back.
• Restarted Editor.
• Restarted VB6.and then started the Editor.

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:

    Set db_BidBase = ws_BidBase.OpenDatabase("BidBase.accdb")
    Set rs_BidTable = db_BidBase.OpenRecordset(str_BidsTbl)
    rs_BidTable.Index = "PrimaryKey"
    rs_BidTable.Seek "=", i
    lng_ID = i
    DisplayBid2Edit 99
    mSave_Click

May 2020: Auto-Generating Bids

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.

November-December 2020:
Installing MS OneNote Disaster

Someone said that Microsoft's OneNote app could do that, so I downloaded and installed it. Here is what happened:

I have two massive programs which have different, very large Access 2007 .accdb databases. One is Natural Language Processing and the other is a bridge game. I've been working on these programs for 20+ years as a retirement hobby; unlikely ever to be finished in my lifetime, but still important to me as a hobby.

I installed MS OneNote recently because I read that it can perform OCR, but I couldn't get it to work, so I uninstalled it, after which neither program would run any more. Long story, short: all the selections in "Project - Reference" and " - Components" were wiped out somehow.

I was able to reselect them all except "Microsoft Office 12.0 Access Database Engine Object Library". It is no longer in the Reference list. Instead, it has "Microsoft Office 16.0 Access Database Engine Object Library", but it points to a file in "C:\Program Files (x86)\Microsoft Office\root\vfs\ProgramFiles...". (That is all that is shown.) The "vfs" folder is now empty.

I don't know the actual filename which the Engine lines pointed to.
In "C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE12" is a file named "ACEDAO.DLL" but when I Browse in References and select that file, it does not show up in the Reference list.

When I load the bridge program and open a form with the Adodc data controls on it, I get the following message for each control: "Provider cannot be found. It may not be properly installed."

In the Adodc controls' Properties window, "Use Connection String" is
Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\Programming\VB98\Bridge\BidBase.accdb;Mode=ReadWrite;Persist Security Info=False

When I "Test Connection", it says:
Test connection failed because of an error in initializing provider.
[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified.

At first I got a message about the Registry not being right (didn't write down the message), so that may be related, though I never got the message again and I wouldn't know what to do in the Registry anyway.

The program's .vbp file has the following at the start:
(The indented lines are part of the line above them.)

Reference=*\G{3D5C6BF0-69A3-11D0-B393-00A0C9055D8E}
        #1.0#0#Package\Support\
        MSDERUN.DLL#Microsoft Data Environment Instance 1.0
Reference=*\G{4AC9E1DA-5BAD-4AC7-86E3-24F4CDCECA28}
        #c.0#0#..\..\..\PROGRA~2\COMMON~1\MICROS~1\OFFICE12\
        ACEDAO.DLL#Microsoft Office 12.0 Access database
        engine Object Library
Reference=*\G{E0E270C2-C0BE-11D0-8FE4-00A0C90A6341}
        #1.5#409#..\..\..\Windows\SysWOW64\simpdata.tlb
        #Microsoft OLE DB Simple Provider 1.5 Library
Reference=*\G{56BF9020-7A2F-11D0-9482-00A0C91110ED}
        #1.0#0#..\..\..\WINDOWS\SysWOW64\msbind.dll
        #Microsoft Data Binding Collection VB 6.0 (SP4)
Reference=*\G{B691E011-1797-432E-907A-4D8C69339129}
        #6.1#0#..\..\..\Program Files (x86)\Common Files\
        System\ado\msado15.dll#Microsoft ActiveX Data
        Objects 6.1 Library
Reference=*\G{06E83385-1A9A-46B1-B94F-D6CAFEAC6A51}
        #1.0#0#BidBaseDB.dll#BidBaseDB
Object={F9043C88-F6F2-101A-A3C9-08002B2F49FB}#1.2#0; ComDlg32.ocx
Object={FAEEE763-117E-101B-8933-08002B2F4F5A}#1.1#0; DBLIST32.OCX
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.2#0; Mscomctl.ocx
Object={6FBA474E-43AC-11CE-9A0E-00AA0062BB4C}#1.0#0; SYSINFO.OCX
Object={67397AA1-7FB1-11D0-B148-00A0C922E820}#6.0#0; MSADODC.OCX
Object={CDE57A40-8B86-11D0-B3C6-00A0C90AEA82}#1.0#0; MSDATGRD.OCX
Object={5E9E78A0-531B-11CF-91F6-C2863C385E30}#1.0#0; MSFLXGRD.OCX

I posted this on VBForums.com and got 6-8 suggestions. Here is my reply a few weekls later:

Thanks to everyone who replied. I've spent the time since then trying everything. Sometimes I could fix one problem only to create a new one. I had not previously tried doing a Restore because in all the years since Restore was "invented", I've never had to do a Restore and eventually just quit bothering to set a Restore Point.

Out of desperation, I looked at the Restore Points list and there was only one - the day MS installed OneNote and screwed up my computer. So I Restored and while that fixed some things, it did not fix the problem of "Microsoft Office 12.0 Access database engine" being missing. This mystified me because I thought that the purpose of Restore was to put things back the way they were before the Restore Point, and everything was fine before that.

Another strange things is that I have daily backups of my program directories, some of them in Zip files, and when I would load one into VB6 and check References, many of them were unchecked and re-checking them got rid of some of my errors, but with the system supposedly restored and with hundreds of these backup files, surely MS didn't somehow uncheck Resources in all of them. My guess is that they did something in the Registry that was causing it as the files are being loaded again. This is out of my league, but I can't think of anything else.

When I tried to download "Microsoft Office 12.0 Access database engine Object Library", MS was no longer making it available and instead put me on a page for downloading "Microsoft Office 10.0 Access database engine" which wasn't what I needed and I didn't want to risk screwing up anything else. But with nothing left to lose, I just tried it and everything is working, and References now shows that "Microsoft Office 12.0 Access database engine" is present.

I was very despondent over the apparent fact that I would no longer be able to work on my programs which provide so much enjoyment in my retirement, and I'm very happy to have them running again, but what is MS's problem?

Prior Bids Sort Order Code

Most often, bidding entries are grouped by Prior Bids. For example, if the prior bids are 1C-P, then all that is displayed in the grid are entries with those prior bids.

It is possible to specify a different starting and ending set of prior bids to be displayed in a grid, but I virtually never need to do that.

Obviously, if only the entries for one set of prior bids is being displayed in a grid we do not need the Prior Bids Sort Order codes, which means that we virtually never need this code, so I am very tempted to drop it because it adds 35 bytes to every entry and it complicates things to compute the code when things like bids with "@" in them are in the the prior bids.

However, it would take a lot of work to remove this code and then if it turned out that it is needed for some reason, I would be sad.

"@" in Slam Seeking Bids and Prior Bids

Since I'm not ready to completely remove the Prior Bids Sort Order Codes, I've decided to at least simplify things by not trying to encode slam seeking bids at this time. I'm just making the code bid the same as the Prior Bids field.

Also, I will not right justify the codes which have @ in them. This will ensure that the slam entries will be grouped at the end of the other bidding entries, which is actually where I want them anyway.

Automation error
ClassFactory cannot supply requested class
Around Mar. 7, 2021

This error went to the following line of code: Set NewBid = New BidBaseDB.bidder. Prior to this error I got a registry error, but it went away.

This had something to do with the file BidBaseDB.DLL and the error came out of nowhere while I had been using the BB programs without this error message.

After a lot of investigation of my files and online for the error message, I finally found that this had happened a few weeks earlier and I had tracked it down to VB6's Project-References saying that BidBaseDB.DLL was in a different directory even though an older copy of the file was in the listed directory.

So I clicked Browse in Project-Reference, opened the program directory, and double-clicked BidBaseDB.DLL, but P-R would not load it into the Reference list, so next I closed everything and rebooted and when I reloaded BidBase_Editor.vbp and repeated the same steps, VB6 loaded the DLL into the list, I selected it, and everyting was fine.

Another problem I had a few weeks ago was it telling me that MSCMCTL.OCX was missing when it wasn't, so I typed CMD into the Win10 search window and right clicked Command Prompt, entered REGSVR32 MSCOMCTL.OCX to re-register it and fixed that problem.

Registry Error loading BidBase programs into VB6.
Mar. 14, 2021 (See April 14, 2022 notes below before doing anything.)

I never turn my PC off at night. Last night I had the BidBase Practice program code open in VB6. It had been saved, but I left it open because I wanted to remember where I was working on the code.

For the 3rd night in a row, my PC rebooted. The first night, Win10 warned that it was going to update and I closed everything down, but the next two times there was no warning, so I don't know why it rebooted.

Windows Defender has not found anything wrong.

When I tried to load BidBase Editor into VB6 I got the Registry Error and clicked on "don't continue loading". I tried loading BB Practice and BB File Viewer and got the same error. But I loaded some other non-VB6 programs and then some VB6 programs without error. That should have been my clue that it was a problem with References and/or Components used by BB, but I was thinking that Viewer didn't use any of the same ones as Editor and Practice. (I was mistaken.)

I had installed drivers for a new Bluetooth adapter a couple of days ago and the installer had set a Restore point, so I tried Restoring the system at that point. I didn't think that there was a problem with the driver, but thought that doing a Restore would restore the Registry. It didn't.

I tried loading Editor again and this time when I got the error, told it to continue loading. I got the same error several times, but kept going. When it was done loading, it told me to see the log file, which had this:

Class MSFlexGridLib.MSFlexGrid of control g_OtherHands was not a loaded control class.
Class MSFlexGridLib.MSFlexGrid of control g_CompareGrid was not a loaded control class.
Class MSDataGridLib.DataGrid of control Grid1 was not a loaded control class.
Class SysInfoLib.SysInfo of control SysInfo was not a loaded control class.
Class MSComDlg.CommonDialog of control CmDia was not a loaded control class.
Class MSAdodcLib.Adodc of control Data1 was not a loaded control class.
Class MSAdodcLib.Adodc of control Data1 was not a loaded control class.
Class MSAdodcLib.Adodc of control Data1 was not a loaded control class.
Class MSAdodcLib.Adodc of control Data1 was not a loaded control class.
Class MSDataGridLib.DataGrid of control Grid1 was not a loaded control class.
Class MSDataGridLib.DataGrid of control Grid1 was not a loaded control class.
Class MSDataGridLib.DataGrid of control Grid1 was not a loaded control class.
Class MSDataGridLib.DataGrid of control Grid1 was not a loaded control class.

So I clicked Project - Components and these classes were not checked as they normally are. I checked them then ran the program and got the same error. I looked in Project - Components again and they were unchecked again.

I left Editor code open in VB6, clicked on Windows search, and ...

• typed "cmd"
• right-clicked on "Command Prompt",
• clicked on "Run as Administrator",
• entered "cd\windows\syswow64"
• entered "regsvr32 ... " followed by the file name for each of the classes
  (See the start of the BB source code to get the file names for the classes.)
  This step re-registered the components and fixed the problem.

Then I opened Project - Components and checked each of the above classes. The process of loading the programs when the classes were not registered caused them to get unchecked. If I had somehow known to do the regsvr32 step first, they wouldn't have gotten unchecked.

Since the components/classes used in Practice and File Viewer are some of the same ones used in Editor, the above steps took care of the problem for components they use too. In fact, since I never opened Practice or File Viewer after the Editor, their Project - Components never got unchecked.

April 14, 2022 Update:

I have been using MS Windows since Win1 and Visual Basic since VB1 -- over 35 years.
Never have I used any software more buggy than MS software and it continues to today.

Last night MS once again updated Windows without warning and once again I got the above registry error when I tried to reload VB6 with BidBase Editor.

I brought up this file, tried doing the CMD fix and got more errors.

I kept messing around and eventually reloaded VB6 with BidBase Editor so that I could get the list shown below, but this time I got no error message when loading it and it runs fine. I'm not aware of anything that I did that could possibly have fixed it, but it's fixed.

Here is the list of References and Components for future reference:

'                      CardShark BidBase Editor                       *
'                                                                     *
' Project - References:                                               *
' The program wouldn't work until I moved these into                  *
' this exact sequence using the Priority Up/Down arrows               *
'       Visual Basic For Applications                                 *
'          c:\windows\syswow64\msvbvm60.dll                           *
'       Visual Basic runtime objectss and procedures                  *
'          c:\windows\syswow64\msvbvm60.dll\3                         *
'       Microsoft Data Environment Instance                           *
'          c:\programming\Miscrosoft Visual Studio\VB98\VB6.OLB       *
'       Microsoft Office 12.0 Access database engine object library   *
'          C:\Program Files (x86)\Common Files\Microsoft Shared ...   *
'             ... \Office12\  ?                                       *
'       Microsoft OLE DB Simple Provider 1.5 Library                  *
'          C:\windows\syswow64\simpdata.db                            *
'       Microsoft Data Binding Collection VB 6.0                      *
'          C:\windows\syswow64\msbind.dll                             *
'       Microsoft AcctiveX Data Objects 6.1 Library                   *
'          C:\Program Files (x86)\Common Files\System\ado\msado15.dll *
'       BidBaseDB.vbp or .DLL                                         *
' I just noticed the next 2 in the list on 3-27-2021:                 *
'       Microsoft Data Source Interfaces for ActiveX Data Binding     *
'          Type Library -- MSDATSRC.TLB                               *
'       Microsoft Data Formatting Object Library 6.0 SP6 MSSTDFMT.DLL *
'                                                                     *
'  - Components:                                                      *
'       Microsoft ADO Data Control 6.0 (OLEDB)                        *
'          c:\windows\syswow64\MSADFODC.OCX                           *
'       Microsoft Common Dialog Control 6.0                           *
'          c:\windows\syswow64\ComDlg32.ocx                           *
'       Microsoft Data Bound List Control 6.0                         *
'          c:\windows\syswow64\DBList32.OCX                           *
'       Microsoft DataGrid Control 6.0                                *
'          c:\windows\syswow64\MSDATGRD.OCX                           *
'       Microsoft FlexGrid Control 6.0                                *
'          c:\windows\syswow64\MSFLXGRD.OCX                           *
'       Microsoft Sysinfo Control 5.0                                 *
'          c:\windows\syswow64\SYSINFO.OCX                            *
'       Microsoft Windows Common Controls 6.0                         *
'          c:\windows\syswow64\MXCOMCTL.OCX                           *

Compile error:
Method or data member not found

This error refers to the ConnectionString line below:

Private Sub Form_Load()
    For i = 0 To 3
        Data1(i).ConnectionString = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & _
             App.Path & "\BidBase.accdb;Mode=ReadWrite;Persist Security Info=False"
    Next

I entered this in the Intermediate window in VB6:

Print Dir$(App.Path & "\BidBase.accdb")

and got

BidBase.accdb

So the file is obviously there, plus this same code worked yesterday.

I think that the following had something to do with the above error, but wouldn't swear to it.

I was comparing a current BidBase_Editor.Frm which was not working right to an older version which was working right. The older version started with the "Object" lines below and the current one didn't. I copie the lines to the current version and it worked.

VERSION 5.00
Object = "{F9043C88-F6F2-101A-A3C9-08002B2F49FB}#1.2#0"; "COMDLG32.OCX"
Object = "{6FBA474E-43AC-11CE-9A0E-00AA0062BB4C}#1.0#0"; "SYSINFO.OCX"
Object = "{67397AA1-7FB1-11D0-B148-00A0C922E820}#6.0#0"; "MSADODC.OCX"
Object = "{CDE57A40-8B86-11D0-B3C6-00A0C90AEA82}#1.0#0"; "MSDATGRD.OCX"
Object = "{5E9E78A0-531B-11CF-91F6-C2863C385E30}#1.0#0"; "msflxgrd.ocx"
Begin VB.Form BBEditor
   BackColor       =   &H00000000&
   Caption         =   "CardShark BidBase Editor"

On Local Error Resume Next
Not Working

In the IDE, click on Tools, Options, General and change  
Break on all errors
to
Break on unhandled errors

In Project - References,

BidBaseDB.VBP shows "Language: English/United States".
BidBaseDB.DLL shows "Language: Standard"

If an error is given on Set NewBid = New BidBaseDB.bidder...

It may be because you are trying to use BidBaseDB.DLL when you need .VBP or vice versa.

Click Projects - References to change it.

If it says "Class not registered", bring up the Command window, enter
CD C:\Programming\Microsoft Visual Studio\VB98\Bridge
then enter
RegSvr32 BidBaseDB.DLL
Or use a file manager :