From: rmf@chopin.cs.columbia.edu (Robert M. Fuhrer)
Newsgroups: comp.sys.mac.programmer
Subject: Think C wish list
Date: 28 Sep 92 23:01:01 GMT
Distribution: comp
Organization: Computer Science Dept., Columbia Univ.

Symantec, are you listening? I've been using Think C (versions 4 and 5) for
some time now, and have come up with the following list of suggested changes
and enhancements to the system:

Debugger:

 1) Scrolls the source window when stepping, even if the current source line is
    already in view.
 2) Prints "struct 0x9AECF" as a value, when it could more usefully bring up
    the field value pane (the current behavior always forces you to
    "de-reference" an extra time).
 3) There is no way to clear the data entry field to cancel the current
    selection and enter a new expression from a non-extended keyboard (why not
    Opt-Clr?).
 4) No context is shown for expressions except by an explicit menu command
    which changes the contents of the source window. Better would be to allow
    data window to show context as part of the expression, perhaps even to edit
    it textually!
 5) Once an expr is highlighted in the source window, you must use the keyboard
    (Cmd-D) to put it in the data window. This forces you to move back and
    forth between the mouse and keyboard.
 6) Never shows values for expressions whose context is higher up in the stack
    frame, even if you explicitly move up the stack frame using the callback
    pop-up menu.
 7) An expression whose type is "char *" always shows up as a pointer instead
    of a C-string. Can't the default either be made "C-String" or changeable? I
    have probably spent many hours simply changing the type of char *'s to C
    string, which is by far the most common interpretation of char *.
 8) An expression whose type is "char" is displayed as int, not char, by
    default. The same principle as for the previous suggestion applies.
 9) Data windows displaying structures are never the "right" size when first
    displayed. I would settle for having the height correct, even if the width
    weren't (which is somewhat tougher).
10) Inconsistently steps to "non-code" at the end of a loop (e.g., when
    evaluating the for-loop test or update expr). I.e., sometimes it does,
    sometimes it doesn't.
11) How about allowing "context-less" data expressions? If you are trying to
    follow an object and its values as control winds through various methods,
    you are forced either to duplicate the data window expressions once for
    each method. Or, you have to explicitly set the context upon entry to each
    method, which coincidentally closes struct viewing panes.
12) Global variables entered as data expressions are qualified to the context
    active when they were entered. As a result, their values no longer appear
    once the context is exited.

13) When using objects, the debugger will deny you access to instance variables
    based on the pseudo-C++ access rules. This should never happen. I'm in the
    debugger, which is akin to being the "root" user on a Unix system.

Editor/Project:

 1) Why can't you close the project window with Cmd-W when it's frontmost?
 2) Why can't you open a new project with Cmd-O when the project window is
    frontmost, or there is no open project?
 3) The editor is easily confused by bracketing delimiters (e.g., [, (, {)
    inside strings or macro definitions when attempting to match delimiters.

Think Ref:
 1) Will we ever see TCL and the C Standard Library documented in Think Ref?
 2) Will Think Ref ever allow construction of user library documentation?
--

-- Bob
Newsgroups: comp.sys.mac.programmer