> - Original Message - From: "Viktor Szakáts"
> To: "Harbour Project Main Developer List."
> Sent: Wednesday, February 03, 2010 11:53 PM
> Subject: Re: [Harbour] Harbour / Clipper Incompatibility Issue: 10
> charvariables with SAVE and REST w/ proof of concept
>
>> Was thinking a bit mo
- Original Message -
From: "Viktor Szakáts"
To: "Harbour Project Main Developer List."
Sent: Wednesday, February 03, 2010 11:53 PM
Subject: Re: [Harbour] Harbour / Clipper Incompatibility Issue: 10
charvariables with SAVE and REST w/ proof of concept
Was thinking a bit more about thi
Wilfried Brunken submitted the following bug report:
http://sourceforge.net/tracker/index.php?func=detail&aid=2945728&group_id=681&atid=100681
When the Windows console buffer size does not match window size,
Harbour programs works in a non-consistent way.
It seems that sometimes the screen size i
Well the program compiled in both Clipper and Harbour behaves
differently on the same machine, same environment, in this case, Vista
32-bit. Hence an incompatibility.
I think that could be changed to "" by default but maybe it's an advantage if
you think that Harbour compile for other OS too.
Well the program compiled in both Clipper and Harbour behaves differently on
the same machine, same environment, in this case, Vista 32-bit. Hence an
incompatibility.
On Wed, Feb 3, 2010 at 7:53 PM, Xavi wrote:
> smu,
>
>
>set printer to
>> ? set(24) // s/b "", but set to LPT1 again
>>
>
smu,
set printer to
? set(24) // s/b "", but set to LPT1 again
Ok but it's also the default printer.
Printer connected to port LPT1 in WoW and NTVDM DOS PC emulator under Windows.
try .-
FUNC MAIN()
? set(24) // Clipper is "", Harbour is LPT1
set printer to ("junk.txt")
? set
Hi
How it can be determined that an expression is a
valid regex which can be submitted to the engine,
without generating a RTE ?
-
enjoy hbIDEing...
Pritpal Bedi
_a_student_of_software_analysis_&_design_
--
View this message in context:
http://n2.nabb
Hi!
I am with a small problem,DLLCALL not working with MINGW, but run fine
using MSVC express.
Bellow piece of code with Hwgui.
#define DC_CALL_STD 0x0020
Function Grafico(sTemp,lPrint)
Local oMainWindow, oFont, hDll
hDll:=loadlibrary("rmchart.dll")
INIT DIALOG oMainWindow TITLE "GRÁFICO"
Thanks Viktor.. you have been most helpful!
On Wed, Feb 3, 2010 at 3:24 PM, Viktor Szakáts wrote:
> > hmm.. i suppose i'd have to use some perl-like regex to test that this
> doesn't write C:\C:\hbm on other version of windows...
>
> I don't think you need to make it that complicated.
>
> If CUR
> hmm.. i suppose i'd have to use some perl-like regex to test that this
> doesn't write C:\C:\hbm on other version of windows...
I don't think you need to make it that complicated.
If CURDIR() returns a drive letter in Harbour, report
it on this list, as it is a clear bug. I'm confident
that
hmm.. i suppose i'd have to use some perl-like regex to test that this
doesn't write C:\C:\hbm on other version of windows...
On Wed, Feb 3, 2010 at 3:12 PM, Viktor Szakáts wrote:
> Try this one:
>
> FUNCTION hb_pwd()
> RETURN CurDrive() + hb_osDriveSeparator() + hb_osPathSeparator() +
> CurD
Try this one:
FUNCTION hb_pwd()
RETURN CurDrive() + hb_osDriveSeparator() + hb_osPathSeparator() + CurDir()
Brgds,
Viktor
On 2010 Feb 4, at 00:05, smu johnson wrote:
> Is there a way an HB_CURDIR or HB_CWD could be implemented, to always return
> the same val, based on it's own system lib t
Is there a way an HB_CURDIR or HB_CWD could be implemented, to always return
the same val, based on it's own system lib thingies?
On Wed, Feb 3, 2010 at 3:04 PM, Viktor Szakáts wrote:
> > Viktor,
> >
> > http://209.97.219.2/sjohnson/misc/curdir-diff.png
> >
> > Please let me know if you need an
> Viktor,
>
> http://209.97.219.2/sjohnson/misc/curdir-diff.png
>
> Please let me know if you need anything else.
My only guess is that CURDIR() is overridden by
some libs. Sorry, but I can't replicate it here
and can't recall seeing such behavior even on W2K
either.
Brgds,
Viktor
_
Hi,
Clipper doesn't make any conversion on the filename,
it just returns you what the OS returned.
Harbour does the same, and returns what the OS returns,
which is in this case the original casing of filenames.
Pls remember you switched OS platform also, not just
the compiler and certain beha
Viktor,
http://209.97.219.2/sjohnson/misc/curdir-diff.png
Please let me know if you need anything else.
On Wed, Feb 3, 2010 at 2:42 PM, Viktor Szakáts wrote:
> Please post more information about Clipper version, OS
> and small test problem.
>
> Here CURDIR() returns /DIR/ format, in sync with
> Viktor,
>
> Was thinking a bit more about this... I suppose there are some things in
> Clipper and Harbour that are not compatible.. such as long variable names...
>
> Since this likely won't be changed, as I also prefer long variable names...
> but would would be the best way to do to just
> Ok. So I suppose the best solution is to just make .MEM saved vars 1-10
> chars long?
In case you need to want to keep using .mem files,
this is the _only_ solution.
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harb
> Hi,
>
> In Clipper, ? SETPOS(10,4) returns 10. In Harbour, it returns NIL
Also DEVPOS(). They should return NIL as per documentation,
but they return the first parameter, unchanged, even if it's
invalid. I can't recall past discussions, but it seems like
a C5.2/5.3 bug.
Brgds,
Viktor
Please post more information about Clipper version, OS
and small test problem.
Here CURDIR() returns /DIR/ format, in sync with C5x
documentation. (C5.2e under Win98)
Brgds,
Viktor
On 2010 Feb 3, at 22:52, smu johnson wrote:
> Hi!
>
> In Clipper, CURDIR() returns the absolute path, including
> Analyze this scenario:
>
> I know the location of my project, say
>
> C:\dev_projects\
>
> Some souce is selected with fileopen dialog and it is
>
> C:\dev_projects\vouch\source\vouch.prg
>
> Now I want to retieve the relative path of this source with
>
> cRelative := hb_pathProc( "C:\dev
FUNC MAIN()
? set(24) // Clipper is "", Harbour is LPT1
set printer to ("junk.txt")
? set(24) // junk.txt
set printer to
? set(24) // s/b "", but set to LPT1 again
RETURN
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB
Hi All,
I just can't get the box characters to show on wince ver 5.00
it does show in the emulator though. what am i missing.
Thanks,
Abeb
--
View this message in context:
http://n2.nabble.com/Help-Please-Box-Characters-In-WINCE-tp4510357p4510357.html
Sent from the harbour-devel mailing lis
Viktor,
Was thinking a bit more about this... I suppose there are some things in
Clipper and Harbour that are not compatible.. such as long variable names...
Since this likely won't be changed, as I also prefer long variable names...
but would would be the best way to do to just keep going ahead
Ok. So I suppose the best solution is to just make .MEM saved vars 1-10
chars long?
Also, sorry about the vague use of "crash". I'll edit my posts prior to
posting to avoid that in the future. The good news is, I've never had
Harbour actually crash yet!
On Wed, Feb 3, 2010 at 2:05 PM, Viktor S
ACHOICE() behaves differently in Harbour than Clipper. In Clipper, the code
below will not have achoicef() called, as it knows that there is no point to
run it.. probably because the pFNames array is blank. Harbour however, will
try to run it, causing "array access" error.
--- code ---
func mai
In this case, Clipper Procedures are documented to not return a value, but in
actual fact, you get whatever the last value put on the return stack. Harbour
actually sets that value to NIL.
IOW, the operation is actually 'undefined' in Clipper - or said another way, do
_not_ rely on thsi si
Hi,
> Variables in Harbour can be over 10 characters. In clipper these can be
> written as 10+ characters but only the 1st 10 are used at compile time.
> When variables are saved to a .mem file only 10 characters are saved,
> however when they are restored they are 10 characters, but the code
> th
For Directory, I'm quite sure that was a conscious desicion to actually support
what the O/S gives you.
Paul
Date: Wed, 3 Feb 2010 13:45:35 -0800
From: smujohn...@gmail.com
To: harbour@harbour-project.org
Subject: [Harbour] Harbour / Clipper Incompatibility Issue: DIRECTORY()
uppercase w
Hi!
In Clipper, CURDIR() returns the absolute path, including the drive letter.
In Harbour, it does the same, but omits the drive letter and colon.
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http:
Hi,
In Clipper, ? SETPOS(10,4) returns 10. In Harbour, it returns NIL
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Hi,
Filenames are not converted to uppercase by Harbour functions such as
Directory() was in Clipper.
#include "Directry.ch"
FUNC MAIN()
aDirectory := DIRECTORY("*.txt", "D")
AEVAL( aDirectory, {|aFile| QOUT(aFile[F_NAME])} )
RETURN
/*
__ HARBOUR (02/03/2010 01:18 PM
Hi,
Variables in Harbour can be over 10 characters. In clipper these can be
written as 10+ characters but only the 1st 10 are used at compile time.
When variables are saved to a .mem file only 10 characters are saved,
however when they are restored they are 10 characters, but the code
that referen
> Viktor Szakáts wrote:
>>
>> It's only necessary if you want to avoid repeating
>> the same long path a lot of times and this long path is
>> not devisable from any root paths. For such purpose,
>> you can use macros, like you say, and this is supported
>> also by hbmk2 ('{MYPATH}\source.prg'
Hi
Analyze this scenario:
I know the location of my project, say
C:\dev_projects\
Some souce is selected with fileopen dialog and it is
C:\dev_projects\vouch\source\vouch.prg
Now I want to retieve the relative path of this source with
cRelative := hb_pathProc( "C:\dev_projects\vouch\sourc
Viktor Szakáts wrote:
>
> It's only necessary if you want to avoid repeating
> the same long path a lot of times and this long path is
> not devisable from any root paths. For such purpose,
> you can use macros, like you say, and this is supported
> also by hbmk2 ('{MYPATH}\source.prg' and '
> vszakats wrote:
>>
>> 2010-02-03 20:59 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
>> * utils/hbmk2/hbmk2.prg
>>+ Enabled -workdir option for non -inc modes.
>>* Change default workdir to be the OS temp dir.
>> Please test it, especially on non-win OSes.
>>
>
> This is good, a
Revision: 13760
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13760&view=rev
Author: vszakats
Date: 2010-02-03 20:59:52 + (Wed, 03 Feb 2010)
Log Message:
---
2010-02-03 21:59 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* utils/hbmk2/hbmk2.prg
2010/2/3 Przemysław Czerpak :
> No. By default all memvars (PUBLIC and PRIVATE) variables are separated
> between threads and each threads starts with its own clean set of memvars.
> If you want to change it then you can use thread attributes in
> hb_threadStart() function. See hbthread.ch and cod
vszakats wrote:
>
> 2010-02-03 20:59 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
> * utils/hbmk2/hbmk2.prg
> + Enabled -workdir option for non -inc modes.
> * Change default workdir to be the OS temp dir.
> Please test it, especially on non-win OSes.
>
This is good, and can
Revision: 13759
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13759&view=rev
Author: vszakats
Date: 2010-02-03 20:01:58 + (Wed, 03 Feb 2010)
Log Message:
---
2010-02-03 20:59 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* utils/hbmk2/hbmk2.prg
Hi,
> hbide_pathProc() is only effective when
> source tree is beneath its location only. In case
> it is there on some upper level folder, this mechanism
> fails.
No it doesn't fail. If it's in an upper level directory,
the only change is that you will use "..\..\mysource.prg".
If the "uppe
Thanks!
As far as the timestamp stuff... have found that using FSETDATETIME and
trying to set only one of the options, either DATE, or TIME, results in the
other one getting timestamped to a NOW() type time. Hence I wrote my cludge
in Clipper get around that... I tried all sorts of tricks..
HB_
Vailton Renato wrote:
>
> Pritpal, in order to continue sending contributions properly to hbIDE,
> the next new dialogs should be make using .ui or .uic? What do you
> recommend?
>
Keep both as .uic is the cpp source form of .ui.
.ui is always required to edit and create .uic.
But compile hbI
Revision: 13758
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13758&view=rev
Author: vszakats
Date: 2010-02-03 19:37:35 + (Wed, 03 Feb 2010)
Log Message:
---
2010-02-03 20:34 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* src/rtl/fstemp.c
* incl
Hello Viktor
hbide_pathProc() is only effective when
source tree is beneath its location only. In case
it is there on some upper level folder, this mechanism
fails.
But in real development pattern one has adopted
since years has to be changed. For example, I keep
my sources in
{root}/dev_
On Wed, 03 Feb 2010, Lorenzo Fiorini wrote:
> Here is the final code:
> begin sequence with { |e| logerror( e, oResponse, cBinFile ) }
> if !empty( pHRB := hb_hrbload( cBinFile ) )
>if !empty( sFunc := hb_hrbGetFunSym( pHRB, "HRBMAIN" ) )
> xRe
On Wed, 03 Feb 2010, smu johnson wrote:
Hi,
> Thanks Przemek.
> Could you post back here when I should get the SVN etc?
It's already ready in SVN.
I committed it few minutes after I sent you the message.
Look at the ChangeLog:
2010-02-03 11:15 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet
Hi again,
I have the code here that I have tested on both Clipper 5.2e and Harbour.
This is the first time I have seen with my own eyes what I was being told
earlier, so I can verify that I have witnessed a difference with my own two
eyes. If you cannot replicate it, perhaps I will need to send y
Hello everybody
I am about to implement find/replace in files/projects/folders
option in hbIDE. Before starting the real-work I would like to
hear from the group experience about what could be the
optimum approach, and how the results should be presented.
I am done with the interface part.
-
Hi!
Pritpal, in order to continue sending contributions properly to hbIDE,
the next new dialogs should be make using .ui or .uic? What do you
recommend?
Regards,
Vailton Renato
2010/2/2 :
> Revision: 13749
>
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13749&view=
Thanks Przemek.
Could you post back here when I should get the SVN etc?
Thank you for your hard work
2010/2/3 Przemysław Czerpak
> On Tue, 02 Feb 2010, smu johnson wrote:
>
> Hi,
>
> > When a table's index file is re-opened (it was previously created), does
> it
> > have to evaluate the FOR cl
Viktor Szakáts wrote:
>
> I've just realized that -workdir doesn't work in
> non-incremental mode. I'll check what can be done.
>
> If this is solved, maybe it'll be possible to set
> it by default to system temp dir (instead of current
> dir). I'll check it too.
>
I had expected the behav
2010/2/3 Przemysław Czerpak :
> or simply migrate to static functions only. You can use
I can do it since all the HRBs have the same func name and I can change it.
Here is the final code:
begin sequence with { |e| logerror( e, oResponse, cBinFile ) }
if !empty( pHRB := hb_h
I've just realized that -workdir doesn't work in
non-incremental mode. I'll check what can be done.
If this is solved, maybe it'll be possible to set
it by default to system temp dir (instead of current
dir). I'll check it too.
Brgds,
Viktor
On 2010 Feb 3, at 16:57, Viktor Szakáts wrote:
> H
Revision: 13757
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13757&view=rev
Author: druzus
Date: 2010-02-03 18:08:32 + (Wed, 03 Feb 2010)
Log Message:
---
2010-02-03 19:08 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbvm.
On Wed, 03 Feb 2010, Lorenzo Fiorini wrote:
> > You are freeing directly or indirectly HRB module which is currently
> > executed. HRB modules are unloaded automatically when all references to
> > pHRB variable returned by hb_hrbLoad() are cleared.
> > Fix you code to keep HRB module alive as long
Thanks Angel !!!
On Tue, Feb 2, 2010 at 7:32 PM, Angel Pais wrote:
> El 03/02/2010 1:22, smu johnson escribió:
>
>> Hi,
>>
>> I found a problem that is very noticeable when using the ALERT() func.
>> If your MS Windows buffer size setting (
>> http://209.97.219.2/sjohnson/misc/alert_problem_buff
FYI I just tested with latest FB 2.5 RC1, and
they fixed the problem, so hbfbird builds again.
I didn't make functional tests, so pls keep the
list posted about the errors you mentioned.
Brgds,
Viktor
On 2010 Feb 3, at 16:31, Viktor Szakáts wrote:
> Hi Fernando,
>
> Last time I tried to it w
2010/2/3 Przemysław Czerpak :
> You are freeing directly or indirectly HRB module which is currently
> executed. HRB modules are unloaded automatically when all references to
> pHRB variable returned by hb_hrbLoad() are cleared.
> Fix you code to keep HRB module alive as long as it is used.
Here
Hi Przemysław,
I tesed it on WinXP and it dosn't seem to work.
Przemysław Czerpak wrote:
>
>
> On Thu, 26 Nov 2009, AbeB wrote:
>> Does TONE() work on WinCE for anyone? (dosn't work for me)
>
> TONE() is implemented by GT subsystem so the most important question
> is which GT you are using
On Wed, 03 Feb 2010, Lorenzo Fiorini wrote:
Hi,
> > Try to use valgrind instead of GDB to detect memory corruption.
> Attached the valgrind log.
==30772== Invalid read of size 1
==30772==at 0x41A7121: hb_vmExecute (hvm.c:1231)
[...]
==30772== Address 0x52794e3 is 35 bytes inside a block of
I think we'd need a self-contained example here.
I tried to check the valgrind log, but the code
running is non-Harbour .c code, so it not very easy
to draw any conclusions, it could basically be
anything corrupting internals.
Brgds,
Viktor
On 2010 Feb 3, at 16:43, Lorenzo Fiorini wrote:
> 2
Hi,
> Hello Viktor
>
> I could see that if -inc mode is not enabled
> and -workdir= is not provided, intermediatery files are
> always created in the folder where .hbp resides.
> Though these are deleted at the end, but preferable
> way should be to create them in under .hbmk/temp
> folder. Can
2010/2/2 Przemysław Czerpak :
> If you want to see information about source file names and line numbers
> then just like for GDB do not strip final binaries and compile Harbour
> code with -g GCC flag.
At last I got a bt
(gdb) bt
#0 0xb8096430 in __kernel_vsyscall ()
#1 0xb7a446d0 in raise ()
Hello Viktor
I could see that if -inc mode is not enabled
and -workdir= is not provided, intermediatery files are
always created in the folder where .hbp resides.
Though these are deleted at the end, but preferable
way should be to create them in under .hbmk/temp
folder. Can it be done?
Hi Fernando,
Last time I tried to it with 2.5 beta,
it didn't even build, and I haven't tried
it again since then.
If you have some problems, report the details
here so we can check it.
[ BTW, hbfbird doesn't currently use any GC
collected pointers, so it falls behind the
Harbour standard i
Hi, Viktor
this native class for access Firebird is run ok?
i was try in last year, and i was some problems with firebird 2.5
Best Regards,
Fernando Athayde
De: "vszak...@users.sourceforge.net"
Para: harbour@harbour-project.org
Enviadas: Quarta-feira, 3 de Fev
Janik, Jaroslav wrote:
>
> 4, I run hbide. After several dialogs it fails.
>
What does this means?
"Several dialogs" ?
I need more detail.
-
enjoy hbIDEing...
Pritpal Bedi
_a_student_of_software_analysis_&_design_
--
View this message in context:
Hi,
Lorenzo Fiorini wrote:
If you want to see information about source file names and line numbers
then just like for GDB do not strip final binaries and compile Harbour
code with -g GCC flag.
Sorry probably I miss sth.
I've rebuilt Harbour ( 13750 ) with -g and I did a make clean make insta
2010/2/2 Przemysław Czerpak :
> If you want to see information about source file names and line numbers
> then just like for GDB do not strip final binaries and compile Harbour
> code with -g GCC flag.
Sorry probably I miss sth.
I've rebuilt Harbour ( 13750 ) with -g and I did a make clean make
Viktor,
thanks, it is a lot more clear now :)
Maurilio.
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.or
Revision: 13756
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13756&view=rev
Author: druzus
Date: 2010-02-03 14:01:55 + (Wed, 03 Feb 2010)
Log Message:
---
2010-02-03 15:01 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/contrib/hbct/
Revision: 13755
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13755&view=rev
Author: vszakats
Date: 2010-02-03 13:56:25 + (Wed, 03 Feb 2010)
Log Message:
---
2010-02-03 14:55 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* utils/hbmk2/hbmk2.pt_BR.p
Hi,
> Viktor,
>
> sorry, but which should I use? I mean, .hbp is for options, so I'd say that
> -mt or -gui have to go there.
.hbp and .hbm uses exactly the same format.
To keep it simple, forget .hbm for now and use one
.hbp file per project (target).
> .hbm is for source files, but how do I
Revision: 13754
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13754&view=rev
Author: vszakats
Date: 2010-02-03 13:24:28 + (Wed, 03 Feb 2010)
Log Message:
---
2010-02-03 14:24 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* contrib/hbfbird/tfirebrd.
Viktor,
sorry, but which should I use? I mean, .hbp is for options, so I'd say that
-mt or -gui have to go there.
.hbm is for source files, but how do I state dependencies or the like?
Given a bunch of .prg, .ch, .c and .h files, is there some syntax to follow to
write them inside a .hbm file?
Hi Maurilio,
On 2010 Feb 3, at 12:37, Maurilio Longo wrote:
> Hi Viktor,
>
> is there somewhere a doc which details .hbp/.hbm file syntax?
Yes, it's 'hbmk2 --help'. The format is the exact
same as for the command-line options.
Brgds,
Viktor
___
Har
Revision: 13753
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13753&view=rev
Author: vszakats
Date: 2010-02-03 11:48:17 + (Wed, 03 Feb 2010)
Log Message:
---
2010-02-03 12:47 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* contrib/hbpgsql/tpostgre.
Hi Viktor,
is there somewhere a doc which details .hbp/.hbm file syntax?
Thanks.
Maurilio.
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.o
francesco perillo escreveu:
I can provide rpm for some suse releases... which one do you need ?
And which optional components do you need (since some of these servers
are production servers I can't install too much stuff on them)
Francesco
Hi,
Not is for me, but to many brazilian users.
I a
Revision: 13752
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13752&view=rev
Author: vszakats
Date: 2010-02-03 10:43:46 + (Wed, 03 Feb 2010)
Log Message:
---
2010-02-03 11:40 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* contrib/hbpgsql/pgrdd.prg
On Wed, 03 Feb 2010, smu johnson wrote:
Hi,
> I will try to take a video of the behaviour and figure it out. I swear to
> you, that I am not making this up. If it helps, we are using Clipper 5.2e
> and Blinker. I will take screenshots of the behavioru to prove what I am
> saying is the case, a
Revision: 13751
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13751&view=rev
Author: druzus
Date: 2010-02-03 10:16:06 + (Wed, 03 Feb 2010)
Log Message:
---
2010-02-03 11:15 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/src/rdd/dbfcd
On Tue, 02 Feb 2010, smu johnson wrote:
Hi,
> When a table's index file is re-opened (it was previously created), does it
> have to evaluate the FOR clause, or can it wait to do that only when a value
> in the table row changes?
It does not need to be evaluated and can wait but it has to be vali
Please check this hbide behaviour:
1, I have created project in hbide and opened my test2.prg.
2, Then I closed hbide. The hbide.ini contains this information.
-
[FILES]
D:/MINI_PRG/CRYPT/test2.prg,64,0
I can provide rpm for some suse releases... which one do you need ?
And which optional components do you need (since some of these servers
are production servers I can't install too much stuff on them)
Francesco
___
Harbour mailing list (attachment s
Przemek,
I will try to take a video of the behaviour and figure it out. I swear to
you, that I am not making this up. If it helps, we are using Clipper 5.2e
and Blinker. I will take screenshots of the behavioru to prove what I am
saying is the case, and hopefully, with your Clipper knowledge :)
> This is what I tried:
> filename_to_be_stored
> project_location
> hbide_pathProc( "C:\dev_sources\vouch\abc.prg",
> "C:\harbour\contrib\hbide\projects\hbide.hbi" )
> and received:
> C:\dev_sources\vouch\abc.prg
> whereas I was expecting somethi
Hi,
> This is the changelog entry:
>
> * contrib/hbide/idemisc.prg
>+ hbide_PathProc()
> This function can combine relative paths together so it's
> the key to avoid macros dealing with placing paths to their
> intended location. It can replace current method of
> = hb_d
On Tue, 02 Feb 2010, smu johnson wrote:
Hi,
> I have the test which has been proven with our Clipper 5.2e running on DOS
> of a difference in Harbour below is an explanation I received by e-mail:
> == start here
> If eval({||devout("hello"),.f.)}) .or. .t.
> endif
> In Clipper the eval()
On 2010 Feb 3, at 03:56, Xavi wrote:
> To Viktor,
>
> El 03/02/2010 0:09, Viktor Szakáts escribió:
>>> for GPF at application startup caused by accessing TSD before HVM
>>> stack is initialized. It seems to work though it can be greatly
>>> simplified and of course the GPF in startup code and no
Viktor, Przemyslaw,
I'd like to see a sample of code which uses with var as well.
Right now, with object enables me to write dynamic html pages via an
interpreter which uses &() to evaluate source code and to hide to this
interpreted code whether it is being run as a CGI or as a fast CGI (sort of
93 matches
Mail list logo
