On Sun, 09 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> Good question but I am not tested that
> What I say is: using gtos2, at least in these tests, screen/output is not
> refreshed and tracing labels existent in body of fuction where error happen
> are not shown
> You will see more samples below
So it's general problem with accessing console from other threads.
> >> if( kbhit() )
> >> ch = getch();
> >Probably kbhit() internally call KbdCharIn() and it's exactly
> >the same problem.
> Maybe
To be precise it's KbdPeek() and kbhit() is probably simple wrapper to it.
It means that OW internals are also effected by this problem.
The question is if it can be resolved or not. Is it OW bug or problem
with OS2 API. In GCC it seems to be resolved. The question is how.
> >If possible then I would like to check if other GTOS2 functions works
> >correctly for 2-nd thread and the problem is only with KbdCharIn().
> >F.e. try mttest02.prg with such modified GTOS2 so we can see if screen
> >output works.
> I was trying with mttest02.prg and we got many results
> Note: I am not testing if "screen output works" with 2nd thread but entire
> execution of program
> For now we have in gtos2.c
> /* KbdCharIn( s_key, IO_NOWAIT, ( HKBD ) * s_hk ); */
[...]
Please also disable mouse polling and comment this code:
if( ch == 0 )
ch = HB_GTSELF_MOUSEREADKEY( pGT, iEventMask );
> As you see in this and other cases, fail within hb_gt_os2_mouse_GetPos()
> but screen/output is not refreshed to show at least
> printf("1. hb_gt_os2_mouse_GetPos()\r\n");fflush(stdout);
> printf("2. hb_gt_os2_mouse_GetPos()\r\n");fflush(stdout);
> This behaviour confuse us because last info seem to be fail in the calling
> function, while fail occur in called function which does not refressh their
> own printf( )
> I do not know if this is a normal behaviour for printf( )
It does not have to be printf() behavior. 1-st it's always better to
redirect output to file to eliminate possible overwriting. The
second problem can be caused by possible compile time optimizations
which can change the order of executed instructions. In such case is
always good to pass to printf() some pointers to variables which are
used in function you want to trace to disable such optimization.
It's the reason why I added s_key pointer to "0. hb_gt_os2_ReadKey(%p)"
though in this case seems that it wasn't help though I'm not sure
you replicated it.
> As summary there are problems in "reading devices" except for thread 1
> Now we have catched at least three points which cause fails:
> KbdCharIn( )
> MouReadEventQue( )
> MouGetPtrPos( )
> and they are NOT Harbour functions/procedures
Many thanks for detail tests. We know the problem and now we will have
to find workaround for it. We can make it in simple way and disable
input for non main thread. BTW can you check if keyboard input works
correctly in GCC builds for all threads, f.e. inm code like:
proc main()
hb_threadJoin( hb_threadStart( @thFunc() ) )
return
proc thFunc()
local k
while (k:=inkey(0)) != 27
? k
enddo
return
OS2 KBD API has functions KbdGetFocus() and KbdFreeFocus(). It's possible
that they will resolve the problem for keyboard input.
Finally we can simply check in GCC source what exactly it does to resolve
the problem. Seeing Maurilio comment in gtos2.c I guess that GCC for OS2
has its own KbdCharIn() instead of direct mapping:
#define KbdCharIn KBD16CHARIN
and inside this function the problem is resolved. But I only guess.
I haven't ever seen this compiler.
For someone who has some experience with OS2 API the problem should
be easy to resolve or find workaround or give us an answer if it can work.
> As you see, I was changing C code myself :-)
With very good results. Many thanks for your help.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
