.ds f. trbl.sec
.NH 1 "TROUBLESHOOTING XVROUTINES"
.XS
\s12\*(SN  TROUBLESHOOTING XVROUTINES\s0
.XE
.sp 2
This section covers problems that are commonly encountered by application
programmers writing xvroutines.  If you are writing an xvroutine, it may
be worth your while to browse through the problems and solutions to see if
your problem is described here. 
.sp 3
\fBProblem:\fP
.IP
When you run your xvroutine, you get a series of error statements from the
parser in the \fIxvforms\fP library.
.sp
.LP
\fBPossible Solution(s):\fP
.IP
You have added or deleted a line to your *.form file, but have not re-executed
\fBconductor\fP.  Re-run \fBconductor\fP, being sure to use the same 
value for the \fIlevels of extraction\fP (-l {levels}) as you did originally.
.sp 2
.LP
\fBProblem:\fP
.IP
When you run your xvroutine, your program does not respond to input to the GUI.
.sp
.LP
\fBPossible Solution(s):\fP
.IP
If your GUI consists of a single pane on a single subform, you may not have 
correctly specified the \fIselected\fP fields on the (-F),
(-M), or (-P) lines as TRUE (1).  Check your *.form file to make sure that 
the second field on each of these lines contains a 1.  If any of these had a 
0 (FALSE), this was probably the source of the problem.
.IP
If you have recently run \fBconductor\fP, did you make sure that you ran it
with the same \fIlevels of extraction\fP (-l {levels}) as you did earlier?
For example, if a program was created with (-l 1), and you later run
\fBconductor\fP with [-l 2], your program will not respond to input.  The
solution is simply to re-run \fBconductor\fP with the correct number of levels. 
.sp 2
.LP
\fBProblem:\fP
.IP
You have an xvroutine that uses the \fIxvgraphics\fP library to display
graphics, or the \fIxvdisplay\fP library to display images in a workspace.  
When the workspace gets obscured by another window, and is then brought
forward again, it does not refresh properly.
.sp
.LP
\fBPossible Solution(s):\fP
.IP
X Programming requires that you install an event handler on the workspace
widget to take care of refreshing when an ExposureEvent is detected.  For
an example, see the code in \f(CW$KHOROS_HOME/src/xvroutines/example1\fP,
particularly lines 127 to 136 and lines 200 to 252 of "lexample1.c". 
.sp 2
.LP
\fBProblem:\fP
.IP
You have a hybrid graphics routine (an application that is non-interactive,
but that displays images or graphics) that uses the utilities in the 
\fIxvutils\fP library but does NOT use the \fIxvforms\fP library to generate
and maintain a graphical user interface.  Your program will not compile, 
complaining about subroutines named \fIxvf_process_event(),\fP
\fIxvf_cap_first_letter()\fP and/or others not defined.
.sp
.LP
\fBPossible Solution(s):\fP
.IP
There are interdependancies between the \fIxvutils\fP and \fIxvforms\fP 
libraries that force you to modify your Makefile for this particular case.
Edit your Makefile, looking for the definition beginning:
\f(CW
.sp
X_LOCAL_LIBRARIES = \
\fP
.sp
Now, copy the line specifying \f(CW$(XVUTILSLIB)\fP and put it above the
\f(CW$(XVFORMSLIB)\fP, so that the \f(CWX_LOCAL_LIBRARIES\fP definition
has two references to the \fIxvutils\fP library, one before the reference
to the \fIxvforms\fP library, and one after it.  Now do \fBmakemake\fP to
update your Makefile, and compile again.
.sp 2
.LP
\fBProblem:\fP
.IP
You have an xvroutine that uses the \fIxvgraphics\fP library to display
graphics.  You think that you are making all your calls correctly, and 
graphics should appear, but your workspace remains blank.
.sp
.LP
\fBPossible Solution(s):\fP
.IP
You didn't make a call to \fIX3D_init_graphics()\fP.
You didn't make a call to \fIX3D_set_X11()\fP.
You didn't make a call to \fIX3D_set_window()\fP.
You didn't make a call to \fIX3D_set_wc_min_max()\fP.
.sp 2
.LP
\fBProblem:\fP
.IP
You have specified selections/buttons/selections on a pane of your graphical 
user interface, but they don't appear.
.sp
.LP
\fBPossible Solution(s):\fP
.IP
Check your UIS file.  If the x and/or y positions in the geometry string (+x+y)
in (wxh+x+y) of a selection, button, or other item is the same as another, only
one will appear.  The other(s) are there, but are obscured.
.sp 2
.LP
\fBProblem:\fP
.IP
You have action buttons on your master form, or guide pane.  When you
click on them, however, the action you intended is not performed;  
instead, something unexpected happens, ie, the program acts as if you had 
entered input on another subform or pane.
.sp
.LP
\fBPossible Solution(s):\fP
.IP
In your main user interface loop, and in drivers that control subforms, 
you must \fIalways\fP check for actions being selected first in your
code.  If you don't, they will be pre-empted by a subform or another pane, as
at least one subform and at least one pane must always be selected.  
.sp
For example, always use:
.br
\f(CW
if (subform_info->action1)
.br
/* respond to action 1 */
.br
else if (subform_info->pane1_selected)
.br
   run_pane1(form, subform_info->pane1);
\fP
.sp
Never use:
.br
\f(CW
if (subform_info->pane1_selected)
.br
   run_pane1(form, subform_info->pane1);
.br
else if (subform_info->action1)
.br
/* respond to action 1 */
\fP
.sp
.LP
\fBProblem:\fP
.IP
You are using \fIxvf_query_wait()\fP to get a set of responses interactively
from the user, and you are using the \fIanswers\fP array initially to supply
default values.  Sometime after your call to \fIxvf_query_wait()\fP,
you get a segmentation fault / core dump for no apparent reason.
.sp
.LP
\fBPossible Solution(s):\fP
.IP
The answers array has a twofold purpose:  (1) you supply default values,
and (2) you get the user's responses returned to you.  If you are supplying
default values, \fIyou MUST allocate enough space for each string to accomodate
the longest possible response, NOT simply enough space in which you fit your
default string\fP.  If you do not supply defaults in the \fIanswers\fP array,
\fIxvf_query_wait()\fP will allocate the strings for you;  however, if you
use the \fIanswers\fP array to supply defaults, \fIxvf_query_wait()\fP 
assumes that you have allocated plenty of space for the user's response.  If you
do not allocate enough space, and the user provides a longer response than what
you have provided for, memory will be over-written, resulting in a segmentation
fault at an unspecified time thereafter. 
.sp 2


