[Harbour] Index compatible bug?
The following sample prints 102 (in Clipper also):
FUNCTION MAIN()
SET DELETED ON
DBCREATE( BUGTEST, { { CODICE, N, 3, 0 } } )
USE BUGTEST
APPEND BLANK
REPLACE FIELD - codice WITH 101
DELETE
APPEND BLANK
REPLACE FIELD - codice WITH 101
APPEND BLANK
REPLACE FIELD - codice WITH 102
INDEX ON FIELD - codice TO BUGTEST UNIQUE
GO TOP
WHILE !EOF()
? FIELD - codice
SKIP
ENDDO
CLOSE
INKEY( 0 )
RETURN NIL
I wonder if it should print 101 and 102.
EMG
--
EMAG Software Homepage: http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: http://www.emagsoftware.it/tbosg
The EMG Music page: http://www.emagsoftware.it/emgmusic
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Wich is the official harbour's user group?
Hi Rathinagiri.Viktor,Roberto (and everybody) Will harbour and hmg share an harbour corner to made good assistance to either final user? http://www.hmgforum.com/ Which is the idea of Rathinagiri HMG Forum site owner and admin ? How is possible have identity of harbour on harbour corner? is possible use a wiki on www.hmgforum? Can harbour and minigui share experience about documentation ? (hbdoc+hmgdoc) Can HMG/Roberto lopez include last version from cvs so we have a final version error free? HMG have a large userbase As ready to use situation i suggest the ready to use Viktor's version at http://www.syenar.hu/harbour/ 2009/10/5 Viktor Szakáts harbour...@syenar.hu: Hi Roberto, Thanks for the explanation, it certainly makes some gray issues clear. [ Still not all though, as there exists another package called MiniGUI Extended, which actually ships with Harbour 2.0.0b2, I'm not sure how's that related, and maybe some of my comments belong to this project. Sorry about this. This one is also called HMG and also MiniGUI so for me it's difficult to know which I'm looking at to this very day. But I'm trying :) ] It's really your project and your decision, but IMO it'd be a big step if you'd use a vanilla Harbour build (without customization). This way it'd be easier to swap components and general Harbour support could be given for both bundled and standalone Harbour distros without first identifying which build is in question. Moreover, general Harbour support could be given at any forums without being concerned about where this build comes from. Same goes for MiniGUI: Support could be given even here or other official or unofficial Harbour forums. For Harboor MiniGUI Extended I think the difference is tget*.prg, for normal Harbour MiniGUI I couldn't find information, about the nature of build customization. I still have plans to make the plugin concept even stronger. In Python, Perl, Ruby, this issue is solved beautifully and no one has to pack the base system with extra libs. One important component of this effort is hbmk2. Brgds, Viktor On 2009 Oct 5, at 18:56, Roberto Lopez wrote: Massimo Belgrano wrote: Please Roberto lopez when you see this messages post your right reply Will harbour and hmg share an harbour corner to made assistance to either final user? At first, regarding the name: When I've created the library, It was only a simple experiment about Harbour-C interface, so, I've not care about the name so much :) I've picked MiniGUI because the library featured only a minimal functionality/GUI object set, so, it appeared to be a good choice. Some time later, I've realized that a Linux product existed with the same name, so I've decided to add 'Harbour' to the name. From that time, the library was called 'Harbour MiniGUI'. So, avoiding the name conflict and also made clear my compiler preferece. There was another problem to solve, I had LOTS of support requests regarding issues about Harbour and C compiler installation/compatibility. Then I've decided to package all needed things ready to use with zero configuration (this was possible with the great help of Lorenzo Fiorini on MingW compatibility issues). From the first 'ready to use' distribution (MiniGUI library + MingW + Harbour) I've decided to use an alternate name: HMG. Of course, it stands for *H*arbour *M*ini *G*ui (indeed, Harbour MiniGUI is a not good one name at all :) ) Regarding the HMG Forum, Viktor is rigth about that the Harbour version bundled with HMG is a customized version. Moreover, the customization is minimal (contrib library names are not changed). Moreover, there is certainly a lack of 'official' Harbour support to users. Across years I've received tons of bugs reports about Harbour, that I can't handle because lack of time or knowledge (mostly about rdd/database issues). Harbour official users lists is usually inactive, then, some users come here (not the right place, of course). HMG Forum site owner and admin is Rathinagiri (a long time HMG user and contributor) so, he is the right person to ask about this. From my part (I've not followed the complete thread about this) there is no problem to add a specific area on the forum to give support to Harbour compiler specific issues, but, of course, we will need the collaboration of some of the Harbour 'masters' to succeed. From about one year ago, HMG includes Harbour 1.01 and MingW 3.4.5, so most questions will surely related to that combo (I'm waiting for Harbour 2.0 final to replace 1.01 and MingW with 4.x). Regards, Roberto. ___ 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 -- Massimo Belgrano
Re: [Harbour] win64 results
high level drawing (seemingly window related) problem. I'll try to make tests with 32-bit UNICODE to check what exactly enables this. AFAIK Windows does not use 32-bit UNICODE values and support only U16. What is the exact problem? Sorry I was talking about Win32 UNICODE build. Just tested MSVC 2008 x86 now default UNICODE build and I'm having the same display problems in GTWIN as in x64. As it turns out, it's not related to UNICODE build though. The console app was starting up with default screen dimensions which is 80x300, and apparently this messes it up. I'll have to investigate further how can any screen dimension mess up such things as windows handling. [ and now Windows doesn't seem to allow me to reset the value to original defaults, well, time to go anyway. ] Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF bug tracker#2873146: Lang ES850c not fully compatible with clipper
After some checks: 1) The file is source/codepage/cpes850c.c (and not source/lang/...). 2) Current SVN version is besically the same version as originally added to the repository. 3) I can't find in the dev list any remarks regarding its validity since the day it was added. NOTE: I'm not a user of this Spanish codepage and have no idea how it is implemented in Clipper. I'm just the guy who forward bug reports from SF to this list. Chen. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Index compatible bug?
On Tue, 06 Oct 2009, Enrico Maria Giordano wrote:
The following sample prints 102 (in Clipper also):
FUNCTION MAIN()
SET DELETED ON
DBCREATE( BUGTEST, { { CODICE, N, 3, 0 } } )
USE BUGTEST
APPEND BLANK
REPLACE FIELD - codice WITH 101
DELETE
APPEND BLANK
REPLACE FIELD - codice WITH 101
APPEND BLANK
REPLACE FIELD - codice WITH 102
INDEX ON FIELD - codice TO BUGTEST UNIQUE
GO TOP
WHILE !EOF()
? FIELD - codice
SKIP
ENDDO
CLOSE
INKEY( 0 )
RETURN NIL
I wonder if it should print 101 and 102.
The behavior is correct. Index contain record 1 with value 101 but
is filter by your SET DELETE ON filter. If you want to filter such
records when index is created then use USEFILTER clause in INDEX ON
command, i.e.:
INDEX ON FIELD - codice TO BUGTEST UNIQUE USEFILTER
In such case record 1 (101) will not be added to filter but
record 2 which has the same key.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Index compatible bug?
-Messaggio Originale- Da: Przemyslaw Czerpak dru...@acn.waw.pl A: Harbour Project Main Developer List. harbour@harbour-project.org Data invio: martedì 6 ottobre 2009 9.56 Oggetto: Re: [Harbour] Index compatible bug? The behavior is correct. Index contain record 1 with value 101 but is filter by your SET DELETE ON filter. If you want to filter such records when index is created then use USEFILTER clause in INDEX ON command, i.e.: INDEX ON FIELD - codice TO BUGTEST UNIQUE USEFILTER In such case record 1 (101) will not be added to filter but record 2 which has the same key. Thank you. EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF bug tracker#2873146: Lang ES850c not fully compatible with clipper
On Tue, 06 Oct 2009, Chen Kedem wrote:
Hi,
After some checks:
1) The file is source/codepage/cpes850c.c (and not source/lang/...).
2) Current SVN version is besically the same version as originally
added to the repository.
3) I can't find in the dev list any remarks regarding its validity since
the day it was added.
NOTE: I'm not a user of this Spanish codepage and have no idea how it is
implemented in Clipper. I'm just the guy who forward bug reports from SF to
this list.
Try the code below.
It generates characters strings which can be used to create CP definition
in Harbour. It's enough to compile this code using Clipper and then link
with given Clipper sort module (usually ntx*.obj) file and then execute.
If there is a problem with cpes850c.c then the upper and lower strings
will be different. If Spanish user can confirm it then we will update
cpes850c.c. Please only remember to attach information about exact version
of used sort modules. In some countries there were different sort modules
with the same CP name, i.e. distributed with CA-Clipper and with SIx3
library.
best regards,
Przemek
/*
* cpinfo.prg
*/
proc main()
local cLo, cUp, c, cl, cu, i, a
set alternate to cpinfo.txt additive
set alternate on
a := array( 256 )
for i := 1 to len( a )
a[ i ] := i
next
asort( a,,, { |x,y| chr( x ) + chr( 0 ) chr( y ) + chr( 0 ) } )
? date(), time(), os(), version()
? Character encoding:
? ===
cLo := cUp :=
for i := 1 to len( a )
c := chr( a[i] )
if isalpha( c )
cl := lower( c )
cu := upper( c )
cLo += cl
cUp += cu
if cl == cu
? upper + charval( cu ) + and lower + charval( cl ) + ;
equal
elseif !isalpha( cl )
? wrongly defined character + ;
charval( c ) + : + charinfo( c ) + ;
, lower + charval( cl ) + : + charinfo( cl )
elseif !isalpha( cu )
? wrongly defined character + ;
charval( c ) + : + charinfo( c ) + ;
, upper + charval( cu ) + : + charinfo( cu )
endif
elseif islower( c ) .or. isupper( c )
? wrongly defined character + ;
charval( c ) + : + charinfo( c )
endif
next
? 'upper: ' + cUp + ''
? 'loerr: ' + cLo + ''
? ===
?
return
static function charval( c )
return ' + c + ' ( + ltrim( str( asc( c ) ) ) + )
static function charinfo( c )
local cInfo
cInfo := ISALPHA- + iif( isalpha( c ), Y, N )
cInfo += , ISUPPER- + iif( isupper( c ), Y, N )
cInfo += , ISLOWER- + iif( islower( c ), Y, N )
return cInfo
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12654] trunk/harbour
Revision: 12654 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12654view=rev Author: druzus Date: 2009-10-06 09:16:56 + (Tue, 06 Oct 2009) Log Message: --- 2009-10-06 11:16 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) + harbour/tests/cpinfo.prg + added simple program to generate information for Harbour CP module definition. Compile it with Clipper and link with given national sorting module (usually ntx*.obj) and then execute to generate letters strings for given national sorting module. Then use this string to define Harbour CP module in source/codepage/ directory. Modified Paths: -- trunk/harbour/ChangeLog Added Paths: --- trunk/harbour/tests/cpinfo.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win64 results
On Tue, 06 Oct 2009, Szak�ts Viktor wrote: Just tested MSVC 2008 x86 now default UNICODE build and I'm having the same display problems in GTWIN as in x64. As it turns out, it's not related to UNICODE build though. The console app was starting up with default screen dimensions which is 80x300, and apparently this messes it up. I'll have to investigate further how can any screen dimension mess up such things as windows handling. [ and now Windows doesn't seem to allow me to reset the value to original defaults, well, time to go anyway. ] It's expected behavior. In Win2K and higher the size of console buffer is returned as window size. If you do not need such big area then simply change to size of console buffer in application preferences or use setMode() best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF bug tracker#2873146: Lang ES850c not fully compatible with clipper
On Tue, 06 Oct 2009, Przemyslaw Czerpak wrote: Hi, Try the code below. I've just committed a little bit extended version of this code to harbour/tests/cpinfo.prg. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[12648] trunk/harbour
Maurilio, Viktor, Przemek: 2009-10-05 14:45 UTC+0200 Maurilio Longo (maurilio.longo at libero.it) * config/os2/gcc.mk * removed for %i in ... hack for library creation in OS/2 gcc build. Work fine with gcc335-a.out (obviously, change was for a.out) I do not know what are pros and cons of for %i , but if this kind must be removed, then it apply to OMF type too Testing some changes in config\os2\gcc.mk work fine with gcc335-OMF and I suppose gcc4xx-OMF should work because is only make related By lack of technical knowledge on it I do not know if it is right or need correction, so adjustments are welcome Replace this section: - # NOTE: The empty line directly before 'endef' HAS TO exist! # It causes that every command will be separated by LF define lib_object @$(ECHO) $(ECHOQUOTE)ADDMOD $(file)$(ECHOQUOTE) __lib__.tmp endef ifeq ($(HB_COMPILER),gccomf) define create_library $(if $(wildcard $(subst /,$(DIRSEP),$(LIB_FILE))),@$(RM) $(subst /,$(DIRSEP),$(LIB_FILE)),) for %i in ( *$(OBJ_EXT) ) do $(AR) $(ARFLAGS) $(HB_USER_AFLAGS) -p128 r $(LIB_DIR)/$@ %i$(ECHOQUOTE) endef else # We have to use a script to overcome the AR limit of max 850 characters # in commmand line define create_library $(if $(wildcard $(subst /,$(DIRSEP),$(LIB_FILE))),@$(RM) $(subst /,$(DIRSEP),$(LIB_FILE)),) @$(ECHO) $(ECHOQUOTE)CREATE $(LIB_DIR)/$...@$(ECHOQUOTE) __lib__.tmp $(foreach file,$^,$(lib_object)) @$(ECHO) $(ECHOQUOTE)SAVE$(ECHOQUOTE) __lib__.tmp @$(ECHO) $(ECHOQUOTE)END$(ECHOQUOTE) __lib__.tmp $(AR) $(ARFLAGS) $(HB_USER_AFLAGS) -M __lib__.tmp endef endif - with this section: - ifeq ($(HB_COMPILER),gccomf) # NOTE: The empty line directly before 'endef' HAS TO exist! # It causes that every command will be separated by LF define lib_object $(AR) $(ARFLAGS) $(HB_USER_AFLAGS) -p128 r $(LIB_DIR)/$@ $(file)$(ECHOQUOTE) endef define create_library $(if $(wildcard $(subst /,$(DIRSEP),$(LIB_FILE))),@$(RM) $(subst /,$(DIRSEP),$(LIB_FILE)),) $(foreach file,$^,$(lib_object)) endef else # NOTE: The empty line directly before 'endef' HAS TO exist! # It causes that every command will be separated by LF define lib_object @$(ECHO) $(ECHOQUOTE)ADDMOD $(file)$(ECHOQUOTE) __lib__.tmp endef # We have to use a script to overcome the AR limit of max 850 characters # in commmand line define create_library $(if $(wildcard $(subst /,$(DIRSEP),$(LIB_FILE))),@$(RM) $(subst /,$(DIRSEP),$(LIB_FILE)),) @$(ECHO) $(ECHOQUOTE)CREATE $(LIB_DIR)/$...@$(ECHOQUOTE) __lib__.tmp $(foreach file,$^,$(lib_object)) @$(ECHO) $(ECHOQUOTE)SAVE$(ECHOQUOTE) __lib__.tmp @$(ECHO) $(ECHOQUOTE)END$(ECHOQUOTE) __lib__.tmp $(AR) $(ARFLAGS) $(HB_USER_AFLAGS) -M __lib__.tmp endef endif - David Macias ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RES: [Harbour] Harbour Wince GUI
Tks Viktor and Massimo Sami QT also runs on WinCE, so it should be possible to build hbqt and hbxbp for WinCE. Brgds, Viktor On 2009 Oct 5, at 16:32, Massimo Belgrano wrote: AKAIK The only free amd opensource gui for wince is the upcoming VIANEMO http://blog.viaopen.com/ Yon can use Gt , istead of gui, so you are able to run clipper application with little modification Commercial GUI ViaCoral at http://www.viaopen.com/ FiveWin for Pocket PC at http://www.fivetechsoft.com/english/ fwppc.html 2009/10/5 Sami Laham sami-si...@laham.com.br: Hello folks, I would like know what GUI can i use with WINCE for developer to mobile devices, someone use HWGUI to WINCE ? ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF bug tracker#2873146: Lang ES850c not fully compatible with clipper
On Tue, 06 Oct 2009, Chen Kedem wrote: Hi, I've just committed a little bit extended version of this code to harbour/tests/cpinfo.prg. The attached results were made with the program you posted in the list (going to check your new one soon). Tested with Clipper 5.2e once with NTXSPA.OBJ and once with MDXSPA.OBJ (I included the internal version string from these files) And Harbour Rev.12653 build with BCC5.5.1 with ES850C (the compatible) and ES850 (modern Spanish) So for sure ES850C in Harbour is not compatible with ntxspa.obj. Interesting is that mdx and ntx use different sorting. I haven't expected it. Maybe it's result of some historical decisions or simply bug. For me the ordering in MDXSPA does not look correctly but maybe in some cases accented characters should be sorted before unaccented ones. It's the question to Spanish user not for me. Anyhow I'll update cpinfo.prg code to show more precise information which should help in replicating exact Clipper behavior. If I find a while then I also try to add alternative method to define CP in Harbour so it will be possible to adopt Clipper's definitions as is and generate them automatically from cpinfo.prg. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12655] trunk/harbour
Revision: 12655 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12655view=rev Author: druzus Date: 2009-10-06 12:07:20 + (Tue, 06 Oct 2009) Log Message: --- 2009-10-06 14:07 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) + harbour/tests/cpinfo.prg * modified to show more precise information about code page definition Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/tests/cpinfo.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win64 results
On Tue, 06 Oct 2009, Szak�ts Viktor wrote: Just tested MSVC 2008 x86 now default UNICODE build and I'm having the same display problems in GTWIN as in x64. As it turns out, it's not related to UNICODE build though. The console app was starting up with default screen dimensions which is 80x300, and apparently this messes it up. I'll have to investigate further how can any screen dimension mess up such things as windows handling. [ and now Windows doesn't seem to allow me to reset the value to original defaults, well, time to go anyway. ] It's expected behavior. In Win2K and higher the size of console buffer is returned as window size. If you do not need such big area then simply change to size of console buffer in application preferences or use setMode() I know this. I need to clarify, by messed up I don't mean the scrollbars and whatnot when using such big buffer. Instead I mean that the displayed (by Harbour app) _screen content_ is wrong. It looks like as if (ctwin) windowing gets confused about current window, so it's painting to the wrong one and returning size of the wrong one. But I'll make some real tests later, could be my app code. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win64 results
On Tue, 06 Oct 2009, Szak�ts Viktor wrote: I know this. I need to clarify, by messed up I don't mean the scrollbars and whatnot when using such big buffer. Instead I mean that the displayed (by Harbour app) _screen content_ is wrong. It looks like as if (ctwin) windowing gets confused about current window, so it's painting to the wrong one and returning size of the wrong one. But I'll make some real tests later, could be my app code. It's possible that there is sth wrong in CTWIN though it should work correctly - at least I do not see any problems looking at the code. If you have some additional extensions then please check if you do not have some places which may cause coordinates casting to BYTE or which may calculate screen offset or index in screen buffer using [U]SHORT value. Try to reduce number of rows to 255 and check if it helps. Few years ago I made some tests with very large screen buffers in MS-Windows console and I've found some bugs in MS-Windows console code so it's possible that the problem is caused by exploiting them. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12656] trunk/harbour
Revision: 12656 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12656view=rev Author: druzus Date: 2009-10-06 14:46:46 + (Tue, 06 Oct 2009) Log Message: --- 2009-10-06 16:46 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/config/instsh.mk * harbour/bin/hb-func.sh * harbour/bin/postinst.sh + added support for HB_INST_PKGPREF which can be used as package temporary install directory * harbour/mpkg_tgz.sh ! use HB_INST_PKGPREF to allow creating install packages without special user rights and to protect against damaging original system installation during package building if sufficient user rights were guarantied Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/bin/hb-func.sh trunk/harbour/bin/postinst.sh trunk/harbour/config/instsh.mk trunk/harbour/mpkg_tgz.sh This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Wich is the official harbour's user group?
-Original Message- From: Roberto Lopez [mailto:rober...@gmail.com] Sent: Monday, October 05, 2009 6:56 PM To: Harbour Project Main Developer List. Subject: Re: [Harbour] Wich is the official harbour's user group? [...] From about one year ago, HMG includes Harbour 1.01 and MingW 3.4.5, so most questions will surely related to that combo (I'm waiting for Harbour 2.0 final to replace 1.01 and MingW with 4.x). Viktor, more developers with its products pending a stable version. F.e. OTC with Mediator. Regards, Marek Horodyski ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] UPPER error iwith some CP-s
Hi, I found a quite strange behavior in some CP settings necessary in my project. See the following sample: CODE proc main() set alternate to uperr.txt additive set alternate on REQUEST HB_CODEPAGE_TR857 HB_SETCODEPAGE( TR857 ) ? diag=diag, UPPER(diag=diag) ? diag, UPPER(diag) return ENDCODE generating the wrong output: diag=diag DAG=DAG diag DIAG Best regards, István Bisz ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12657] trunk/harbour
Revision: 12657 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12657view=rev Author: druzus Date: 2009-10-06 16:34:58 + (Tue, 06 Oct 2009) Log Message: --- 2009-10-06 18:34 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/harbour.spec ! fixed to build with postinst.prg executed by shared linked hbrun * harbour/bin/hb-func.sh * harbour/debian/rules * harbour/harbour.spec % use HB_INST_PKGPREF instead of _DEFAULT_*_DIR Please test DEB building in Debian, Ubuntu or in other DPKG based distro. It probably has the same problem with postinst.prg as all other builds. * harbour/debian/rules * harbour/harbour.spec * harbour/mpkg_tgz.sh * harbour/source/compiler/gencobj.c * updated harbour.cfg localization in *nix builds * harbour/utils/hbrun/Makefile ! restored support for default include directory in system wide builds Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/bin/hb-func.sh trunk/harbour/debian/rules trunk/harbour/harbour.spec trunk/harbour/mpkg_tgz.sh trunk/harbour/source/compiler/gencobj.c trunk/harbour/utils/hbrun/Makefile This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[12648] trunk/harbour
with this section: - ifeq ($(HB_COMPILER),gccomf) # NOTE: The empty line directly before 'endef' HAS TO exist! # It causes that every command will be separated by LF define lib_object $(AR) $(ARFLAGS) $(HB_USER_AFLAGS) -p128 r $(LIB_DIR)/$@ $(file)$(ECHOQUOTE) endef define create_library $(if $(wildcard $(subst /,$(DIRSEP),$(LIB_FILE))),@$(RM) $(subst /,$(DIRSEP),$(LIB_FILE)),) $(foreach file,$^,$(lib_object)) endef else # NOTE: The empty line directly before 'endef' HAS TO exist! # It causes that every command will be separated by LF define lib_object @$(ECHO) $(ECHOQUOTE)ADDMOD $(file)$(ECHOQUOTE) __lib__.tmp endef # We have to use a script to overcome the AR limit of max 850 characters # in commmand line define create_library $(if $(wildcard $(subst /,$(DIRSEP),$(LIB_FILE))),@$(RM) $(subst /,$(DIRSEP),$(LIB_FILE)),) @$(ECHO) $(ECHOQUOTE)CREATE $(LIB_DIR)/$...@$(ECHOQUOTE) __lib__.tmp $(foreach file,$^,$(lib_object)) @$(ECHO) $(ECHOQUOTE)SAVE$(ECHOQUOTE) __lib__.tmp @$(ECHO) $(ECHOQUOTE)END$(ECHOQUOTE) __lib__.tmp $(AR) $(ARFLAGS) $(HB_USER_AFLAGS) -M __lib__.tmp endef endif - Thanks David, I'll commit it. Please make sure to test it, as copying code from e-mail body is quite error prone due to required manual reformat. Any takers to remove OS/2 watcom hacks? Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12658] trunk/harbour
Revision: 12658 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12658view=rev Author: vszakats Date: 2009-10-06 16:58:20 + (Tue, 06 Oct 2009) Log Message: --- 2009-10-06 18:57 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * INSTALL - Deleted sudo from one pkg creation command. * config/global.mk + Added MSVS 10.0 compiler version autodetection. * config/os2/gcc.mk % Deleted OS/2 make bug workarounds from OMF specific code. Submitted by David Arturo Macias Corona. Please test/review. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL trunk/harbour/config/global.mk trunk/harbour/config/os2/gcc.mk This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] UPPER error iwith some CP-s
On Tue, 06 Oct 2009, Bisz István wrote: Hi, I found a quite strange behavior in some CP settings necessary in my project. See the following sample: CODE proc main() set alternate to uperr.txt additive set alternate on REQUEST HB_CODEPAGE_TR857 HB_SETCODEPAGE( TR857 ) ? diag=diag, UPPER(diag=diag) ? diag, UPPER(diag) return ENDCODE generating the wrong output: diag=diag DAG=DAG diag DIAG It's Clipper compatible behavior in UPPER() optimization. Clipper optimize UPPER( cConst ) at compile time if cConst contains only characters like [A-Za-z0-9 ] and as result if gives cUpperConst where characters like [a-z] are converted to [A-Z]. During compilation CP is unknown so only such strings are translated and only pure Latin letters. In Harbour Clipper behavior is fully replicated because some code which initialize static variables needs it, i.e.: static s := upper( diag ) Unfortunately it creates problems for Turkish CPs where upper(i) is not I but due to compile time optimization it's wrongly translated to I. In your example first string contains = character what disables compile time UPPER() optimization so it's correctly translated at runtime but the second string is fully optimized. The only one solution I can give you is not using UPPER() with string constant values containing Turkish strings. Maybe in the future I'll add new -k? switch to disable UPPER() optimization but I cannot make it in default builds due to compatibility with existing code. If it's critical for you now then you can disable UPPER() optimization in Harbour compiler code and recompile your custom Harbour version. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Wich is the official harbour's user group?
Viktor Szakáts wrote: ... [ Still not all though, as there exists another package called MiniGUI Extended, which actually ships with Harbour 2.0.0b2, There was only one project from 2002 to 2005 (the one I've started) from then, two forks emerged: HMG extended and OOHG (I'm only responsible for HMG). It's really your project and your decision, but IMO it'd be a big step if you'd use a vanilla Harbour build (without customization). This way it'd be easier to swap components and general Harbour support could be given for both bundled and standalone Harbour distros without first identifying which build is in question. Moreover, general Harbour support could be given at any forums without being concerned about where this build comes from. Same goes for MiniGUI: Support could be given even here or other official or unofficial Harbour forums. It's a good idea. The current HMG distribution uses Harbour 1.01 for MingW build downloaded from Sourceforge. I've removed 'binutils' not required by HMG and (of course) added libraries and other things, but this shoud be not create problems regarding Harbour compiler support. Moreover, I'll begin experimenting with Harbour 2.0 beta and publish a test HMG release ASAP. If something goes wrong, I'll seek for help here, prior to attempt a dirty hack, I promise :) So, hopefully, we will have full 'Harbour support compatible' HMG releases. Regards, Roberto ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Wich is the official harbour's user group?
Massimo Belgrano wrote: Hi Rathinagiri.Viktor,Roberto (and everybody) Will harbour and hmg share an harbour corner to made good assistance to either final user? http://www.hmgforum.com/ From my part (and Rathinagiri agrees) there is no problem at all. But as I've said, we will need help from Harbour experts to succeed. ... Can harbour and minigui share experience about documentation ? (hbdoc+hmgdoc) ... It could be done. And I guess that some kind of Wiki, could be great. Specially, using as base the current official Harbour docs. But (again) we will need LOTS of help of Harbour developers and users to succeed. Let mi think about it... Regards, Roberto. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] UPPER error iwith some CP-s
Hi Przemek, Unfortunately this i to İ (LATIN CAPITAL LETTER I WITH DOT ABOVE - 0x98 152 in CP857) upper conversion generates more problems, now in MEMOEDIT: Error BASE/1004 Message not found: HBMEMOED˜TOR:HBEDITOR Called from __ERRRT_SBASE(0) Called from HBMEMOED˜TOR:ERROR(0) Called from (b)HBOBJECT(0) Called from HBMEMOED˜TOR:MSGNOTFOUND(0) Called from HBMEMOED˜TOR:HBEDITOR(0) Called from HBMEMOED˜TOR:EDIT(0) Called from MEMOEDIT(0) The missed I in 'HBMEMOED˜TOR' is this İ ugly character. I don't know how to handle this. Thank you in advance, István -Original Message- From: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] On Behalf Of Przemyslaw Czerpak Sent: 2009. október 6. 18:59 To: Harbour Project Main Developer List. Subject: Re: [Harbour] UPPER error iwith some CP-s On Tue, 06 Oct 2009, Bisz István wrote: Hi, I found a quite strange behavior in some CP settings necessary in my project. See the following sample: CODE proc main() set alternate to uperr.txt additive set alternate on REQUEST HB_CODEPAGE_TR857 HB_SETCODEPAGE( TR857 ) ? diag=diag, UPPER(diag=diag) ? diag, UPPER(diag) return ENDCODE generating the wrong output: diag=diag D˜AG=D˜AG diag DIAG It's Clipper compatible behavior in UPPER() optimization. Clipper optimize UPPER( cConst ) at compile time if cConst contains only characters like [A-Za-z0-9 ] and as result if gives cUpperConst where characters like [a-z] are converted to [A-Z]. During compilation CP is unknown so only such strings are translated and only pure Latin letters. In Harbour Clipper behavior is fully replicated because some code which initialize static variables needs it, i.e.: static s := upper( diag ) Unfortunately it creates problems for Turkish CPs where upper(i) is not I but due to compile time optimization it's wrongly translated to I. In your example first string contains = character what disables compile time UPPER() optimization so it's correctly translated at runtime but the second string is fully optimized. The only one solution I can give you is not using UPPER() with string constant values containing Turkish strings. Maybe in the future I'll add new -k? switch to disable UPPER() optimization but I cannot make it in default builds due to compatibility with existing code. If it's critical for you now then you can disable UPPER() optimization in Harbour compiler code and recompile your custom Harbour version. 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
Re: [Harbour] Wich is the official harbour's user group?
Hi Roberto, [ Still not all though, as there exists another package called MiniGUI Extended, which actually ships with Harbour 2.0.0b2, There was only one project from 2002 to 2005 (the one I've started) from then, two forks emerged: HMG extended and OOHG (I'm only responsible for HMG). Okay, now I see the whole picture. It's really your project and your decision, but IMO it'd be a big step if you'd use a vanilla Harbour build (without customization). This way it'd be easier to swap components and general Harbour support could be given for both bundled and standalone Harbour distros without first identifying which build is in question. Moreover, general Harbour support could be given at any forums without being concerned about where this build comes from. Same goes for MiniGUI: Support could be given even here or other official or unofficial Harbour forums. It's a good idea. The current HMG distribution uses Harbour 1.01 for MingW build downloaded from Sourceforge. I've removed 'binutils' not required by HMG and (of course) added libraries and other things, but this shoud be not create problems regarding Harbour compiler support. Moreover, I'll begin experimenting with Harbour 2.0 beta and publish a test HMG release ASAP. Good news. mingw is actually included now starting with 2.0 beta releases. Please start with beta 3, as this is the closed to current state, even if it's not official release. If something goes wrong, I'll seek for help here, prior to attempt a dirty hack, I promise :) So, hopefully, we will have full 'Harbour support compatible' HMG releases. Great, feel free to tell us any problems you run into. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] UPPER error iwith some CP-s
On Tue, 06 Oct 2009, Bisz István wrote: Hi, Unfortunately this i to İ (LATIN CAPITAL LETTER I WITH DOT ABOVE - 0x98 152 in CP857) upper conversion generates more problems, now in MEMOEDIT: Error BASE/1004 Message not found: HBMEMOED˜TOR:HBEDITOR Called from __ERRRT_SBASE(0) Called from HBMEMOED˜TOR:ERROR(0) Called from (b)HBOBJECT(0) Called from HBMEMOED˜TOR:MSGNOTFOUND(0) Called from HBMEMOED˜TOR:HBEDITOR(0) Called from HBMEMOED˜TOR:EDIT(0) Called from MEMOEDIT(0) The missed I in 'HBMEMOED˜TOR' is this İ ugly character. I don't know how to handle this. In practice setting such CP causes that all symbols containing 'i' may not be properly converted if .prg code use UPPER(). In above case it's working and only class name looks ugly bad it should not cause bigger bad side effects as long as you do not want to make sth with such class name, i.e. use it in macro compiler. The above can be quite easy resolved by small modification in include/hbclass.ch. It's enough to change: HBClass():new( (ClassName) to: HBClass():new( Upper( (ClassName) ) and compile time optimization for UPPER resolves the problem so it's enough to recompile the Harbour code. Anyhow seems that it will be good to add new function i.e. HB_ASCIIUPPER() and use it instead of UPPER() in core library code in all places where we are operating on compiler symbols or other ASCII identifiers. [ Viktor I think we should make it. ] Please only remember that you also have to be careful writing your own code. BTW How are you leaving with such CPs? ;-) best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] UPPER error iwith some CP-s
The missed I in 'HBMEMOED˜TOR' is this İ ugly character. I don't know how to handle this. In practice setting such CP causes that all symbols containing 'i' may not be properly converted if .prg code use UPPER(). In above case it's working and only class name looks ugly bad it should not cause bigger bad side effects as long as you do not want to make sth with such class name, i.e. use it in macro compiler. The above can be quite easy resolved by small modification in include/hbclass.ch. It's enough to change: HBClass():new( (ClassName) to: HBClass():new( Upper( (ClassName) ) and compile time optimization for UPPER resolves the problem so it's enough to recompile the Harbour code. Anyhow seems that it will be good to add new function i.e. HB_ASCIIUPPER() and use it instead of UPPER() in core library code in all places where we are operating on compiler symbols or other ASCII identifiers. [ Viktor I think we should make it. ] I agree. I'd rather user hb_upperAscii() though, to keep names well aligned (i.e. it's a sub-type of upper()). Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] UPPER error iwith some CP-s
On Tue, 06 Oct 2009, Szak�ts Viktor wrote: I agree. I'd rather user hb_upperAscii() though, to keep names well aligned (i.e. it's a sub-type of upper()). Fine though if we plan to add also other ASCII oriented functions for LOWER, ISALPHA, ISUPPER, ISLOWER, ISDIGIT operations then IMO using hb_ascii*() prefix will be better to keep names aligned. Just like now we have set of hb_utf8*() functions: HB_UTF8CHR(), HB_UTF8LEN(), HB_UTF8LEFT(), HB_UTF8RIGHT(), HB_UTF8STUFF(), HB_UTF8SUBSTR(), HB_UTF8STRTRAN(), HB_UTF8PEEK(), HB_UTF8POKE(), HB_UTF8TOSTR() best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12659] trunk/harbour
Revision: 12659 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12659view=rev Author: druzus Date: 2009-10-06 19:14:36 + (Tue, 06 Oct 2009) Log Message: --- 2009-10-06 21:14 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/harbour-win-spec * harbour/harbour-wce-spec - commented out HB_BUILD_PARTS=compiler as workaround for using postinst.prg % use -undef:.ARCH. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/harbour-wce-spec trunk/harbour/harbour-win-spec This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] UPPER error iwith some CP-s
Okay, fine with me. Brds, Viktor On 2009 Oct 6, at 21:13, Przemyslaw Czerpak wrote: On Tue, 06 Oct 2009, Szak�ts Viktor wrote: I agree. I'd rather user hb_upperAscii() though, to keep names well aligned (i.e. it's a sub-type of upper()). Fine though if we plan to add also other ASCII oriented functions for LOWER, ISALPHA, ISUPPER, ISLOWER, ISDIGIT operations then IMO using hb_ascii*() prefix will be better to keep names aligned. Just like now we have set of hb_utf8*() functions: HB_UTF8CHR(), HB_UTF8LEN(), HB_UTF8LEFT(), HB_UTF8RIGHT(), HB_UTF8STUFF(), HB_UTF8SUBSTR(), HB_UTF8STRTRAN(), HB_UTF8PEEK(), HB_UTF8POKE(), HB_UTF8TOSTR() 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
Re: [Harbour] Wich is the official harbour's user group?
Viktor Szakáts wrote: Good news. mingw is actually included now starting with 2.0 beta releases. Please start with beta 3, as this is the closed to current state, even if it's not official release. Ok. Great, feel free to tell us any problems you run into. Thanks, I'll do. Regards, Roberto. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win64 results
Hi Przemek, On 2009 Oct 6, at 15:13, Przemyslaw Czerpak wrote: On Tue, 06 Oct 2009, Szak�ts Viktor wrote: I know this. I need to clarify, by messed up I don't mean the scrollbars and whatnot when using such big buffer. Instead I mean that the displayed (by Harbour app) _screen content_ is wrong. It looks like as if (ctwin) windowing gets confused about current window, so it's painting to the wrong one and returning size of the wrong one. But I'll make some real tests later, could be my app code. It's possible that there is sth wrong in CTWIN though it should work correctly - at least I do not see any problems looking at the code. If you have some additional extensions then please check if you do not have some places which may cause coordinates casting to BYTE or which may calculate screen offset or index in screen buffer using [U]SHORT value. Try to reduce number of rows to 255 and check if it helps. Few years ago I made some tests with very large screen buffers in MS-Windows console and I've found some bugs in MS-Windows console code so it's possible that the problem is caused by exploiting them. Some more results, this time using GTWVT, as it seems the problem isn't GTWIN specific, so: 1) SetMode( 80, 255 ) // works as expected 2) SetMode( 80, 256 ) // works with display artifact (will check it further to eliminate local cause) The artifact is slightly different in Win32 and Win64 mode. In Win32 only current window is messed up, while in Win64 mode some additional problems are visible, like mentioned wrapped menu on screen. 3) SetMode( 80, 257 ) // not accepted by GTWVT, resulting in default 80, 25 dimensions. Both in Win32 and Win64. (notice however that it would use such bigger resolutions if it is the system default, this may of course only happen with GTWIN) 4) SetMode( 250, 80 ) // will result in a no window situation, where the app works, but there is no visible screen. Experienced with GTWVT. Case 3) may be wrong, at least I see no reason why Harbour should limit dimensions this way. It's of course possible that this is the threshold value where window couldn't fit on screen anymore and 256 vs. 257 is just a coincidence. In case 2) the desktop (CTWIN) window creation will fail and return -1, and my app isn't ready to handle that, causing mentioned mess. Traces pointed to these lines in ctwin.c: #define HB_CTWIN_MAXROWS 255 #define HB_CTWIN_MAXCOLS 255 Which artificially limits max window size. Removing the size validation in window creation code fixes all artifacts experienced in 2). Shall I commit it? In case 3) it's again an artificial limit controlled by #define WVT_MAX_ROWS 256 #define WVT_MAX_COLS 256 Do we need this, or should we raise this limit? This leaves 4) on the TOFIX list. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12660] trunk/harbour
Revision: 12660 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12660view=rev Author: druzus Date: 2009-10-06 22:28:23 + (Tue, 06 Oct 2009) Log Message: --- 2009-10-07 00:27 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/source/rtl/Makefile + harbour/source/rtl/hbascii.c * harbour/include/hbextern.ch + added new .prg functions which operates on pure ASCII strings: hb_asciiUpper(), hb_asciiLower(), hb_asciiIsAlpha(), hb_asciiIsUpper(), hb_asciiIsLower(), hb_asciiIsDigit() * harbour/source/rtl/objfunc.prg * harbour/source/rtl/tget.prg * harbour/source/rtl/treport.prg * harbour/source/rtl/tpersist.prg * harbour/source/rtl/memoedit.prg * harbour/source/rtl/menuto.prg * harbour/source/rtl/tgetlist.prg * harbour/source/rtl/tclass.prg ! use hb_asciiUpper() instead of Upper() to convert identifiers and pictures Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/hbextern.ch trunk/harbour/source/rtl/Makefile trunk/harbour/source/rtl/memoedit.prg trunk/harbour/source/rtl/menuto.prg trunk/harbour/source/rtl/objfunc.prg trunk/harbour/source/rtl/tclass.prg trunk/harbour/source/rtl/tget.prg trunk/harbour/source/rtl/tgetlist.prg trunk/harbour/source/rtl/tpersist.prg trunk/harbour/source/rtl/treport.prg Added Paths: --- trunk/harbour/source/rtl/hbascii.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win64 results
On Wed, 07 Oct 2009, Szak�ts Viktor wrote: Some more results, this time using GTWVT, as it seems the problem isn't GTWIN specific, so: 1) SetMode( 80, 255 ) // works as expected 2) SetMode( 80, 256 ) // works with display artifact (will check it further to eliminate local cause) The artifact is slightly different in Win32 and Win64 mode. In Win32 only current window is messed up, while in Win64 mode some additional problems are visible, like mentioned wrapped menu on screen. 3) SetMode( 80, 257 ) // not accepted by GTWVT, resulting in default 80, 25 dimensions. Both in Win32 and Win64. (notice however that it would use such bigger resolutions if it is the system default, this may of course only happen with GTWIN) GTWVT is limited at compile time to: #define WVT_MAX_ROWS 256 #define WVT_MAX_COLS 256 It's historical limit in very old xHarbour code which can be removed from current code. 4) SetMode( 250, 80 ) // will result in a no window situation, where the app works, but there is no visible screen. Experienced with GTWVT. I guess it's side effect of code which tries to allocate font which fits given dimensions. The original code was working in different way. BTW There is no support for automatic scroll bars in GTWVT and I think it will be nice to add it. Case 3) may be wrong, at least I see no reason why Harbour should limit dimensions this way. It's of course possible that this is the threshold value where window couldn't fit on screen anymore and 256 vs. 257 is just a coincidence. This limit was taken arbitrary by Peter and it was the size of screen buffer in very old GTWVT implementation. When I was rewriting GT core code I removed this limit from GTWVT and I left only #define for backward compatibility. You can safely remove them but please only remember to add dynamically allocate in RESIZE() method TCHAR[cols] string and use in hb_gt_wvt_PaintText() function instes of text[]. BTW there is typo: 'text[ WVT_MAX_ROWS ]' instead of 'text[ WVT_MAX_COLS ]' though without bad side effects because both defines are equal. In case 2) the desktop (CTWIN) window creation will fail and return -1, and my app isn't ready to handle that, causing mentioned mess. Traces pointed to these lines in ctwin.c: #define HB_CTWIN_MAXROWS 255 #define HB_CTWIN_MAXCOLS 255 It's only for strict CT3 compatibility. Which artificially limits max window size. Removing the size validation in window creation code fixes all artifacts experienced in 2). Shall I commit it? The only bad side effect will be internal error (out of memory) if user tries to create very huge window. In case 3) it's again an artificial limit controlled by #define WVT_MAX_ROWS 256 #define WVT_MAX_COLS 256 Do we need this, or should we raise this limit? This can be eliminated. If we fix the code for automatic font resizing then limitation by screen dimensions should begin to work just like in old GTWVT code. We can introduce minimal font size (i.e. 4x2 or 6x3) to resolve the problem. This leaves 4) on the TOFIX list. You can disable the code for font resizing by: HB_GTINFO( HB_GTI_RESIZEMODE, HB_GTI_RESIZEMODE_ROWS ) and it should resolve the problem. I have no idea what is expected behavior for: SetMode( 250, 250 ) when HB_GTI_RESIZEMODE_FONT is set. We have few possible choices, i.e.: 1. chose default window dimensions: 25x80 2. resize rows and cols like in HB_GTI_RESIZEMODE_ROWS 3. refuse to create window (SETMODE()-FALSE). Users using HB_GTI_RESIZEMODE_FONT should chose sth what they prefer. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF bug tracker#2873146: Lang ES850c not fully compatible with clipper
I have aleatory corrupted indexes that include and UPPER, Remember Clipper documentation .- Note: Changing the collation sequence in an application with existing indexes will cause index corruption. You should rebuild all indexes before the application is used. ... By using the //INFO command line switch with your application, you can determine what National Language Drivers have been linked into your application. For example, C:\ MYAPP //INFO Different *versions* of National Language Drivers can not update the same index. If you need to update an existing index, IMO .- cpinfo.prg code to show more precise information which should help in replicating exact Clipper behavior. (thanks for this) to customize the/your Harbour codepage C file. -- Xavi Chen Kedem escribió: I forward this from the SF bug tracker http://sourceforge.net/tracker/?func=detailatid=100681aid=2873146group_id=681 Maurizio Faccio (maufacc) wrote: - I have aleatory corrupted indexes that include and UPPER, I've found that some accented letters are not converted identically in clipper and harbour 2.0beta1. Here I send you the results of a test program that I have run in clipper and harbour. Here are the ascii conversions of clipper an harbour, and their UPPER and lower caracters. - The original message contain a list of characters, but I'm almost sure my mail program is going to mess the output, so look at the link if you need that info. I don't have access to the repository now, so I don't know if current SVN gives better results. Chen. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] UPPER error iwith some CP-s
Hi!! Do you have to think about 'TransForm()' ? This is difficult function!! Fine though if we plan to add also other ASCII oriented functions for LOWER, ISALPHA, ISUPPER, ISLOWER, ISDIGIT operations then IMO using hb_ascii*() prefix will be better to keep names aligned. Just like now we have set of hb_utf8*() functions: HB_UTF8CHR(), HB_UTF8LEN(), HB_UTF8LEFT(), HB_UTF8RIGHT(), HB_UTF8STUFF(), HB_UTF8SUBSTR(), HB_UTF8STRTRAN(), HB_UTF8PEEK(), HB_UTF8POKE(), HB_UTF8TOSTR() ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour 2.0 changes...
Viktor: I'm trying to compile HMG code (working on Harbour 1.0) with 2.0 and I'm getting lot of errors on 'hb_storni' 'hb_stornl' and hb_parc. I've searched the changelog for changes on these functions, but I've not found any help on that there. The error message is 'too many arguments'. TIA. Regards, Roberto. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0 changes...
Roberto I can help you I write in private. best regards Ciro 2009/10/6 Roberto Lopez rober...@gmail.com: Viktor: I'm trying to compile HMG code (working on Harbour 1.0) with 2.0 and I'm getting lot of errors on 'hb_storni' 'hb_stornl' and hb_parc. I've searched the changelog for changes on these functions, but I've not found any help on that there. The error message is 'too many arguments'. TIA. Regards, Roberto. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- http://www.oohg.prg http://sistemascvc.tripod.com donaciones para CVC de ooHG https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=5369884 ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0 changes...
Ciro Vargas C escribió: Roberto I can help you I write in private. Ok. Regards, Roberto. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12661] trunk/harbour
Revision: 12661 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12661view=rev Author: vszakats Date: 2009-10-07 05:37:22 + (Wed, 07 Oct 2009) Log Message: --- 2009-10-07 07:36 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbct/ctwin.c + Added HB_C52_STRICT guard around artificial windows size limits. Please review me. HB_C52_STRICT macros should be renamed to HB_CLP_STRICT to reflect usage of recent years, where it's also used to cover 5.3 strictness f.e.. * source/rtl/gtwvt/gtwvt.c ! Minor formatting. ! Fixed to use WVT_MAX_COLS instead of WVT_MAX_ROWS in one place. * source/codepage/Makefile + source/codepage/cpeliso.c + source/codepage/cptriso.c + Added two new codepage modules. Patch submitted by Istvan Bisz. * include/hbextcdp.ch + Added above codepages to codepage list. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbct/ctwin.c trunk/harbour/include/hbextcdp.ch trunk/harbour/source/codepage/Makefile trunk/harbour/source/rtl/gtwvt/gtwvt.c Added Paths: --- trunk/harbour/source/codepage/cpeliso.c trunk/harbour/source/codepage/cptriso.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win64 results
Hi Przemek, with GTWIN) GTWVT is limited at compile time to: #define WVT_MAX_ROWS 256 #define WVT_MAX_COLS 256 It's historical limit in very old xHarbour code which can be removed from current code. 4) SetMode( 250, 80 ) // will result in a no window situation, where the app works, but there is no visible screen. Experienced with GTWVT. I guess it's side effect of code which tries to allocate font which fits given dimensions. The original code was working in different way. BTW There is no support for automatic scroll bars in GTWVT and I think it will be nice to add it. Indeed, especially for WinCE users, on desktop I expect it to be used rather rarely, although it may also be useful f.e. when connecting to a remote GT with higher resolutions. Case 3) may be wrong, at least I see no reason why Harbour should limit dimensions this way. It's of course possible that this is the threshold value where window couldn't fit on screen anymore and 256 vs. 257 is just a coincidence. This limit was taken arbitrary by Peter and it was the size of screen buffer in very old GTWVT implementation. When I was rewriting GT core code I removed this limit from GTWVT and I left only #define for backward compatibility. You can safely remove them but please only remember to add dynamically allocate in RESIZE() method TCHAR[cols] string and use in hb_gt_wvt_PaintText() function instes of text[]. BTW there is typo: 'text[ WVT_MAX_ROWS ]' instead of 'text[ WVT_MAX_COLS ]' though without bad side effects because both defines are equal. If possible, I'd like to ask to make this modification, as I'm almost sure my solution wouldn't be good enough. BTW, GTXWC also has the same artificial limit. In case 2) the desktop (CTWIN) window creation will fail and return -1, and my app isn't ready to handle that, causing mentioned mess. Traces pointed to these lines in ctwin.c: #define HB_CTWIN_MAXROWS 255 #define HB_CTWIN_MAXCOLS 255 It's only for strict CT3 compatibility. I've added a strict guard there. Which artificially limits max window size. Removing the size validation in window creation code fixes all artifacts experienced in 2). Shall I commit it? The only bad side effect will be internal error (out of memory) if user tries to create very huge window. Perhaps other guards could be added to avoid that, but otherwise this is expected behavior. In case 3) it's again an artificial limit controlled by #define WVT_MAX_ROWS 256 #define WVT_MAX_COLS 256 Do we need this, or should we raise this limit? This can be eliminated. If we fix the code for automatic font resizing then limitation by screen dimensions should begin to work just like in old GTWVT code. We can introduce minimal font size (i.e. 4x2 or 6x3) to resolve the problem. Such thing would be nice. This leaves 4) on the TOFIX list. You can disable the code for font resizing by: HB_GTINFO( HB_GTI_RESIZEMODE, HB_GTI_RESIZEMODE_ROWS ) and it should resolve the problem. I have no idea what is expected behavior for: SetMode( 250, 250 ) when HB_GTI_RESIZEMODE_FONT is set. We have few possible choices, i.e.: 1. chose default window dimensions: 25x80 2. resize rows and cols like in HB_GTI_RESIZEMODE_ROWS 3. refuse to create window (SETMODE()-FALSE). Users using HB_GTI_RESIZEMODE_FONT should chose sth what they prefer. I'd vote for 3. (and 1. as the second choice) Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
