AnsweredAssumed Answered

vrf My personal VEE gripe list

Question asked by VRFuser on Mar 27, 2002
Hello to the VRF,

Since the topic of VEE-NR has come up again, let me pull out my running
list of gripes with VEE Pro 6. OK, some are rather petty. But anything
that can contribute to a smoother look and feel for the programmer HAS
to have a positive impact on his/her productivity AND flatten the learning
curve a few degrees for the next generation of programmers as well as help
the more casual engineer & tech users.

Some of these may have already been addressed in the next release and
others may be too late for them to do anything about, but there's always
VEE-NNR too! I'M NOT LOOKING FOR WORK-AROUNDS, unless it's stupid obvious.
(Hey, I don't read the manuals cover-to-cover when each new release comes
out, so once in a while an obvious thing gets by me.)

Here they are in no particular order. Comments and additions are always
welcome. (I hope Agilent has there EARS on! <g>)

1) Program Explorer always starts collapsed. How about a user choice??
    Complex programs can take a lot of clicks to get back where you were.

2) Need to be able to select multiple items in PANEL VIEW mode to move.
    Somehow PANEL VIEW *MUST* get a LOT easier to construct views, move
    things around, change colors, fonts, etc. It's been getting better
    over the years, but it is STILL way too clumsy for detailed panels.

3) PANEL VIEW needs "SEND-TO-BACK" command to un-hide layered objects.

4) Need to be able to change properties of MULTIPLE ITEMS at one time, OR
    be able to CLONE PROPERTIES somehow. (Changing your VEE code globally
   in a text editor for this does work, but it's not for the weak hearted.)

5) RESERVED WORDs are freely accepted by some elements, like DECLARE(!),
    but are flagged as violations by other operations, like DIRECT I/O.
    It's not consistent. Example words: "MASK", "DATA", "REAL", "NOP",
    "EOL", "STATE". But then words like "THISTEST" and "RESULT" are NEVER
    flagged and probably should be as they may cause unpredictable results.

6) In I/O boxes, you can ONLY read data to an output pin name. Why can't
    data be read DIRECTLY into a local or global variable instead? This
    could cut down on the "box count" in many applications.

7) Comments at the end of IF/THEN/ELSE statement lines using the format
    "// Comment" are DELETED by VEE. Does it REALLY HAVE to do this?

8) Declaring complex RECORDS is a pain in the ****! Every last detail
    MUST MATCH EXACTLY the way the record is initialized. It SEEMS like I
    have to define everything TWICE. Also, RECORDS containing RECORDS can't
    be declared at all. (I don't know if anything can be done with this.
    It's more of a whine than anything.)

9) In Direct I/O, there is NO short-cut key for "COPY TRANS". MAKE ONE!

10) When entering data into a 1D TEXT ARRAY constant, you can highlight
    many elements at once and COPY or CUT them to the clipboard, but you
    can only paste *1* element at a time FROM the clipboard. Let's have
    it BOTH ways!

11) In a RECORD constant with a 1D TEXT ARRAY field, ditto gripe #10, PLUS
    when you highlight and delete multiple elements, it leaves an annoying
    "0" behind instead of a NULL string like you would expect.

12) Can you PLEASE standardize on how arrow keys, highlighting, cutting and
    pasting, and mouse actions work ANYWHERE data or ESPECIALLY TEXT needs
    to be entered?? Preferably if you would follow the Windows' Notepad ways
    of doing things, it would make life a LOT easier. Take YOUR "Note Pad"
    for example. If you are at the end of a line and you press the right
    arrow key, PLEASE put the cursor at the beginning of the next line down.
    AND make the same thing happen in reverse. If you press the down arrow
    key in the middle of a line, and the next line down is too short for a
    direct drop down, PLEASE put the cursor at the END of the next line
down,
    NOT at the beginning. PLEASE, always let a SHIFT-ARROW KEY highlight!

    Your "DESCRIPTION" areas of each box for text entry are CLOSE to the
    above desired arrow movements (except for the very last line), BUT there
    is NO CUTTING AND PASTING allowed, and no highlighting large blocks of
    text for deleting or moving like some of your other text boxes can do.

    There are MANY more examples, but my point simply is, PLEASE make as
many
    of these areas as you can follow CONSISTENT editing rules that the
majority
    of us users can be comfortable with. (These little things DO count a
lot!)

13) Thank you for allowing a MOUSE WHEEL to be functional in some areas. How
    about the rest??

14) When using the Alloc Array box for making an INTEGER or REAL array, if
    you change the title, you can no longer tell what type of Array you are
    working with (INT16, REAL64, etc.) without running it and checking the
    output.

15) When reading a file in as a STRING array, please do NOT automatically
    delete the white-space in front of a string! If I don't want it there,
    I can strTrim it myself. Many times strings are formatted text, that
    MUST stay that way. I know the "work-around" of reading in TOKEN format,
    but why not just make the READ STRING work the way (I think) it should?

    AND...
    When reading STRING ARRAYS, PLEASE do NOT skip over blank lines for the
    same reasons as above. Just put a null string in the array there.
Simple!

    (I realize changing this now could cause unexpected results in older VEE
    programs, but that never stopped you before. <g>)

16) Have a way to change variable values during a pause of execution. Even
    just GLOBAL values would be a good start. I can't tell you how many
times
    I've wanted this! The View/Variables seems so tantalizingly close, but
    it only lets you "look but not touch".

17) While waiting for input from a Dialog Box, you can't do ANYTHING. I find
    myself avoiding these boxes like the plague. Typical situation is a user
    runs a program to collect data on some DUT. There's graphs, plots,
Logging
    Alphanumeric, and a PASS/FAIL indicator on the screen. The part is done
    and this dialog box pops up asking for the next serial number. It has
two
    buttons on it, "TEST" and "QUIT". The user wants to change scaling on
the
    graph to see a particular area better, or scroll back the data to
compare
    this part with the last one, but CAN'T as long as that stupid box is
still
    on the screen. He knows if he presses "TEST" the plots get cleared for
the
    next part, or "QUIT" closes the program altogether. He's basically
screwed.
    I VERY much dislike these Dialog Boxes and will ALWAYS custom write my
own
    pop-ups using panels. (Again, this is more of a whine than anything, but
    why can't these be more friendly?)

18) In a RECORD CONSTANT, you can enter data directly into a 1D ARRAY, but
as
    soon as that array is defined with more than 1 dimension, data CAN'T be
    entered directly (but you can SEE data there!). The programmer has to
resort
    to creating this array on his own (which we KNOW can be done, but it
involves
    several boxes to do!) Can this be changed to allow direct editing of
arrays
    greater than 1 dimension?

    NOTE: I actually found a way to do it, so I KNOW this is not an
impossible
    task for VEE it just needs to get a LOT easier!
    If I want to create a [100,4] TEXT ARRAY in a RECORD, I first make a 1D
    TEXT ARRAY that is [400] long. I can then type in the TEXT data I want
    (which BTW, will be a look-up table for me) keeping in my head that when
    I'm done [0] will map to [0,0], [1] will map to [0,1] ... [398] will map
    to [99,2] and [399] will map to [99,3]. When all the data is entered,
    change the dimensioning to 2D with the size [100,4] and viola! all the
    data entered is still there, only now it's mapped where you want it.

19) Many VEE programmers have developed a way of color coding boxes to help
    tremendously in the readability of a program. It would be almost too
much
    to wish for that we could somehow set a default set of properties for
each
    type of box we select (without having to find a similar box and clone
it).
    (I've seen here on the VRF, ways of parsing the native .VEE file to
change
    attributes of targeted boxes globally. This is kind of what I'm asking
for
    only I would like it to happen on-the-fly.) An acceptable work-around
would
    be to get GRIPE #4 incorporated.

20) This thing with the SCROLL BARS has to be fixed. I think you know what
I'm
    talking about. Where you can accidentally loose sight of your USER
OBJECT or
    FUNCTION because you LEANED too hard on a SCROLL BAR and WHOOOOSH it
flies
    off the screen. Yes, I'm familiar with the work-arounds to getting it
back,
    but can we somehow keep it from doing it in the first place?

21+ OK, there's my top 20. Here's YOUR chance to whine! What would YOU like
to
    see changed in VEE-NR (or NRR)?  Agilent can't improve things if they
don't
    know what's bugging us!

Don't get me wrong, I like VEE and have grown with it since the distribution
of it was on a few floppy disks. However, I think it's past time to knock
off
some more of the rough edges that it has.

Thanks for letting me rant,

Mike Groves
UltraRF a CREE company
Sunnyvale, CA

Outcomes