Good morning Przemyslaw and Viktor, first of all you have to answer a question I'm asking myself since a long time: how are you able to avoid sleeping and still be able to write such good code?? I see messages of yours during all night: 00.46, 01.17, 01.49, 02.53, 03.45, 04.17, 04.48, 08.50!!
That said, it works now like a charm: (E:\REPOSITORY\HARBOUR\tests)hbmk2 -mt speedtst.prg hbmk2: Processing environment options: -mt -compiler=gcc hbmk2: Processing configuration: E:\harbour\bin\hbmk.cfg Harbour 2.0.0beta3 (Rev. 13082) Copyright (c) 1999-2009, http://www.harbour-project.org/ Compiling 'speedtst.prg'... Lines 1204, Functions/Procedures 79 Generating C source output to 'speedtst.c'... Done. Thanks so much guys. Maurilio. Przemysław Czerpak wrote: > On Tue, 01 Dec 2009, Szak�ts Viktor wrote: >>> Fine. Please also check >>> tst.exe | grep . >>> to check the results for pipes. >>> I've just check that in DOS OpenWatcom builds it works as we want. >> Works fine with mingw + cmd.exe. >> Also works fine with mingw + msys. > > In DJGPP builds with COMMAND.COM and BASH also works as expected > so only OS/2 builds should be verified yet. > >>>>> Oops. I've forgot that FD_* constants are in .ch file for CL53 >>>>> FSETDEVMOD() >>>>> functions so we already have everything in core code so please simply add: >>>>> FSETDEVMOD( 1, FD_TEXT ) >>>>> FSETDEVMOD( 2, FD_TEXT ) >>>>> or if you want to make it in more generic way which will work also for >>>>> multi GT output (i.e. with some code which allocates many different GTCGI >>>>> drivers with different redirection) then make: >>>>> FSETDEVMOD( hb_gtInfo( HB_GTI_OUTPUTFD ), FD_TEXT ) >>>>> FSETDEVMOD( hb_gtInfo( HB_GTI_ERRORFD ), FD_TEXT ) >>>> Will commit it ASAP, I hope Maurilio can test it then. >>> I tested DOS OpenWatcom builds and it resolved the problem. > > Also in DJGPP builds. > >>> BTW in most of cases we expanded names of Clipper functions cut to 10 >>> characters, i.e. dbSelectArea(). Maybe we should also change FSetDevMod() >>> to FSetDevMode()? >> That's a good question. Maybe the best solution would be to >> add it as HB_FSETDEVMODE() and leave FSETDEVMOD() as >> a compatibility wrapper. >> This also helps hbmk2 to build when HB_COMPAT_C53 is disabled. > > So let's add HB_FSETDEVMODE() > >> [ BTW it's not fully compatible, as C5.3 returned the old >> dev mode value. ] > > Yes, I know. I think we should change: > BOOL hb_fsSetDevMode( HB_FHANDLE hFileHandle, USHORT uiDevMode ) > to: > int hb_fsSetDevMode( HB_FHANDLE hFileHandle, int iDevMode ) > > and also return previous value or -1 on error and then update FSETDEVMOD() > to work like in Clipper. I can make such modification. > > best regards, > Przemek > _______________________________________________ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __________ | | | |__| Maurilio Longo |_|_|_|____| farmaconsult s.r.l. _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
