AnsweredAssumed Answered

vrf Vertically challenged editing

Question asked by VRFuser on Apr 12, 2004
Fellow VRF'ers (mostly to the newer programmers),

I have to agree with many of the programming practices already mentioned. Yes,
having UO and UF boxes in a unique color DOES make the code much more readable.
Maybe one day we will standardize on the use of colors for various boxes.
Perhaps if we as a group can come up with a common set of colors that we (more
or less) agree on, Agilent will see the picture (literally) and incorporate that
color set into some future version OF VEE. Wouldn't that be better than to have
them arbitrarily pick their own colors?

Yes, I agree closing boxes is a good practice. Not only will it make them more
compact and readable, but they will also execute faster. While we are on the
subject of boxes, watch that you don't add unnecessary sequence lines! If you
have a solid data line going from the output of box "A" to the input of box "B",
box "B" CAN'T execute until box "A" passes it's data to it, so there is no
reason at all to put an extra sequence line from the bottom of box "A" to the
top of box "B". It's already implied.

(Best viewed with a fixed font.)

What I'm saying is, DON'T do this...

                  |       |
      +---+---+   |   +---+---+
      |       |   |   |       |
  --->+   A   +---|-->+   B   +--->
      |       |   |   |       |
      +---+---+   |   +---+---+
          |       |

When you can just do THIS instead...

      +---+---+       +---+---+
      |       |       |       |
  --->+   A   +------>+   B   +--->
      |       |       |       |
      +---+---+       +---+---+

Now there ARE cases when adding a sequence line is mandatory to get the desired
results. Boxes with control inputs (dashed data lines), making sure a variable
is set before it's accessed, sequencing boxes that have no input or output pins,
controlling flow with the output pins of IF/THEN/ELSE boxes, and so on. The best
rule is, let the data control the execution sequence whenever possible.

Something I do to avoid "wires and clutter" is try to reduce the "box count"
where I can. For example, if I have some global variable that I want to
increment by 1, instead of having one GET VARIABLE box, and one INTEGER16
constant box with a "1" in it, both wired to the input pins of a FORMULA box
with an A+B inside, with the results of that finally going to a SET VARIABLE
box; for goodness sake, use a single formula box with GLOBAL=GLOBAL+1 in it! I
use this principle for many different boxes, like IF/THEN/ELSE, DIRECT I/O, TO
STRING, etc., etc. Build your formula lines with some "smarts" in them. Granted,
there's ALWAYS a trade off between having a formula that is so complex it's
difficult to figure out what's going on (and troubleshoot), and having a screen
stuffed full of tiny bits of boxes and wires.

For something that's difficult to program, I will start with discrete boxes, so
I can easily ping the lines, or add an AlphaNumeric display, to make sure the
intermediate data is what I expect, then when it's working, I start combining
things into fewer and fewer boxes.

If a box's formula(s) are too complex to follow, no problem! Click on the "bar"
in the upper-left corner of any box, then click on "Description" and add
whatever comments you need to make, so someone reading your code later (often
that's you!) can better understand what that box's function is. Whenever I add
any description to a box, I always add an asterisk '*' to the end of the box's
title, to alert me that there is additional "help" available to understand it.
Also, if I happen to clone that box for some other purpose, I can remember to
change or delete the description. I use the description also as one of the ways
to track changes I've made to objects. I wish the Description editor was a
little more "friendly", but I haven't fired up 7 yet, so there's always hope.

I've learned many of these principles the hard way. One of the things I've had
to do over the years is to "clean up" and document older VEE code. Some of it
could only be described as "rats nest" programming. OK, some of it was my own
code too from years back, but not the real nasty stuff. I had no idea VEE
programming could look that bad! By using a combination of repositioning boxes
on the screen, moving code into formula boxes, adding UserObjects where needed,
and occasionally adding some local variables (to replace long crossing signal
wires), it was amazing how compact and "readable" it could be when done, without
changing one bit of the functionality (except most of the time increasing
execution speed).

Martin, to answer a question you raised, I can't really say when it's OK to
group boxes into UserObjects. I think it really depends on the situation. Like
many of you, I like to keep me code to one "screen", if possible, and I usually
use 1280x1024. I can say this, you need to be VERY careful when creating
UserObjects in and around loops and IF/THEN/ELSE boxes. Sometimes the sequencing
turns out much different than one would expect.

OK, enough lecturing for now. Class dismissed.

Mike Groves

One more unrelated item. Is anyone interested in an older Logic Analyzer rather
cheap? I have a good working Tek Prism 3002 with a box full of probes. It's
rather heavy. Please email me directly if you have an interest and I'll describe
it and the pods in more detail.

-----Original Message-----
From: Martn Castillejos, Juan Carlos []
Sent: Monday, April 12, 2004 2:57 AM
Subject: [vrf] Re: Vertically challenged editing

Hi Mark and Bill,

I agree with Bill. I use to write VEE applications more in horizontal way than
in vertical. I try to get no more than 2 screens (as Bill has said, it depends
on the monitor resolution).

Additionally I use to minimize all the VEE objects and I try (as far as
possible) to set the title of the objects the same than the code into them, or
at least a descriptive name. In such a way I don't need open/restore a object in
order to see what it does and understand the code flow. Moreover, I use to paint
UserObjetcs and UserFunctions calls with other colour, in order to detect if I
am working at deepest level or not. I use to call all UserFunctions as:
F_name_of_the_function and all UoserObjects as capital letters (the rest of the
code are in small letters). I think all this items are related to a Programmers
Manual with good coding practices as programming advices.

Related to above is: when is considered that a UserObject/UserFunction has to
many objects and need to be split in lower level UserObjects/UserFunctions? What
is the "limit" number, 20/30/40 objects, in they can be considered as too much
big? I know that this is not universal, but "in general" it could be said that
an UserObject/UserFunction has to many objects if they are more than "N". This
is interesting for maintenance and debugging purposes.

Any suggestion?


> -----Mensaje original-----
> De: []
> Enviado el: jueves, 08 de abril de 2004 16:50
> Para: VRF
> Asunto: [vrf] Re: Vertically challenged editing
> Mark,
> I'll offer my opinion here. First, I find that when I follow
> the advice
> offered in the User's Guide and let the data flow determine
> the program
> flow, my programs tend to organize themselves horizontally rather than
> vertically. I use relatively few sequence lines which tend to
> make things
> vertical. Many examples I see have many more sequence lines
> than necessary
> making the screen cluttered and hard to read.
> Second, I would find a VEE program of 4-5 page heights
> virtually impossible
> to follow, even if I was the one who wrote it. I sometimes
> violate the "one
> screen" guideline when there doesn't seem to be a good way to
> group things
> into userObjects, but then it's more like 1.5 screens. I find
> things much
> easier to follow when I can group things into userObjects and
> userFunctions
> with descriptive titles like "Extract Features", "Count the
> Categories",
> etc. Others may be better at this, but if there are too many
> objects at
> once, I have real trouble keeping track of where in the
> program I am, so
> rather than "resigning myself" to using userObjects I employ them as a
> major organizational tool.
> I'll admit that I have a large monitor and set the resolution
> to 1600X1200,
> but I really need to see the whole program or userFunction to work
> effectively with it.
> Just my opinion, your mileage may vary.
> --
> Bill Ossmann
> Philips Ultrasound
> e-mail:
> --------------------------------------------------------------
> ------------------------
> I'd like to float some thoughts on vee editing, and see if
> there are any
> good ideas in the community.
> To me , one of my biggest complaints with vee is with the
> actual editing.
> For better or worse, over the years I've come to end up
> editing my vee code
> mostly vertically. By that I mean that I generally try not to
> let unseen
> objects go off screen right or left, only just up and down.
> To read the
> code, I then usually need only the vertical scroll bar. For
> me, this seems
> to give more readable code (reads a little more like text
> based code that
> way).
> Firstly, I wonder if many others also do things this way.
> Secondly, this method also causes me great grief. I've long
> been bothered
> by the vee editor when I need to insert new code where there
> is no space.
> Whenever I have a longer chunk of code, maybe 4-5 page
> heights, I have to
> highlight (select) all the objects below where I need to
> insert new code by
> using the "CTRL + Right Click and Drag" method. Then I must drag the
> selected objects down (or up) to create the new space. This is getting
> painful (literally).
> I always wished there was some sort of push function in the
> vee editor,
> whereby you could click a start point , give it some distance
> info, and let
> the editor do all the pushing of objects, maintaining the
> relative object
> positions and making some new edit space.
> I've attached 2 sample programs to illustrate my idea (version 6.01).
> - spacing_test.vee is an example code illustrating my
> vertically challenged
> editing method. Notice it scrolls up/down but not left/right (mostly,
> probably depends on your monitor size etc.) Note inside this
> code there is
> a special notepad object with the text "vert_page_insert".
> Move this object
> to the point where you want new space created, then save the
> file. The next
> attached code does the pushing.
> - push_vertical.vee is the code to do the pushing. When you
> run it, a file
> dialog opens- use it to select spacing_test.vee It searches
> the vee text
> file for the "vert_page_insert" text, assumes its a notepad
> object, finds
> its pinCenter vertical point, then finds all instances of pinCenter
> vertical points greater than that of the special notepad's vertical
> pinCenter, and increments all those it finds by 1000. It
> thereby pushes all
> objects found in the spacing_test.vee code, which were below the
> "vert_page_insert" notepad object, down by 1000. It then
> saves the newly
> "pushed" file as spacing_test.vee_new.vee.
> This pushing code is not very robust, I've only tested it
> with the special
> case vee file attached. Its likely riddled with many bugs.
> (One example
> problem would be how to limit its pushing to only the user
> object or user
> function which is the currently open window?)
> I am wondering what good ideas folks may have relating to
> this subject. Is
> something like attached worth pursuing and debugging? Is
> there any simpler,
> more robust way to do what I want? Should I resign myself to
> constantly
> wrapping up large code chunks into user objects or user functions? Is
> anyone else bothered by the editor in this regard? Does
> something already
> exist I don't know about?
> Thanks all.

You are currently subscribed to vrf as:
To subscribe send a blank email to "".
To unsubscribe send a blank email to "".
To send messages to this mailing list,  email "". 
If you need help with the mailing list send a message to "".