Problem identified and fixed (at least for normal objects). Problem
occurs when Interface>DisableTransmit:All is selected
(and transmit_disable is set to true).
Objects/Items created by the user are relying on output_my_data() to add
the newly created object to the linked lists through a call to
decode_ax25_line() right at the end of output_my_data(). The call to
output_my_data() is usually wrapped in a test like the following:
if (object_tx_disable)
output_my_data(data,-1,0,1,0,NULL); // Local loopback only
else
output_my_data(data,-1,0,0,0,NULL); // Transmit/loopback object
Right at the begining of output_my_data is a test to see if
the global transmit_disable is true and the loopback parameter is false.
If it is, then output_my_data immediately returns, without reaching the
call to decode_ax25_line(). Thus if object_tx_disable is false, and
transmit_disable is true, output_my_data() is called with loopback
false, and it immediately exits.
I have fixed this by adding transmit_disable to each of the tests in
objects.c:
if (object_tx_disable || transmit_disable)
output_my_data(data,-1,0,1,0,NULL); // Local loopback only
else
...
There is a similar pair of calls to output_my_data() in main.c:
process_RINO_waypoints(). Can someone familiar with the RINO
functionality please check to see if the same fix should be applied
here as well?
There are calls to output_my_data() in other files but it doesn't look
like any of them are in pairs with transmit disable tests.
Merry Snailing,
-Paul
On Wed, 9 Jan 2008 10:59:04 -0500
"Paul J. Morris" <[EMAIL PROTECTED]> wrote:
> On Wed, 9 Jan 2008 08:48:16 -0700
> Tom Russo <[EMAIL PROTECTED]> wrote:
> > On Wed, Jan 09, 2008 at 10:33:36AM -0500, we recorded a
> > bogon-computron collision of the <[EMAIL PROTECTED]> flavor,
> > containing:
> > > In the current cvs, I'm seeing objects and items that are created
> > > by the user through either the Object/Item->Create dialog or as
> > > Predefined Objects not show up on the screen until a restart, or
> > > be
> ...
> > > Can anyone else replicate this and see what I'm missing?
> >
> > Nope.
>
> Good. It looks like it is bad data somewhere in my ~/.xastir
> directory. I moved ~/.xastir, started Xastir and the problem went
> away.
--
Paul J. Morris
Biodiversity Informatics Manager
Harvard University Herbaria/Museum of Comparative Zoölogy
[EMAIL PROTECTED] AA3SD PGP public key available
_______________________________________________
Xastir-dev mailing list
Xastir-dev@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir-dev
