🚀 go-pugleaf

Hi, I wrote the following for a final document after having used
DevGuide 3.0 for some time. You might find it useful to
hear from my experiences. If you have have any comments,
please do not hesitate to email or followup.

I used DevGuide 3.0 with Xview and gxv++ only.

----------------------8<--------------------------------------------
WORKING WITH DEVGUIDE
---------------------

Some unexpected features of DevGuide 3.0 were discovered while
seriously using it.  Most issues addressed below cannot be found in the
DevGuide manuals.


Tips & Tricks
-------------

This trick is applied on the lower layered pane:
If you want the previous control area to re-appear, you only have
to hide the current control area. This seems to work flawlessly.
It has not been tested if this works more than once, i.e. 
hiding the visible control area more than once.
The alternative would have been to use a variable which keeps track
of the previously visible control areas.

The following feature is available in DevGuide, but appeared to be "not
implemented" in gxv++ for Xview. gxv++ generates a x_stubs.cc file without
warning, inserting comment lines like "not implemented".  The feature
is a connection "from" anything "to" enabling or disabling an
nonexclusive setting item.  The workaround is to do a "manual" xv_set
on the setting's PANEL_VALUE.  The PANEL_VALUE is a bitmap of the
states of the setting items.  The LSB corresponds to the first item,
etc. See the O'reilly's XView book for more details.

When there is a callback defined for a Notify or Deselect event for
an exclusive menu item, and only one item is touched, callbacks
will be called for all items instead of just the touched item.
This means that many callbacks are useless, since the corresponding
user interface element did not undergo a real change. 
This is theoretically not a problem, but in practice it may be,
especially when the callback takes much time.

Help texts must be entered without carriage returns if you want
them to be aligned correctly. The DevGuide window in which the text
is edited, and the runtime help window have different sizes, so
aligning the text is best left to the help system. If you want blank
lines, you may enter carriage returns.

DevGuide does a reasonable good job keeping the manual adjustments
merged with the generated part of x_stubs.cc. But when a UI 
element is deleted or renamed, gxv++ thinks the old piece of code
is written by the user, and therefore keeps it in the file. The
stubs file may grow at best, but will not compile at worst. When
a compilation error occurs, the offending old code can simply be
removed. It is recommended to temporarily throw away the stubs file,
generating a new one, and merging it with the manual changes again.
For this reason it is wise to have only a few small manual changes.

Be sure that each popup window has an existing parent. If not,
everything seems to be working fine, until you click on the pushpin
to dismiss a popup window. The window will never be seen again.

Bugs in DevGuide
----------------

Showing/hiding a setting item in a connection works on the entire
setting instead of just the item.
A workaround is to make a separate setting with one item if
you want to selectively show or hide that item.

When a help text is slightly longer than can be shown in the runtime
help window, the scrollbar cannot be moved. This means that the
remaining help text cannot be read. 
A workaround is to append a few carriage returns to the help text
using DevGuide. The scrollbar will then be moveable.

The following applies to a pinnable exclusive menu with notify
callbacks on each menu item: if the menu is not pinned, everything is
fine, but if the menu is pinned, and some item is chosen, the callback
of the last item is called, instead of the corresponding callback.
A workaround is to put an exclusive setting in a popup window, which
looks and acts very similar.

In DevGuide's test mode, the behaviour of the pushpins is not exactly
the same as in reality. This is not severe if you know about it.
----------------------8<--------------------------------------------
-- 
Maarten J. Landzaat (analyst/programmer, bass player, Atari/midi freak)
BSO/Aerospace & Systems			Mail: Spuistraat 97
Email: maarten.landzaat@fel.tno.nl	      1012 SV  Amsterdam
Phone: +31 20 6266098			      The Netherlands