From: Michael Swartz [mailto:email@example.com]
Sent: Monday, April 29, 2002 11:45 AM
To: James D. Dill (James D. Dill); Julie E. Nelson (Julie E.
Wendy Harrison (Wendy Harrison); Harold E. Helson (Harold E.
Cc: Mark Olson (Mark Olson); Stewart Rubenstein (Stewart
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.
described in the top portion of his email.
He has also identified several suggested improvements that are
substantial usability issues. I believe we should reserve
time to discuss at the May 8th ChemFinder meeting (this week
From: Dominick Mobilio [mailto:MOBILID@wyeth.com]
Sent: Monday, April 29, 2002 2:37 PM
Subject: ChemFinder 7.0.1
Below are some ChemFinder bugs followed by some desired
features are general ones that occur to me outside the context
to use ChemFinder to replace, say, BioBench. I'll send
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
I've written my lists in my usual style; I'm not bashing the
Overall it is excellent, but there are several bugs, some
would be nice to have and a few baffling behaviors that I
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
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.
would actually do is make it a property of the main form (on a
tab basis, not one way for each tab on the form) with an
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
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
database I attached in the zip file is your agrobase sample
at the data table you can make from the first tab
("main") and you
should see the problem (on my computer anyway, ChemFinder
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
and each subform from ALL OF THE TABS in the data table, not
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
cannot recall if pairs are always switched, but you do often
wrong heading. I also cannot say if this occurs on the
current window" or "in separate window" or in
4. SD File export:
When exporting an SD file and including data from
the subforms, the data shows up correctly but the data source
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
"export_bug.zip." 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
been DISC_RV1831A, DISC_RV1831B, DISC_RV1831D and
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
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
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
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.
that you see all of the values from the first subform but only
values for the first record from the second subform, it makes
sense to include subforms in the data table other than those
the main form. Of course, as soon as this is
"removed" from the
application, I'll have a case where the lower level subform
contains a single record for all of the records on the higher
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
level" subforms and a second default as to whether to
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
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
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
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
fields" back into view. It took me a long time to
figure that out.
This is particularly problematic because I often fall into the
when resizing fields and subform boxes. Each time, I
managed to make
the fields reappear again but until now, never knew how I did
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
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
above the field. A preference should allow one to turn
this feature on
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
thought about how painful it is to go through, field by field,
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
The first odd thing about ChemFinder's behavior in this regard
it contains a "Text" menu which appears useless (I
know it is not
exactly useless, but people rarely stumble across its use).
text block and go to that menu and you will find that 100% of
options are dimmed. Why???
Now, when the user does finally figure out what he has to do
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
what is it there for), he then wonders why he cannot select
items and change them all at once. The first time I
tried this I
thought it would work because shift-clicking multiple items
to select multiple items. However, only the item you
on to bring up the properties window actually changed if you
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
the property box or the text menu). In once sense, this
seem petty considering all that ChemFinder does, but it is the
issue that smacks you in the face and can severely affect the
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
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
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
HE CLOSES THE FORM OR SWITCHES BACK AND FORTH BETWEEN DATA
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
rearrange columns but so far have avoided telling people that
program quickly forgets what you just did. The field
order and column
width MUST both be saved with the form.
over current list: This is quite a useful feature.
problem is not knowing how you have it set. It was quite
prompt the user if he got no hits when searching over a subset
data, but if he did get a hit, he does not know what he
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
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
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
database or current list" with a checkboxes in front of
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
Formula and Weight: Just because you can calculate
on the fly does not mean you should always do so. The
problem is that
searching these is extremely slow. There should be an
that allows you to specify whether these values should be
put in the database. Now, I import SD files, make a form
molid, MF and MW, export them into a text file, import them
and run an update query that puts them into the table with the
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.
to put a button on a subform to switch from form view back to
and could not because the menu selection was a submenu off of
8. Wizards: The
wizards need some work. First, you should get away
from the concept that every form someone is building will
structures. They will not. Now, you ask the person
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
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
table either in the main form or on a subform), if you do not
ChemFinder from "counting records" in each data
source, one by one, you
will have rendered ChemFinder useless as a tool for searching
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
large numbers of records (high throughput screening results,
inventory etc.). They perform perfectly well as data
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
watching me open the form.
I realize that you have an alternate way of linking Oracle
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
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
top of the subform. However, I cannot move the text as
close to the
subform as I would like. Basically, the text gets hidden
invisible blue border. In other words, even though the
border on top of the subform is only visible when you select
still hides any object you try to place on top of it. Selecting
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
becomes more glaring.
Headings: It would be great if I could use my own
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
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.
the column width smaller but need to be able to make sense of
13. When exporting
text files (as opposed to SD files), why should I
not be able to include data from subforms?