Re: [XForms] Xforms & threads-functions & others

[Jens Thoms Toerring]

Hi Sergey,

On Fri, Oct 07, 2011 at 11:00:57PM +0400, Sergey Klimkin wrote:
> >>1
> Multithreading is required for work with serial port, I see no other
> solution.

Another soluttion migh be to run the communication with the device
connected to the serial port in another process, but for what I
understand of you program that might complicate things unneces-
sarily since them you'd need some kind of interprocess communi-
cation (IPC).

> Functions to work with serial port in a separate file and do not cause
> functions xforms.

Then you should be fine;-)

> >>2
> Makefile:
> # compiler
> CC = gcc -Wall
> # target "survey"
> OUTPUT = survey
> 
> # create target file "survey"
> (OUTPUT): survey_main.o survey.o survey_cb.o comport.o
>       $(CC) survey_main.o survey.o survey_cb.o comport.o -o $(OUTPUT) -lforms
> 
> # create obj "survey_main.o"
> survey_main.o: survey_main.c survey.h
>       $(CC) -c survey_main.c -o survey_main.o
> # create obj "survey.o"
> survey.o: survey.c survey.h
>       $(CC) -c survey.c -o survey.o
> # create obj "survey_cb.o"
> survey_cb.o: survey_cb.c survey.h
>       $(CC) -c survey_cb.c -o survey_cb.o
> # create obj "comport.o"
> comport.o: comport.c survey.h
>       $(CC) -c comport.c -o comport.o
> 
> clean:
>       -rm *.o *~ -
> 
> In file survey_cb.c
> void cb_btn1( FL_OBJECT * ob,
>          long        data )
> {
>     /* Fill-in code for callback here */
>       // Manually add 2 strings - for switch to form/window "FILES" from
> "GNSS_MONITOR"
>       fl_hide_form(fd_GNSS_MONITOR->GNSS_MONITOR);
>       fl_show_form( fd_FILES->FILES, FL_PLACE_CENTERFREE, FL_FULLBORDER,
> "FILES" );
> }
> 
> ... and so on cb_btn2() -- cb_btn6()
> 
> terminal:
> address@hidden:~/projects/fdesign/surveyfd$ make
> gcc -Wall -c survey_cb.c -o survey_cb.o
> survey_cb.c: In function ‘cb_btn1’:
> survey_cb.c:22: error: ‘fd_GNSS_MONITOR’ undeclared (first use in this
> function)
> survey_cb.c:22: error: (Each undeclared identifier is reported only once
> survey_cb.c:22: error: for each function it appears in.)

The variable ‘fd_GNSS_MONITOR’ is a variable local to the main()
function in survey_main.c. One way to avoid that would be to
define it as a global variable in survey_main.c and add a line
like

extern FD_GNSS_MONITOR *fd_GNSS_MONITOR;

to survey_cb.c (or survey.h)

All the other error messages have the same reason, you attempt
to use variables in survey_cb.c that are only defined as local
variables in main() in survey_main.c. After you correct that
everything should compile successfully (at least it did for me).

> Declarations fd_XXXXXX (FD_GNSS_MONITOR *fd_GNSS_MONITOR;) are in
> survey_main.c

What you have in main() in survey_main.c are definitions of those
variables. A "definition" tells the compiler to create a variable
while a declaration merely tells the compiler that a variable is
defined somewhere else and it thus shouldn't worry that it didn't
see a definition.

> in main()  - they need to move in survey.h as: static FD_GNSS_MONITOR
> *fd_GNSS_MONITOR;
> otherwise they are invisible to the call from any location. 

No, never define variables in heade files! This will result in
each file including the header file getting its own set of the
variables and that's absolutely not what you want. With the
'static' qualifier this still will compile and link without
warnings but the program will not work - each file will have
its own variable of that name, which is completely independent
of the one in another file.

So: always define a variable only once in a .c file and declare
it as far as necessary in a header file or another .c file that
needs access to it (with the 'extern' keyword).

> >>3
> The file exists and the right to read it is. Error in fd-Xforms:
> Objects->Attributes->Spec->button_Browse
> writes the truncated pathy /projects/fdesign/surveyfd/2Garmin_iPAQ.xpm
> but even the full
> path /home/sklimkin/projects/fdesign/surveyfd/2Garmin_iPAQ.xpm 
> will be useless when you transfer the program to another machine
> In the file survey.c in the function create_form_GNSS_MONITOR () is a
> line that does not work:

Well, there are some limitations to fdesign - it can't forsee
the future, i.e. where the program will get installed and where
image files are going to be. All it can do is either store the
place where the image file is at the moment you run fdesign -
then you have to make sure that it can be found there when the
program is run (that's why using an absolute path makes a  bit
of sense). The alternative is to include the file into your
program (with the "Use Data" button - for xpm files that's an
option since it's nothing but a C array) but in your case the
2Garmin_iPAQ.xpm file is unsuitable since its name results in
a variable name of '2Garmin_iPAQ.xpm' which is not a valid C
variable name since it starts with a digit) and thus compiling
the program with this option will fail).

The simplest solution is probably not to set the file name with
fdesign (that may not look too nice in fdesign, but there are
worse problems;-) and instead set it within the handwritten
part of your program since you're the only one who as any idea
where those image files can be really found. That's at least
how I do it, perhaos someone else here on the mailing list has
some better ideas...

> >>4
> I meant to attach to my e-mail message file with source code, or
> archive-file ZIP-format with an image copy of the screen (as is now
> common at many conferences Internet).
> Here are just now found at the bottom of my Meassage image attached to
> it!
> So you can send Attachment?

Yes, of course, you're sending an email and the mailing list
software can deal quite well with attachments (at least I have
not seen any problems).

On a different topic, not really related to XForms: I also had a
peek at the code for accessing the device connected the serial
device port. And I would like to comment on a few points that
might help you with that part.

I noticed that you open the serial port device file with the
O_NDELAY option (I would consider using O_NONBLOCK). That's
quite fine (and can avoid the open() call to hang). But then
you do things like

    BytesRead = read( fd, bRead, BUFSIZE );
    if ( BytesRead < 2 )
            printf("None answer from Garmin-device. End of connection!\n");

and that could be problematic if the device can't react imme-
diately. In non-blocking mode read() will return just as many
bytes as are available at the moment it is called (even none).
This doesn't necessarily mean that the device is not reacting
or not able to send the data you want but only that not all
you asked for was available at the precise moment read() was
called. The way you do it you might be in for a lot seemingly
not working communications with the device even though the
device is working 100% correct.

There's even a good chance that read() returns -1 because no
data where available at that moment. This is not necessarily
an error. You should check 'errno' for the reason why read()
returned -1. E.g. if 'errno' is 'EAGAIN' the reason was that
no data were available and in that case it's often reasonable
to just try again until some time limit in which the device
should have sent a complete reply has been exceeded.

And even if you had unset O_NONBLOCK read() could return less
bytes than you expected and this would still not necessarily
mean that the device isn't respoding correctly - all you're
guaranteed also in blocking mode is that you will get at least
one byte...
                             Regards, Jens
-- 
  \   Jens Thoms Toerring  ________      address@hidden
   \_______________________________      http://toerring.de