CardShark BidBase Editor
Data Input Boxes

Contents:

The contents of this file are in the same order as the
Input Boxes at the bottom of the BidBase Editor screen.

Introduction Selecting Bids/Conventions (Cnv, Sub and Pct) R (Bidding Round #) P (Player #) Prior Bids The Bid Order (Bid Order Number)        The Plus Button Bid Bid/Convention Name Convention Notes Button Google Look-Up Button Use Against Hand Strength Hi Card Pts. Distribution Points and Total Points Custom Points # Winners Losing Tricks Quick Tricks Suits Stopped Shape Intermediates

Suit Specifications "X" Suit Num and Points Suit Num and Points Combined Suit Num & Points A Complex Example Other Specifications Vulnerability Position Best Contract Disclosures Type of Disclosure Disclosure Description Asks Partner For Or To Bid Other Test Hand        Auto-Fill Reference Date Saved ID Number Dupe Entries Battery and Time Displays Save Button Hand Specs

Related Help Files:

BidBase - Introduction and Background
BidBase Editor - Overview
BidBase Editor - Menu System
BidBase BidSim - Bidding Simulator
BidBase Practice Dealer
Frequently Used Abbreviations

Notes:

Double suit symbols are used to indicate that either of two bids can be made:

= Diamonds or Clubs.
= Hearts or Spades.

Links to web pages for more information are sometimes given, followed by an archived page link, similar to the way Google does. The purpose is to provide the web link to the site of the person who created the page, but also to provide a backup to a local copy of the page in case the original link is no longer valid.

Introduction:

To be able to define any convention in a database, you must be able to enter all the criteria, such as points and distribution, which a hand must meet to make a specific bid. For example, to reply 1 to an opening bid of 1, a hand might be required to have 6+ points and 4+ Spades, but you cannot just make one entry with those specifications (a.k.a.: "specs").

Many hands will come up which have 4+ Spades and 6+ points, but with which you will not want to simply bid 1. For example, with 6-9 HCPs and 3+ Hearts, you are too weak to bid a new suit; you should just raise partner's Hearts.

For each of these different types of holdings, we must have entries to state more specific criteria. And each of those entries will have exceptions to their specs which also require other entries.

BidBase has a lot of different spec fields for defining entries because we considered it better to have too many than not enough. The more spec fields, the better able you are to define a bid, and you can always ignore the ones you don't need. The vast majority of entries need only the HCPs and some suit specs (in addition to the entry identification and disclosure fields).

Some of the fields allow you to specify the same requirements in slightly different ways. For example, in addition to High Card Points ("HCPs"), the quality of the points in a hand can be specified using KNR Points, Custom Points (e.g.: 6-4-2-1, A=2,K=1, etc.), Winners, Quick Tricks, Suits Stopped (total or by suit), Intermediates (total or by suit), and by entering specific HCP requirements for each suit, the latter of which allows you to specify for each suit a range of points, # of stoppers, first or second round control, and more.

Another example is specifying the distribution of the hand by entering distribution points required or the number of cards by suit or any of the alternatives in the Shape drop-down list.

Obviously, you do not have to enter the same information in each of these alternative fields. Which ones you use depend on exactly what you are trying to require. Or if you are a casual user, you can use whichever field(s) you understand best, which is usually HCPs for the hand and by suit.

In later rounds of bidding, you do not have to (but you can if you wish) respecify the same specs you entered for a hand for an earlier bid in the Prior Bids. For example, if an entry for the first-round bid for a hand specifies 2.5 Quick Tricks, you do not have to specify 2.5 Quick Tricks in bidding specs for the same hand for subsequent rounds after making that first-round bid.

But the bottom line is that you only have to enter data in the fields you wish/need to, so an entry can be made pretty quickly. Also, we have done everything we could to make entering bids and specs as fast and efficient as possible. There are also many features designed to insure that the data entered is correct.

Following are the criteria which a hand may be required to meet in order to use the current entry to make a bid. Also included are fields which are not hand requirements, but are present to further describe the entry for a player or to make the database easier for a user to edit. Examples are the Convention Name and Disclosure fields.

The fields are discussed below in the order of the input boxes at the bottom of the screen.

One last general note: If you make entries for a convention not already in BidBase, if a hand does not match the specs for any bid you entered for the convention, and if you do not want any other bids to be made which are NOT part of the convention, then make the last entry for the convention a bid of Pass. You can leave all the fields blank.

For example, if your RHO opens 1N and you are playing the Meckwell convention in defense of 1N, then the last entry for Meckwell should be a Pass because the hand either matches one of the other Meckwell bids or the hand must be passed7 .

The Bid Frame

This section explains the input boxes and buttons located at the top of the input boxes below the grids.

Selecting Bids/Conventions
(Cnv, Sub and Pct):

All bids, conventions, etc., in BidBase are stored in a single database. You select the ones you wish to use and deselect the others.

There are three levels for selecting which entries will be used in bidding and which are deactivated. Leave all three of these fields blank to use an entry, or enter "0" in any of them to deselect it.

First you have the root Convention Names, such as Splinter for showing a singleton or void or 2C Strong for a forcing opening bid (as opposed to Precision, for example).

Next comes subcategories , such as Splinter in "2C Strong: Splinter" or in "2C Strong: 2D Waiting: Splinter". Notice that while 2D Waiting is a subcategory specific to 2C Strong, a Splinter can be a convention by itself or a subcategory to other conventions.

For example, the entry for 1S-P-4C is identified as a Splinter, while 2C-P-2D-P-2H-P-4D is 2C Strong: 2D Waiting: Splinter.

Let's say you have the following conventions and subcategories with Precision deselected (by putting "0" in its convention name field):

Cnv	Sub	Bid/Conv.Name
0		Precision
		Splinter
		Strong 2C
		Strong 2C: 2D Waiting
		Strong 2C: 2D Waiting: Splinter

If you de-select Splinter, which is not part of SAYC, you end up with:

Cnv	Sub	Bid/Conv.Name
0		Precision
0		Splinter
		Strong 2C
		Strong 2C: 2D Waiting
	0	Strong 2C: 2D Waiting: Splinter

If you select Precision by removing the "0" from its Cnv field and deselect Strong 2C, you would have:

Cnv	Sub	Bid/Conv.Name
		Precision
0		Splinter
0		Strong 2C
0		Strong 2C: 2D Waiting
0	0	Strong 2C: 2D Waiting: Splinter

Note that you can deselect individual subcategories via the Subcategory selection field.

Also note that when you deselect 2C Strong via the Cnv field, all 2C Strong subcategories are deselected, even though their individual Sub fields do not change. This allows you to select and deselect whole conventions without losing your preferences for treatment of the individual subcategories.

The final method for selecting bids is the Pct.Used field. This lets you choose among alternative bids for the same situation within a convention or subconvention.

For example, say that for opening 2N Balanced: 2 Doubletons, we have three alternative entries which specify --

1. Both doubletons are stopped, or
2. At least one doubleton is stopped, or
3. Neither doubleton is stopped.

To select which alternative to use, you could set up a subcategory for each option, such as

1. 2N Balanced: 2 Doubletons: Both Stopped,
2. 2N Balanced: 2 Doubletons: One Stopped and
3. 2N Balanced: 2 Doubletons: Neither Stopped.

However, the main reason for setting up Bid Names and subcategories is to be able to select and deselect an option throughout the database with a single click. In this case, you will probably have only one entry for each of these, so it is easier just to use the Pct field than to set up several new subcategories.

So if you want to use #1, above, leave its Pct field blank and put "0" in the Pct field of the other two entries.

The use of the Pct field will be discussed in more detail below.

The following codes can be used for Cnv, Sub, and Pct: 

• W indicates that We are using this option, but not the opponents.
• T in this field indicates that the opponents (They) are using this bid, but not us.
• When the field is left blank, it indicates that both sides are using the bid.
• When the field has a "0" (zero) in it, it means that neither side is using the bid.

In addition to the codes above, the Pct field accepts the following codes:

NOTE: Up to 3 codes can be entered in the Pct field. For example, if an entry is for use only when using IMPs scoring, but you wish to deactivate it, you would need to enter "0I".

M indicates an entry to be used only for MatchPoints, not IMPs. (If link doesn't work, see the archived page.)

I (as in IMPs) says the entry is for IMPs only.

D indicates a Double Dummy Analysis ("DDA") entry. When a bid is not found in BidBase matching a particular hand's specs, DDA is used to determine the best contract based on bidding by all players plus the current player's actual cards.

However, while DDA may determine the best contract, DDA does not actually make bids. To find the bid to make, after DDA is done, another call to BidBase looks for an entry with D in the Pct field whose Best Contract field matches DDA's.

If no DDA entry is found for the DDA contract, then the DDA will bid whatever contract it computed as being best. Example: If the bidding is 1S-P-2S-P and DDA determines that 4S is the best contract, it will just bid 4S if no DDA entry is found with 4S in the Best Contract field and some other bid specified.

A number from 1 to 99 in the Pct field can be used to randomly make different bids with hands of the same criteria.

The entries should have the same Bid Order Numbers and those numbers should not be shared with any other entries. The BONs are how the software determines which entries are alternatives.

The way an entry is chosen is for the software to generate a random number between 1 and 100. Say that you have four entries with Pcts of 50, 20, 20 and 10. If the number is less than or equal to the Pct of the first entry, it will use that entry; otherwise, it will bring up the next entry and sum the Pcts. If the number falls within the sum, that entry is used, etc.

Normally, if you have the same hand specs for different bids, the Pcts should total 100% and all the specs should be identical. The Note field above the test hand can be used to explain the reason for different bids or you can click the N box to create a text file for the entry if you need more room to explain things.

Bridge magazines have panels of experts who each vote on the best bid in a particular situation. The fact that they frequently disagree indicates that there is often more than one good bid available, so you could create entries for the two alternative bids and give each a 50% use factor, or 80%-20%, or three alternative entries with 60-20-20 or whatever percents you wish (as long as they add up to 100%).

That being said, over time I've come to feel that the above procedure may add confusion to the database. All we really want is reasonable bidding. There is no easy way to determine what is actually the best bid among the alternatives, and anyway, we just want are reasonable, expert-level bids, so now just the top vote-getter is entered into BidBase.

You could also use the Pct field to enter psychic bids with a low percentage such as 1%. For example, if you might sometime psych by opening 1 with a hand like Q5432 2 6532 432, then you could make such an entry and put 1 in the Pct field. This doesn't mean that 1% of the time, only 1% of all the bids you make will be psychs, just 1% of the hand with the entry's specific hand specs and prior bidding.

If you want to disable an entry which uses a Pct, put an "x" before the number. This allows you to retain the percentage rather than replacing it with a zero so that when you do want to use it, you can simply remove the "x".

R (Bidding Round #):

The Bidding Round Number starts with the first non-passing bid and can be only one digit. This limits you to 9 rounds of bidding (1-9), but that already goes well beyond the intended scope of BidBase.

Ignoring beginning passes holds down the size of the database and for most bids, a player's being a passed hand does not affect the bidding. If it does affect the bidding, there is a field to specify if the bidder is a passed hand or not.

For example, if you are a passed hand and your partner opens 1N, all of your responses will have the same meaning as if you were NOT a passed hand. But if partner opens 1C, a response by you of 2H will have one meaning if you are a passed and another meaning if you are unpassed, in which case you should use the Position field to show which entry is for a passed or unpassed hand.

P (Player #):

The Player field is the number of the player, 1-4, starting with the first non-passing player. If being a passed hand is a factor in making a bid, you can specify that in the Position field (discussed later).

Prior Bids:

Using "M" for Major Suits and "m" for Minors
The "@" Symbol
Prior Bid Sort Order

Prior Bids In General:

The technically correct terminology is "Prior Calls". Only calls of some number of a suit or notrump are "Bids". Thus Pass, Double, and Redouble are "Calls", not "Bids". But since most people use "Bids" to refer to all Calls, so will I. (I don't remember ever hearing anyone ask "What did you Call?")

Bids are indicated by the bidding level number followed by the first letter of the suit bid, such as 1H. For BidBase database purposes, N is used for a notrump bid, such as 1N, rather than the commonly used 1NT. Likewise, P = Pass, D = Double, and R = Redouble. If you enter Double or Dbl or X, they would not be recognized by the program, only D.

While we're on the subject, BidBase uses "T" for the Ten card, not "10'. JT73 is more easily readable than J1073, but a bigger issue is that using T lets each card reference use only 1 character like every other card.

In these help files, "" are normally used instead of "CDHS", though of course in these entry boxes, The suit letters must be used.

In the Prior Bids field, all Bids/Calls are separated by dashes ("-"), suich as 1C-P-1H-P-2H-P-4H.

Any time you are required to enter a set of Prior Bids, the program provides these shortcuts and aids:

• Letters, such as suits, are automatically uppercased.
• Pressing the space bar inserts a dash ("-").
• Invalid letters and numbers are not accepted.

Prior Bids start with the first non-passing call. For example, whether the real bidding has gone

Pass-Pass-Pass-1C, or Pass-Pass-1C, or Pass-1C, or just 1C,

the Prior Bids field would simply be "1C".

Ignoring beginning passes allows us to cut the number of entries in the database by 75% or more since for most bids, it doesn't matter if the first non-passing call is made in 1st, 2nd, 3rd, or 4th seat. For the times that it may matter, such as whether or not to bid Drury when partner has opened in 3rd seat, you can indicate the opening bidder's position in the Position field.

Here is how the Prior Bid field is used by the BidBase Bidding module:

1.	Lets say that the bidding has gone "1C-1S" and now it is the 3rd player's bid.
2.	The bridge program passes over to BidBase the hand (e.g.: AQ3-T87-K6432-T4), the Prior bids (1C-1S, in this example), and optionally, other game criteria such as vulnerability, bidder's position, etc.
3.	BidBase looks at the first entry (in bid number order) with prior bids of "1C-1S".
4.	BidBase then examines the hand data (points, etc.) for that bid to see if it matches the current hand.
5.	BidBase uses the first entry which matches and quits looking. If a subsequent entry would have also matched, BB never sees it. Say that you have an entry with specs which you usually want selected, but there are exceptions. Put an entry with the exceptions before the more general entry and if it matches the hand, it will be used.
6.	BidBase passes back to the bridge program the selected entry's bid, along with any disclosures to be made to the other players (human or the bridge program's computer players).
7.	If the hand's specs do not match the first entry's specs, BidBase looks at the next bid in the database with the same prior bids of 1C-1S. If there is one, then the program reverts to step 4.
8.	Few entries specifying a call of "P" (Pass) are in BidBase, and those few are just for when we want to be certain that the calling bridge program passes rather than coming up with another bid.   If there are no more entries, including a passing bid, a blank entry would be passed back to the bridge-playing program which can then use its own methods to determine if/what it should bid. However, if BidBase finds a matching entry with "P" as its bid, the calling program should pass. Only if no bid is returned should the calling program keep trying.

There are over 125 trillion, trillion, trillion possible unique bidding sequences. At the outset, BidBase's primary goal was to provide bids for conventions in addition to basic standard bids. However, the longer BidBase is used, more and more entries will continue to be added to it so that eventually, bidding done by the database will become much more extensive and not just for conventions.

Prior to 2022, most if not all fairly common conventions have been encoded into BB and since that time, more emphasis has been given to creating entries for standard types of bids.

This is being done by having the Practice program generate deals then bidding them using the database. If there is no entry matching the specifications of the hand being bid, BB uses the Double Dummy Analysis ("DDA") to guide the bidding.

For example, if south opens 1 and north invites with 3, then if DDA shows that the pair should make 4, south will bid it.

Of course, it is much more complicated than that. If 4 is the optimum contract, south wouldn't just open 4. A normal bidding sequence must be made and that is where very extensive coding comes in.

The "@" Symbol:

In some cases, a large variety of different bids can lead up to a convention such as Roman Key Card Blackwood where the responses to, say, 4N, are essentially the same, no matter what bidding took place priort to the 4N bid.

When the first bid in a slam exploration convention is made, such as 4N, we add "@##" to the bid where the first # is the trump suit (in the case of RKCB) and the second # is another suit when the convention may use that, such as 6-Ace Key Card.

For example: 1S-P-3S-P-4N@40, where the 4 after the @ indicates Spades is trump and 0 indicates no second suit. Another auction could be 2C-P-2D-P-2H-P-3C-P-3D-P-3H-P-4N@30 where 3=trumps-hearts.

BidBase has entires for bidding sequences with prior bids of 4N@10, 4N@20, 4N@30, etc., but we do not need separate entries for all the differen sets of bids which could take place before the 4N bid.

In the CSBB Practice Program, an auction may have 4N@## in it such as those shown above. When CSBB makes a call to the CSBB Bidder which has an "#" in it, only the auction starting with the bid containing the "@" is passed to the Bidder.

In the Practice program, the complete auction is shown, including the bidding starting with "4N@##", but in the Editor, when the Prior Bids have a 4N bid in it, only the auction starting with 4N is shown in Prior Bids.

Prior Bid Sort Order:

When sorting the database by Prior_Bids in alphabetical order, Microsoft's database engine does not support alternative alpha-numeric sorting sequences, so, for example, it puts 1N ahead of 1S, as well as creating other problems.

To get around these problems, the PB_Sort_Order field contains a coded format for the Prior Bids which will result in correct bridge-suit sorting. When you specify sorting by Prior_Bids, which is the normal method, the program doesn't really do so; instead, it sorts on the PB_Sort_Order field.

If you unhide all columns on the grid (or do a Show All), you will see this field to the left of the Prior_Bids field. To get the grid to sort correctly, the PB_Sort_Order entries are padded with blank spaces on the left of the code. You can see the code, but when you click on the field, the cursor starts on the first blank space, which moves the code off to the right where you may not be able to see it.

This field is not used for finding a bid for play, it used solely for displaying the database in the correct order on the grids in the BidBase Editor, so it only of use in the Editor program.

Whenever you save an entry in the Input Boxes, the program automatically calculates the PB_Sort_Order number. Users do not have to do anything with this field, so there normally is no reason to show it.

If you see an entry out of place on the grid, such as 1C-1H prior bids being in with the 1C-1S entries, it is because the sort order field is wrong. To fix it, just click the left part of the grid line to put the entry into the Input Boxes, then save it. Just re-saving it will fix it.

Bid Order Number:

The Bid Order Number is for specifying the order in which the bidding program compares entries to the current hand.  
Entries for conventions must start with the digits 0-8. One or two letters can optionally be used after the first digit to identify the convention.  
For example, Bergen Raises may have numbers such as 1B2300. After the letter(s), I like to use 1-5 to identify the suit being bid (1=C ... 4=S, 5=NT). Then 1-7 for the number bid. So "23" would mean "3D".  
The next two digits after the suit and bid level can be used for different specifications for the same bid, such as "2301" through "2399". Skip digits between entries to allow room for future entries to be inserted, though existing entries can be easily renumbered if needed.

The Bid Order Number for non-conventional bids must start with a "9" so that they come after all the conventions (which start with a digit 0-8).  
Because in computer-ese letters come after numbers, entries for conventions must not start with a letter. The reason for conventions to be tried first is explained next.

When entering a non-conventional bid, if the Bid Order Number field is blank, BB will create a Bid Order Number based on the bid made. For example, if the bid is 2, the BON will be 942000 where 4=S and 2 is the bid level. A 5=Notrump, 6=Double, 7=Redouble, and 9=Pass.

The reason for using numbers which indicate suits and bid levels is just to group similar entries together to make them easier to compare, but it can be necessary at times to forego this type of numbering so that an entry can be inserted where needed, because...

Each entry filters the specifications for the entries which follow it.

By having the conventional bids numbered lower than the non-conventional bids, a convention can be activated which will cause their entries to be tried before the non-conventional alternatives without having to go through the database deactivating the latter. 
When conventions are deactivated, then BidBase ignores those conventions and continues testing subsequent entries. 
The only problem is best illustrated with an example: Playing Bergen Raises, 3D shows 10-12 HCP and 4+ cards in opener's major. But if a hand doesn't match those specs, BidBase will continue testing subsequent non-Bergen entries and find another entry matching the hand's specs and also with a bid of 3D with a different meaning, such as a weak jump-shift. 
One option would be to have a code in the last entry for a convention which says that when the convention is activated, don't look beyond that entry. 
The problem is that we almost always do want BB to keep looking if a hand doesn't match the specs for any entries in the activated convention. We just don't want it to make a non-conventional bid with a different meaning than the same bid in the convention, and to date, no uncomplicated way to prevent that has turned up.

For more information, see the programming notes file.

To sum up:

When a program searches the database for an opening bid, it looks at each entry (matching the actual prior bids) in Bid Order Number order, stopping with the first entry whose specifications match the current hand's. For those of you with some programming knowledge: the database listed in entry number order is like a huge IF-THEN-ELSEIF-ENDIF statement where IF the specs in the first entry match the specs for the hand, the bid is used, ELSEIF the specs for the next entry match, it is used, ELSEIF... etc.

In effect, every entry defines what every other entry following it is not. Without this approach, then for each entry, you would have to try to specify everything that the current entry is not, which would be very difficult, at best.

This filtering effect is usually easy to manage. If it happens to be difficult, you can move an entry out of its usual suit-bid order by changing its Bid Order Number.

The Plus Button:

A button with a plus sign is above the Order input box. This is used to increment the Bid Order Number. This is useful when you are entering a series of bids which you want numbered sequentially, but it is otherwise not needed.

When you left-click on the Plus Button, you will be prompted to enter an amount with which to increment the number. The default will be the last increment number entered, if any. If you right-click the button, the last increment number will be used without prompting.

When you use the Plus Button, it also puts a check mark in the New Entry box so that the entry will be saved as new instead of overwriting the original entry. If you just wanted to renumber the current entry without saving it as new, uncheck the box.

You can decrement the Bid Order Number by entering a negative number. It's hard to think, offhand, of why you would need to do this, but the function is there if needed.

Bid:

The Bid field contains the call the program will make when this entry's criteria match the current hand, and the Prior Bids match the actual prior bids.

If the bid is some number followed by "x", such as "2x", it means that the criteria is the same for more than one suit. Obviously, the bid returned by the BidBase bidding module will be whichever suit meets the criteria, not something like "2x". This will be explained in more detail later.

If the bid is a slam explortion bid - control cue bidding, Grand Slam Force, or ace asking - "@..." is added to the bid.

A control cue bid will have a format such as 4D@Q4, where Q stands for control que bid and 4 is the trump suit number, such as 4=spade.

A Grand Slam Force is 5N@G# where "#" is the suit number.

An ace-asking bid will have a format like 4N@42, where the first digit after the @ is the trump suit and the second digit is a second suit, if needed by the ace asking convention such as 6-Ace Key Card or the suit to be excluded from a response in Exclusion Blackwood.

The Bid box only has room for 2 characters, but if you enter "@" after the first two charaacters, such as "4N@...", the box will expand to allow seeing the rest of the bid.

Bid/Convention Name:

Sometimes we refer to this field as Bid Name and other times, Convention Name, depending on the context of the discussion. There is no good, concise term which encompasses both of these, unfortunately.

The Bid/Convention Names have nothing to do with BB's selection of a call to make. They are just for help in organizing and finding entries. BB selects bids to make based on specifications of the hand and the previous bids made.

The Bid Name field allows you to identify the convention (or bidding treatment) of which the current bid is a part, such as Stayman or Takeout Double.

Each bid/convention name has a Selected field (which will be described in detail later). When you choose a bid name from the drop-down list, its Selected field is displayed in the Sel box.

You can select or deselect a convention by double-clicking the Sel cell on the grid. This selects or deselects a convention for all entries in the database which include this bid name.

This is how you choose which conventions you will be using.

The Subcategory name allows you to select bidding options within a convention, such as Takeout Double: Resp.Dbl - Unbids or Takeout Double: Resp.Dbl - Minors where Takeout Double is the convention name and the text after the colon is the Subcategory name. These are alternative treatments. When you select or deselect one it affects all entries which reference that specific subcategory in its Bid Name field.

Again, the Subcategory name should only be shown if there are alternative, mutually exclusive subcategories where you want only one activated at a time.

For example, 1-1 has a Bid Name of 1-Over-1 Response, but alternative treatments (subcategories) are Up The Line (bidding 1 before 1 when both are 4-card majors) and Maj. Before D.

At one time I lost sight of this and entered subcategory names just to make it easier to identify different parts of the same convention no matter which actual subcategory is used. The first 3 subcategory names all fall into that trap.The only 2 needed were Maj. Before D and Up The Line.

The subcategory code can be changed by double-clicking the Sub cell on the grid.

The way the grid works, you have to fist click on a cell to set the focus there before double-clicking it. If you double-click the Sel or Sub cell on the grid and it doesn't change, try it a second time.

The Pct field allows you to, among other things, select or deselect one, specific entry. Early on, when we came across conflicting opinions about the best bid for a particular hand specification, such as in It's Your Call in ACBL's Bridge Bulletin, we would make an entry or each bid and put the percent of votes it got into this field.

However, the goal of BB is to make reasonably good bids, since clearly even top experts usually disagree about what the absolute best bid should be. So now a single entry is made for the top vote getter and the other bids and votes are shown in the entry's note field.

The Pct field can still be used to activate or deactivate a specific entry, so if a user disagrees with an entry, it can be deativated by putting a "0" in the Pct field rather than just deleting the entry entirely.

To recap:

• Convention selection - use the Cnv box.
• Bid Subcategory selection - use the Sub field..
• Specific bid entry selection - use the Pct Used field.  

A final note on this subject - although the bid/convention name and the Cnv and Sub fields appear in the Input Boxes with an entry, as well as in each line of the grid boxes with each entry, the text of names and selection codes are not part of each entry.

The bid/convention names and selection codes are stored in a separate table, each with a unique ID number. Each bid entry has a field for its convention's ID number, and this is what is used to look up and display the name and selection fields. As a result, when a name or code is changed, the change is automatically seen in the bid entries grids.

This is what makes it fast and easy to de-/activate all entries in BidBase for a specific convention or subconvention by just double-clicking on one entry in the grid.

Convention/Notes Y/N Button:

This button displays a black N or a red Y and is located next to a "G" button at the top of the input fields in the Bid frame.

Most bid/convention names have a help file for them, stored in the Notes subfolder in BidBase's folder. The file's name is whatever text comes before a colon (":"), if any, in the Bid/Conv. Name field.

When the button above the Conv. Name field shows Y, clicking it will display a document with information about the bidding system. If the button shows N, clicking the button starts a new file in which you can enter notes of your own.

If you click on N to create a new file, then decide not to create one, you must click on Delete File in the File menu in the document viewing window to remove the file, even if you have not added anything to it. Otherwise, the blank file will just remain on your hard drive, cluttering things up.

Once in the BidBase File Viewer, if you click File - Open to open a new file, it will be displayed in place of the file you brought up by clicking the Notes button. You can use the left and right arrow buttons in the viewer to go backwards and forwards if you have opened multiple files. The viewer can also be used to edit note files so that you can add your own notes to the file or create new files.

Double-click a Convention Name on a grid to bring up the file while scrolling the grid. Some names in the Convention Name fields do not have system note files, normally because the names are just there to identify the type of entry and don't rate a note file.

When double-clicking the grid to bring up a note file, you have to click once on the field to select it, then double-click to bring up the file. (This is a "feature" of the grid which is outside of our control.)

Adding to or changing the convention name list:

You should check the drop-down list when entering a convention to avoid having multiple names for the same convention. When looking for an existing entry name, you should be aware that we have tried to use names which group alternative or related names together.

For example, most notrump related bid names start with "NT". However, if a convention is very well known, such as Stayman or Jacoby Transfers, they are listed without the beginning "NT".

Update: BB now has one file for all notrump openings and conventions, although there may still be some note files for individual conventions.

Other groupings are

• NT, Strong and NT, Weak
• 2C, 19-HCP and 2C Strong
• Constructive Raises and Preemptive Raises

Regarding the line above -- names starting with Raise, Jump-Shift, Cue Bid, Free Bid, etc., are responses to opening bids. You will also see these same names as subcategories under Overcalls and Takeout Double.

If you already have a convention name entered for the current entry and then you type in a new convention name, the program will ask you if you want to add the name to the list as a new convention name, change the old name to the new name, or revert back to the original name.

If you do add a new convention name to the list, you usually will want to add some notes about the convention by clicking the "N" button above the Conv.Name field. If you already had a note file with the name of the convention, the button will show a red "Y", and you can click it to see the file.

The "G" Spot:

Click the G button to Google the web for more information about a convention. If the Convention Name field contains a colon (":"), only the text before the colon is Googled.

If the Convention Name field is blank, you will be asked for text for which to search.

BidBase adds "bridge+convention" to the search text to make sure the search is related to bridge conventions; however, once the Google web page is up, you can search for whatever you want.

Obviously, you must be connected to the Internet for this feature to work.

(Google is a trademark of whoever owns Google, is not affiliated with this program, etc., etc. All we are doing is bringing up the Google web page for you in a browser.)

Bid/Convention Used Against:

The Use_Against field specifies which system to use a bid against.

For example, if your partner opens 1 and your RHO bids 2, you might want to bid a major suit if 2 is natural, but probably not if it is Michaels (showing 5-5 or more in the majors... unless you are playing Invisible Cue Bids).

There are two bids in BidBase for when Prior Bids are 1-2, one for if RHO's bid is natural and one for if it is Michaels.

But how does BidBase know which of these to use when all we are passing to BidBase are Prior Bids and not an explanation of the meaning of those bids?

Good question.

Haven't figured that out yet.

One option is make a check list out of the BidBase list of conventions for the opponents, but that would not cover every possible convention much less every possible alternative bid so when there are different conventions or subcategories for the same Prior Bids and hand specifications, have BidBase ask which to use.

Hand Strength

Standard High Card Points ("HCPs"):

A=4, K=3, Q=2, J=1.

The P prefix for responding to 1N:

The P signifies that the points required for the entry's bid is total partnership points. To come up with the points in partner's hand, he must have made a bid which requires a specified minimum number of points. Those points are added to the bidder's points to come up with the minimum total combined partnership points.

A variety of opening 1N ranges can be used: 16-18, 15-17, 14-16, 12-14, 11-13, 10-12, and even lower. A quantitative raise to 3N would normally have a HCP spec such as 9-13 opposite a 16-18 NT, but 10-14 opposite a 15-17 NT, etc.

Rather than making separate sets of entries for all possible reponses for all possible ranges of opening NT bids, you can enter a spec which is computed from the opening NT bid's specs, allowing BidBase to have one set of responses for all possible opening NT ranges.

(Click here for a more in-depth discussion of this feature.)

NOTE 1: The Test Hand in the Notrump entries are based on a 15-17 HCP notrump which means that if you are using a different NT range, the test hand will probably fail. This does not affect the use of such bids by BidBase when bidding, just the testing of the entries. There just isn't any reasonable way to enter test hand for every possible NT point range in every entry.

NOTE 2: This concept works with ANY bidding which starts with an opening of 1NT. For example, after 1N-2-2, the entry to bid 4 uses total partnership points for "Std. HCP" because the opening bid was notrump.

Here are the steps to follow entering total Partnership HCP: (The entries described have already been entered for standard NT bidding ranges. This explanation is provided in case you want to enter different ranges.)

First, enter your desired HCP range for 1N and 2N. The Bid Order Number for the 2N entry is #110000 and for 1N, #130000. No modifications should be made to these entries and no other entries should be given those numbers.

To be able to open 1N or 2N with other than a balanced hand within the specified HCP range, add new entries with different numbers. For example, if your opening range is 15-17 but you sometimes open 1N with good 14-HCP hands, create a new entry for that. Do not put 14-18 in entry #130000 for your 1N range unless you want to open all balanced 14-HCP hands 1N.

Second, create entries for responses: In the entry for making a quantitative raise to 3N, the hand's HCP field would normally be 10-14, as previously mentioned, but with the "P" prefix, we put the total minimum, which is opener's minimum (15, in this case) added to the 10-14 range, resulting in a HCP spec of P25-29.

So when entering specs for a response to 1N, first come up with the HCP range you would like to specify, then add the minimum HCP spec for the opening 1N bid you are using. The spec does not have to be a range of points. It could be something like 10+ or <8. which, opposite a 15-17 1N, would be entered as P25+ or P<23.

Say that the requirement for making the entry's bid for a response to an opening 1N is P25+. As we've seen, if the HCP range for 1N is 15-17, then responder must have at least 10 points, or 25 minus 15. If the bid requirement is P25-29, then responder must have 10-14, or 25 minus 15 to 29 minus 15.

But if the HCP range for 1N is 12-14, then responder must have at least 13 points, or 25 minus 12. Or a bid requirement of P25-29 would convert to 13-17.

Notice that P25-29 is not the full range of combined HCPs. It is the range of total points assuming that opener has a minimum.

The  "Min" spec for rebids by 1N/2N opener:

"Min" has a purpose similar to the "P" spec, except that it is for rebids by opener. Responder may make an invitational raise, which asks opener to bid on if he is at the top of his range or to pass if he has a minimum.

Again, rather than having a different set of entries for each possible set of opening NT ranges, we use "Min" in the spec to tell BidBase to use the original minimum for the opening NT bid.

Here is how to use "Min" in the HCPs field. The examples use 15-17 as an opening range, 18-19 for a jump rebid
of 2N (e.g.: 1-1-2N), 20-21 for an opening 2N. 

	Min	the specified opening NT minimum
	Min+	anything more than the minimum
	Min+1	the middle value for 1N the maximum for 2N
	Min+2	the maximum for 1N; 1 over the max for 2N (i.e.: for a "bad" 22 assuming 2N shows 20-21)
	Min+3	1 over the max for 1N (i.e.: for a "bad" 18)
	Min-1	1 less than the minimum (for a "good" 14-point 1N or 19-point 2N)

The  "1N" and "2N" specs for rebids by 1N/2N opener:

The 1N/2N specs are used to fill in the gaps between 1N and 2N openings by adding the amounts shown to the opening notrump minimum:

1N         = 15-17
1N+3+4 = 18-19
2N         = 20-21
2N+2+3 = 22-23
3N         = 24-25

The  "HCP1N" and "HCP2N" Specs:

Enter "HCP1N" for the HCP spec to use the specified opening 1N range and "HCP2N" for 2N. You will see this mostly in the opening bids section for different bid specs which apply to all opening NT ranges.

Entries which apply only to a specific HCP range of opening NT will have the actual HCP range specified and must be manually activated and deactivated when used or not used.

Rebidding/Responding-To  Strong vs. Weak NT:

A response to or rebid following 1N may be appropriate for a strong notrump but not for a weak notrump, or vice-versa, even with the HCP range adjusted.

When this is the case, such entries can still use the "P" or "Min", but they will have to be activated or deactivated manually when a change is made to/from weak/strong NT openings. To make this task easier, include the HCP range in the Convention Name field to make the entries easier to spot, such as Weak NT: ... or Strong NT:..., or even NT 12-14.

Distribution Points, Dummy Points, and Total Points:

Total points for distribution where

• doubleton = 1
• singleton = 2
• void = 3

Distribution points are not counted for...

honors without a lower card: AK, KQ, K or
doubleton or singleton Q or J.

Dummy Points when there is a known fit of a combined 8+ cards:

• +1 for each extra card beyond a known 8-card fit.
• 3 for a singleton instead of 2
• 5 for a void instead of 3.

To use the Distribution Points field to specify Total Points for a hand (HCP + Distribution points), put a "T" before the number, such as:

T12+, T6-10

It is not necessary to specify distribution points if you specify a singleton or void in the Shape field or in the suits' Num fields, but you can do so if you wish.

For example, a preemptive raise of 1 to 4 might be described as 8-10 HCP, 4+ Hearts, plus...

• an unbalanced hand (in the Shape field) or
• singleton/void (in the Shape field) or
• "<2" in one of the suit Num fields or
• "2+" points in the Distrib.Points field.

Custom Points:

You can define the number of points you would like assigned to each honor card. For example you might want to assign the usual 4-3-2-1 points to the A-K-Q-J, but also assign .5 to the Ten. Or you can use the 6-4-2-1 point count method.

Another common count is for A-K points (or 2-1 points) where A=2 and K=1. This can be used to assure that a 10-HCP hand is not all Queens and Jacks, for example.

Custom points are (optionally) in addition to the other counts. In other words, you can still specify regular HCP, Total Points, etc., as well as your custom points, but if you do so, a hand must meet all the point requirements entered, not just one.

Enter the minimum total custom points in the Cust.Points box, and enter the points assigned to each honor in the boxes below.

Let's say that you want just a minimum number of Aces in a hand and you're not concerned about any other honors. To assure having at least 2 Aces, enter 2 in Cust.Points and 1 in the Ace box.

# Winners:

The number of winners in a hand (Playing Tricks) is based on the first four cards in a suit, plus one winner counted for each card more than four in a suit.

AKQJ=4,  AKQT=3.5,  AKJT=3.5,  AQJT=3.5,  AKQ=3,
KQJT=3,  AQJ=2.5,  AK=2,  KQJ=2,  QJTx=2,
AQ=1.5,  A=1,  KQ=1,  QJT=1,  Kx=.5

Running Winners - Sometimes you need to have some number of winners which you can take immediately. For example, if RHO opens 3S and you have a single stop in Spades (e.g.: Ax), and a strong hand, you can probably only make 3N by taking 9 tricks off the top (the AS and 8 more) since the opponents will run Spades if they get in again after the opening Spade lead.

To specify Running Winners (or "cashable" winners), put an R in front of the numbers, such as "R9".

The number of Winners specified is treated as a minimum requirement, so you can just enter 3, for example, and not 3+.

Losing Tricks:

The number of losers (Losing Trick Count) is based on the first 3 cards (if that many) in a suit.
"x" refers to any card below the last honor shown. E.g.: "A=0, x=1" where x=K-2.

A=0, x=1
AK=0, AQ=.5, Ax=1, Kx=1, xx=2
AKQ=0, AQJ=1, AJT=1.5, Axx=2, KQJ=1, KQT=1.5, Kxx=2, QJx=2, QTx=2, Qxx=2.5, xxx=3

Because of the way Winners and Losers are calculated, they normally do not add up to 13, as the names might suggest.

Enter the maximum number of Losers to allow. For example, "3" means <=3.
Otherwise, "3+" means more than 3 (or whatever number is entered).

Quick Tricks:

The number of Quick Tricks, where AK=2, AQ=1.5, Ax=1, A=1, KQ=1, Kx=.5, K=0.

In a 6-card or longer suit, half a Quick trick is deducted from any Quick tricks in the suit because of the odds that the suit will not survive two rounds without being ruffed. If you don't like this idea, you can offset it by reducing your QT requirements by a half trick.

Some sources talk about "cashing" quick tricks. They are not using the phrase "quick tricks" in the same way as it is used in hand evaluation, since if you try to "cash" the Q from AQ or K from Kx, the opponents will overtake you. (See "Winners", above, for specifying "cashable" tricks.)

Other sources may say that AKQ is 3 quick tricks and that QJT is 1, but standard usage is to only count the likely winners in the 1st two rounds of play of a suit under the assumption that the 3rd round is likely to get trumped. In saying that AQ = 1.5 QT, the assumption is made that if finessed, the Q will win half the time. Ditto for Kx.

Most players say that "quick tricks" are "defensive" tricks and that "winners" are for evaluating offensive hands. Therefore, it may be confusing when they say that you need at 2 (+ or - .5) quick tricks (i.e.: defensive tricks) to open 1 of a suit and 5 to open 2C (offensive bids), but the reason is that a 1x or 2C opening bid should have some defensive, as well as offensive, strength.

To avoid confiusion, the caption in the Editor for quick/defensive tricks is Defen. Tricks.

The number of Quick Tricks specified is treated as a minimum requirement (i.e.: "2" means 2+).

Suits Stopped:

This field specifies the number of suits in which a hand has sufficient high cards and length to keep the opponents from running more than a few tricks.

This number of suits normally excludes a suit bid by partner. Otherwise, the suits stopped are unspecified. To require specific suits to be stopped, indicate that in the suits' Points fields.

A Stopper is a suit holding which, when the player is declarer, can keep the opponents from running more than 4 tricks in the suit off the top. Stoppers are: A, Kx, QJx, QT9x, Q98x, JT9x, J98xx, T98xx or better. This field does not count the number of stoppers. For example, AK in a suit is just counted as 1 suit stopped, but in the Points field for each suit, it would be counted as 2 stoppers in the suit.

A half-stopper is Qxx or Jxxx. Half-stoppers are counted in the hand's total of suits stopped. That is, two half-stopped suits are counted as one stopped suit.

The number of Suits Stopped specified is treated as a minimum requirement, so "2" is the same as "2+".

Different Ways Of Specifying High Cards

Let's go back now and look at different ways of specifying high cards.

HCP - You might specify 10+ HCP and end up with Q32 QJ2 QJ2 Q432, which is pretty ugly. Specifying 10+ KNR points will require a hand with better quality points and shape, such as A32 AQ432 32 432

Getting more specific, you can use Custom Points, where you rate Aces as 2 and Kings as 1, then give a minimum number of total custom points you want the hand to have, such as 3, which could be an ace and a king, or 3 kings. The former would require a hand such as AJ32 KQ32 2 5432. .

You could also get a hand like the last one if you specified 2 Winners or 2 Suits stopped.

Finally, in the suit fields, discussed below, you can specify not only a particular range of points, but optionally which honor cards make them up.

Shape:

Hand shapes are: balanced, unbalanced, any 1-, 2-, 3-suiter, any singleton, any void, any singleton or void.

The Shape field is for generalized shape, such as when a 2-suited hand can be any two suits, but not when it must be two specific suits, such as the Majors. If you need to name specific suits, you should do so in the suits' Num fields.

Examples:

If 2 over 1 shows 5-5 or more in the Majors, put 5+ in both the Spades and Hearts Num fields; do not put "2-suiter" in the Shape field because that could be any two suits.

If 2 over 1N shows ANY 1-suited hand, put "1-suiter" in the Shape field and leave the Num fields blank.

You may have to use both the Shape box and the suit length boxes if it is not possible to cover all the specs using just one or the other. If you still have trouble getting all the specs into one entry, you can always make two (or more) entries for the same bid but with different specs.

Example:

Brozel 2 over 1N shows 6 Diamonds and 4 Hearts. Put 6 in the Diamonds Num box and 4 in the Hearts Num box. It is not necessary to put "2-suiter" in the Shape field, because the entries in the Diamonds and Hearts Num boxes already specify a 2-suiter.

Brozel Dbl over 1N shows just a 6+ card suit with 5+ HCP in it. This can be any suit, so you could put "1-suiter" in the Shape box. But then how would you specify that the long suit must also have 5+ points?

So instead of using the Shape box, use the X suit boxes to specify 6+ Num and 5+ Points and put an "x" in each suit's Num and Points box.

But when you do this, the Brozel Dbl entry used to specify a 6-card suit would also catch hands that match the criteria for Brozel 2, which also specifies a 6-card suit, Diamonds, in addition to a 4-card Heart suit. So to avoid this, also put "1-suiter" in the Shape box for the Brozel Dbl entry to distinguish it from the 2 entry which shows a specific 2-suiter.

To sum up what the Brozel Dbl entry would look like (in part):

	Num	Pts
"X" Suit	6+	5+
Spades	x	x
Hearts	x	x
Diamonds	x	x
Clubs	x	x
Shape	1-suiter

And here is what the Brozel 2 entry would look like:

Hearts	4
Diamonds	6
Shape:	(blank)

On a side note - notice that using the X Suit field lets one Bid database entry take the place of having four separate entries, one for each suit. This not only saves room in the database, but it makes it faster and easier to add to or update the database. It also makes selecting a bid faster because the BidBase bidding module can examine one entry instead of as many as four.

Shape - Singleton/Void:

If you use a bid such as Random Splinter (1-[P]-3N) to show an unspecified singleton or void, use the Shape field to specify the singleton/void.

But if you use a normal Splinter to show a singleton/void in a particular suit (e.g.: 1-4 to show a Club singleton or void), you should use the suit's Num field to specify a singleton/void. In this example, you would enter "<2" in the Club's Num field.

Intermediates:

If you specify only High Card Points, you can end up with a hand like this: A432 K2 Q432 432.

In the Intermediates box under the Shape box, you can enter the total number of Intermediates a hand must have. If you enter 5, for example, the above hand would have to look something like this: AT32 K2 QT82 982.

Alternatively, you can specify Intermediates by suit. See Suit Num And Points, below. If you specify a number of Intermediates for the hand and also for specific suit(s), those specifications overlap. That is, if you say that the hand must have 2 and then say that Spades must have 2, that is a redundant specification of 2 Intermediates. If you want the hand to have 2 outside of, say, Spades, then specify 4 for the hand and 2 for Spades.

The Intermediates field is of greatest value when trying to decide whether or not to use an entry when a hand is at the bottom of the HCP range. For example, if your notrump range is 15-17, but you sometimes open a good 14-HCP hand 1N, then you could make an entry that specifies exactly 14 HCP, but also 3 or 4 intermediates.

If you want really good Intermediates (with more 10's then 9's or 8's, for example), you could specify a number of Intermediates, and under Custom Points, specify a minimum number of 10's. For example, you could specify five Intermediates and three 10's. Those specs also overlap. The hand above would look something like this: AT32 K2 QT92 T92

Note: Over the years, very very few entries have needed the input fields from # Winners through Shape. They are there if needed, but may be removed in the future if it turns out that they are never needed. When first setting up BidBase, it was decided that it was better to have a field available and not need it than vice versa.

Suit Specifications

"X" Suit Num and Points:

Let's say that you want to enter or edit partner's responses to 1. You could make a separate entry for a strong jump-shift in each suit (2, 2, 2), where you enter "6+" in the appropriate suit number field.

To save time in making entries, as well as to save space in and to simplify the database, you can enter specifications in the "X" suit length and/or suit HCP fields, then put "x" in the appropriate suit fields.

Longest or Highest Suit First:

When the "X" Suit fields are used, the program uses the longest suit with x in its Num field. For example, if "X" Num is "5+" and the hand in question has 5 Spades and 6 Hearts, the program will bid Hearts. However, when there is more than one suit of equal length, the higher suit (Spades, in this example) will be chosen, unless...

Longest or Lowest Suit First:

The vast majority of the time, you want to BidBase to bid the higher ranking of two suits of equal length, so this method of handling the "X" suits works fine. However, if you do not want the higher suit bid, add a "U" to the spec to get BidBase to look "up-the-line" from Clubs to Spades. Example: with 4+U and Spades and Hearts both 4-card suits, Hearts will be bid, while with just 4+, Spades will be bid.

"X" Suit Doesn't Have to Be The Suit Bid:

The "X" Suit Num can be used for suits other than the one being bid. For example, an entry for Michaels over 1 (i.e.: 1-2) which shows 5+ Spades and 5+ of one of the two minors may have an entry like this

X:   5+
S:   5+
H:   -
D:   x
C:   x

Entering An Alternative Specification:

Sometimes you may want a suit to match some other specification if it does not match the "X" spec. To do this, the second specification can be entered in the Suit's field, separated from the "X" spec by a comma, such as x,4+. This means that the suit must either match the "X" specification, or if it does not, it must be at least 4 cards long.

If you enter an "X" spec, at least one suit must match the "X" spec. For example, to specify 6-4 in the majors and that either major can have 6, you would enter an "X" spec of 6 and for each major, you would enter x,4. If the majors were 4-4, they would each match the alternative spec, but the test would fail because neither suit would match the "X" spec of 6.

If you enter "x" plus an alternative spec for a suit, the "x" must come first.

If you specify both xNum and xHCP, then a suit must match both to pass testing.

If you specify an alternative spec for xNum, such as "x,5+" and also specify a value for xHCP, the xHCP applies only when testing the xNum value for the suit. If that test fails, then when the program next tests the alternative (5+, in this example), the "x" in the "Points" field will be ignored.

Since BB automatically tests xNum and before testing xHCP (and then only if xHCP passes), there is no reason to put "x" in the suits' HCP fields. For example, if you enter x in the suits' Num fields and "4" in xNum and "5+" in xHCP, you do not have to put anything in the suits' HCP fields.

Say you make an entry with the following suit specs: 

	Num	HCP
X	6,4+	5+
Spds	x,4	<5
Hrts	x,4	<5

1. 6 with 5+ HCP
2. 4+ with 5+
3. <4 with <5 HCP

Here's another example:

Taking the Long Way Out:

Bobby Wolff gave the hand 8 AJ63 AKQJ94 97 in his May 6, 2022, Aces column, saying that after RHO opened 1, this hand was too strong to overcall and a TOX should be made instead.

So other than clubs, one suit has to be Num=6+ and HCP=10, one has to be either Num=+ and HCP=5+, and the other one needs to be anything.

Creating a Test Hand For "X" Specs:

When entering a Test Hand for an x-suit entry, make the highest suit match the "x" specs. BidBase will do this automatically. For example, if xNum is, say, 5+ and Diamonds and Clubs have "x" for their Num fields, then the test hand should be something like 432-2-KQJ32-6543.

Although 432-2-6543-KQJ32 would work for testing the entry, consistently giving the highest "x" suit the "x" specs makes entry comparison easier and more reliable, which is very important.

Even if your source from an entry is a hand from a magazine, change the hand to make the highest "x" suit match the "x" specs. Example: If the magazine's hand is 32-AQJ8432-QJ7-83 and this is an entry for making a weak jump overcall of a 1C opening, so the "x" spec is for a 6-card suit, swap the Hearts and Spades for the Test Hand.

Suit Num and Points:

For each suit, you can specify the number of cards required for the suit, as well as the strength (in HCP or specific cards) of the suit.

Specifying Suit Quantity:

The number of cards may be specified such as <4, 2-5, >C, >=D, <H, =H or, as explained above, x.

>C means more of the suit than there are Clubs.

>=D means more than or equal to the number of Diamonds, etc.

See the previous section for an explanation of using the x field. In addition to having "x" fields, a non-x field may use >x, >=x, <x, or <=x, where the suit is compared to whichever suit meets the "x" specs.

For example, if "x" = 5+ and Clubs and Diamonds are each "x" fields, Spades and/or Hearts could contain something like "<=x" so that a minor suit will not be bid if a major suit is longer.

You can make alternative specs by separating them with a comma, such as <3,>5, which means that if the suit is either less than 3 or more than 5 in length, it is okay.

If you specify Points, then the Num field cannot be left blank. For example, with the hand KJ9653-JT3-Q2-53, we want to specify that the bidder has a 6-card suit and no outside stoppers, so for the lower 3 suits, Num is specified as "<8" and Points as "0stop". At some point I will fix the program to allow Num to be left blank when specifying Points.

Most of the features in the Input Box hand specs are designed to allow multiple suit specs in just one entry in order to save database space and processing time.

For example, for a recent hand (A-AK742-A3-AQ753 in Bobby Wolff's "Aces" bridge column, the question was whether to open 2 or 1 (as is usually recommended for strong 2-suited hands).

Wolff said:

It is often better to start bidding strong two-suiters at the one level to provide more space to describe your shape. However, with a major and a minor, opener can start with 2, then introduce the major followed by the second suit at the three level.

The problem is how to show this in one entry. Here is the answer:

To open 2, Wolff says the two suits should be a major and a minor. By setting "X" to 5+ and putting an X in Spades and Hearts, we are assured of getting a 5-card major.

But we don't want TWO 5-card majors, so in the Combination field, we specify that Spades and Hearts combined must be fewer than 10 cards. Saying fewer than 9 would be just as good.

To get the minor, we say that Clubs and Diamonds must each have either 5 cards or fewer than 4. Since we are already assured of a 5-card major, only one of the minors can have 5 and the other has to have <4.

If compressing multiple specifications into one entry seems too complicated, it is always possible to make separate entries with simpler specs, such as having 4 entries specifying

• S: <4   H: 5+   D: <4   C: 5+
• S: <4   H: 5+   D: 5+   C: <4
• S: 5+   H: <4   D: <4   C: 5+
• S: S+   H: <4   D: 5+   C: <4

These 4 entries as a group generate the same 2C bid as the one entry pictured above, but at the cost of having to maintain 4 times as many entries at 4 times the amount of space andtaking 4 times longer for BidBase to process when looking for a bid.

Specifying Points:

Points may be specified in the usual manner: 2-4, 4+, <=2, etc.

You may also specify an Ace or King by entering A or K. Usually the case of letters does not matter, but since lowercase a is used for AK, KQ or AQ (see below), then to specify an Ace, you must use uppercase A. You can control Aces and Kings for the whole hand with Custom Points.

Points may be specified by using the following codes. Alternative specs can be entered separated by commas . 

x = use the "x" specs, as previously described.
A = Ace. Add "A" to other specs to insure an Ace.
A,K = Ace or King
a = "AK, KQ, or AQ". Again, to insure an Ace, enter aA.
b = "AJT, KJT, or QJT"
c = "KQJ, AQJ, or AKQ"
d = "AKQJ, KQJT, AKQT, or AKJT"
x/y = x of top y, such as this:

2stop = "AK, AQ, AJTx, AT98x, KQJ, KQT, KQ9x, KJTx, or KT9x",
1stop = "A, Kx, QJx, QT9x, Q98x, JT9x, J98xx, or T98xx"
hstop = half-stop = "Qxx or Jxxx". (See Western Cue Bids.)
0stop = no stopper. (Opps can take 5 tricks off the top.)
FRC = First Round Control (either an Ace or Void)
SRC = Second Round Control (either King or Singleton)
P = honors are protected by the bidding.
i# = Intermediates (e.g.: 4+i1 means 4+ HCP and 1 intermediate.)
#/# = # of top #. (e.g.: 2/3 = 2 of top 3, 3/4 = 3 of top 4). Limit is top 5.
#H# = HCP & minimum number of honors including consecutive intermediates
(e.g.: Qty=5 & 3H4 = QJT9x. where just "3" could be Kxxxx and "3i2" could be KJTx)
HA = Help Suit - Ask: suit must have 3+ cards without A or K.
HH = Help Suit - Have: 1st or 2nd round control, either A/K or void/singleton in suit.
or... = Either the quantity specified OR the HCP specified. See notes below
SS = Solid Suit

Number of Honors can be more important than just number of points.
For example,

QJT98 ("3H5") vs K5432 (just "3") and
KQJxx ("6-7H3") vs AJxxx (unless your primary concern is first-round control).
AKQxx ("6+H3".
To avoid getting the latter, use "6+H3" instead of "5+H3".

If you specify "c", it would be redundant to also specify "a" since "c" is just a stronger version of "a". Any hand which has, for example, the "KQJ" alternative in "c" would already match the "KQ" alternative in "a". However, "ab" and "bc" are non-redundant combinations. So you might want to enter a, b, ab, or bc, but not ac nor abc.

If you enter ONLY "b", then holdings better than "AJT, KJT, QJT", such as "AQJT" or "KQJT" will be rejected. To include better holdings, you must enter "ab" or "bc" or use some other type of input.

You can make alternative specs by separating them with a comma, such as <3, >5, which means that if the suit's HCP are less then 3 or more than 5, it is okay. If there are alternative number specs and only 1 points spec, the points spec goes only with the first number spec.

Num	Points	Means
6+, <6	<5	Either 6+ cards with <5 points or <6 cards
<6, 6+	<5	Either <6 cards with <5 points or 6+ cards
<6, 6+	<5, 4+	Either <6 cards with <5 points or 6+ cards with 4+ points

The Protected Honors specification is primarily for use for 4th seat where the opponents have bid and partner has passed, such as 1-P-1, where KJ of Spades are "protected" because RHO bid them, but KJ of Hearts are not protected because LHO bid them.

Protected Honors can also be used where just one opponent has bid, such as in Spades where the bidding has gone 1S-?? or 1S-P-P-??.

To specify points plus Intermediates (8-10) for a suit, enter "i#" after the other specs, such as "abi2". A suit matching "abi2", for example, might have "KQT92", where the "KQ" matches the "a" spec and the "T9" matches the "i2" spec. Another example is "4+i1", which says 4+ HCP plus at least one intermediate, such as "AT32" or "KJ92".

Do not be confused when you see "4+i1" and think that it means "4 HCP plus 1 intermediate". That spec would simply be "4i1". The spec "4+i1" means 4 or more HCP and 1 (or more) intermediate(s).

In the August 2020 Bridge Bulletin, page 51, Marty Bergen says that AT98 is just as good as AJxx, So an entry in BidBase reflecting this shows suit points required as being "4+i3".

If a suit does not have the required Intermediates but has more than the minimum HCP required, then the suit will be accepted. It would make no sense if, for example, when specifying "abi1", that "AQ92" should be accepted ("9" being an intermediate), but that an even better holding without an intermediate, such as "AQJ2", should be rejected.

Using ai1 for an example, the a requires AK, KQ or AQ. "KQ" has the least high-card points (5), so to fulfill the ai1 requirement, you would need an intermediate to go with the KQ, but not with the AQ or AK. Likewise, for abi2, you could have KQT92, or AKT42 or AQ942.

An example with HCP specified is 2+i2. The cards Q98 meet this spec exactly, but K92 (1 less intermediate, but one more HCP) and KJ2 (2 fewer intermediates but 2 more HCP) also meet the spec.

In retrospect, it would seem to be easier to count tens as half a HCP and that could be changed in the future.

In theory, a HCP for an honor is normally worth more than an intermediate, so that for each extra HCP, we should be able to drop two intermediates instead of just one, but we are being a little conservative. If there is a great outcry about this, we could be convinced to change it, or you could just change your specs (i.e.: use 3+i2 instead of 3+i1).

An 8 is only counted as an intermediate when it is with other intermediates, such as KQ98 or KQT8, but not KQ8x.

When specifying Intermediates, do not put a comma before the "i". If you put "a,i1", it would tell the program that either "a" or "i1" is acceptable. You normally want both "a" and "i1".

Using "or" in Points:

Quantity AND Points specifications for a suit must be met for an entry's bid to be used unless "or" is specified in Points.

Combined Suit Num & Points

The Combined Suit input boxes allow you to cover several hand types in one entry.

In the boxes labeled Comb, you can specify the total number of cards and points for any 2 or 3 suits. For example, in the Num. input box, you could enter SH=8-9, specifying that Spades and Hearts together must total 8 or 9 cards.

Assuming you don't want, say, 9 cards split 8-1, then in the individual Num. input boxes for each suit, enter 4-5. This allows you to specify that the two suits may be 4-4, 4-5, or 5-4 but not, for example, 6-3 or 3-5. Without this field, you would have to create two entries, one for Spades 4-5, Hearts 4, and a second entry for Spades 4, Hearts 4-5. Instead, you can create one entry with Spades 4-5, Hearts 4-5, Comb SH=8-9.

Example: RHO opens 1. You want to make a takeout double if you have support for the unbid suits. Assume that you don't mind 3-card support for one suit, but not for more than one. If you specified 3-4 cards for each suit, that would allow 3 cards in each suit. By entering SHD=11-12 in the Combo box and 3-4 in each of the suit's Num boxes, you will enforce a distribution of 3-4-4, 4-3-4, 4-4-3, or 4-4-4.

Here are examples of the acceptable formats for specifying combined suits:

	CD=8	CDH=12
	CD=8-9	CDH=12-13
	CD>7	CDH>11
	CD<10	CDH<14

You must specify either 2 or 3 suits, followed by a one-character math symbol (=, >, or <), followed by a number or a range of numbers (e.g.: 12-13).

Specifying combined suit HCP is especially useful for making sure when a hand is at the minimum of the range of HCP allowed, that the points are concentrated in the desired suits. For example, after 1-P-P, the minimum for balancing is as little as 7 HCP, but you don't want, say, 2 of those points being a Queen in LHO's Diamonds.

But if you have a non-minimum, such as 9+ HCP, you don't mind if 2 of the points are in LHO's suit, so you don't really want to specify that Diamond HCP must be <2. One solution would be to make one entry for 6-8 HCP hands with D<2 and a second entry 9+ HCP hands where Diamonds could (but doesn't have to) have 2+ HCP.

But instead of making two entries, you can make one which says that SHC combined must be 7+ HCP. Now if the hand has 7 HCP, all the points must be in Spades, Hearts, and Clubs, but if the hand has, say 10 HCP, you can now have 3 points in Diamonds because you will still have 7 HCP in the other 3 suits.

Using 'x' in the Comb field:

If an entry uses the "X" field, you can use "x" in the Comb field. For example: "xD>7" says that the "x" suit (whether Clubs, Hearts or Spades) plus Diamonds must be greater than 7.

When using "x" in the Comb field, the "x" must always come first.

A Complex Example

1. Start with the lower-ranked 6-card suit in the "x" field. The "a" means any 2 of the top 3 honors. Hearts are not considered because if hearts were the 6-card suit, spades would have to be the 5-card suit and it is a "touching" suit. So only C and D get an "x".  
2. Likewise, diamonds cannot be a 5-card suit over 6 clubs. So we say that only spades and hearts each have either 5 cards or fewer than 3. 
3. Given only the above specs, H could have 5 cards and D could have 6, but H and D are touching suits, so to make sure that doesn't happen, the Combo field says that HD combined must have fewer than 11 cards. 

Entry 1:  S:5, D:6
Entry 2:  S:5, C:6
Entry 3:  H:5, C:6 

Other Specifications

The vast majority of entries assume that vulnerability and position don't matter. If one or both of them do matter, then those fields in those entires should be marked accordingly and the entries should come before entries for which vulnerability and position do not matter.

For example, Drury is a convention used by a passed hand and its entries should be marked as "Y" for Position, while 2/1 Game Forcing is a convention used by an unpassed hand and its entries should be marked as such.

Vulnerability:

U = Unfavorable (current bidder is, opponents are not)
F = Favorable (opponents are vulnerable, bidder is not)
B = Both (everyone is vulnerable)
N = Neither (nobody is vulnerable)
V = Vulnerable (bidder is vulnerable; opp may or may not be)
X = Not vul. (bidder is not; opp may or may not be)
"" = blank (any vulnerability is accepted)

Position:

See discussion of Prior Bids, above. This field indicates the position of either the opener or his partner. This field is needed because lead-off Passes are ignored in the Prior Bids field, yet the requirements for some bids differ greatly if the bidder or his partner has already passed.

For example, if the Prior Bids are 1-P and responder has KQ932 AJ4 2 J432, he should bid 1 if he is an unpassed hand, but as a passed hand, he may want to jump to 2 to show that he is at the top of his range for being passed.

Here are the acceptable database values for Position, along with their meaning:

1 = bidder is in 1st seat
2 = bidder is in 2nd seat
3 = bidder is in 3rd seat
4 = bidder is in 4th seat
F = bidder is in First or Second seat (meaning partner is in 3rd or 4th)
T = bidder is in Third or Fourth seat (meaning partner is in 1st or 2nd).
Y = bidder is a passed hand (i.e.: this player passed originally)
N = bidder is an unpassed hand (i.e.: this player bid originally)
P = bidder's partner is a Passed hand (i.e.: partner passed originally)
U = bidder's partner is an Unpassed hand (i.e.: partner bid originally)

If the field is left blank, it means that position does not matter.

Examples:

• Prior Bids: 1C-P-1S. Bid: 1N
  
  For unpassed bidder, this shows 15-18 balanced.

  For a passed bidder, it shows 7-9 HCP, 5-5 in the unbid suits (Sandwich Notrump).

  So you need two entries, one for each of the above cases.

• Prior Bids: 1S-P. Bid: 2C
  
  For unpassed responder, this shows 11+ HCP, Clubs could be short.

  For a passed responder (not playing Drury), this shows 6+ HCP and a real Club suit, or if playing Drury, it shows 10-11 HCP and Spade support.

  So again you need 2 entries: one for each of the above possibilities. Note that it doesn't really matter if you specify that opener is in 3rd/4th seat or that responder is a passed hand because if one is true, the other is true. However, there may be times when it seems more logical to use one rather than the other.

You do not always need to specify position. For example, after 1S-P, if responder has 3-2-5-3 and <10 HCP, it does not matter if opener is in 3rd chair or if responder is a passed hand or not, the bid is always going to be 2S.

For those times when being a passed hand or not does matter, select the desired Position in the Position drop-down list box. Again, this is the position relative to the dealer. The Player number box to the left of the Prior Bids box is the position relative to the first non-passing bid.

So if partner was dealer and passed and your RHO passed and you made an opening bid,

• You are Player number 1 (first to "Bid") (to the left of the Prior Bids box) but
• You are also Position number 3 (third to "Call") (in the center of the Input Boxes area.)

Best Contract:

Disclosures

Type of Disclosure:

In bridge, the opponents are entitled to know the details of any agreements your partnership has made regarding the meaning of any artificial bids.

The three basic types of disclosures are

1. Alerts -- The bidder's partner simply says "Alert" and provides no other information unless asked. A bridge program normally has some way of alerting a human about such a bid, then the user can click something for more information.

2. Announcements -- An announcement, such as saying "Transfer" when a transfer response to a 1NT opening is made, should also be automatically shown to the user of a bridge program.

3. Pre-alerts -- Some types of partnership agreements must be explained to the opponents prior to the start of a game (IMPs) or set of deals (MPs). In BidBase, this can be done by the user's reviewing the database before playing.

Disclosure Description:

The main purpose of the Disclosure text field is to clarify for human players the information in the other disclosure fields or to provide additional information or references.

It can also be used for short notes about an entry for reference when modifying the database. Start with a left bracket "[" for any such notes which you do not want displayed during the game.

The N button to the right of the Disclosure field brings up a note file in which you can enter more information about a particular bid. This is in contrast to the info file for Conventions which is for notes about an overall convention. The Disclosure field file is for just the current bid. This information is not routinely shown to players, but a program could offer it as an option if the programmer wished.

When you click the N button, if a note file does not yet exist for the entry, one is created in the EntryNotes folder inside the Notes folder/directory as follows

• The file is given a name made up of:
  • the Prior Bids,
  • the entry's Bid,
  • the text _ID and the entry's ID#,
  • and the extension .txt.
  • Example: 1C-1H-P-1S_ID1234.txt
    where 1C-1H-P are the prior bids for the entry,
    1S is the bid made by the entry, and
    1234 is the entry's ID#.
• The N button is changed to Y.
• The BidBase File Viewer is called up to display the file.
• The phrase See notes --> is added to the Disclosure file if there is room.

If you decide you don't want the file, you must delete it in the BidBase File Viewer by clicking on Delete File in the File menu, even if you did not add any text to the file. Failure to delete files you don't put notes in will just junk up your Notes folder.

If you use BidBase File Viewer to delete the file rather than enter notes into it, the BidBase Editor has no way of knowing that right away, since it does not continuously check for the presence of the file, but it will change the button the next time it checks for the file. However, you should remove the phrase [See notes --> from the Disclosure field before saving the entry.

If you edit an entry (move it from the grid to the input boxes) and the program sees that the entry has a description file, it changes the button from N to Y to let you know that, yes, there is a file for the entry. Click the button to view/edit it.

Some times you may want to refer an entry to an existing note file rather than creating a new note file for the entry which simply duplicates information in an already existing file. To do this, enter the file name in the Explanation field in brackets, such as
[See file: Negative_Doubles.htm] or
[See file: 1C-1D-3C_ID278.txt].

You can leave out the See notes: phrase if there is not room, but don't forget to put the left bracket at the start of the Disclosure field.

When scrolling a grid, if the Explanation column contains a note file reference, you can bring up the file by double-clicking on it. (You may have to single-click on it once to select the field before double-clicking it. Blame Microsoft, not me!)

Asks Partner For Or To Bid:

This field indicates if a bid asks partner for specific information or asks him to make a specific bid, such as a transfer or relay or simply forces him to bid one more round or to game.

If the forcing nature of a bid is obvious, then this field may be left blank. For example, after 1-[P]-2, only the rawest beginner would not be aware that opener is expected to bid again, and let's face it, this program is not aimed at raw beginners. However, if you WANT to enter that information for every bid, you could certainly do so.

H(elp)s(=C,D,H,S): Invites to game if partner can help in the suit bid. Example: 1-2, 3. For the 3 bid, you would enter HC in the Asks For field to show that 3 asks partner to bid game if he has help in the Club suit. Also see Western Cue Bids.

C(ontrol)s(=C,D,H,S): Asks partner for a control in the suit indicated. This is normally a slam try.

Examples:

(CD): 1-3, 4 is a cue bid asking for a Diamond control. By agreement, this could be an Ace or King or singleton or void

(HD): 1-(1)-2 asks partner to bid 3N if he has Diamonds stopped.

B(id)xx: Asks partner to make the specified bid "xx". For example, B2H indicates that bidding 2D over 1N, is a transfer to Hearts, although for such standard types of transfers, this field is skipped.

P(ick a suit/slam): P asks partner to pick a suit and bid game/slam.

D(ecide contract): Example: A Forcing Pass.

U(nbalanced): Usually to warn partner away from NT: 1-1, 3-3N, 4. The last bid shows an unbalanced hand with likely only 3 hearts.

A(ces), K(ings), K(ey)C(ards): "A" or "K" or "KC", as in Blackwood.

1: Forces partner to bid one more round.

G: Forces partner to bid until some game is reached.

O: Bidding again is Optional, or semi-forcing. For example, some people play that a 1N response to 1 of a major opening is forcing, but others play that it is "semi-forcing". Doubling a high-level preempt is usually optional, such that doubler's partner has the option of passing for penalties or bidding.

SO: Sign-Off - strongly suggests that partner pass.

Strength Disclosure
Suit Lengths Disclosure

Strength disclosure and suit length disclosures are no longer being entered. They seem to be inadequate when a bid may have more than one meaning. For example, in the Meckwell convention, a double of 1N shows either a long minor OR both majors. Some people play that Michaels shows either a weak hand or a strong hand but not an intermediate hand.

The alternative being used in the BidBase Practice program at present is to show the hand specifications in the Disclosure box for every entry for the bid being made.

Other

Test Hand:

If this field is blank and you click on it, or if you have the Auto-Fill box checked, the program attempts to use the specifications you have entered to create a test hand. The program creates what is about the worst possible hand which meets those specs. So a typical "10+ HCP" test hand, for example, may look something like Q32 Q432 Q432 KJ.

The reason for the program's making the test hand the worst possible hand which meets the entry's specs is to let you see how bad a hand the specs allow. If you think the test hand is too awful for the bid, then you need to beef up your specs, such as by specifying custom points (particularly aces and kings), intermediates, etc.

Other than honors or when intermediates are specified, the test hand's cards start with 2 and go up, resulting in hands like KQ432 32 32 A432. If you see a more realistic hand, like K97 8643 AK76 T5, then that is normally a hand from a bridge column, magazine article, book, etc., which should be noted in the Reference field.

Sometimes it may be necessary to make a separate entry for the minimum point(s) so that you can require such hands to have compensating features, such as better distribution or more intermediates. Entering a value in the KNR field can have the same effect since KNR takes compensating features into account, although it will then be up to you to create a matching test hand since at present, the program does not attempt to adjust the test hand for KNR specs.

The Auto-Fill routine is already very, very long and complicated, and the other fields in the Hand Strength section are even more complex when it comes to figuring out what honors to put where, and they are not used very often, so it is not worth the program space to include them. One exception is that Auto-Fill does try to take into account Custom Points where A=2 and K=1, and even then, it cannot make it work 100% of the time.

When entering a Test Hand for an x-suit entry, make the highest suit match the "x" specs. For example, if xNum is, say, 5+ and Diamonds and Clubs have "x" for their Num fields, then the test hand should be something like 432-2-KQJ32-6543.

Although 432-2-6543-KQJ32 would work for testing the entry, consistently giving the highest "x" suit the "x" specs makes entry comparison easier and more reliable, which is very important.

Any place where you enter a hand, the program provides these functions:

• Automatically uppercases letters.
• Space bar inserts a dash ("-") between suits.
• Card validity is checked (e.g.: can't enter AJQ, must be AQJ, and invalid letters and numbers are not accepted).
• Hand is checked for exactly 13 cards.

Test Hand Checking:

When you save an entry, the test hand is checked automatically. When you use the Sort/Show box to specify the entries to be shown in the grid, the program also automatically checks each entry displayed. Finally, you can manually cause the grid to be tested at any time using the Edit - Test Hands menu option.

(1) The first purpose of the Test Hand check is to make sure an entry does not have the same criteria as a previous entry.

If you make an entry with the same criteria as a previous entry, then the BidBase bidding module will never see your new entry because it will stop looking at the first entry whose criteria matches the current hand.

For example, say you are entering a 2D response to prior bids of "1D-P" and you enter specs as 6-10 points and no 4-card major and 5+ Diamonds. Now say that you enter a test hand of K32 32 KJ432 432. This hand meets the criteria you specified, but when you test it, you might get a message saying that the test hand also meets the criteria for an entry for 1N (after 1D-P). You look at that entry and see that its specs are 6-10 points and a balanced hand. (3-2-5-3 is considered balanced.)

There are several ways to resolve this conflict:

1. Move the 2D entry ahead of the 1N entry.

2. Modify the 1N entry so that the test hand no longer meets the specs for 1N.

3. Or if you think that 1N is a better bid than 2D for the test hand you entered, then modify the test hand to something like K32 2 KJ432 5432. This is no longer a balanced hand, so it will not meet the 1N response criteria, and will thus make it to the new entry for a 2D response. If you are going to do this, you should also change the specs for the entry to specify an unbalanced hand. (And you should also change similar entries for similar Prior Bids to maintain consistent specs in the database, such as for 1C-P-2C, in this example.)

4. When the conflicting entries are for the same bid, either change the test hand and/or the new entry, or just delete the new entry. For example, say you save a 2D entry, and BidBase tells you that the test hand meets the specs of an earlier 2D entry. If the new entry's specs are not identical to the previous entry's, then change the test hand to more closely match the new entry's specs. If the specs are the same for both entries, simply delete the new, redundant one.

5. Enter a number for both entries for Pct_Used. It is acceptable to have two entries with the same criteria when the earlier entry also has a percentage entered to control the frequency with which the entry should be used.

While testing your entry, if the program stops on a different entry before getting to the one being tested, it will ask if you would like to keep testing. Normally, when the earlier entry has a non-blank Pct field, you would say yes.

(2) The second purpose of the Test Hand check is to make sure that the specifications you entered have the results you had in mind.

If the Test Hand does not meet the current entry's specs, the program will show you the specs for the hand and tell you which specs did not match.

Either the Test Hand is what you had in mind, but you didn't enter the specs correctly, or the specs are what you intended, but the Test Hand was not properly constructed. Fix whichever is the problem and re-save, which will automatically test the entry again.

Auto-Fill:

When you make a change to any of the Num or Points fields in the Suits frame, if Auto-Fill is checked, the program will automatically fill in the Test Hand and the Distribution fields accordingly.

Leave the Auto-Fill box unchecked if you do not want the Test Hand and Distribution fields updated automatically.

If the box is unchecked, you can still get the program to fill in the Test Hand or Distribution just by clicking on their input boxes when they are empty.

Reference:

In fact, it would be a little foolhardy to change a referenced entry without referring to the source first. The explanation given there may change your mind.

These references include bridge books, magazines, newspaper columns, and Internet sources. Nevertheless, experts differ on what the best bid is for a given situation. Sometimes an expert may make a bid different from one he made before for the exact same hand and prior bids.

Some entries are based on hands from BidBase's deal/practice program. That is, the hands came up there and were not covered by entries in the database, so we created the entry. Such entries are even less likely to be the absolute best. although they are guided by the Double Dummy Analyzer. You can bring up the hand in the dealing section by double-clicking on the deal number (e.g.: "Deal #11180-E") in the Reference box and decide for yourself.

The Reference field is also very useful when you find two similar entries (e.g.: 1C-1H-2D and 1C-1S-2D) which have conflicting specs when, in fact, they should have nearly identical specs. Seeing where each entry originated may help you decide which set of specs to go with, then you should change the entry which doesn't have the specs you prefer. Or you may decide that both entries have merit for different types of hands, in which case you could leave the original entries in each Prior Bids section and copy the entries into each other's sections as well, resulting in two similar entries, instead of one dissimilar entry, in each section.

Abbreviations for some sources: 

Aces - Bobby Wolff's newspaper column
BD - Alan Truscott - Bidding Dictionary (published 1996)
Becker - newspaper column
Bul - ACBL Bridge Bulletin - Back issues are on ACBL's web site.
BW - Bridge World - from articles in Bridge World magazine.
BWS - Bridge World Standard - bidding system used for quizzes in Bridge World.
MB - Marty Bergen - P-S (Points Schmoints)
MH - Max Hardy (Bidding For The 21st Century)
ML - Mike Lawrence - various books, mainly from the early 2000s or before.
PBN - If the test hand is from a PBN file, its Reference will look something like
"PBN casacarta_20191217_2 #8". Double-click it to view it if it's in the PBN folder.

References given do not guarantee that the specs for an entry are correct!! Sources virtually never give sufficient information for creating specifications for an entry as needed by BidBase, so it is up to us (or the user) to try to figure out the generalized specifications which will result in the bid given by the source for the example hand given by the source, as well as for similar hands.

For example, an author may say that a suit such as AQ432 is the minimum needed to make a bid, but we do not enter minimum HCP required as 6 because such as isn't the same as exactly. A hand like AJT98 or even KJT98 is normally just as good (if not better). However, making such generalizations opens the door to errors in judgment, so don't feel shy about adding new entries to enhance the entries in BidBase.

BidBase is updated on a daily basis using the sources above. When a source says that a given hand should make a specified bid and BidBase doesn't make that bid, the discrepancy can usually be resolved by modifying the specifications for an existing entry.

For example, if an existing entry says that a hand should have 17-19 HCP to make the entry's bid but a new source shows a 16-HCP hand making the bid, the simplest solution is to lower the HCP requirement to 16-19, but it may be that other specs should also be adjusted, such as the 16-HCP hand having all prime points. In such a case, rather than changing the existing entry, it is better to add a new entry with the new hand's specs for the same bid.

Also, BidBase's citing a source in the Reference field does not imply an endorsement by that source for the entry's specs in particular, nor for BidBase in general, only that we recommend the source as a place to look for more information.

Drop-Down List of References:

If you enter a new reference for an entry, the source is added to the drop-down list when you leave the input box.

This saves typing when adding a lot of entries from the same general source with, say, a different date, page number or deal number. Just click on the source from the list and modify it as needed. This list also helps keep references in a standardized format.

To remove an entry from the list, just click on the entry. This will put the entry into the Reference box. Click "X" and you will be asked if you want to remove the entry from the list.

The other buttons above the Reference box are similar to those in the Find Bid box (Ctrl-Y).

[C] clears the list. [S] saves the list. [L] loads a saved list. When you save or load, you have the option of overwriting or adding to what's already in the file or list.

When your start the Editor, the default references are loaded into the Reference list. The entries look like "Bul 2021-". Click on that and you can change it to something like "Bul 2021-05 p.43 #02" which means the May 2021 issue of the Bridge Bulletin, page 43, hand number 2. You can make it whatever you want.

Date Saved

This is primarily intended as a means of adding entries you have created to a new database. For example, say that you download a major update to BidBase. You can use the new database and tell BidBase to import entries from your old database starting with whatever date you specify.

Another use of the Date field is to sort on this column in the grids to see new entries you have made. Click View-Show/Sort, leave the first Show field blank, put "z" in the next one, select Prior Bids in the drop-down list, then on the Sort side, put Date in the top drop-down list and click on Show.

ID Number:

This is a unique ID number assigned by the program automatically when a new entry is saved. You should never try to change the ID number, so there is no input box for that field, although it does appear in the grids.

The ID number is not used when playing a game. It is only used when editing the database. For example, when you delete an entry, you first select the entry in a grid by clicking on the line, then the program uses the unique ID number on that line to make sure that the right entry is being deleted.

Likewise, when you edit an entry in the input boxes, the ID number assures that the correct entry is changed in the database.

Dupe Entries:

If you should need to make a change to an entry in one Prior Bids section, the same change should normally be made to the other sections. Likewise, a new entry made to one section should usually also be made to the other sections.

Yet it would be easy to miss making these changes to similar Prior Bids sections were it not for the Dupe Entries boxes and grid.

When you select an entry in a grid to edit or when you enter Prior Bids in the Input Boxes, the program will automatically enter other similar Prior Bids into the Dupe boxes. It will also display the similar entries in the second grid if you have Dupes Grid selected in the View menu.

In fact, using the Dupe Entries boxes along with the Dupes Grid when making new entries is one of the most important features of BidBase. After saving a new entry, you can duplicate it for as many as 8 similar sets of Prior Bids within a matter of seconds.

To duplicate an entry, click on the button which appears to the left of a Dupe box when a set of Prior Bids is entered into it.

BidBase will create a new entry in the Input Boxes based on the data in the selected entry in the top grid. Check the new entry to make sure that it is correct and then save it.

When you have saved it, you can then click on other Dupe buttons to repeat the process for each similar Prior Bids entry.

The list of similar Prior Bids is stored in BidBase.. Sometimes, there may be only one or two similar sets of bids; other times, there may be as many as eight, such as these with the format 1x-1y-2z (non-jump) -- 

• 1C-1H-2D
• 1C-1S-2D
• 1C-1S-2H
• 1D-1H-2C
• 1D-1S-2C
• 1D-1S-2H
• 1H-1S-2C
• 1H-1S-2D

Note that although two different sections of Prior Bids may not be similar enough to warrant the general duplication of entries of one section into the other, you may run across a particular bid which is similar enough that you want to ensure that the specs for the entries are consistent.

For example, the specs for a 3N bid after 1C-D-2C and 1C-D-3C are identical, yet these are not set up in BidBase as similar Prior Bids because they are similar only for the 3N bid. So in this example, after changing the 3N entries after the non-jump raises, you should also change the specs for 3N after the jump-raise entries.

On the other hand, some sets of Prior Bids may have special features which keep them from being similar to other sets which may look similar. For example, the set of Prior Bids 1H-D-2H-2S-4H is unique because if the bidding is 1D-D-2D-2S-4D, then the 4D bid is not game, yet if they bid 5D, you would have to bid 5S rather than 4S, so the Prior Bids are not really similar.

If you are creating or editing an entry for which no similar sets of Prior Bids are shown, you can manually type them into the Dupe boxes and you will be prompted for saving them in BidBase for future use.

To make it easier to see the specs for similar entries, click on the menu item View - Dupes Grid. In fact, we strongly recommend always keeping the Dupes Grid open unless you have to temporarily view a second set of Prior Bids in it.

Battery and Time Displays

When using BidBase Editor on a notebook which is running on a battery (i.e.: not plugged into A/C), the percentage charge and run-time left are displayed. These numbers are a function of Windows and may jump around, depending on what the computer is doing at the time. For example, it will show more time remaining if you are simply viewing the database with no programs running in the background than if you are running disk-intensive programs (such as the BidBase Simulator) in the background.

The time also is a Windows function and displays the system's time of day. If this is not correct, look for an icon in the Windows Task Bar tray for changing the time.

Save Button

The Save button is just a shortcut to the Edit - Save Entry menu option.

Pressing Ctrl-S is another shorcut.

Hand Specs