[Harbour] SF bugtracker#1672301: Charset Mapping CP437 or CP850 (not documentated ?)
This is more than a year old report / feature request about locale maping. After reading the recent codepage discussion here on the list, I put this as a reminder that might help users porting thier DOS application to *nix world. http://sourceforge.net/tracker/index.php?func=detail&aid=1672301&group_id=681&atid=100681 Chen. [I was away for a while and just finished reading more that 100 digest (!) posts from this list] ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] the FRM
hi Victor: the Frm goes to you best regards Ciro -- http://sistemascvc.tripod.com (la casa del clip2win y nodosimp / the no2imp and clip2win home ) http://www.oohg.org ( Object Oriented Harbour GUI, more simple, more powerfull ) cvc.frm Description: Binary data ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-11-11 05:34 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
2008-11-11 05:34 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * make_b32.mak * make_vc.mak * common.mak * bin/hbmk.bat + Added generation of MT harbour .dlls for BCC and MSVC. ; TOFIX: 'hbmk -shared -mt' doesn't seem to work, resulting app simply exists for both BCC and MSVC. ; TODO: Please update make_gcc.mak. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-11-11 04:22 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
2008-11-11 04:22 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * make_b32.mak * make_vc.mak * make_gcc.mak * common.mak * Changed dll and mt obj locations to reside inside the platform dir: obj/dll/* -> obj/*/dll obj/*_mt -> obj/*/mt + Added provisions for new obj location: obj/*/mt_dll -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-11-11 03:56 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
2008-11-11 03:56 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * make_b32.mak * make_vc.mak * make_gcc.mak * common.mak + Added generation of hbmainstd and hbmainwin libs. * bin/hbmk.bat + Changed to use above libs. This also means that '-shared' can now be used in Harbour binary distributions, too. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SET PRINTER TO ( cPrinter ) - Bug
First of turn _SET_DEFEXTENSIONS to .F.,
after that in Harbour you'll need to convert
the Windows printer name to a port, share
name, or filename in order to print to it using
SET PRINTER TO.
Harbour core doesn't support any Windows
printers natively, so you'll need to use
hbwin.lib for some name to port conversion
and getting Windows printer name list.
IOW, in Harbour 'SET PRINTER TO' always need
to point to a filename, or any name that
can be opened using FOpen().
Brgds,
Viktor
On 2008.11.11., at 2:47, Pritpal Bedi wrote:
Hello All
Here is the code:
cPrinter := 'Kyocera FS-1000 (KPDL-2)'
SET PRINT ON
SET CONSOLE OFF
SET PRINTER TO ( cPrinter )
? 'Ok, I am printing'
eject
SET PRINTER TO
SET PRINT OFF
SET CONSOLE ON
The code above correctly prints on the specified printer in xHarbour
but fails in Harbour. In Harbour it creates a disk file with .prn
suffix:
Kyocera FS-1000 (KPDL-2).prn
xharbour/source/rtl/set.c :
case HB_SET_PRINTER:
hb_retl( hb_set.HB_SET_PRINTER );
if( args > 1 )
{
hb_set.HB_SET_PRINTER = set_logical( pArg2,
hb_set.HB_SET_PRINTER );
if( hb_set.HB_SET_PRINTER )
{
hb_set_SetPrinterStart();
}
else
{
hb_set_SetPrinterStop();
}
}
break;
harbour/source/vm/set.c :
case HB_SET_PRINTER:
hb_retl( pSet->HB_SET_PRINTER );
if( args > 1 )
pSet->HB_SET_PRINTER = set_logical( pArg2, pSet-
>HB_SET_PRINTER
);
break;
Which compiles has the correct behavior?
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/SET-PRINTER-TO-%28-cPrinter-%29---Bug-tp20431996p20431996.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_gtInfoEx( pGT, nGtInfo, xValue, xValue2 ) - Feature Request
To keep it alive ! Pritpal Bedi wrote: > > Hello Przemek > > Can we have hb_gtInfoEx() function accepting > as its first parameter and then the rest parameters. > It will help me to control GT behavior from other threads . > > Also can we retrieve for current context, i.e., > pGT := hb_gtCurrent() or like ? > > hb_gtReload() returns TRUE/FALSE. How can I retreive its . > > Regards > Pritpal Bedi > -- View this message in context: http://www.nabble.com/hb_gtInfoEx%28-pGT%2C-nGtInfo%2C-xValue%2C-xValue2-%29---Feature-Request-tp20414605p20432291.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Clipper RL compilation problem
Hi all, RL will crash when compiled with Harbour. The problem is that it's using 10 chars longer PRIVATE vars, then saves them to a .mem file and restores them before doing anything. Now, .mem files can only store var names up to 10 chars, so when the vars are restored their names are truncated and not found at runtime using the longer names used in the source. Any suggestion how to solve this Clipper compatibility problem the most efficient way? I had thought that we could limit PRIVATE/ PUBLIC var names to ten chars at runtime for compatibility. PRIVATE/PUBLIC is not something users want to use for new code, yet, above situation can very easily break old apps. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] abour EJECT in CLASS TREPORT
Hi Ciro,
Can you send the .frm, too?
Brgds,
Viktor
On 2008.11.11., at 0:48, Ciro Vargas Clemow wrote:
Hi Victor:
i'm not sure if the problem is the Treport.prg
but the next code... in clipper generate FF chr(12) chars after
each page
in harbour the FF chars not appear in list.txt
best regards
Ciro
local i
local aDbf := {}
AADD(aDbf, { "Name", "C", 10, 0 })
AADD(aDbf, { "Address", "C", 20, 0 })
AADD(aDbf, { "Phone", "N", 13, 0 })
//
DBCREATE("People", aDbf)
Use People
for i:= 1 to 200
append blank
replace name with str(i)
replace address with str(i+1)
replace phone with i+2
next i
set printer to list.txt
report form cvc to print
set printer to
**// (3 columns name 10, address 20 phone 13 )
--
http://sistemascvc.tripod.com (la casa del clip2win y nodosimp /
the no2imp and clip2win home )
http://www.oohg.org ( Object Oriented Harbour GUI, more simple, more
powerfull )
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-11-11 03:13 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
2008-11-11 03:13 UTC+0100 Viktor Szakats (harbour.01 syenar hu) + contrib/examples/rl + contrib/examples/rl/Makefile + contrib/examples/rl/hbmk_b32.bat + contrib/examples/rl/hbmk_vc.bat + contrib/examples/rl/readme.txt + Added build files for Clipper RL utility. (if someone remembers :) * contrib/examples/guestbk/hbmk_vc.bat * contrib/examples/pp/hbmk_vc.bat * contrib/examples/pe/hbmk_vc.bat * contrib/examples/dbu/hbmk_b32.bat * contrib/examples/dbu/hbmk_vc.bat * contrib/examples/hscript/hbmk_vc.bat * utils/hbdoc/hbmk_b32.bat * utils/hbdoc/hbmk_vc.bat * utils/hbmake/hbmk_b32.bat * utils/hbmake/hbmk_vc.bat % Removed winspool.lib from liblists. % Removed '/subsystem:console' from MSVC commandlines. + Added gtwvt.lib + gdi32.lib to liblists. (work in progress) * contrib/examples/dbu/readme.txt * Minor. * contrib/examples/pe/editorhi.prg ! Fixed stupid s&r error which broke compilation. [TOMERGE 1.0] -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] How to implement remote printing in Harbour
Hello All How can I implement remote printing at the client terminal. I am using TCP/IP protocol, I mean hb_INet* functions to have my own terminal. ( anybody interested can download http://www.vouch.info/downloads/vouchclient.zip user1/user1 ~ user9/user9 userid/password ) I need something to feed as to SET PRINTER TO ( cPrinter ) command. Server knows the client's IP address. OR any other alternative. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/How-to-implement-remote-printing-in-Harbour-tp20432275p20432275.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-11-11 02:44 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
2008-11-11 02:44 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * bin/hbmk.bat + Added '-shared' support for MSVC. ! Fixed to cleanup mainstd.obj and mainwin.obj. * ChangeLog * Some TODO/TOFIX marked as [DONE]. One [DONE] marked as [DONE - REOPENED]. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SET PRINTER TO ( cPrinter ) - Bug
Hello All
Here is the code:
cPrinter := 'Kyocera FS-1000 (KPDL-2)'
SET PRINT ON
SET CONSOLE OFF
SET PRINTER TO ( cPrinter )
? 'Ok, I am printing'
eject
SET PRINTER TO
SET PRINT OFF
SET CONSOLE ON
The code above correctly prints on the specified printer in xHarbour
but fails in Harbour. In Harbour it creates a disk file with .prn suffix:
Kyocera FS-1000 (KPDL-2).prn
xharbour/source/rtl/set.c :
case HB_SET_PRINTER:
hb_retl( hb_set.HB_SET_PRINTER );
if( args > 1 )
{
hb_set.HB_SET_PRINTER = set_logical( pArg2,
hb_set.HB_SET_PRINTER );
if( hb_set.HB_SET_PRINTER )
{
hb_set_SetPrinterStart();
}
else
{
hb_set_SetPrinterStop();
}
}
break;
harbour/source/vm/set.c :
case HB_SET_PRINTER:
hb_retl( pSet->HB_SET_PRINTER );
if( args > 1 )
pSet->HB_SET_PRINTER = set_logical( pArg2, pSet->HB_SET_PRINTER
);
break;
Which compiles has the correct behavior?
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/SET-PRINTER-TO-%28-cPrinter-%29---Bug-tp20431996p20431996.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-11-11 02:35 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
2008-11-11 02:35 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * make_b32.mak * make_vc.mak * make_gcc.mak + Added -DHB_TR_LEVEL_DEBUG C compiler option when HB_BUILD_DEBUG=yes. * source/rtl/hbinet.c * Minor formatting. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-11-11 01:39 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
2008-11-11 01:39 UTC+0100 Viktor Szakats (harbour.01 syenar hu) + config/w32/pocc64.cf + Added Pelles C x64 GNU-make file. * config/w32/pocc.cf * Minor cleanup. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] abour EJECT in CLASS TREPORT
Hi Victor:
i'm not sure if the problem is the Treport.prg
but the next code... in clipper generate FF chr(12) chars after each page
in harbour the FF chars not appear in list.txt
best regards
Ciro
local i
local aDbf := {}
AADD(aDbf, { "Name", "C", 10, 0 })
AADD(aDbf, { "Address", "C", 20, 0 })
AADD(aDbf, { "Phone", "N", 13, 0 })
//
DBCREATE("People", aDbf)
Use People
for i:= 1 to 200
append blank
replace name with str(i)
replace address with str(i+1)
replace phone with i+2
next i
set printer to list.txt
report form cvc to print
set printer to
**// (3 columns name 10, address 20 phone 13 )
--
http://sistemascvc.tripod.com (la casa del clip2win y nodosimp / the no2imp and
clip2win home )
http://www.oohg.org ( Object Oriented Harbour GUI, more simple, more powerfull )
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-11-11 00:39 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
2008-11-11 00:39 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * make_b32.mak * make_vc.mak ! Fixed linking hbtest-dll.exe with tracing enabled. * bin/hbmk.bat + Added '-shared' option. ; TOFIX: - '-shared' won't work in binary installations. - '-shared' cannot create MT apps. - '-shared' only works for BCC32 yet. - tests/hbmk_b32_dll.bat - Removed. Use 'hbmk_b32 -shared' instead. * source/rtl/treport.prg * Minor formatting. * make_b32.bat * make_vc.bat * common.mak * Changed default of HB_BUILD_DLL to 'yes'. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compiler source code SVN
Joel, could you please post your C_USR, L_USR and
other extra build settings?
Brgds,
Viktor
On 2008.11.10., at 23:16, Joel YAHOO wrote:
Hello
Starting from one it tree new of the msys.
I am also having problems to compile the harbour (SVN+MingW+Msys).
They are 2 errors.
1-
sh make_gnu.sh
config/global.cf:44: config/w32/mingw32.cf: No such file or directory
make: *** No rule to make target `config/w32/mingw32.cf'. Stop.
I copied mingw.cf for mingw32.cf
--
=
=
=
==
2-
c:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin
\ld.exe: cannot find -lhbmainstd
collect2: ld returned 1 exit status
make[3]: *** [hbdoc.exe] Error 1
make[3]: Leaving directory `/harbour/utils/hbdoc/w32/mingw32'
make[2]: *** [descend] Error 2
make[2]: Leaving directory `/harbour/utils/hbdoc'
make[2]: Entering directory `/harbour/utils/hbmake'
make[3]: Entering directory `/harbour/utils/hbmake/w32/mingw32'
gcc -Wall -W -O3 -march=i586 -ohbmake.exe hbmfrdln.o hbmgauge.o
hbmlang.o hbmake.o-L../../../../lib/w32/mingw32 -Wl,--start-
group-lhbdebug -lhbvm -lhbrtl -lhbnulrdd -lhbrtl -lhbvm -
lhbmacro -lhbcommon -lrddntx -lrddcdx -lrddfpt -lhbsix -
lhbhsx -lhbusrrdd -lhbmainstd -lgtcgi -lgtpca -lgtstd -lgtwin -
lgtwvt -lgtgui -Wl,--end-group -luser32 -lgdi32 -lwsock32 -
lwinspool -lcomctl32 -lcomdlg32 -lole32 -loleaut32 -luuid -lmpr -
lws2_32 -lmapi32
c:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin
\ld.exe: cannot find -lhbmainstd
collect2: ld returned 1 exit status
make[3]: *** [hbmake.exe] Error 1
make[3]: Leaving directory `/harbour/utils/hbmake/w32/mingw32'
make[2]: *** [descend] Error 2
make[2]: Leaving directory `/harbour/utils/hbmake'
make[1]: *** [install] Error 2
How can I solve that?
Many thank´s
{}s
Joel Bernardes
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compiler source code SVN
Hi Joel, sh make_gnu.sh config/global.cf:44: config/w32/mingw32.cf: No such file or directory make: *** No rule to make target `config/w32/mingw32.cf'. Stop. I copied mingw.cf for mingw32.cf Instead you should use 'set HB_COMPILER=mingw' or even better just drop this setting completely and let it be autodetected by make_gnu.sh. gcc -Wall -W -O3 -march=i586 -ohbmake.exe hbmfrdln.o hbmgauge.o hbmlang.o hbmake.o-L../../../../lib/w32/mingw32 -Wl,--start- group-lhbdebug -lhbvm -lhbrtl -lhbnulrdd -lhbrtl -lhbvm - lhbmacro -lhbcommon -lrddntx -lrddcdx -lrddfpt -lhbsix - lhbhsx -lhbusrrdd -lhbmainstd -lgtcgi -lgtpca -lgtstd -lgtwin - lgtwvt -lgtgui -Wl,--end-group -luser32 -lgdi32 -lwsock32 - lwinspool -lcomctl32 -lcomdlg32 -lole32 -loleaut32 -luuid -lmpr - lws2_32 -lmapi32 c:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin \ld.exe: cannot find -lhbmainstd The real question is why hbmainstd is not created. Please check your log for warnings or errors before this point, around hbmainstd creation. BTW, it works here without any such problems also with 3.4.5. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Compiler source code SVN
Hello
Starting from one it tree new of the msys.
I am also having problems to compile the harbour (SVN+MingW+Msys).
They are 2 errors.
1-
sh make_gnu.sh
config/global.cf:44: config/w32/mingw32.cf: No such file or directory
make: *** No rule to make target `config/w32/mingw32.cf'. Stop.
I copied mingw.cf for mingw32.cf
--=
2-
c:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot
find -lhbmainstd
collect2: ld returned 1 exit status
make[3]: *** [hbdoc.exe] Error 1
make[3]: Leaving directory `/harbour/utils/hbdoc/w32/mingw32'
make[2]: *** [descend] Error 2
make[2]: Leaving directory `/harbour/utils/hbdoc'
make[2]: Entering directory `/harbour/utils/hbmake'
make[3]: Entering directory `/harbour/utils/hbmake/w32/mingw32'
gcc -Wall -W -O3 -march=i586 -ohbmake.exe hbmfrdln.o hbmgauge.o hbmlang.o
hbmake.o-L../../../../lib/w32/mingw32 -Wl,--start-group-lhbdebug
-lhbvm -lhbrtl -lhbnulrdd -lhbrtl -lhbvm -lhbmacro -lhbcommon -lrddntx
-lrddcdx -lrddfpt -lhbsix -lhbhsx -lhbusrrdd -lhbmainstd -lgtcgi -lgtpca
-lgtstd -lgtwin -lgtwvt -lgtgui -Wl,--end-group -luser32 -lgdi32 -lwsock32
-lwinspool -lcomctl32 -lcomdlg32 -lole32 -loleaut32 -luuid -lmpr -lws2_32
-lmapi32
c:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot
find -lhbmainstd
collect2: ld returned 1 exit status
make[3]: *** [hbmake.exe] Error 1
make[3]: Leaving directory `/harbour/utils/hbmake/w32/mingw32'
make[2]: *** [descend] Error 2
make[2]: Leaving directory `/harbour/utils/hbmake'
make[1]: *** [install] Error 2
How can I solve that?
Many thank´s
{}s
Joel Bernardes___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Printer list
'sh make_gnu.sh install'
This works here with 4.1.2, but should also with 3.4.5.
But I am using Windows XP + Harbour (SVN) + MinGW, and this, ('sh
make_gnu.sh install' ), is for Linux.
What would it be for WinXP?
It is for XP, just try. 'sh' is part of msys.
[ Despite some drawbacks (you have to use forward
slash dir seps and no drive name in your HB_*_INSTALL
and HB_INC_* macros), this method looks much more
solid (and even quicker) than command.com forced
version. It also works without additional environment
hacks. ]
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] abour EJECT in CLASS TREPORT
Hi Ciro, IF lPrinter // To the printer ::lFormFeeds := .T. ELSE ::lFormFeeds := .F. ENDIF in other words if I send the report to a file the EJECTS are not triggered. and if I normally send first to a file and later copy this file to print port, then my report will not have EJECTS. I not agree with this point. it's not clipper compatible. It is compatible with C5.2e and also C5.3b. If you can create a small example to show the difference, of course we should fix it though, maybe there's indeed a problem elsewhere. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Bug: :__enumKey context is lost for codeblocks
Other method is declaring temporary local variables for enumerators and forbid using normal MEMVAR/STAATIC/LOCAL variables so the code will look like: proc p( aCountry ) for each aI in aCountry // aI is temporary local variable // allocated automatically by compiler ? aI next return I think it's better to have it declared manually. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-05 03:01 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Przemyslaw Czerpak-2 wrote: > > 2008-11-05 03:01 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > .. > * harbour/contrib/gtwvg/gtwvg.c > * cover LWA_ALPHA usage by #if ( _WIN32_WINNT >= 0x0500 ) > to keep at least compile time compatibility with older systems > > I think is it should be as #if ( _WIN32_WINNT >= 0x0500 ) SetWindowLong( pWVT->hWnd, GWL_EXSTYLE, GetWindowLong( pWVT->hWnd, GWL_EXSTYLE ) | WS_EX_LAYERED ); pWVT->pfnLayered( pWVT->hWnd, RGB( 255,255,255 ), hb_itemGetNI( pInfo->pNewVal2 ), /*LWA_COLORKEY|*/ LWA_ALPHA ); #endif because we can see in winuser.h #if(_WIN32_WINNT >= 0x0500) #define WS_EX_LAYERED 0x0008 #ifdef BR, Petr -- View this message in context: http://www.nabble.com/2008-11-05-03%3A01-UTC%2B0100-Przemyslaw-Czerpak-%28druzus-at-priv.onet.pl%29-tp20335131p20427623.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Printer list
Szakáts Viktor escribió:
Hi Guillermo,
I have this version of Harbor:
--
C:\HarbourMinGW\bin>harbour
Harbour 1.0.1dev Intl. (Rev. 9229)
Copyright (c) 1999-2008, http://www.harbour-project.org/
--
and here is not hbwin, What is equivalent to hbwin in this version?
It was called hbw32 lib in <= 1.0.1.
Thanks Viktor, Solved!!!, add LIB "libwinspool.a".
--
D:\harbour>make_gnu
c:\mingw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe:
cannot find -lhbmainstd
Well, I've built a version from the current SVN and I get these messages:
Difficult to tell. I'd recommend starting with a
clean Harbour source tree, and to try with this command
after putting msys, then mingw bin dirs in your PATH:
'sh make_gnu.sh install'
This works here with 4.1.2, but should also with 3.4.5.
But I am using Windows XP + Harbour (SVN) + MinGW, and this, ('sh
make_gnu.sh install' ), is for Linux.
What would it be for WinXP?
TIA
Best Regards
GVS
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] DBFCDX + HB_CDX_DBGCODE_EXT
Hello Przemek, Creating database with cdx index on field with binary data, then appending records seems successful. Then recompiling dbfcdx1.c with HB_CDX_DBGCODE_EXT defined, program ends with message: inserting, iSize=29, childs[i]->iFree=30 iKeys=102, iMaxReq=3 Unrecoverable error 9201: hb_cdxPageGetChild: index corrupted. Called from DBGOTOP(0) Is there bug covered or only some inaccuracy in debugging code and can be ignored? Test sample is quite simple, but data appended over thousand records and unable to reduce. Best regards, Saulius ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] abour EJECT in CLASS TREPORT
HI all: I found a little thing that I don't undesrtand. in TREPORT.prg I found this IF lPrinter // To the printer ::lFormFeeds := .T. ELSE ::lFormFeeds := .F. ENDIF in other words if I send the report to a file the EJECTS are not triggered. and if I normally send first to a file and later copy this file to print port, then my report will not have EJECTS. I not agree with this point. it's not clipper compatible. best regards Ciro -- http://sistemascvc.tripod.com (la casa del clip2win y nodosimp / the no2imp and clip2win home ) http://www.oohg.org ( Object Oriented Harbour GUI, more simple, more powerfull ) ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Printer list
Hi Guillermo, I have this version of Harbor: -- C:\HarbourMinGW\bin>harbour Harbour 1.0.1dev Intl. (Rev. 9229) Copyright (c) 1999-2008, http://www.harbour-project.org/ -- and here is not hbwin, What is equivalent to hbwin in this version? It was called hbw32 lib in <= 1.0.1. Well, I've built a version from the current SVN and I get these messages: -- D:\harbour>make_gnu c:\mingw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin \ld.exe: cannot find -lhbmainstd Difficult to tell. I'd recommend starting with a clean Harbour source tree, and to try with this command after putting msys, then mingw bin dirs in your PATH: 'sh make_gnu.sh install' This works here with 4.1.2, but should also with 3.4.5. When compiling my PRG, which has only this: -- function main () aPrn: GETPRINTERS = () wait RETURN NIL -- I get these messages: -- Proyecto: tst_CT, Entorno: H_SVN_MinGW: [1]:Harbour.Exe tst_Prn.prg /m /w0 /es2 /a /b /iC: \HRBSVN~1\Include /oObj\tst_Prn.c Harbour 1.1.0dev (Rev. 9894) Copyright (c) 1999-2008, http://www.harbour-project.org/ Compiling 'tst_Prn.prg'... Lines 99, Functions/Procedures 2 Generating C source output to 'Obj\tst_Prn.c'... Done. [1]:gcc.Exe -IC:\HRBSVN~1\Include -mno-cygwin -Wall -c tst_Prn.c - otst_Prn.o [1]:gcc.Exe -otst_CT.Exe -Wall -mno-cygwin -mconsole tst_CT.gcl You'll need to add Windows winspool lib to your liblist in order to use these functions in hbwin lib. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb* scripts and dylibs path under Mac OS X
On Mon, Nov 10, 2008 at 2:38 PM, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote:
> change -install_name parameter to:
>${CCPREFIX}libtool -dynamic -install_name "${BASE}${SLIB_EXT}" \
>
> Check if everything works correctly. If yes then please commit it.
Thanks it was it :)
Since today Mac OS X is a first class citizen in our company.
Many thanks to all.
best regards,
Lorenzo
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Bug: :__enumKey context is lost for codeblocks
On Mon, 10 Nov 2008, Mindaugas Kavaliauskas wrote:
Hi Mindaugas,
> I'm just trying to made my understand about an answer to two questions:
> 1) is it good that enumerators are detached to references to iterated items
> (or is it better to remain it enumerators in the codeblocks)?
If we left them as enumerator they will be updated by farther iterations
and it will not be possible to detach given item.
> 2) can it remain an enumerator in codeblocks? Can we implement it
> technically? Or this is not possible because of current enumerators
> implementation or some other side effects.
We do not have such functionality now but it can be implemented.
We will have to add support for reference counter to enumerators
and unblock their copping but it's possible. The question is if
we want to have such functionality.
> PROC main()
> LOCAL aCountry, aI, aJ, nI
>
>aCountry := {"LTU", "ZWE"}
>aJ := {}
>FOR nI := 1 TO LEN(aCountry)
> aI := aCountry[nI]
> AADD(aJ, {|| aI})
>NEXT
>FOR nI := 1 TO LEN(aCountry)
> ? EVAL(aJ[nI])
>NEXT
> RETURN
> But in this sample aI is not detached to current aI value, and sample
> prints:
> ZWE
> ZWE
> How can I easy understand/remember the difference between this behavior and
> enumerators behavior?
Just like now you have to remember that:
FOR EACH aI IN aCountry
aI := NIL
NEXT
will set NIL to all aCountry items. FOR and FOR EACH are different
things. In FOR EACH iterator is reference to item. When this reference
is detached it's not longer updated by next iterations. For me it's
correct behavior.
The only one problem I see here is the fact that comp;iler does
not generate compile time warning for the code you send. It should.
It's caused by side effect of simple codeblock implementation.
When expressions are created compiler does not know that they are
part of codeblock which is not allocated yet and finds aI as iterator
in parent function. For extended codeblocks and simple aI:__enum*()
usage warning message is correctly generated. F.e.:
PROC main()
LOCAL aCountry, aI, bc
aCountry := {"LTU"=>"Lithuania", "ZWE"=>"Zimbabwe"}
FOR EACH aI in aCountry
QOUT(aI:__enumKey) // OK
EVAL({|| QOUT(aI:__enumKey), asd asd}) // RTE
bc:={||; return aI:__enumKey; } // WARNING
NEXT
QOUT(aI:__enumKey) // WARNING
RETURN
It should be fixed. To make it well we should change the method
of codeblock creating in compiler but it's to small problem for
me to invest time for it now. I'll make it in the future with some
other modifications but now I can simply add new variable to FUNCTION
structure to indicate that we are in simple codeblock context.
I'll commit this modification in a while.
Meanwhile you may think about expected behavior for other FOR EACH
related contexts. F.e. please also remember that after leaving FOR EACH
original enumerator value is restored, f.e.:
aI := 1234.567
FOR EACH aI IN aCountry
aI := NIL
NEXT
? aI // 1234.567
It's original behavior implemented by Ryszard we still keep.
If we begin to detach enumerators then after leaving FOR EACH
detached enumerators should also point to original value (1234.567
in above example).
Other method is declaring temporary local variables for enumerators
and forbid using normal MEMVAR/STAATIC/LOCAL variables so the code
will look like:
proc p( aCountry )
for each aI in aCountry // aI is temporary local variable
// allocated automatically by compiler
? aI
next
return
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Printer list
Szakáts Viktor escribió: Hi, Check GETPRINTERS() in hbwin.lib. Hi Viktor, ENV: WinXP+Harbour from SVN+MinGW I have this version of Harbor: -- C:\HarbourMinGW\bin>harbour Harbour 1.0.1dev Intl. (Rev. 9229) Copyright (c) 1999-2008, http://www.harbour-project.org/ -- and here is not hbwin, What is equivalent to hbwin in this version? Well, I've built a version from the current SVN and I get these messages: -- D:\harbour>make_gnu c:\mingw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lhbmainstd collect2: ld returned 1 exit status make[3]: *** [hbrun.exe] Error 1 make[2]: *** [descend] Error 2 c:\mingw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lhbmainstd collect2: ld returned 1 exit status make[3]: *** [hbtest.exe] Error 1 make[2]: *** [descend] Error 2 c:\mingw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lhbmainstd collect2: ld returned 1 exit status make[3]: *** [hbdoc.exe] Error 1 make[2]: *** [descend] Error 2 c:\mingw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lhbmainstd collect2: ld returned 1 exit status make[3]: *** [hbmake.exe] Error 1 make[2]: *** [descend] Error 2 make[1]: *** [first] Error 2 D:\harbour>c: -- What do these messages? Can I use the build? But if I generate in Harbour.exe and LIBS (including hbwin.a). When compiling my PRG, which has only this: -- function main () aPrn: GETPRINTERS = () wait RETURN NIL -- I get these messages: -- Proyecto: tst_CT, Entorno: H_SVN_MinGW: [1]:Harbour.Exe tst_Prn.prg /m /w0 /es2 /a /b /iC:\HRBSVN~1\Include /oObj\tst_Prn.c Harbour 1.1.0dev (Rev. 9894) Copyright (c) 1999-2008, http://www.harbour-project.org/ Compiling 'tst_Prn.prg'... Lines 99, Functions/Procedures 2 Generating C source output to 'Obj\tst_Prn.c'... Done. [1]:gcc.Exe -IC:\HRBSVN~1\Include -mno-cygwin -Wall -c tst_Prn.c -otst_Prn.o [1]:gcc.Exe -otst_CT.Exe -Wall -mno-cygwin -mconsole tst_CT.gcl C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0x10f): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0x171): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0x1e6): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0x1f8): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0x408): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0x485): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0x5c2): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0x61b): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0x813): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0x867): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0x880): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0x965): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0x9a2): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0x9bf): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0x9dc): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0xbf1): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0xc53): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0xd0c): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0xd41): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0xdbb): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0xf42): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0xfa4): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2.o):win_prn2.c:(.text+0x1058): undefined reference to [EMAIL PROTECTED]' C:\HrbSVNMinGW\Lib/libhbwin.a(win_prn2
Re: [Harbour] Bug: :__enumKey context is lost for codeblocks
Hi,
PROC main()
LOCAL aCountry, aI
aCountry := {"LTU"=>"Lithuania", "ZWE"=>"Zimbabwe"}
FOR EACH aI in aCountry
QOUT(aI:__enumKey) // OK
EVAL({|| QOUT(aI:__enumKey)}) // RTE
NEXT
RETURN
It's expected and correct behavior. Variables stored in codeblocks
are detached. During detaching enumerators becomes simple references
to iterated items which is not later changed.
I'm just trying to made my understand about an answer to two questions:
1) is it good that enumerators are detached to references to iterated
items (or is it better to remain it enumerators in the codeblocks)?
2) can it remain an enumerator in codeblocks? Can we implement it
technically? Or this is not possible because of current enumerators
implementation or some other side effects.
It allows to create code like:
proc main()
local aCountry, aBlocks, aI, aB
aCountry := {"LTU"=>"Lithuania", "ZWE"=>"Zimbabwe"}
aBlocks := array( len( aCountry ) )
FOR EACH aI, aB in aCountry, aBlocks
aB := {|x| iif( pcount()==0, aI, aI := x ) }
NEXT
? eval( aBlocks[ 1 ] )
? eval( aBlocks[ 1 ], "X" )
? eval( aBlocks[ 1 ] )
? eval( aBlocks[ 2 ] )
? eval( aBlocks[ 2 ], "Y" )
? eval( aBlocks[ 2 ] )
return
As you can see this code does not fail when codeblocks are
evaluated autside FOR EACH loop and in each codeblocks aI
referes to separated aCountry item which were valid when
codeblock was created.
PROC main()
LOCAL aCountry, aI, aJ, nI
aCountry := {"LTU", "ZWE"}
aJ := {}
FOR nI := 1 TO LEN(aCountry)
aI := aCountry[nI]
AADD(aJ, {|| aI})
NEXT
FOR nI := 1 TO LEN(aCountry)
? EVAL(aJ[nI])
NEXT
RETURN
But in this sample aI is not detached to current aI value, and sample
prints:
ZWE
ZWE
How can I easy understand/remember the difference between this behavior
and enumerators behavior?
Best regards,
Mindaugas
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-09 20:58 UTC+0100 Viktor Szakats (harbour.01syenar hu)
On Mon, 10 Nov 2008, [EMAIL PROTECTED] wrote: Hi Toninho, > Here is the results for Windows Vista 6.0.6000. Strange that DL-Alloc > wins pratically in all parts except in last part of memtst. Maybe is > possible do an optmization in this process? You can make some experiments with DEFAULT_GRANULARITY, f.e.: set C_USR=-DDEFAULT_GRANULARITY=0x10 there are also other settings like: set C_USR=-DDEFAULT_MMAP_THRESHOLD=0x10 You can use them together. Such switches are used to balance between memory usage and speed. Make some tests and chose optimal values for your application. > Why in memtst.prg we have > this warning: "Warning!!! some compilers may badly fail here" Try it with default BCC5.5 memory manager. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Bug: :__enumKey context is lost for codeblocks
On Mon, 10 Nov 2008, Mindaugas Kavaliauskas wrote:
Hi Mindaugas,
> PROC main()
> LOCAL aCountry, aI
>aCountry := {"LTU"=>"Lithuania", "ZWE"=>"Zimbabwe"}
>FOR EACH aI in aCountry
> QOUT(aI:__enumKey) // OK
> EVAL({|| QOUT(aI:__enumKey)}) // RTE
>NEXT
> RETURN
It's expected and correct behavior. Variables stored in codeblocks
are detached. During detaching enumerators becomes simple references
to iterated items which is not later changed.
It allows to create code like:
proc main()
local aCountry, aBlocks, aI, aB
aCountry := {"LTU"=>"Lithuania", "ZWE"=>"Zimbabwe"}
aBlocks := array( len( aCountry ) )
FOR EACH aI, aB in aCountry, aBlocks
aB := {|x| iif( pcount()==0, aI, aI := x ) }
NEXT
? eval( aBlocks[ 1 ] )
? eval( aBlocks[ 1 ], "X" )
? eval( aBlocks[ 1 ] )
? eval( aBlocks[ 2 ] )
? eval( aBlocks[ 2 ], "Y" )
? eval( aBlocks[ 2 ] )
return
As you can see this code does not fail when codeblocks are
evaluated autside FOR EACH loop and in each codeblocks aI
referes to separated aCountry item which were valid when
codeblock was created.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re: [Harbour] 2008-11-09 20:58 UTC+0100 Viktor Szakats (harbour.01syenar hu)
>Thanks Toninho. > >You could further help by sending speedtst and >memtst results for both DLALLOC and STDALLOC >builds, run on Vista and XP. Hi Viktor, thank you, but please, wait until tonight. In my home I have windows XP. I´ll collect all results and post here. Regards, Toninho. __ Faça ligações para outros computadores com o novo Yahoo! Messenger http://br.beta.messenger.yahoo.com/ ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re: [Harbour] 2008-11-09 20:58 UTC+0100 Viktor Szakats (harbour.01syenar hu)
>As a last resort we may want to disable DLALLOC
>for BCC >= 6.0 if this seems to be best from the
>results.
Hi Viktor,
Here is the results for Windows Vista 6.0.6000. Strange that DL-Alloc
wins pratically in all parts except in last part of memtst. Maybe is
possible do an optmization in this process? Why in memtst.prg we have
this warning: "Warning!!! some compilers may badly fail here"
memtst WITH DL
testing single large memory blocks allocation and freeing...
CPU time: 0.84 sec.
real time: 0.84 sec.
testing many large memory blocks allocation and freeing...
CPU time: 5.08 sec.
real time: 5.09 sec.
testing large memory block reallocation with intermediate
allocations...
Warning!!! some compilers may badly fail here 1000 2000
3000 4000 5000 6000 7000 8000 9000
1 11000 12000 13000 14000 15000 16000
17000 18000 19000 2 21000 22000 23000
24000 25000 26000 27000 28000 29000 3
31000 32000 33000 34000 35000 36000 37000
38000 39000 4 41000 42000 43000 44000
45000 46000 47000 48000 49000 5 51000
52000 53000 54000 55000 56000 57000 58000
59000 6 61000 62000 63000 64000 65000
66000 67000 68000 69000 7 71000 72000
73000 74000 75000 76000 77000 78000 79000
8 81000 82000 83000 84000 85000 86000
87000 88000 89000 9 91000 92000 93000
94000 95000 96000 97000 98000 9900010
CPU time: 5.27 sec.
real time: 5.30 sec.
memtst WITHOUT DL
testing single large memory blocks allocation and freeing...
CPU time: 0.86 sec.
real time: 0.86 sec.
testing many large memory blocks allocation and freeing...
CPU time: 8.36 sec.
real time: 8.36 sec.
testing large memory block reallocation with intermediate
allocations...
Warning!!! some compilers may badly fail here 1000 2000
3000 4000 5000 6000 7000 8000 9000
1 11000 12000 13000 14000 15000 16000
17000 18000 19000 2 21000 22000 23000
24000 25000 26000 27000 28000 29000 3
31000 32000 33000 34000 35000 36000 37000
38000 39000 4 41000 42000 43000 44000
45000 46000 47000 48000 49000 5 51000
52000 53000 54000 55000 56000 57000 58000
59000 6 61000 62000 63000 64000 65000
66000 67000 68000 69000 7 71000 72000
73000 74000 75000 76000 77000 78000 79000
8 81000 82000 83000 84000 85000 86000
87000 88000 89000 9 91000 92000 93000
94000 95000 96000 97000 98000 9900010
CPU time: 1.39 sec.
real time: 1.41 sec.
speedtst
11/10/08 13:15:19 Windows Vista 6.0.6000
Harbour 1.1.0dev (Rev. 9888) CodeGear C++ 6.1 (32-bit)
THREADS: 0
N_LOOPS: 100
...DLA ...WIN
[ T000: empty loop overhead ].0.09 ..0.09
=
[ T001: x := L_C ]0.13 ..0.13
[ T002: x := L_N ]0.14 ..0.14
[ T003: x := L_D ]0.13 ..0.11
[ T004: x := S_C ]0.13 ..0.13
[ T005: x := S_N ]0.22 ..0.14
[ T006: x := S_D ]0.13 ..0.11
[ T007: x := M_C ]0.14 ..0.13
[ T008: x := M_N ]0.11 ..0.27
[ T009: x := M_D ]0.11 ..0.13
[ T010: x := P_C ]0.13 ..0.14
[ T011: x := P_N ]0.14 ..0.11
[ T012: x := P_D ]0.22 ..0.13
[ T013: x := F_C ]0.48 ..0.69
[ T014: x := F_N ]0.41 ..0.64
[ T015: x := F_D ]0.19 ..0.27
[ T016: x := o:GenCode ]..0.39 ..0.36
[ T017: x := o[8] ]...0.25 ..0.44
[ T018: round( i / 1000, 2 ) ]0.45 ..0.50
[ T019: str( i / 1000 ) ].3.28 ..3.50
[ T020: val( s ) ]0.45 ..0.45
[ T021: val( a [ i % 16 + 1 ] ) ].1.31 ..1.33
[ T022: dtos( d - i % 1 ) ]...0.94 ..1.14
[ T023: eval( { || i % 16 } ) ]...0.63 ..0.98
[ T02
Re: [Harbour] Re: Harbour under OS/2 - OpenWatcom
On Mon, 10 Nov 2008, Maurilio Longo wrote: Hi Maurilio, > It seems you did focus on mouse code, I've never dealt with it, but I'd say it > has to do with openwatcom, because with GCC mttest*.* work ok. To be precise the problem is with any console input and it's inside pure OS2 API functions. It means that we probably using them in wrong way. It may works for GCC because it may use some wrappers which resolve the problem or hide it. I would be good to find what exactly it does because it's a risk that the problem will be exploited also in some GCC builds. First we should check keyboard input and disable mouse code. It should give some answers which probably will also help to resolve problem with mouse. We can easy disable mouse code for tests by removing: if( ch == 0 ) ch = HB_GTSELF_MOUSEREADKEY( pGT, iEventMask ); from hb_gt_os2_ReadKey(). Now when 2-nd thread calls: KbdCharIn( s_key, IO_NOWAIT, ( HKBD ) * s_hk ); it fails with internal error. In OW this call is directly translated by: #define KbdCharIn KBD16CHARIN inside bsesub.h. Why does it fail? Why we have s_hk which is only low memory block initialized to NULL? This code efectively works like: KbdCharIn( s_key, IO_NOWAIT, NULL ); so why we have s_hk variable if it does nothing? OS2 API contains KbdGetFocus() and KbdFreeFocus(). If we begin to use them to protect can it help us? You left this comment in gtos2.c: #if defined(HB_OS_OS2_GCC) /* 25/03/2000 - [EMAIL PROTECTED] OS/2 GCC hasn't got ToolKit headers available */ #include #else #include #ifndef KBDTRF_EXTENDED_CODE #define KBDTRF_EXTENDED_CODE 0x02 #endif #endif It suggests me that in GCC builds KbdCharIn() is not directly translated to KBD16CHARIN() but it's a wrapper function. Can you check its body and what it exactly does? If the problem is not solved by some external setting then the answer should be here. > If I'm not wrong, openwatcom development, at least for os/2, has been stopped. OS2 OW builds are still release. OW17a is the newest release. AFAIK incoming 1.8 will also be released for OS2. > Why are you trying to use it? It allows to locate GCC only code and clean it. It's C++ compiler so it allows to easy locate code which is not C++ compatible though here include G++ builds like in Linux should also be solution. It should allow to create cross binaries and I will want to add support for it. It should allow to make OS2 build test also for developers which do not have OS2 what should greatly help us when we have to touch code which is compiled conditionally only in OS2 builds. best regards and many thanks for you help. Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-09 20:58 UTC+0100 Viktor Szakats (harbour.01syenar hu)
Thanks Toninho. You could further help by sending speedtst and memtst results for both DLALLOC and STDALLOC builds, run on Vista and XP. As a last resort we may want to disable DLALLOC for BCC >= 6.0 if this seems to be best from the results. Brgds, Viktor On 2008.11.10., at 13:04, [EMAIL PROTECTED] wrote: Could you post the details of your Harbour build switches and C compiler type/version, Harbour revision? Did you do your tests in MT or ST mode? ---cut--- SET C_USR=-DHB_GUI -DHB_FM_STATISTICS_OFF -DHB_NO_PROFILER -DADS_LIB_VERSION=700 -DHB_HASH_MSG_ITEMS -DHB_FM_STD_ALLOC -DHB_NO_DEBUG ---cut--- ---cut bcc32.cfg--- -IE:\bcc55\include;E:\bcc55\include\dinkumware -LE:\bcc55\lib -O2 -d -5 -6 -a8 -WC -w-inl- ---cut bcc32.cfg--- Path is called bcc55, but I´m using bcc6.10. To compile test\memtst.prg I set: ---cut--- set HB_ARCHITECTURE=w32 set HB_COMPILER=bcc32 rem set HB_USER_LIBS=rddads.lib,ace32.li set HB_BIN_INSTALL=e:\harbour\bin\b32 set HB_LIB_INSTALL=e:\harbour\lib\b32 set HB_INC_INSTALL=e:\harbour\include COPY e:\bcc32.cfg e:\harbour\tests ---cut--- and call from tests dir: ..\bin\hbmk memtst Maybe also Vista version/SP level, CPU type and physical memory could also help. Windows Vista Ultimate, Intel Pentium 4 CPU 3.06 GHz, RAM 1Mb Experience from Vista users would also be great to hear. With the same environment and Windows XP I see no problem with dlalloc Best regards, Toninho. __ Faça ligações para outros computadores com o novo Yahoo! Messenger http://br.beta.messenger.yahoo.com/ ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-11-10 15:17 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
2008-11-10 15:17 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/hbcurl/common.mak * contrib/hbcurl/Makefile * contrib/hbcurl/hbcurl.c + contrib/hbcurl/hbcurlm.c + Some disabled (not mainstream) functions moved to a separate file. * contrib/hbwin/win_prn2.c * Minor fix in comment. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-09 14:29 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
Hi Przemek, I like the second one better, as it clears the ambiguity and even the requirement to use -n switch when someone defines MAIN(). So there would be one thing less to worry about. First choice however is more Clipper compatible, so IMO we should do it. Please remember that current support for startup function is a hack which works only with few C compilers and even for them does not work correctly in all cases and we had to add yet another hack: -n1 switch which disable it for DLLs because DLL functions where registered before normal functions and 1-st dll function was used as startup one. Now we have two different behaviors which may cause portability problems for Harbour code and this is probably even bigger problem then strict Clipper compatibility. Yes, I've even got such support question privately :( This problem cannot be resolved at compile time. To make it well we need linker wrapper which will extract first Harbour function from linked modules and mark it as startup one. I added such functionality to hb* scripts and this is the only one method which works in all conditions and does not dependent on the order of init code execution. Anyhow it works only for GCC. For backward compatibility with older Harbour code I gave main() higher priority then 1-st linked function but it can be removed. This feature exists for many years and works well. So far no one reported that it's a problem. I think it should be default for all platforms/C compilers. Okay with me. Any solution which closes platform, compiler, build-system differences is superior. It would be also nice to remove the hb* script hack if possible. [ Some developers seem to use _APPMAIN() as an entry point probably to achieve that. ] BTW If we want to keep -n1 then it should be changed to -n2 and simply -n1 should be the same as -n and -n0 should work like -n- to make it compatible with other switches. No, if possible let's please remove -n1 and keep only -n/-n-. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Bug: :__enumKey context is lost for codeblocks
Hi,
PROC main()
LOCAL aCountry, aI
aCountry := {"LTU"=>"Lithuania", "ZWE"=>"Zimbabwe"}
FOR EACH aI in aCountry
QOUT(aI:__enumKey) // OK
EVAL({|| QOUT(aI:__enumKey)}) // RTE
NEXT
RETURN
Best regards,
Mindaugas
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-09 14:29 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
On Sun, 09 Nov 2008, Szak�ts Viktor wrote: Hi Viktor, > I like the second one better, as it clears the ambiguity > and even the requirement to use -n switch when someone > defines MAIN(). So there would be one thing less to worry > about. First choice however is more Clipper compatible, > so IMO we should do it. Please remember that current support for startup function is a hack which works only with few C compilers and even for them does not work correctly in all cases and we had to add yet another hack: -n1 switch which disable it for DLLs because DLL functions where registered before normal functions and 1-st dll function was used as startup one. Now we have two different behaviors which may cause portability problems for Harbour code and this is probably even bigger problem then strict Clipper compatibility. This problem cannot be resolved at compile time. To make it well we need linker wrapper which will extract first Harbour function from linked modules and mark it as startup one. I added such functionality to hb* scripts and this is the only one method which works in all conditions and does not dependent on the order of init code execution. Anyhow it works only for GCC. For backward compatibility with older Harbour code I gave main() higher priority then 1-st linked function but it can be removed. This feature exists for many years and works well. So far no one reported that it's a problem. I think it should be default for all platforms/C compilers. BTW If we want to keep -n1 then it should be changed to -n2 and simply -n1 should be the same as -n and -n0 should work like -n- to make it compatible with other switches. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Harbour under OS/2 - OpenWatcom
David, Przemyslaw,
I'm sorry, I was not monitoring this list lately because of lack of spare
time, anyway, can I do to help?
It seems you did focus on mouse code, I've never dealt with it, but I'd say it
has to do with openwatcom, because with GCC mttest*.* work ok.
If I'm not wrong, openwatcom development, at least for os/2, has been stopped.
Why are you trying to use it?
Maurilio.
David Arturo Macias Corona wrote:
>>> is executed but screen is not refreshed with tracing labels on it
>>> I was catching and error DISAPPEAR applying in hb_gt_os2_ReadKey():
>>>/* KbdCharIn( s_key, IO_NOWAIT, ( HKBD ) * s_hk ); */
>>> As you said, fail reading keyboard input except thread 1 :-)
>
>>we will have to find why it happens. Maybe Maurilio can help.
>
> Maurilio, help !
>
>>> ... and screen/output is not updated ?
>
>>??? I do not understand. Do you want to say that only 1-st thread can
>>display data on the screen?
>
> 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
>
>>> if( kbhit() )
>>> ch = getch();
>
>>Probably kbhit() internally call KbdCharIn() and it's exactly
>>the same problem.
> Maybe
>
>>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 ); */
>
> and mttest02.exe results:
>
> 1. hb_gt_def_InkeyPollDo()
> 0. hb_gt_os2_ReadKey()
> 1. hb_gt_os2_ReadKey()
> 2. hb_gt_os2_ReadKey()
> 3. hb_gt_os2_ReadKey()
> 4. hb_gt_os2_ReadKey()
> 1. hb_gt_def_MouseReadKey()
> SYS1808:
> The process has stopped. The software diagnostic
> code (exception code) is 0001.
>
>
> Using replacement for HB_GTSELF_MOUSEISPRESENT( pGT ):
>
>printf("1. hb_gt_def_MouseReadKey()\r\n");fflush(stdout);
>/* if( HB_GTSELF_MOUSEISPRESENT( pGT ) ) */
>if( hb_gt_def_MouseIsPresent( pGT ) )
>
> and mttest02.exe results:
>
> 4. hb_gt_os2_ReadKey()
> 1. hb_gt_def_MouseReadKey()
> 10. hb_gt_def_MouseReadKey()
> SYS1808:
> The process has stopped. The software diagnostic
> code (exception code) is 0001.
>
>
> so error happen trying HB_GTSELF_MOUSEISPRESENT( pGT )
>
> Using
>printf("1. hb_gt_def_MouseReadKey()\r\n");fflush(stdout);
>if( HB_GTSELF_MOUSEISPRESENT( pGT ) )
>/* if( hb_gt_def_MouseIsPresent( pGT ) ) */
>
> and
>
> static BOOL hb_gt_os2_mouse_IsPresent( PHB_GT pGT )
> {
>printf("1. hb_gt_os2_mouse_IsPresent()\r\n");fflush(stdout);
>HB_SYMBOL_UNUSED( pGT );
>printf("2. hb_gt_os2_mouse_IsPresent()\r\n");fflush(stdout);
>return s_uMouHandle != 0;
> }
>
> and mttest02.exe results:
>
> 4. hb_gt_os2_ReadKey()
> 1. hb_gt_def_MouseReadKey()
> 1. hb_gt_os2_mouse_IsPresent()
> 2. hb_gt_os2_mouse_IsPresent()
> SYS1808:
> The process has stopped. The software diagnostic
> code (exception code) is 0001.
>
>
> so hb_gt_os2_mouse_IsPresent( ) is working fine
>
> Using in hb_gt_def_MouseReadKey( )
>
> /* if( iEventMask & INKEY_LDOWN && HB_GTSELF_MOUSEBUTTONPRESSED(
> pGT, 0, &iRow, &iCol ) ) */
> if( iEventMask & INKEY_LDOWN && hb_gt_def_MouseButtonPressed( pGT,
> 0, &iRow, &iCol ) )
>
> and mttest02.exe results:
>
> 1. hb_gt_os2_mouse_IsPresent()
> 2. hb_gt_os2_mouse_IsPresent()
> 8. hb_gt_def_MouseReadKey()
> SYS1808:
> The process has stopped. The software diagnostic
> code (exception code) is 0001.
>
>
> which belong to:
>
> printf("8. hb_gt_def_MouseReadKey()\r\n");fflush(stdout);
> HB_GTSELF_MOUSEGETPOS( pGT, &iRow, &iCol );
> printf("9. hb_gt_def_MouseReadKey()\r\n");fflush(stdout);
>
> and HB_GTSELF_MOUSEGETPOS() should be checked later and is pending
>
> Reusing:
> /* if( iEventMask & INKEY_LDOWN && hb_gt_def_MouseButtonPressed(
> pGT, 0, &iRow, &iCol ) ) */
> if( iEventMask & INKEY_LDOWN && HB_GTSELF_MOUSEBUTTONPRESSED( pGT,
> 0, &iRow, &iCol ) )
>
>
> and
>
>
> static BOOL hb_gt_os2_mouse_ButtonPressed( PHB_GT pGT, int iButton, int
> * piRow, int * piCol )
> {
>HB_SYMBOL_UNUSED( pGT );
>printf("1. hb_gt_os2_mouse_ButtonPressed()\r\n");fflush(stdout);
>hb_gt_os2_mouse_ReadMouseState();
>printf("2. hb_gt_os2_mouse_ButtonPressed()\r\n");fflush(stdout);
>
> and mttest02.exe results:
>
> 4. hb_gt_os2_ReadKey()
> 1. hb_gt_def_MouseReadKey()
> 1. hb_gt_os2_mouse_IsPresent()
> 2. hb_gt_os2_mouse_IsPresent()
> 1. hb_gt_os
[Harbour] 2008-11-10 14:41 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
2008-11-10 14:41 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbapi.h * harbour/source/common/hbstr.c + added hb_numToStr() * harbour/source/vm/estack.c * harbour/source/compiler/genc.c * harbour/source/compiler/gencc.c * use hb_numToStr() for integer number conversions * harbour/source/vm/dlmalloc.c * disable #pragma warning ... in MinGW builds. If some newer MinGW versions support it and it's useful then it can be enabled after checking MinGW version best regards Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb* scripts and dylibs path under Mac OS X
On Wed, 05 Nov 2008, Lorenzo Fiorini wrote:
Hi Lorenzo,
> I use standard gnu makefiles with hb* scripts but under Mac OS X I
> can't find the right way to shared executables.
> Everything gets built correctly using the same makefiles I use under
> Win and Lin but at runtime the executable looks for libmylib.0.dylib
> while my lib is libmylib.dylib.
> If I change it using install_name_tool I can get it working but it's
> not the best way.
> Could it be that we need sth different in the hb-mkslib for darwin?
> Any idea?
In hb-mkslib.sh we have:
FULLNAME="${BASE}.${VERSION}${SLIB_EXT}"
${CCPREFIX}libtool -dynamic -install_name "${BASE}.${MAJOR}${SLIB_EXT}" \
-compatibility_version ${MAJOR}.${MINOR} -current_version ${VERSION} \
-flat_namespace -undefined warning -multiply_defined suppress
-single_module \
-o "${DSTDIR}/${FULLNAME}" "$@" && \
ln -sf "${FULLNAME}" "${DSTDIR}${BASE}.${MAJOR}${SLIB_EXT}" && \
ln -sf "${FULLNAME}" "${DSTDIR}${BASE}${SLIB_EXT}"
change -install_name parameter to:
${CCPREFIX}libtool -dynamic -install_name "${BASE}${SLIB_EXT}" \
Check if everything works correctly. If yes then please commit it.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Mon, 10 Nov 2008, Lorenzo Fiorini wrote:
Hi Lorenzo,
> On Mon, Nov 10, 2008 at 12:29 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote:
> > Experienced hash users should say the final word.
> We use hashes extensively and the RTE is useful to avoid mispelled
> keys exactly like arrays gets RTE if accessed out of bounds.
> When it's expected we use:
> #xtranslate GETKEYORDEFAULT( , , ) => iif( hHasKey( ,
> ), hGet( , ), )
> or
> #xtranslate GETKEYOREMPTY( , ) => iif( hHasKey( , ),
> hGet( , ), "" )
To avoid confusion.
In practice we are talking about two functions where we can remove
RT errors: hb_hGet() and hb_hDel(). We do not want to touch RT errors
in direct hash access. Removing RT errors from hb_hDel() will make their
behavior similar to aDel() function which does not generate RT error
in code like aDel( {}, 2 ). With hb_hGet() it's a problem with returning
value when key does not exists because hash can hold any values.
So we can leave it as is and reduce the problem to:
hb_hDel( {=>}, "key" )
Should it generate RT error or not.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Harbour under OS/2 - OpenWatcom
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
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Mon, Nov 10, 2008 at 12:29 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote: > Experienced hash users should say the final word. We use hashes extensively and the RTE is useful to avoid mispelled keys exactly like arrays gets RTE if accessed out of bounds. When it's expected we use: #xtranslate GETKEYORDEFAULT( , , ) => iif( hHasKey( , ), hGet( , ), ) or #xtranslate GETKEYOREMPTY( , ) => iif( hHasKey( , ), hGet( , ), "" ) best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Przemek, Probably some RT errors from function call should be eliminated for flexible usage. I never though about this problem so far and when I was adding hashes to harbour I simply replicated most of RT errors which exists in xHarbour. What I've suspected. You've just accepted autoadd in assign because you have quite nice example of these feature used for i18n translation tables and so far you haven't created any code which can benefit from autoadd in access and you still think about hash items like like about some type of static storage. This feature is usable when hash is used as backed to collect some results. F.e. I want to collect information about quantity of articles sold: Thanks for these hashing examples. In this sense they are basically a small in-memory database table with a unique key. Nice! does not exists in the hash array. F.e. In the 1-st report above I may want to group some type of articles together and rest present individually. With this feature it's enough to change the line with: hReport[ FIELD->ARTICLE ] += FIELD->QUANTITY to: hReport[ hGroups[ FIELD->ARTICLE ] ] += FIELD->QUANTITY but I can also use: hReport[ hb_hKey( hGroups, FIELD->ARTICLE ) ] += FIELD->QUANTITY Instead of adding new attribute to hashes. This is a bit mind bending at first, but I get the idea :) More elegant / compact than using arrays, for sure. It cannot because NIL is also valid hash item value so it will not be usable in all cases. But of course it does not mean that we cannot remove RT error from hb_hGet() and document it as expected behavior. If someone prefers functions call instead of faster h[key] then probably he has some special reasons for this. One of such reason can be missing RT error. Experienced hash users should say the final word. [ As a non-experienced one, I'd vote to drop similar RTEs from functions. ] xhb compatibility is not a concern BTW, because it uses different function names anyway. Because you asked to translate most of them. At the beginning this implementation was using xHarbour compatible API. Anyhow I do not think we have to be strictly compatible with RTE in such functions. It was not a complaint. Renaming has a nice side effect that Harbour functionality is easy to detach from any xhb heritage (meaning we're not restricted by xhb). If we happen to bend any hash functions too far, we can just add the old version to xhb.lib with the fully compliant functionality and without any extra mapping tricks. xhb users should decide what counts as "too far", and they'll most probably let us know. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re: [Harbour] 2008-11-09 20:58 UTC+0100 Viktor Szakats (harbour.01syenar hu)
>Could you post the details of your Harbour build >switches and C compiler type/version, Harbour revision? >Did you do your tests in MT or ST mode? ---cut--- SET C_USR=-DHB_GUI -DHB_FM_STATISTICS_OFF -DHB_NO_PROFILER -DADS_LIB_VERSION=700 -DHB_HASH_MSG_ITEMS -DHB_FM_STD_ALLOC -DHB_NO_DEBUG ---cut--- ---cut bcc32.cfg--- -IE:\bcc55\include;E:\bcc55\include\dinkumware -LE:\bcc55\lib -O2 -d -5 -6 -a8 -WC -w-inl- ---cut bcc32.cfg--- Path is called bcc55, but I´m using bcc6.10. To compile test\memtst.prg I set: ---cut--- set HB_ARCHITECTURE=w32 set HB_COMPILER=bcc32 rem set HB_USER_LIBS=rddads.lib,ace32.li set HB_BIN_INSTALL=e:\harbour\bin\b32 set HB_LIB_INSTALL=e:\harbour\lib\b32 set HB_INC_INSTALL=e:\harbour\include COPY e:\bcc32.cfg e:\harbour\tests ---cut--- and call from tests dir: ..\bin\hbmk memtst >Maybe also Vista version/SP level, CPU type and >physical memory could also help. Windows Vista Ultimate, Intel Pentium 4 CPU 3.06 GHz, RAM 1Mb >Experience from Vista users would also be great to >hear. With the same environment and Windows XP I see no problem with dlalloc Best regards, Toninho. __ Faça ligações para outros computadores com o novo Yahoo! Messenger http://br.beta.messenger.yahoo.com/ ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Printer list
Hi, Check GETPRINTERS() in hbwin.lib. Brgds, Viktor On 2008.11.10., at 4:09, Guillermo Varona Silupú wrote: Hi Is there any role that I return the printer list (names and ports they use)? and the default printer I use: WinXP SP3 + Harbour + MinGW Best Regards. GVS ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-11-09 20:58 UTC+0100 Viktor Szakats (harbour.01syenar hu)
Hi Toninho,
Could you post the details of your Harbour build
switches and C compiler type/version, Harbour revision?
Did you do your tests in MT or ST mode?
Maybe also Vista version/SP level, CPU type and
physical memory could also help.
Experience from Vista users would also be great to
hear.
Brgds,
Viktor
On 2008.11.10., at 12:03, [EMAIL PROTECTED] wrote:
In windows vista my tests display bad results if we use DL_ALLOC,
Can you tell some more about this? What does
"bad results" mean? It'd be important to know about
such problems before we settle with our default.
Hi Viktor, sorry for delay. I don´t have windows vista in my home, so
I was waiting to do another test in my office.
I did two posts here in the past, about this because I thought this
issue important.
In Windows Vista, my application doesn´t run smooth with dlalloc, it
pauses with a short delay in some circunstancies.
To reproduce this problem, run tests\memtst.prg. In last test with
standard bcc memory manager memtst run smooth and fast, but with
dlalloc it pause in each test.
---cut---
a := {}
for i := 1 to N_LOOPS
aadd( a, {} )
if i%1000 == 0
?? i
endif
next
---cut---
With windowsXP both MM works fine.
Regards,
Toninho.
__
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Harbour under OS/2 - OpenWatcom
I found in documentation included in OW a sample for multithreading
Entirely page is below
Przemek, can you check page ?
They talk about DosEnterCritSec() and DosExitCritSec() to prevent
collisions between threads
I tested using
wcl386 -bt=os2 -bm -l=os2v2 mthread
and results are:
Initial thread id = 1
Hi from thread 5
Hi from thread 4
Hi from thread 3
Hi from thread 2
There are this info in doc too
There is a limit to the number of threads an application can create
under 16-bit OS/2. The default limit is 32. This limit can be adjusted
by statically initializing the unsigned global variable __MaxThreads.
Under 32-bit OS/2, there is no limit to the number of threads an
application can create. However, due to the way in which multiple
threads are supported in the Open Watcom libraries, there is a small
performance penalty once the number of threads exceeds the default limit
of 32 (this number includes the initial thread). If you are creating
more than 32 threads and wish to avoid this performance penalty, you can
redefine the threshold value of 32. You can statically initialize the
global variable __MaxThreads.
By adding the following line to your multi-threaded application, the new
threshold value will be set to 48.
unsigned __MaxThreads = { 48 };
David Macias
Let us create a simple multi-threaded application. The source code for
this example can be found in \watcom\samples\os2.
#include
#include
#include
#define INCL_DOS
#include
static volatile intNumThreads;
static volatile intHoldThreads;
#define NUM_THREADS 5
#define STACK_SIZE 32768
static void a_thread( void *arglist )
/***/
{
while( HoldThreads ) {
DosSleep( 1 );
}
printf( "Hi from thread %d\n", *_threadid );
DosEnterCritSec();
--NumThreads;
DosExitCritSec();
_endthread();
}
int main( void )
/**/
{
int i;
printf( "Initial thread id = %d\n", *_threadid );
NumThreads = 0;
HoldThreads = 1;
/* initial thread counts as 1 */
for( i = 2; i <= NUM_THREADS; ++i ) {
if( _beginthread( a_thread, NULL, STACK_SIZE, NULL ) == -1
)
{
printf( "creation of thread %d failed\n", i );
} else {
++NumThreads;
}
}
HoldThreads = 0;
while( NumThreads != 0 ) {
DosSleep( 1 );
}
return( 0 );
}
Note:
1.In the function a_thread, DosEnterCritSec and DosExitCritSec are
called when we modify the variable NumThreads. This ensures that the
action of extracting the value of NumThreads from memory, incrementing
the value, and storing the new result into memory, occurs without
interruption. If these functions were not called, it would be possible
for two threads to extract the value of NumThreads from memory before an
update occurred.
Let us assume that the file mthread.c contains the above example.
Before compiling the file, make sure that the WATCOM environment
variable is set to the directory in which you installed Open Watcom
C/C++. Also, the INCLUDE environment variable must include the
\watcom\h\os2 and \watcom\h directories ("\WATCOM" is the directory in
which Open Watcom C/C++ was installed).
We can now compile and link the application by issuing the following
command.
[C:\]wcl386 -bt=os2 -bm -l=os2v2 mthread
The "bm" option must be specified since we are creating a multi-threaded
application. If your multi-threaded application contains more than one
module, each module must be compiled using the "bm" switch.
The "l" option specifies the target system for which the application is
to be linked. The system name os2v2 is defined in the file wlsystem.lnk
which is located in the "BINW" subdirectory of the directory in which
you installed Open Watcom C/C++.
The multi-threaded application is now ready to be run.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re: [Harbour] 2008-11-09 20:58 UTC+0100 Viktor Szakats (harbour.01syenar hu)
>> In windows vista my tests display bad results if we use DL_ALLOC,
>
>Can you tell some more about this? What does
>"bad results" mean? It'd be important to know about
>such problems before we settle with our default.
Hi Viktor, sorry for delay. I don´t have windows vista in my home, so
I was waiting to do another test in my office.
I did two posts here in the past, about this because I thought this
issue important.
In Windows Vista, my application doesn´t run smooth with dlalloc, it
pauses with a short delay in some circunstancies.
To reproduce this problem, run tests\memtst.prg. In last test with
standard bcc memory manager memtst run smooth and fast, but with
dlalloc it pause in each test.
---cut---
a := {}
for i := 1 to N_LOOPS
aadd( a, {} )
if i%1000 == 0
?? i
endif
next
---cut---
With windowsXP both MM works fine.
Regards,
Toninho.
__
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Harbour under OS/2 - OpenWatcom
[Przemek]
> ../../thread.c(1240): Error! E029: col(60) symbol '_gettid' has not
been declared
>
> _gettid() is GCC local function.
> I do not see function which returns directly thread ID in OS2 API.
> Probably it can be extracted from TIB structure returned by
> DosGetInfoBlocks(). I cannot find simpler method. Maurilio can you help?
>
[Maurilio]
> I've not tested this code, but something like this should give you
the thread id.
> unsigned long _gettid()
> {
>PTIB ptib = NULL;
>APIRET rc;
>
>rc = DosGetInfoBlocks(&ptib, NULL);
>
>return ptib->tib_ptib2->tib2_ultid;
> }
> Hope this help.
[Przemek]
>Yes, thanks. I hoped that maybe there is simpler version then using
>DosGetInfoBlocks() but we can also use this. Thank you very much.
Przemek, Maurilio:
I do not know if it is what you are looking for
I found in different places of documentation included in OW
-
The macro _threadid can be used to determine the current thread
identifier.
-
The _threadid macro can be used to determine the current thread
identifier. It is defined as follows.
int *__threadid(void);
#define _threadid (__threadid())
The header file stddef.h contains the definition of the _threadid macro.
-
_threadid
Prototype in .
This variable/function may be used to obtain the id of the current
thread which is an int. In the 32-bit libraries, _threadid is a
function that returns a pointer to an int. In the 16-bit libraries,
_threadid is a far pointer to an int. Note that the value stored where
_threadid points does not necessarily change when a thread context
switch occurs (so do not make a copy of the pointer ... it may change).
To obtain the current thread identifier, simply code:
int tid = *_threadid;
-
So I tried in source\vm\thread.c
---
#if defined( HB_OS_OS2 )
#include< David was here !
ULONG _hb_gettid( void )
{
ULONG tid = 0;
PTIB ptib = NULL;
printf( "_hb_gettid()\r\n", tid ); fflush(stdout);
/* < David was here !
if( DosGetInfoBlocks( &ptib, NULL ) == NO_ERROR )
{
if( ! ptib )
{ printf( "ptib is NULL\r\n" ); fflush(stdout); }
else if( !ptib->tib_ptib2 )
{ printf( "ptib->tib_ptib2 is NULL\r\n" ); fflush(stdout); }
else
tid = ptib->tib_ptib2->tib2_ultid;
}
*/
tid = *_threadid; < David was here !
printf( "TID=%lu\r\n", tid ); fflush(stdout);
return tid;
}
#endif
---
and mttest02.exe result with values TID=1, 2
---
[...]
_hb_gettid()
TID=1
1. hb_threadMutexLock()
_hb_gettid()
TID=2
[...]
---
So if _threadid is useful giving same value as GCC _gettid(), then
_hb_gettid() can be discarded and use in harbour\include\hbthread.h:
---
//discard
extern ULONG _hb_gettid( void );
# if defined( __GNUC__ )
# define HB_THREAD_SELF()( ( TID ) _gettid() )
# else
// case for OpenWatcom
// Use something like
#include< David was here !
tid = *_threadid; < David was here !
int vs ULONG ?
In the 32-bit libraries, _threadid is a function that returns a pointer
to an int
# else
//discard
# define HB_THREAD_SELF()( ( TID ) _hb_gettid() )
# endif
---
And in this case ( thread ID ) what is happening/using in Windows
OpenWatcom ? It can be used in OS/2 Watcom ?
David Macias
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Problem with TOleAuto class
Hi Przemek,
I already tryed that.
oReport:Set("RECORDSELECTIONFORMULA" , '{FFAC.CODJOU} = "VEN"' )
is also working...
in win_ole.c
I checked the result of
OleGetID( pDisp, hb_itemGetSymbol( hb_stackBaseItem() )->szName, &DispID,
&bSetFirst )
Wich succeded and correctly set bSetFirst to True.
It is only the assignation wich failed ...
OleSetProperty( pDisp, DispID, &DispParams )
Regards,
JF
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Przemyslaw
Czerpak
Envoyé : lundi 10 novembre 2008 1:12
À : Harbour Project Main Developer List.
Objet : Re: [Harbour] Problem with TOleAuto class
On Sun, 09 Nov 2008, J. Lefebvre wrote:
Hi,
> I have a strange problem with the TOleAuto Class from contrib/hbwin
> I can create an ole automation object without any problem,
> I can Get a propertie, using the automatic Getproperty routing method (by
> onerror method), so this one is working fine
> cFormula := oReport:RecordSelectionFormula
> But doing this one does not work :
> oReport:RecordSelectionFormula := '{FFAC.CODJOU} = "VEN"'
> (Error 25926100/3 DISP_E_MEMBERNOTFOUND: _RECORDSELECTIONFORMULA)
> Whilst this one is working :
> oReport:Set("RecordSelectionFormula" , '{FFAC.CODJOU} = "VEN"' )
> I checked win_ole.c sources, comparing HB_FUNC( TOLEAUTO_ONERROR ) and
> HB_FUNC( TOLEAUTO_SET )and I did no see any reason for those error.
> Any Idea ?
Messages are in upper case and maybe this is the source of problem.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-11-10 09:50 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
2008-11-10 09:50 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * include/hbmath.h ! Fixed Pelles C 5.00 not having an 'inf' (HUGE_VAL) symbol when in -Tarm-coff (~WinCE) mode. Pelles C bug (?). ; NOTE: Now core fully compiles in WinCE mode. So we have a new port. ; TOFIX: (this is a complete list of all Pelles C WinCE problems) [except hbmysql errors] --- WARNINGS POLINK: warning: Multiple '.rdata' sections found with different flags (0x4040 and 0xc040). POLINK: warning: Multiple '.rdata' sections found with different flags (0x4040 and 0xc040). ../../ctnet.c(119): warning #2027: Missing prototype for 'WNetGetLastError'. ../../ctnet.c(167): warning #2027: Missing prototype for 'WNetCancelConnection'. ../../ctnet.c(208): warning #2027: Missing prototype for 'WNetAddConnection'. ../../ctnet.c(210): warning #2027: Missing prototype for 'WNetAddConnection'. ../../ctnet.c(251): warning #2027: Missing prototype for 'WNetGetProviderName'. ../../ctnet.c(271): warning #2027: Missing prototype for 'WNetGetProviderName'. ../../disk.c(127): warning #2027: Missing prototype for 'GetDriveType'. ../../disk.c(244): warning #2027: Missing prototype for 'SetVolumeLabel'. ../../disk.c(270): warning #2027: Missing prototype for 'GetVolumeInformation'. ../../disk.c(307): warning #2027: Missing prototype for 'GetVolumeInformation'. ../../disk.c(337): warning #2027: Missing prototype for 'GetFullPathName'. ../../winapi.c(194): warning #2027: Missing prototype for 'InsertMenuItem'. ../../winapi.c(219): warning #2027: Missing prototype for 'SetMenu'. ../../getenvrn.c(177): warning #2027: Missing prototype for 'GetEnvironmentStrings'. ../../getenvrn.c(246): warning #2027: Missing prototype for 'FreeEnvironmentStrings'. contrib\hbsqlit3\sqlite3\sqlite3.c(9936): warning #2027: Missing prototype for 'localtime'. ../../tpwin32.c(75): warning #2027: Missing prototype for 'BuildCommDCB'. ../../wincorec.c(164): warning #2027: Missing prototype for 'CreateMDIWindow'. ../../fi_winfu.c(97): warning #2027: Missing prototype for 'CreateDIBitmap'. ../../fi_winfu.c(147): warning #2027: Missing prototype for 'GetDIBits'. ../../sqlbase.c(509): warning #2130: Result of unsigned comparison is constant. --- ERRORS contrib\gtwvg\gtwvg.h(78): fatal error #1035: Can't find include file . ../../ctnet.c(119): warning #2027: Missing prototype for 'WNetGetLastError'. ../../disk.c(129): error #2048: Undeclared identifier 'DRIVE_RAMDISK'. ../../disk.c(129): error #2045: Case label must be a constant integer expression. ../../disk.c(132): error #2048: Undeclared identifier 'DRIVE_REMOVABLE'. ../../disk.c(132): error #2045: Case label must be a constant integer expression. ../../disk.c(135): error #2048: Undeclared identifier 'DRIVE_FIXED'. ../../disk.c(135): error #2045: Case label must be a constant integer expression. ../../disk.c(138): error #2048: Undeclared identifier 'DRIVE_CDROM'. ../../disk.c(138): error #2045: Case label must be a constant integer expression. ../../disk.c(141): error #2048: Undeclared identifier 'DRIVE_REMOTE'. ../../disk.c(141): error #2045: Case label must be a constant integer expression. ../../winapi.c(70): error #2048: Undeclared identifier 'CS_OWNDC'. ../../winapi.c(75): error #2048: Undeclared identifier 'IDI_APPLICATION'. ../../winapi.c(75): error #2140: Type error in argument 2 to 'LoadIconW'; found 'int', expected 'const wchar_t *'. ../../winapi.c(181): error #2048: Undeclared identifier 'MFS_DISABLED'. ../../getenvrn.c(177): error #2168: Operands of = have incompatible types 'wchar_t *' and 'int'. ../../odbc.c(94): fatal error #1035: Can't find include file . contrib\hbsqlit3\sqlite3\sqlite3.c(9936): error #2168: Operands of = have incompatible types '(incomplete) struct tm *' and 'int'. contrib\hbsqlit3\sqlite3\sqlite3.c(9937): error #2152: Unknown field 'tm_year' of '(incomplete) struct tm'. contrib\hbsqlit3\sqlite3\sqlite3.c(9938): error #2152: Unknown field 'tm_mon' of '(incomplete) struct tm'. contrib\hbsqlit3\sqlite3\sqlite3.c(9939): error #2152: Unknown field 'tm_mday' of '(incomplete) struct tm'. contrib\hbsqlit3\sqlite3\sqlite3.c(9940): error #2152: Unknown field 'tm_hour' of '(incomplete) struct tm'. contrib\hbsqlit3\sqlite3\sqlite3.c(9941): error #2152: Unknown field 'tm_min' of '(incomplete) struct tm'. contrib\hbsqlit3\sqlite3\sqlite3.c(9942): error #2152: Unknown field 'tm_sec' of '(incomplete) struct tm'. contrib\hbsqlit3\sqlite3\sqlite3.c(22136): error #2120: Redeclaration of 'localtime' previously declared at contrib\hbsqlit3\sqlite3\sqlite3.c(9936): found '(incomplete) struct tm * __cdecl function(const un
