>> Wich other harbour part need be rewritten from scratch?
>
> I can't think of any other.
I've found three:
- XML handling in xhb lib, but that rather needs a reimplementation
in core.
- .dll support in hbwin. (the x86 part)
- SORT command
( + ACHOICE() and MEMOEDIT() of course)
Brgds,
Vik
> Wich other harbour part need be rewritten from scratch?
I can't think of any other.
> rewriting will allow also a true and native GUI mode?
It has nothing to do with GUI mode. These are
Clipper functions, and if rewriting them, the only
one goal is to implement them as close as possible
to
Wich other harbour part need be rewritten from scratch?
rewriting will allow also a true and native GUI mode?
think how memoedit seem to windows user for select/copy/past operation
2010/2/6 Viktor Szakáts :
>> I am curious about this ACHOICE stuff. It sounds as though Przemek thought
>> it neede
In order to do a lot of the other Clipper implementations, did the Harbour
Project reverse engineer Clipper code, or was some source code donated from
the original Clipper company? In this instance, would you have to just take
an approximate guess as to how ACHOICE functions under any circumstance
> I am curious about this ACHOICE stuff. It sounds as though Przemek thought
> it needed to be rewritten from scratch. Is that a big project to do, or
> likely to be done? I'm starting to think I'd be a lot more useful to the
> Harbour Project if I was a good C programmer.
ACHOICE() (and als
I am curious about this ACHOICE stuff. It sounds as though Przemek thought
it needed to be rewritten from scratch. Is that a big project to do, or
likely to be done? I'm starting to think I'd be a lot more useful to the
Harbour Project if I was a good C programmer.
On Sat, Feb 6, 2010 at 7:30 A
Hi,
I didn't miss them, but what I reported look like new
errors after recent patches.
Just run ac_test.prg, press , then -> RTE.
It was okay in 2.0.0, but it's not okay in current trunk.
Brgds,
Viktor
On 2010 Feb 6, at 16:22, smu johnson wrote:
> Hi Viktor, see:
>
> http://lists.harbour-p
Hi Viktor, see:
http://lists.harbour-project.org/pipermail/harbour/2010-February/031590.html
http://lists.harbour-project.org/pipermail/harbour/2010-February/031661.html
In case you missed them.
On Sat, Feb 6, 2010 at 3:51 AM, Viktor Szakáts wrote:
> Hi All,
>
> In recent SVN, tests/ac_test.p
The same with
HPDF_Page_GetMiterLimit
Best regards,
Saulius
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Hi,
>> List:tar -tf
>> Extract: tar -xf
>> Create: tar -cf [filenames...]
>> Help:tar --help
>> wc: harbour-2.0.0-darwin.bin.tar.gz: open: No such file or directory
>> cat: harbour-2.0.0-darwin.bin.tar.gz: No such file or directory
>> ---
>
> You have non GNU tar which accepts --v
On Wed, 06 Jan 2010, Szak�ts Viktor wrote:
Hi,
> I got this while trying to create a 2.0.0 tgz for darwin (Snow Leopard):
> ---
> [...]
> ./bin/postinst.sh
> tar: Option --owner=root is not supported
> Usage:
> List:tar -tf
> Extract: tar -xf
> Create: tar -cf [filenames...]
> Hel
Hi Przemek,
> It means that you had to take above code from xHarbour.
> I've just check that above fix were committed to xHarbour CVS by Paul at:
> 2006-07-01 18:35 UTC-0500 Paul Tucker
Mea Culpa!
I understand that don't know much about history :(
Thank you for correcting me.
Best regards,
Sa
Przemysław Czerpak pisze:
The real problem is the fact that you didn't start new thread
but simply used "replay" option in your mail program so your
both messages still belongs to the same initial thread. The context
of subject is unimportant for mail programs which can follow threads.
Just look
Yes, you are right. Strange that no one reported it for such long time.
Not true. I found version of gtwin.c dated 2008.01.18 and there were lines:
...
/* Special case */
if ( usRows < _GetScreenHeight() && usCols > _GetScreenWidth() )
{
HB_GT_FUNC(gt_SetM
On Wed, 23 Dec 2009, Saulius Zrelskis wrote:
Hi,
> > Yes, you are right. Strange that no one reported it for such long time.
> Not true. I found version of gtwin.c dated 2008.01.18 and there were lines:
> ...
> /* Special case */
> if ( usRows < _GetScreenHeight() && usCols > _G
> Yes, you are right. Strange that no one reported it for such long time.
Not true. I found version of gtwin.c dated 2008.01.18 and there were lines:
...
/* Special case */
if ( usRows < _GetScreenHeight() && usCols > _GetScreenWidth() )
{
HB_GT_FUNC(gt_SetMode( us
On Tue, 22 Dec 2009, Jacek Potempa wrote:
Hi,
> (sorry for my previous post under invalid subject - please ignore)
The subject is not the problem.
The real problem is the fact that you didn't start new thread
but simply used "replay" option in your mail program so your
both messages still belong
Massimo,
The bug is not related to Cytrix or Terminal server.
Just try to execute the following PRG code directly under Windows console:
SetMode(25,80)
? "Initial console size:", maxrow()+1,"X", maxcol()+1
? "Changing to :", maxrow()+1+1, "X", maxcol()+1-1
wait
SetMode(maxrow()+2,maxcol(
Can you post a little sample to show the problem so i can try on
Terminal server & Citrix?
2009/12/22 Jacek Potempa :
> Hi,
>
> (sorry for my previous post under invalid subject - please ignore)
>
> Recently one of our customers reported bug in Terminal software. After
> tracing it down it seems t
On Mon, 07 Dec 2009, Pritpal Bedi wrote:
Hi
> > It may change in different HVM version so no one should create code
> > which depends on current behavior anyhow if you are interested what
> > happens now then return value is overwritten by last return value in
> > executed code (depending on cont
Hi
Przemysław Czerpak wrote:
>
> It may change in different HVM version so no one should create code
> which depends on current behavior anyhow if you are interested what
> happens now then return value is overwritten by last return value in
> executed code (depending on context it may cause so
On Mon, 07 Dec 2009, Pritpal Bedi wrote:
Hi,
> > I've just checked hbqt_slots.cpp and there are _many_
> > hb_vmRequestReenter() calls without hb_vmRequestRestore()
> > pairs.
> > I don't know the consequences, but it doesn't seem right.
> Matched.
> I also do not know its implications, Przemek
Hi
Viktor Szakáts wrote:
>
> I've just checked hbqt_slots.cpp and there are _many_
> hb_vmRequestReenter() calls without hb_vmRequestRestore()
> pairs.
>
> I don't know the consequences, but it doesn't seem right.
>
Matched.
I also do not know its implications, Przemek ?
Regards
Pritpal B
> Viktor Szakáts wrote:
>>
>> It's just a sort of hunch, since I don't have
>> test code and detailed theoretical proof for this,
>> but it looks like existing HBQT_QTPTR_FROM_GCPOINTER()
>> is a wrong concept and should not be used at all.
>>
>> It converts GC pointer to a simple one.
>>
>>
Hello Viktor
Viktor Szakáts wrote:
>
> It's just a sort of hunch, since I don't have
> test code and detailed theoretical proof for this,
> but it looks like existing HBQT_QTPTR_FROM_GCPOINTER()
> is a wrong concept and should not be used at all.
>
> It converts GC pointer to a simple one.
On Mon, 07 Dec 2009, Szak�ts Viktor wrote:
Hi,
> So, I'm afraid I'm confused. For sure I don't want to
> unblock it just for the sake of having it unlocked. But
> now I can't see why it cannot work as main CP, but can
> work as DB CP. I assume if it can be used in DB, sorting
> must be workin
>> Ok I see. Although this also means that I can't use
>> it as native CP in an application.
>> You seem to have suggested that any app may use UTF-8
>> even now. But maybe I misunderstood something. I understand
>> this needs UTF-8 sorting support (for ASORT(), <, > operators,
>> maybe else, p
On Mon, 07 Dec 2009, Szak�ts Viktor wrote:
Hi,
> Ok I see. Although this also means that I can't use
> it as native CP in an application.
> You seem to have suggested that any app may use UTF-8
> even now. But maybe I misunderstood something. I understand
> this needs UTF-8 sorting support (fo
Hi,
>> 'SET( _SET_CODEPAGE, "UTF8" )' does't work, it leaves CP in previous setting.
>
> 2009-09-11 20:37 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> + added pseduto codepage "UTF8" which can be used in trnaslations only
>
On Mon, 07 Dec 2009, Szak�ts Viktor wrote:
Hi,
> 'SET( _SET_CODEPAGE, "UTF8" )' does't work, it leaves CP in previous setting.
2009-09-11 20:37 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
+ added pseduto codepage "UTF8" which can be used in trnaslations only
Hi Przemek,
>> Please note I haven't tested this on C5.2e, so it may
>> be Clipper compatible behavior, but anyway I just noticed
>> it today in repository, and felt better to report it:
>> ---
>> #ifdef MACRO
>> ? 1
>> #else
>> ? 0
>> ---
>> Will not report any warning in Harbour. Probably it
On Sat, 28 Nov 2009, Szak�ts Viktor wrote:
Hi,
> Please note I haven't tested this on C5.2e, so it may
> be Clipper compatible behavior, but anyway I just noticed
> it today in repository, and felt better to report it:
> ---
> #ifdef MACRO
> ? 1
> #else
> ? 0
> ---
> Will not report any war
Viktor,
> Please note I haven't tested this on C5.2e, so it may
> be Clipper compatible behavior
Clipper 5.2e behave the same (no warning or error is given).
I think it will be a good practice to report it as an error
(Maybe guard current behavior with HB_CLP_STRICT).
Chen.
___
>> Upgrade to latest SVN and PSDK dir is added automatically
>> by the build process.
>
> I'm at the tip
> Harbour 2.0.0beta3 (Rev. 12877)
>
> I only set
> HB_COMPILER=bcc
> (since I have a couple others installed)
That's the reason. If you do this, the build system will
not be able to auto
I know that this list is perhaps not the correct one I hope you
will forgive me :-)
Francesco
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
>> I now added -L"...\psdk" and works
>
> Yes, this is the key.
>
> Upgrade to latest SVN and PSDK dir is added automatically
> by the build process.
I'm at the tip
Harbour 2.0.0beta3 (Rev. 12877)
I only set
HB_COMPILER=bcc
(since I have a couple others installed)
Francesco
_
On Sun, 15 Nov 2009, Przemysław Czerpak wrote:
[...]
And I forgot about the most important thing.
Welcome to the devel team :-)
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour
>> If it doesn't work for you pls post your env and error,
>
> Error:
> bcc32.exe -I. -I../../../../../include -q -tWM -w -w-sig- -Q -d -6
> -O2 -OS -Ov -Oi -Oc -onortl.obj -c ../../../nortl.
> c
> ../../../nortl.c:
> tlib.exe /P128 "..\..\..\..\..\lib\win\bcc\hbnortl.lib" -+nortl.obj
> TLIB 4
On Sun, 15 Nov 2009, francesco perillo wrote:
Hi,
> I'm only a bit puzzled about the fact that removing that libraries it
> compiles, links and works.
Amazing, do you know that I can compile and link my application
without xhb.lib and final binaries works.
Does it means that we should say th
Viktor, you are right as usual
On Sun, Nov 15, 2009 at 1:25 AM, Viktor Szakáts wrote:
>> I had to rem this line in config\win\global.mk to compile succesfully in bcc
>> 5.5
>> # SYSLIBS += kernel32 user32 ws2_32 advapi32 gdi32
>>
>> bcc has no kernel32.lib and the other ones
>
> This is
> I had to rem this line in config\win\global.mk to compile succesfully in bcc
> 5.5
> # SYSLIBS += kernel32 user32 ws2_32 advapi32 gdi32
>
> bcc has no kernel32.lib and the other ones
This is not true. All of them are present in PSDK dir,
which is part of BCC 5.5 kit.
If it doesn't work f
On Wed, 28 Oct 2009, Przemysław Czerpak wrote:
> > > hb_gtInfo( HB_GTI_WINTITLE, "string with accented chars" )
> > > doesn't seem to respect app CP (like now f.e. GTWVT does)
> > > with GTXWC, accented chars don't appear correctly in title
> > > bar.
> > > I tried to fix it by convertin
On Wed, 28 Oct 2009, Tamas TEVESZ wrote:
Hi,
> > hb_gtInfo( HB_GTI_WINTITLE, "string with accented chars" )
> > doesn't seem to respect app CP (like now f.e. GTWVT does)
> > with GTXWC, accented chars don't appear correctly in title
> > bar.
> > I tried to fix it by converting to UTF8 in gtx
On Wed, 28 Oct 2009, Viktor Szakáts wrote:
> hb_gtInfo( HB_GTI_WINTITLE, "string with accented chars" )
>
> doesn't seem to respect app CP (like now f.e. GTWVT does)
> with GTXWC, accented chars don't appear correctly in title
> bar.
>
> I tried to fix it by converting to UTF8 in gtxwc.c,
Hi,
VS> Hi All,
VS> Found this in our tracker, converted the example to self-contained one:
VS> ---
VS> PROCEDURE Main()
VS>dbCreate( "test", {{ "ITEM", "N", 10, 2 }} )
VS>USE test
VS>dbAppend() ; FIELD->ITEM := 5.00
VS>dbAppend() ; FIELD->ITEM := -5.12
VS>dbAppend() ; FIELD->I
On 2009.07.20., at 1:22, Przemyslaw Czerpak wrote:
On Mon, 20 Jul 2009, Szak�ts Viktor wrote:
in hbinet.c line 981, buffer is initialized to NULL,
Yes it is.
later in line 1003, buffer is used in recv() line as
'buffer + iReceived'.
Yes it is but iMaxLen is 0 so as long as recv() impleme
On Mon, 20 Jul 2009, Szak�ts Viktor wrote:
> in hbinet.c line 981, buffer is initialized to NULL,
Yes it is.
> later in line 1003, buffer is used in recv() line as
> 'buffer + iReceived'.
Yes it is but iMaxLen is 0 so as long as recv() implementation
is not broken then nothing wrong should happe
in hbinet.c line 981, buffer is initialized to NULL,
later in line 1003, buffer is used in recv() line as
'buffer + iReceived'.
Brgds,
Viktor
On 2009.07.20., at 0:50, Przemyslaw Czerpak wrote:
On Sun, 19 Jul 2009, Szak�ts Viktor wrote:
Hi,
There is a potential GPF bug (recently introduced) i
On Sun, 19 Jul 2009, Szak�ts Viktor wrote:
Hi,
> There is a potential GPF bug (recently introduced) in s_inetRecvInternal().
> If hb_itemGetWriteCL() returns FALSE, buffer will be NULLed, and later
> used as recv() buffer.
I'm sorry but I cannot find it.
And you explain when it can appear.
best
Hi Chen,
No it's simple IF statement, without brackets.
Brgds,
Viktor
On 2009.07.08., at 7:36, Chen Kedem wrote:
Viktor,
hbformat on contrib/hbtip/thtml.prg gives "Error 3" (in line 837 :
ENDDO)
Try to see if the IF() function is used, as I reported in the past,
hbformat think its the I
hbformat does not handle SWITCH/ENDSWITCH, and use the ENDSWITCH to close the
DO:
DO WHILE .T.
SWITCH x
CASE y
ENDSWITCH
ENDDO
Chen.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbo
Viktor,
> hbformat on contrib/hbtip/thtml.prg gives "Error 3" (in line 837 : ENDDO)
Try to see if the IF() function is used, as I reported in the past,
hbformat think its the IF statement. If so, just change it into IIF()
Chen.
___
Harbour mailing l
I can confirm Clipper returns .F. in first test while Harbour .T.,
with latest revision.
Brgds,
Viktor
On 2009.07.02., at 18:47, Randy Portnoff wrote:
Hi all,
The first output line (below) should return FALSE but returns TRUE
instead. The first line is equivalent to "? .F. .AND. .T. .AND. .
But when I type the ls command in the term
the normal color is back
Bruno
2009/7/2 Bruno Luciani
> I try this example in Kubuntu , konsole terminal ,
> and work ok , but when executes , change the color font
> to gray.
>
> The term is white font over black originally.
>
> Bruno
>
> 2009/7/2 Vik
I try this example in Kubuntu , konsole terminal ,
and work ok , but when executes , change the color font
to gray.
The term is white font over black originally.
Bruno
2009/7/2 Viktor Szakáts
> Hi Przemek and All,
>
> I've seen fixes and I may even have reported this, but something is
> still
On Darwin the crash is now gone. On Win I've only rebuilt
hbrtl yet and it instantly solved the problem.
Thanks a lot.
Brgds,
Viktor
On Mon, Jun 29, 2009 at 3:59 PM, Przemyslaw Czerpak wrote:
> On Mon, 29 Jun 2009, Przemyslaw Czerpak wrote:
>> Bingo - memory corruption which happens when OS CP c
On Mon, 29 Jun 2009, Przemyslaw Czerpak wrote:
> Bingo - memory corruption which happens when OS CP conversion is enabled.
> Thank you for the log. I'll fix it in a while.
Should be fixed by:
2009-06-29 15:58 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
best regards,
Przemek
__
On Mon, 29 Jun 2009, Szak�ts Viktor wrote:
> There seem to be some problem around hb_fsNameConv().
> Here is valgrind on Darwin output:
> ==41669== Invalid write of size 1
> ==41669==at 0x297590: hb_strncat (in ./ep)
> ==41669==by 0x293A73: hb_fsFNameMerge (in ./ep)
> ==41669==by 0x36AA
On Mon, 29 Jun 2009, Szak�ts Viktor wrote:
> Here's one with MinGW 4.4.0 on Windows:
> (this was built with 'set HB_BUILD_DEBUG=yes')
> ---
> Program received signal SIGSEGV, Segmentation fault.
> hb_rddFieldGet (pItem=0x1aa4954, pFieldSymbol=0xa094c0) at ../../wafunc.c:479
> 479 if( (
On Mon, 29 Jun 2009, Szak�ts Viktor wrote:
> Not much closer I guess after switching to plain -g.
> [ BTW, I'm doing these traces on Darwin x86, so there was no
> -fomit-frame-pointer
> switch here. All what's changed now is missing TRACE calls. ]
> ---
> Program received signal EXC_BAD_ACCESS, Co
There seem to be some problem around hb_fsNameConv().
Here is valgrind on Darwin output:
---
==41669== Memcheck, a memory error detector.
==41669== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et
al.
==41669== Using LibVEX rev 1900M, a library for dynamic binary
translation.
==41
Here's one with MinGW 4.4.0 on Windows:
(this was built with 'set HB_BUILD_DEBUG=yes')
---
Program received signal SIGSEGV, Segmentation fault.
hb_rddFieldGet (pItem=0x1aa4954, pFieldSymbol=0xa094c0) at ../../wafunc.c:479
479 if( ( PHB_DYNS ) pField->sym == pDynSym )
(gdb) bt
#0 hb_r
Not much closer I guess after switching to plain -g.
[ BTW, I'm doing these traces on Darwin x86, so there was no -fomit-
frame-pointer
switch here. All what's changed now is missing TRACE calls. ]
---
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAI
On Mon, 29 Jun 2009, Szak�ts Viktor wrote:
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x
> hb_dynsymName (pDynSym=0xd5ddb4) at dynsym.c:463
> 463 HB_TRACE(HB_TR_DEBUG, ("hb_dynsymName(%p)", pDynSym));
GDB shows line
On Mon, 29 Jun 2009, Szak�ts Viktor wrote:
> I'm getting this when trying to build Harbour with
> HB_BUILD_DEBUG=yes on darwin:
> In file included from ../../hvmall.c:69:
> ../../arrays.c: In function ‘hb_arraySetTDT’:
> ../../arrays.c:717: warning: format ‘%lf’ expects type ‘double’,
> but argume
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
hb_dynsymName (pDynSym=0xd5ddb4) at dynsym.c:463
463HB_TRACE(HB_TR_DEBUG, ("hb_dynsymName(%p)", pDynSym));
(gdb) bt
#0 hb_dynsymName (pDynSym=0xd5ddb4) at dynsym.c:463
#
I'm getting this when trying to build Harbour with
HB_BUILD_DEBUG=yes on darwin:
In file included from ../../hvmall.c:69:
../../arrays.c: In function ‘hb_arraySetTDT’:
../../arrays.c:717: warning: format ‘%lf’ expects type
‘double’, but argument 4 has type ‘LONG’
../../arrays.c:717: warning: t
On Mon, 29 Jun 2009, Szak�ts Viktor wrote:
> Thank you. The small test is okay now,
> but my large app still GPFs in dbUseArea().
> (after rebuilding everything with recent
> Harbour)
Use GDB or VALGRIND to catch the GPF and show C call stack.
best regards,
Przemek
___
Thank you. The small test is okay now,
but my large app still GPFs in dbUseArea().
(after rebuilding everything with recent
Harbour)
Brgds,
Viktor
On 2009.06.29., at 12:04, Przemyslaw Czerpak wrote:
On Fri, 26 Jun 2009, Szak�ts Viktor wrote:
I'm still investigating, but with r11543 and MinGW
On Fri, 26 Jun 2009, Szak�ts Viktor wrote:
> I'm still investigating, but with r11543 and MinGW, I'm getting GPF
> in DBUSEAREA() and also in ORDCREATE() in this small example:
> ---
> FUNC MAIN()
> USE TEST
> INDEX ON FIRST TO test
> ---
Should be fixed after:
2009-06-29 12:02 UTC+0200 Przemys
>-Original Message-
>From: Viktor Szakáts [mailto:harbour...@syenar.hu]
>Sent: Friday, June 26, 2009 9:01 PM
>To: Harbour Project Main Developer List.
>Subject: [Harbour] bug: RDD GPF with MinGW + r11543
>
>I'm still investigating, but with r11543 and MinGW, I'm
>getting GPF in DBUSEAR
On Tue, 23 Jun 2009, Szak�ts Viktor wrote:
> I did a full rebuild with r11486, but I'm getting this with hbmk2
> (even the simplest session):
> ---
> Error F0036 Invalid filename ''
> ---
> In hbmk2, it's invoked by:
> ---
> HB_COMPILE( "", { } )
> ---
> Maybe the first empty parameter is now unn
I did a full rebuild with r11486, but I'm getting this with hbmk2
(even the simplest session):
---
Error F0036 Invalid filename ''
---
In hbmk2, it's invoked by:
---
HB_COMPILE( "", { } )
---
Maybe the first empty parameter is now unnecessary?
(or it always was, but didn't cause a problem so fa
On Mon, 22 Jun 2009, Szak�ts Viktor wrote:
Hi,
> This code:
> --- test.prg
> PROC MAIN()
>? hb_compile( NIL, { "test.prg", "-gc2", "-l", "-l-" } )
>RETURN
> ---
> will create test.c *with* line numbers, while equivalent Harbour
> command line below will properly disable it by second -l- o
Hi Viktot
Viktor Szakáts wrote:
>
> ../../wincallb.c: In function 'void* _GenerateCallback(CALLBACKDATA*)':
> ../../wincallb.c:346: error: invalid conversion from 'LRESULT
> (*)(CALLBACKDATA*, ...)' to 'void*'
> ../../wincallb.c:346: error: initializing argument 3 of 'void
> _ucp(BYTE*, ULONG
Hi Przemek,
Thanks for the information and the patch.
I'll retry this issue after your change. Wrong path sep
was my first suspect, but couldn't make it work.
> ps. in *nixes I can use:
> hbmk2 tst
>to create binaries from tst.prg but in DOS ir prints:
> hbmk: Error: No source fi
On Wed, 10 Jun 2009, Szak�ts Viktor wrote:
Hi,
> As subject, hb_DirBase() and hb_ProgName() will correctly
> return the value, except that it uses forward slashes instead of
> backslashes on dos/djgpp platform.
> I've added this workaround to hbmk2:
>#define HB_DIRBASE() StrTran( hb_D
Viktor Szakáts wrote:
Looks quite strange:
---
C:\work\harbour\harbour\_hbinst\hb200\bin>HBMK2.EXE speedtst.prg
Harbour 2.0.0beta1 (Rev. 11292)
Copyright (c) 1999-2009, http://www.harbour-proje
ct.org/
Compiling 'speedtst.prg'...
speedtst.prg(141) Error F0029
>-Original Message-
>From: Viktor Szakáts [mailto:harbour...@syenar.hu]
>Sent: Thursday, June 04, 2009 9:49 AM
>To: Harbour Project Main Developer List.
>Subject: Re: [Harbour] Bug in GTWVT ?
>
>What you describe may happen when an app is not releasing its
>i
:
>>-Original Message-
>>From: Pritpal Bedi [mailto:bediprit...@hotmail.com]
>>Sent: Thursday, June 04, 2009 2:34 AM
>>To: harbour@harbour-project.org
>>Subject: Re: [Harbour] Bug in GTWVT ?
>>
>>
>>Hello
>>
>>
>>marek.horodyski wrot
>-Original Message-
>From: Pritpal Bedi [mailto:bediprit...@hotmail.com]
>Sent: Thursday, June 04, 2009 2:34 AM
>To: harbour@harbour-project.org
>Subject: Re: [Harbour] Bug in GTWVT ?
>
>
>Hello
>
>
>marek.horodyski wrote:
>>
&
Hello
marek.horodyski wrote:
>
> Why I'm return from gui back to GTWIN ?
>
:-(
> According to this scenario GTWVT hangs :
> - aplicaction start and correctly work.
> - when i'm push ALT+TAB app lost focus, but as before work ok.
> But when I'm again push ALT+TAB to return to app, and app h
On Thu, 14 May 2009, Luis Krause Mantilla wrote:
Hi Luis,
> FWIW, I tested with xHarbour with ads 8.1, 9.0 and 9.1 dlls
> and it does not add an extra dummy char. I changed the field
> length to 40 and it still worked as expected.
I located the reason and the bug is in all versions of ADS RDD
I
Thanks, it's good now
I had the problem with 7.0 ace32.dll
interesting though is, that linking with an older rddads.lib I had from
around 12/25/08 it seemed to be OK!
Przemyslaw Czerpak wrote:
>
> On Wed, 13 May 2009, fmanc...@viaopen.com wrote:
>
> Hi,
>
>> I had that problem. I solved using
Mindaugas:
I'm using 1.140. I'm in the middle of heave code changes on our
app and I won't be able to try 1.141 anytime soon but will see if
someone else can test it and confirm/deny.
Regards,
Mindaugas Kavaliauskas wrote:
Luis Krause Mantilla wrote:
Przemek:
FWIW, I tested with xHarbour wi
Luis Krause Mantilla wrote:
Przemek:
FWIW, I tested with xHarbour with ads 8.1, 9.0 and 9.1 dlls
and it does not add an extra dummy char. I changed the field
length to 40 and it still worked as expected.
Hi,
Have you tried with ads1.c file revision 1.141 (Mon May 4 08:25:44 2009
UTC) or ne
Przemek:
FWIW, I tested with xHarbour with ads 8.1, 9.0 and 9.1 dlls
and it does not add an extra dummy char. I changed the field
length to 40 and it still worked as expected.
Regards,
It seems to be ACE bug. Not Harbour.
Here is reduced example:
REQUEST ADS
proc main()
ad
Can someone who has older ACE libraries check if the problem is local to
version 9.00 and does not exist in 8.10 and/or in older versions?
Not an issue in ACE 6.2
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.or
Przemyslaw Czerpak wrote:
Here is reduced example:
REQUEST ADS
proc main()
adsSetServerType( 1 )
rddSetDefault( "ADS" )
dbCreate( "test.dbf", { { "F", "C", 24, 0 } } )
USE test
while lastrec() < 10
dbappend()
field->F := repl( "12345678
Hello Przemek,
>> I had that problem. I solved using the latest ADS 9.10 SDK.
>
> Thanks for the information. So it's already fixed.
> Can someone who has older ACE libraries check if the problem is local to
> version 9.00 and does not exist in 8.10 and/or in older versions?
I was using before AC
Przemyslaw just fixed it, in't this guy just great?! Thanks Przemyslaw.
2009-05-14 00:23 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/contrib/rddads/ads1.c
! added workaround for ACE bug: character fields longer then 23 bytes
are
increased by one byte when read by Ad
On Wed, 13 May 2009, fmanc...@viaopen.com wrote:
Hi,
> I had that problem. I solved using the latest ADS 9.10 SDK.
Thanks for the information. So it's already fixed.
Can someone who has older ACE libraries check if the problem is local to
version 9.00 and does not exist in 8.10 and/or in older v
On Wed, 13 May 2009, AbeB wrote:
Hi,
> with the following test.prgProc MAIN()
> --
> REQUEST ADS
> AdsSetServerType( 1 )
>
> dbCreate( "test.DBF", {;
> { "ITEMID", "C", 8, 0 }, ;
> { "ITEM", "C", 12, 0 }, ;
> { "CLASS", "C", 8, 0 }, ;
> {"SUB", "C", 8, 0 }
Hello Abe,
> with the following test.prgProc MAIN()
>
>
> --
> REQUEST ADS
> AdsSetServerType( 1 )
>
> dbCreate( "test.DBF", {;
> { "ITEMID", "C", 8, 0 }, ;
> { "ITEM", "C", 12, 0 }, ;
> { "CLASS", "C", 8, 0 }, ;
> {"SUB", "C", 8, 0 }, ;
> { "CQTY
Many thanks Przemek.
Brgds,
Viktor
On Sun, Feb 22, 2009 at 11:51 AM, Przemyslaw Czerpak wrote:
> On Sat, 21 Feb 2009, Szak�ts Viktor wrote:
>
> Hi,
>
> > I've run into a problem on Linux/Darwin, this code behaves differently:
> > PROC MAIN()
> >dbCreate( "test.dbf", {{ "ID", "C", 10, 0 }})
>
On Sat, 21 Feb 2009, Szak�ts Viktor wrote:
Hi,
> I've run into a problem on Linux/Darwin, this code behaves differently:
> PROC MAIN()
>dbCreate( "test.dbf", {{ "ID", "C", 10, 0 }})
>dbUseArea( .T., NIL, "test.dbf", "w_TEST", .T., .T. ) /* SHARED, READONLY
> */
>? FLock()
> Clipper on
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 c
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 the
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 det
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
1 - 100 of 147 matches
Mail list logo
