Dominick Mobilio's ChemFinder Wish List
2 May 02

Below is a message sent by Dominick Mobilio of Wyeth Pharmaceuticals (Westchester County, New York).  He reports bugs and requests features based on his experiences training users with ChemFinder 7.  This is a great list.  I'm just glad he didn't try printing :-)

We intend to address a chunk of this in 7.0.3.  For responses and status of items, see the Dominick Status Table.

-----Original Message-----
From: Michael Swartz []
Sent: Monday, April 29, 2002 11:45 AM
To: James D. Dill (James D. Dill); Julie E. Nelson (Julie E. Nelson);
Wendy Harrison (Wendy Harrison); Harold E. Helson (Harold E. Helson)
Cc: Mark Olson (Mark Olson); Stewart Rubenstein (Stewart Rubenstein);
Dominick Mobilio
Subject: FW: ChemFinder 7.0.1

Dear Wendy, Jim, Julie and Harold -

Appended please find an e-mail from Dr. Dominick Mobilio of Wyeth. He is
one of our top ChemFinder users.

He has found several bugs, which we should try to reproduce. These are
described in the top portion of his email.

He has also identified several suggested improvements that are quite
substantial usability issues. I believe we should reserve sufficient
time to discuss at the May 8th ChemFinder meeting (this week I'll be

Michael S

-----Original Message-----
From: Dominick Mobilio []
Sent: Monday, April 29, 2002 2:37 PM
Subject: ChemFinder 7.0.1


Below are some ChemFinder bugs followed by some desired features.  The
features are general ones that occur to me outside the context of trying
to use ChemFinder to replace, say, BioBench.  I'll send you those
enhancements separately.

The demos I've been giving have gone very well.  Many people have said
"why are we even looking at BioBench, this does everything we want."
The last user said that in a demo I gave with Bev Eccles present.

I've written my lists in my usual style; I'm not bashing the product.
Overall it is excellent, but there are several bugs, some features that
would be nice to have and a few baffling behaviors that I wanted to
point out.


Bugs (and a few features):

1.  Data Table view: this only shows data from subforms on the first
tab.  Viewing the table from any other tab only shows data from the main
form regardless of the "export" preference. (By the way, whether or not
to include subform data on the table should be independent of the data
export preference.  I looked for a long time to see why subform data did
not show up and never would have guessed what I needed to do.  What I
would actually do is make it a property of the main form (on a tab by
tab basis, not one way for each tab on the form) with an application
preference setting the default. If you want to get carried away, you can
make whether or not the fields show in the table a property of each
subform (the default taken from the main form).

2.  Data Table:  It is quite common for fields to appear multiple times
in the table even though they are on the form only once.  This seems to
happen mainly (exclusively?  I cannot say for sure) when you open the
data table in a separate window as opposed to "in current window."  The
database I attached in the zip file is your agrobase sample file.  Look
at the data table you can make from the first tab ("main") and you
should see the problem (on my computer anyway, ChemFinder 7.0.1).

As I'm writing this, I think I see what is happening.  When you show the
data table in a separate window, it puts the fields from each main form
and each subform from ALL OF THE TABS in the data table, not just the
tab you are looking at.  The "in current window" table seems to show
only the fields from the current tab.  Some implementation of this could
be considered a feature, but right now it is a bug.  It should show the
fields from the current tab only.

3.  Data Table:  It is quite common for column headings to get mixed up.
In other words, the column for MW has the heading of another column.  I
cannot recall if pairs are always switched, but you do often see the
wrong heading.  I also cannot say if this occurs on the table "in
current window" or "in separate window" or in both.

4.  SD File export:  When exporting an SD file and including data from
the subforms, the data shows up correctly but the data source is
incorrect.  It appears to list the name of the first data source as the
name for all of them.  I've included a sample in the file
"" Notice the four "fields" called "<DISC_RV1831A>" which
is the name of the first data source.  As you can tell by the data which
is all different, the data sources had to be different (they should have
been DISC_RV1831A, DISC_RV1831B, DISC_RV1831D and DISC_RV1831E).

5.  Moving Objects:  It is common for objects to move on the form.  Text
objects appear to move most often.  Use the text tool to type some text
on the form and it will move.  This happens either (not every time) when
you return to the form from another tab or return to the form from
"search mode."

I have one form that contains the structure and molecular weight on the
top.  Below it, from left to right, are four subforms, each the same
size and each with a block of text above them describing the data
source.  It is quite common to see each block of text moved up an inch
or so.  This usually happens to all blocks together, but sometimes you
see only one moving.  Less often, a subform moves.

6.  Data Table:  When you have a subform on a subform, the data table
attempts to include fields from the lowest level subform.  Considering
that you see all of the values from the first subform but only the
values for the first record from the second subform, it makes little
sense to include subforms in the data table other than those directly on
the main form.  Of course, as soon as this is "removed" from the
application, I'll have a case where the lower level subform only
contains a single record for all of the records on the higher level
subform and will be annoyed that I cannot see it.  Of course, this can
be handled by preferences too (a default as to whether to include "main
level" subforms and a second default as to whether to include "lower
level" subforms).

7.  Disappearing fields on the subform: This used to happen to me a lot
but I now think I know what is going on.  When you are working with a
subform in "data table" view, you may find that fields, beginning on the
left, disappear off the form.

Try this.  Create a subform with, say, five fields.  Go into data table
view for the subform.  Make the subform box smaller than necessary to
show all five of the fields.  Use the horizontal scroll bar to display
the last two fields (on the right) on the form.  Now, resize the subform
box so that it is more than big enough to display all five of the
fields.   You will only see the two that were visible before you made
the subform bigger.  The bottom scroll bar is stretched from end to end
so you cannot slide it to more things to the right.  Double-clicking to
go back to "form view" and then back to the data table does not
accomplish anything.  What you have to do is click on the arrow on the
left end of the scroll bar.  Doing that will bring the "disappearing
fields" back into view.  It took me a long time to figure that out.
This is particularly problematic because I often fall into the problem
when resizing fields and subform boxes.  Each time, I managed to make
the fields reappear again but until now, never knew how I did it.

General Features (as a general ChemFinder user, not someone who wants it
to replace BioBench).

1.  The most glaring omission regarding features is the inability of
ChemFinder to place the name of the field on the form when you put a
field on the form.  When using a framed field, it should add the name to
the frame.  If it is not framed, then it should place a text string
above the field.  A preference should allow one to turn this feature on
or off.

2.  The second most glaring omission (provided there is not a way to do
this that I have not discovered) is the inability to change the font and
its styles for multiple selections of text blocks.  Have you ever
thought about how painful it is to go through, field by field, text
block by text block, to change fonts?  If you did this just once, the
program would already do what I am about to tell you it should do.

The first odd thing about ChemFinder's behavior in this regard is that
it contains a "Text" menu which appears useless (I know it is not
exactly useless, but people rarely stumble across its use).  Select a
text block and go to that menu and you will find that 100% of its
options are dimmed.  Why???

Now, when the user does finally figure out what he has to do to change
fonts, in addition to being left to wonder why the "text" menu does not
work (and if not for changing text which is what he is trying to do,
what is it there for), he then wonders why he cannot select multiple
items and change them all at once.  The first time I tried this I
thought it would work because shift-clicking multiple items allowed me
to select multiple items.  However, only the item you actually clicked
on to bring up the properties window actually changed if you changed
something about the font.

When I demo ChemFinder, I never point this out because I do not want to
suffer the looks I am going to get.  Please fix this.  Leave the stuff
in the properties boxes if you wish but allow ALL changes to text to be
able to be accomplished through the "text" menu and allow changes to
apply to multiple items if multiple items are selected (either through
the property box or the text menu).  In once sense, this complaint may
seem petty considering all that ChemFinder does, but it is the type of
issue that smacks you in the face and can severely affect the users view
of the program.

3.  When I pick a background color for a main form, I do not want it to
apply to each tab.  I want to be able to set each tab separately.

4.  You absolutely must come up with a different way to set the order in
which fields get displayed in the data tables.  This "feature" is even
harder to discover than the one to display subform data on the data

The answer is trivial.  When going into data table view for the first
time, use the creation order.  It is as good as any.  However, let the
guy rearrange the columns by dragging them around just as he can do now.
The trick is to remember how he placed them and DO NOT RESET THEM WHEN
FORM..  This also applies to the data table view of the entire form.  In
demos to date, I point out how wonderful it is that you can easily
rearrange columns but so far have avoided telling people that the
program quickly forgets what you just did.  The field order and column
width MUST both be saved with the form.

5.  Search over current list:  This is quite a useful feature.  The
problem is not knowing how you have it set.  It was quite clever to
prompt the user if he got no hits when searching over a subset of the
data, but if he did get a hit, he does not know what he searched.  The
problem as I see it is that, even if you look at the search menu, it is
not obvious what your selection is even when you are staring directly at
the option in the menu.  A check box would be much better (like you have
for substructure search).

Next, there is nothing obvious I can tell by looking at the icon on the
toolbar which lets me know how things are set.  I could not come up with
a better icon than you did and, given your icon, I cannot tell whether
I'm searching over all data when it is "pushed in" or when it is left
flat.  The status of this choice is critical to the user getting what he
wants out of the search.  The rest of the icons are irrelevant and only
serve as shortcuts.  I would spell out on the toolbar somehow what the
selection is.  Perhaps it could appear something like "search entire
database or current list" with a checkboxes in front of the choices.

Do not think of this as a feature of convenience.  Think of it as a
feature that helps prevent the user from getting the wrong answer.

6.  Molecular Formula and Weight:  Just because you can calculate these
on the fly does not mean you should always do so.  The problem is that
searching these is extremely slow.  There should be an import option
that allows you to specify whether these values should be calculated and
put in the database.  Now, I import SD files, make a form that shows
molid, MF and MW, export them into a text file, import them into Access
and run an update query that puts them into the table with the rest of
the data from the SD file.  I search MW a lot and would rather not have
to do this.

7.  CAL scripting As far as I can tell, when you try to script a menu
selection, you cannot select an item from a hierarchical menu.  I wanted
to put a button on a subform to switch from form view back to data table
and could not because the menu selection was a submenu off of "data

8.  Wizards:  The wizards need some work.  First, you should get away
from the concept that every form someone is building will contain
structures.  They will not.  Now, you ask the person where the
structures will come from (default location or molserver).  You need a
third choice (there won't be any structures on this form).

9.  ODBC:  When you show Oracle tables after the user opens an ODBC
connection, you MUST show the schema name and not just the table name.
The way it is now, it is impossible to find anything unless you work in
a company with an extremely small database.

10.  ODBC again:  When adding an attached table (Oracle table odbc
linked to Access) to a form (or opening a form containing an attached
table either in the main form or on a subform), if you do not stop
ChemFinder from "counting records" in each data source, one by one, you
will have rendered ChemFinder useless as a tool for searching corporate
data.  We cannot spend 1 to 30 minutes waiting for forms to open.  Many
of our views are what I call "poor performing" (many joins or functions
used to create them, poor performance because of that and not
necessarily large numbers of records) and many other contains extremely
large numbers of records (high throughput screening results, compound
inventory etc.).  They perform perfectly well as data sources for
subforms but do not try to count records in them or "select *" from
them.  You will be waiting forever.

In my demos, I wanted very much to include compound inventory
information on a subform but could not because I could not risk someone
watching me open the form.

I realize that you have an alternate way of linking Oracle data coming
down the road.  If it does the same thing, you do not have a product (at
least in the context of "remote" data).  Also, if this new method does
not have the same drawback, if a user can still use an Oracle table that
is odbc linked to Access, you still have the problem.

11.  Subform top border:  I often put a text string above a subform
indicating what it is rather than use the label you put in the border on
top of the subform.  However, I cannot move the text as close to the
subform as I would like.  Basically, the text gets hidden by the
invisible blue border.  In other words, even though the thick blue
border on top of the subform is only visible when you select it, it
still hides any object you try to place on top of it.  Selecting the
text and picking "bring to front" has no effect.  While on the one hand
this may seem petty, it does prevent you from designing the form the way
you want to.  And it does so leaving the user wondering why.  When real
estate is tight, you really want to move things close and this problem
becomes more glaring.

12.  Column Headings:  It would be great if I could use my own column
headings on the data table, particularly on the subform.  Start doing it
the way you do it now but let me change them.  I realize this may not be
straightforward, but it is highly desirable.  Many of the Oracle
database fields have names that were either not meant to be seen by the
user or are too long for the amount of data they contain.  People make
the column width smaller but need to be able to make sense of the

13.  When exporting text files (as opposed to SD files), why should I
not be able to include data from subforms?