My relationship with checkboxes has been one of those love/hate ones.  They’re amazing because they allow for text to be entered exactly how I want it to be, but they’re a pain because of the fact that checkboxes with large value lists take up so much screen real-estate.  Well, I’ve started taking a new approach to handling them, and I think it’s a relatively elegant one, so wanted to share it with you.  This technique will let you enjoy the benefits of the tidy data-entry that checkboxes allow for without sacrificing any more real-estate than a typical text box would.

To explain how I use this technique, I’m going to have to start by naming some fields for you — this should make things easier to follow.

Let’s say that I have a field on my layout called “languages”.  It’s the one that you would normally have displayed as a checkbox, but I’m displaying it as a plain text box.

Even though it’s on my layout, and is enterable in browse mode, it’s not going to be immediately visible to any users of your database system.  The reason behind that is because it’s actually covered up with another field.  We’ll call that field “zc__languages”.

zc__languages is defined as a calculation field with the following definition.

zc__languages

Substitute ( languages ; "¶" ; ", " )

All that does is replace every carriage return with a comma followed by a space.  This field will also be displayed as a text box, but will be non-enterable in browse mode.  It will be placed directly on top of  your languages field.

The end result will look something like this

We’ve already saved ourselves quite a bit of screen real-estate, however, we don’t have the benefits of the checkbox for data-entry any longer.  In order to get the benefits of the checkbox back, you’ll need to do a little bit of scripting.

The script that I’m using will require:

• a global text field “zv__temporaryStorage__gt”
• a layout “Temporary Storage” that displays zv__temporaryStorage__gt using a checkbox set linked to the proper value list.
• a script “Display Value List”

zv__temporaryStorage__gt is defined as a global text field because when it’s a global field like this, it will allow multiple users to enter values into it at the same time.

The Script is the trickiest part.
First, you should define the script to be called as a script trigger onObjectEnter, and attach it to your “languages” field.

When the script runs, it will analyze the current field, and extract both its contents, and its fieldName… storing those into separate variables ($fieldName and $fieldContents)  to be used later.  Within the script, you will want to set the value of zv__temporaryStorage__gt so that it becomes equal to $fieldContents.  Once this has been done, you will want to open a new window, go to the Temporary Storage layout, size it, center it etc.  By the time it appears on the user’s screen… it will look to the user like they’re still in the same field.

When finished with this checkbox, the user should have to perform some kind of action in order to signal that they are done.  At that point in time, you will grab the new contents of zv__temporaryStorage__gt, and write it back to the original languages field.

In my particular case, I displayed the Temporary Storage layout in a modal pop-up window, so the user had to hit OK or Cancel in order to move away from it.  I also took this a few steps further, and re-used this layout for multiple value lists by taking advantage of a hidden tab panel trick.  One of the hidden tab panels on this layout is used for a simple text box instead of a checkbox, and I’m able to use that for almost anything!

Are you already using a similar technique?  Got any ideas on how I can further expand upon this idea?  I would love to hear from you!

Other Sites