VEE 3.21 Introduction Notes (may 96)

last update 28 aug 98 / greg goebel / public domain / vwv_3_21

* This document provides introduction notes for the VEE 3.21 release in the spring of 1996.

* We have just released a new version of VEE, intended to fix some bugs that have been found in VEE 3.2. The following defects were found in VEE 3.2 and have been repaired in VEE 3.21:

• Strings as parameters for a Plug&Play function call don't work.

• DataSets load very slowly on VEE 3.2 on the PC.

• Executing a Print All with a To/From Plug&Play object with transactions will fail with a "Big Red Box" (BRB) error.

• On Win95, the invocation of the ID compiler, "hpidc2.exe", from VEE (when the driver ends in '.id') is broken. The compiler can be invoked from the command line and work OK.

• Due to the use of a braindamaged Win95/NT function to build numbers from ASCII strings, the 'From DataSet" object is slowed down by about 100 times.

• Classic VEE instrument drivers have problems on UX 10.01. HP-UX 10.01 changed the behaviour of a string function that, dependent on how the driver is written, may not cause a problem at all -- or make the ID unusable. The IDlang instruction "ENTER variable FORMAT K" is interpreted as "ENTER variable FORMAT k". This will break some drivers.

• With VEE 3.2 do the following:

  • Build a UserObject with a XY Display added to its panel.
  • With either Panel or Detail view showing, iconize the UserObject.
  • Mimic a Get/Save cycle by cloning the iconized UserObject.
  • Unpack the clone while it's still iconized.
  • Notice the warnings.

  While the warnings seem innocuous, things are in a bad state. Any meaningful work, particularly on the objects that were on the UserObject panel, may not save correctly.

  The workaround is to make sure that the UserObject is un-iconized before unpacking (again, detail or panel view showing doesn't matter).

• Build a UserObject with input or output terminals, and populate the inside of the UserObject with primitive VEE objects that connect to the UserObject's input or output terminals.

  Build a panel on the UserObject and clone it to mimic a Get/Save cycle. While the cloned UserObject is still in panel mode (or in icon mode) and has never been switched to Detail view, delete a terminal.

  When the UserObject is brought back to Detail view, the internal connections to the input or output terminals are screwed up. The UserObject will not execute correctly and will force a BRB, nor will it save correctly.

  The workaround is to force the UserObject to detail view before deleting a terminal.

• This defect is dependent on editing a maximized UserObject that has a panel that has been added to either the main work area's panel, or to a surrounding UserObject's panel. The key is that the nested UserObject must be edited when maximized; if the UserObject is edited when not maximized, everything is fine.

  To create this, do the following:

  • Pull down a UserObject. Pull down another UserObject and place it inside the first UserObject.
  • Place a XY trace display inside the nested UserObject. Add it to that UserObjects panel.
  • Now add the nested UserObject's panel to the parent UserObject's panel.
  • Change the parent UserObject to detail view and the nested UserObject to detail view.
  • Maximize the nested UserObject using the title bar "maximize" button and delete the XY trace.
  • Shrink the nested UserObject back down by clicking on the maximize icon in the title bar.
  • Change the parent UserObject back to panel view.
  • Notice error!

  This can be avoided by not maximizing the nested UserObject.

• This defect is very much like the one above, but it is harder to create. Again, it depends on editing a maximized UserObject that has a panel that has been added to a surrounding UserObject's panel.

  Furthermore, the nested User Objects must have gone through a Get/Save cycle when the surrounding UserObject is in Detail view. In this case, it isn't neccessary to delete an object that is on the nested UserObject's panel; all that has to be done is that some objects within the nested UserObject be removed or added. It is not neccessary that the objects be on any panel.

  When the nested UserObject is unmaximized, and an attempt is made to move to the surrounding UserObject's panel view -- remember, a get/save occurred and the surrounding UserObject was not in panel view -- a caution error occurs that complains about not recognizing some keyword.

  It is this innocuous caution which is the insidious part. At this point the VEE program is not in a good state; any subsequent save puts out a worthless file. At some point in the future, the file becomes unusable: it will not Save correctly and will not Get correctly, and any attempt at editing it will cause BRBs.

  The nasty part is the decay happens slowly. The initial caution may have occured last week and been forgotten, but a week later the file is dead.

As noted, all these defects have been fixed.