date:20100311

BTW, here is the full result matrix for mingw 4.4.1 and MSVC 2008:

 mingwmsvc
C++  13.57   *13.59
C   *14.2713.76

(* is default build mode in Harbour)

This means that in C++ mode msvc and mingw are very close, 
in C mode msvc still leads, and in default Harbour builds, 
msvc also leads.

I have to correct mingw size increase results 
(forgot to strip them), so mingw in C++ is about 
0.3-1.5% larger than C counterpart. In practice,
it's negligible.

msvc and mingw sizes are a little fuzzy to compare:
---
 mingw C++ mingw C   msvc C++ msvc C
harbour-21.dll   3.523.584   3.499.520  2.569.216  2.567.680
harbourmt-21.dll 3.553.280   3.526.144  2.595.840  2.594.816
harbour.exe577.024 568.832583.168583.168
hbformat-dll.exe26.112  26.112 60.416 60.416
hbformat.exe   745.984 744.448462.848462.848
hbi18n-dll.exe  11.776  11.776 46.080 46.080
hbi18n.exe 726.016 724.480446.464446.464
hbmk2-dll.exe  696.320 689.152704.512704.512
hbmk2.exe1.474.048   1.460.224  1.107.968  1.105.920
hbpp.exe   133.632 130.560172.544172.544
hbrun-dll.exe  591.872 585.216600.064600.064
hbrun.exe3.393.536   3.372.032  2.589.184  2.584.576
hbtest-dll.exe 373.760 374.272407.552407.552
hbtest.exe   1.477.120   1.472.512  1.100.288  1.099.776
---

Some binaries are smaller, some others are much 
larger in mingw.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] standalone .dll with full harbour RTL+VM

Hi Przemyslaw,

Yes I did put a call to hb_vmInit( FALSE ); in my code and it was enough.

I'll add you code, though, and I fully second your idea to have an include
which has all the needed code to start-up the hvm.

Thanks a lot.

Maurilio.

Przemysław Czerpak wrote:
 On Wed, 10 Mar 2010, Maurilio Longo wrote:
 
 Hi,
 
 it does not work :(
 Question: do I have to startup the HVM or does it start up by itself as soon
 as the .dll is loaded?
 
 You haven't added any code to initialize HVM after loading DLL file.
 You are creating DLL which uses its own HVM and you have to initialize it.
 For single thread support it's quite simple and the code below should be
 enough. I haven't tested it.
 
 best regards,
 Przemek
 
 
#include hbvm.h
#include windows.h
 
extern void hb_winmainArgInit( HANDLE hInstance, HANDLE hPrevInstance, int 
 iCmdShow );
 
#if defined( HB_OS_WIN_CE )  ( defined( _MSC_VER ) || defined( __POCC__ 
 ) )
BOOL WINAPI HB_DLL_ENTRY_POINT( HANDLE hInstance, DWORD dwReason, PVOID 
 pvReserved )
#else
BOOL WINAPI HB_DLL_ENTRY_POINT( HINSTANCE hInstance, DWORD dwReason, PVOID 
 pvReserved )
#endif
{
   hb_winmainArgInit( hInstance, 0, 0 );
   HB_SYMBOL_UNUSED( pvReserved );
 
   switch( fdwReason )
   {
  case DLL_PROCESS_ATTACH:
 hb_vmInit( HB_FALSE );
 break;
  case DLL_PROCESS_DETACH:
 hb_vmQuit();
 break;
   }
   return TRUE;
}
 
#if defined( __DMC__ ) || defined( __WATCOMC__ )
   HB_EXTERN_BEGIN
   void hb_forceLinkMainWin( void ) {}
   void hb_forceLinkMainStd( void ) {}
   HB_EXTERN_END
#endif
 ___
 Harbour mailing list (attachment size limit: 40KB)
 Harbour@harbour-project.org
 http://lists.harbour-project.org/mailman/listinfo/harbour
 

-- 
 __
|  |  | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] standalone .dll with full harbour RTL+VM

Przemyslaw,

-gui

on hbmk2 command line is not enough, I've found the answer in an old message
of Viktor, I had to add to my .prg code

procedure HB_GT_SYS()
REQUEST HB_GT_GUI_DEFAULT
return

This did the trick :)

Maurilio.

Przemysław Czerpak wrote:
 On Wed, 10 Mar 2010, Maurilio Longo wrote:
 
 Hi,
 
 No, it was not working with my .cmd file, either adding -gtnul to hbmk2 or
 adding -lgtgui to list of .dll it still asked for gtwin with an unresolved
 external.
 
 Yes and it should. Please look at harbour/doc/gtapi.txt. The second part
 of this file is copy of may message I sent to this list few years ago.
 Please read about:
ANNOUNCE HB_GTSYS
 and how it works.
 
 But, now that hbmk2 with the correct order of parameters works I can simply
 call it like this:
 hbmk2 -strip -st -gtgui -hbdyn -hbnolib- my.prg my_c.c
 and I get my.dll without errors.
 Now I just have to see if it works :)
 
 I think that you may want to add code to initialize HVM.
 
 best regards,
 Przemek
 ___
 Harbour mailing list (attachment size limit: 40KB)
 Harbour@harbour-project.org
 http://lists.harbour-project.org/mailman/listinfo/harbour
 

-- 
 __
|  |  | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] standalone .dll with full harbour RTL+VM

Przemyslaw,

I've just tested your code and it does not work, it seems hb_vmInit() is not
called.

My simpler code was to call hb_vmInit() explicitly.

Maurilio.

Przemysław Czerpak wrote:
 On Wed, 10 Mar 2010, Maurilio Longo wrote:
 
 Hi,
 
 it does not work :(
 Question: do I have to startup the HVM or does it start up by itself as soon
 as the .dll is loaded?
 
 You haven't added any code to initialize HVM after loading DLL file.
 You are creating DLL which uses its own HVM and you have to initialize it.
 For single thread support it's quite simple and the code below should be
 enough. I haven't tested it.
 
 best regards,
 Przemek
 
 
#include hbvm.h
#include windows.h
 
extern void hb_winmainArgInit( HANDLE hInstance, HANDLE hPrevInstance, int 
 iCmdShow );
 
#if defined( HB_OS_WIN_CE )  ( defined( _MSC_VER ) || defined( __POCC__ 
 ) )
BOOL WINAPI HB_DLL_ENTRY_POINT( HANDLE hInstance, DWORD dwReason, PVOID 
 pvReserved )
#else
BOOL WINAPI HB_DLL_ENTRY_POINT( HINSTANCE hInstance, DWORD dwReason, PVOID 
 pvReserved )
#endif
{
   hb_winmainArgInit( hInstance, 0, 0 );
   HB_SYMBOL_UNUSED( pvReserved );
 
   switch( fdwReason )
   {
  case DLL_PROCESS_ATTACH:
 hb_vmInit( HB_FALSE );
 break;
  case DLL_PROCESS_DETACH:
 hb_vmQuit();
 break;
   }
   return TRUE;
}
 
#if defined( __DMC__ ) || defined( __WATCOMC__ )
   HB_EXTERN_BEGIN
   void hb_forceLinkMainWin( void ) {}
   void hb_forceLinkMainStd( void ) {}
   HB_EXTERN_END
#endif
 ___
 Harbour mailing list (attachment size limit: 40KB)
 Harbour@harbour-project.org
 http://lists.harbour-project.org/mailman/listinfo/harbour
 

-- 
 __
|  |  | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] standalone .dll with full harbour RTL+VM

 Przemyslaw,
 
 -gui
 
 on hbmk2 command line is not enough, I've found the answer in an old message
 of Viktor, I had to add to my .prg code
 
 procedure HB_GT_SYS()
   REQUEST HB_GT_GUI_DEFAULT
 return
 
 This did the trick :)

-gui doesn't set any GTs, only executable build mode.
You should use -gtgui (which will also set -gui automatically).

BTW, -gtnul should also work for normal cases.

The problem in your case is that the method hbmk2 
uses (inherited from hbmk script) to set default GT, 
is an internal VM call executed on app startup. In 
context of .dlls with full VM, such app startup 
has no meaning. In such case a different stub would 
be needed, something like Przemek posted. I can 
add support for such thing to hbmk2, but first we 
should clear up any issues with it.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: [Harbour] Error in SDDFB

2010-03-11 Thread Horodyski Marek (PZUZ)

-Original Message-
From: Luis R. Stach [mailto:luisrst...@yahoo.com.ar] 
Sent: Wednesday, March 10, 2010 11:04 PM
To: harbour@harbour-project.org
Subject: [Harbour] Error in SDDFB

English by Google

Hi
I'm trying to connect to Firebird but I can not, I get this error:

Error SDDFB/1903 Prepare statement failed: SELECT * FROM agenda (DOS
Error 335544569)

What I do is this:

ANNOUNCE RDDSYS
REQUEST SQLMIX, SDDFB
RDDSETDEFAULT( SQLMIX )

hConn := RDDINFO( RDDI_CONNECT, { FIREBIRD,, SYSDBA, masterkey,
192.168.0.1:d:\data\agenda.fdb } )
MsgInfo( hConn )  //Return 1
DBUSEAREA( .T.,, SELECT * FROM agenda ) //Line error
I use Firebird 2.1.3.18185
*---

I use this so :
dbUseArea( .T., SQLMIX, select pok, oddz from jednostki order by
pok, JEDNOSTKI)

with Oracle. Try so like I.


Regards,
Marek Horodyski


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] standalone .dll with full harbour RTL+VM

2010-03-11 Thread Przemysław Czerpak

On Thu, 11 Mar 2010, Szak�ts Viktor wrote:

Hi Viktor,

 -gui doesn't set any GTs, only executable build mode.
 You should use -gtgui (which will also set -gui automatically).
 BTW, -gtnul should also work for normal cases.
 The problem in your case is that the method hbmk2 
 uses (inherited from hbmk script) to set default GT, 
 is an internal VM call executed on app startup. In 
 context of .dlls with full VM, such app startup 
 has no meaning. In such case a different stub would 
 be needed, something like Przemek posted. I can 
 add support for such thing to hbmk2, but first we 
 should clear up any issues with it.

The startup code in DLLs is executed just like in normal
application so it should work for DLLs two.
At least I do not see any reasons why it should not work.

Maurilio's messages are strongly confusing and it's hard to
guess what he exactly does or even what it the exact problem.
In this particular case he joined two different things.
He disabled binding to GTWIN by defining defining HB_GTSYS
and set default GT by using HB_GT_*_DEFAULT so I do not
know what problem he resolved.

Maurilio I know that we do not have good documentation
but I strongly suggest to read at least these few peaces
we have. In doc/gtapi.txt this is described and should
help to understand how it works. IMHO it's much better
method then trying different methods in the hope that
some of them gives expected results because in such way
you can unintentionally create sth what works only due
to some side effects in current implementation and will
not work in the future so you will report the problem to
the list again. The code to select GTs in PRG code I
implemented many years ago for xHarbour and only names
has changed a little bit (i.e. now we have HB_GTSYS instead
of original GTSYS). I think it's long enough period to find
a while to read how it works to not have such problems in
the future :-)

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] standalone .dll with full harbour RTL+VM

Viktor,

Viktor Szakáts wrote:
 -gui doesn't set any GTs, only executable build mode.
 You should use -gtgui (which will also set -gui automatically).
 
Not enough without the hb_gtsys() procedure.

 BTW, -gtnul should also work for normal cases.
 
I'm not sure I've tested this, but I think I've done this test and it was not
working either.

 The problem in your case is that the method hbmk2 
 uses (inherited from hbmk script) to set default GT, 
 is an internal VM call executed on app startup. In 
 context of .dlls with full VM, such app startup 
 has no meaning. In such case a different stub would 
 be needed, something like Przemek posted. I can 
 add support for such thing to hbmk2, but first we 
 should clear up any issues with it.
 
I'm doing a pretty strange thing, I don't know if it is worth adding to hbmk2,
while I think having a .c file to include to start-up the HVM could be a more
general and useful thing.

Best regards.

Maurilio.

-- 
 __
|  |  | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14130] trunk/harbour

Revision: 14130
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14130view=rev
Author:   vszakats
Date: 2010-03-11 10:42:09 + (Thu, 11 Mar 2010)

Log Message:
---
2010-03-11 11:40 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
  * src/vm/estack.c
  * include/hbstack.h
% hb_stackDispLocal() internal debug function made static, 
  and guarded with HB_VM_DEBUG (pls change it to something 
  better if there is one), so it's not included in every 
  regular build and final executable.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/include/hbstack.h
trunk/harbour/src/vm/estack.c


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] mingw32-make -j

Hi,

it's just me or mingw32-make -j n with  1 does not work? It seems, looking at
cpu monitor, that just a core is occupied.

If I issue a mingw32-make -j (without limit) it fully saturates all cores. I
have a dual core, so a -j 3 or 4 should be enough, I've tested -j 6 or 8, with
always just a core working.

Best regards.

Maurilio.

-- 
 __
|  |  | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14131] trunk/harbour

Revision: 14131
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14131view=rev
Author:   vszakats
Date: 2010-03-11 11:34:41 + (Thu, 11 Mar 2010)

Log Message:
---
2010-03-11 12:33 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
  * external/sqlite3/sqlite3.c
  * external/sqlite3/sqlite3.h
+ sqlite upgraded to 3.6.23 (from 3.6.22)

  * INSTALL
+ Added one more real-life example for unnecessary 
  envvars (HB_DIR).

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/INSTALL
trunk/harbour/external/sqlite3/sqlite3.c
trunk/harbour/external/sqlite3/sqlite3.h


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

Results in 64-bit mode using MSVC 2008 (same as 32-bit) 
and mingw 4.4.4 20100129 (prerelease):

 mingw  msvc
C++ 11.63
C11.08

mingw seems to be the winner here in default 
Harbour builds, even though msvc had the advantage 
of C++ mode.

Plus, 64-bit mode has a clear advantage over 32-bit.

Sizes:
  ming64 C   msvc64 C++
harbour-21-x64.dll   3.380.7363.091.456
harbourmt-21-x64.dll 3.403.2643.130.880
harbour.exe625.152  720.384
hbformat-dll.exe35.840   61.952
hbformat.exe   706.560  524.800
hbi18n-dll.exe  20.480   45.568
hbi18n.exe 684.032  506.880
hbmk2-dll.exe  751.616  847.360
hbmk2.exe1.462.7841.342.976
hbpp.exe   133.632  171.520
hbrun-dll.exe  643.072  738.304
hbrun.exe3.314.6883.127.808
hbtest-dll.exe 391.168  417.280
hbtest.exe   1.419.7761.239.552

I will make more tests, but it seems it's 
worth switching to mingw also for 64-bit mode.

Last time the problem was weak or none (yet) 
3rd party support for mingw64 (f.e. openssl).

Brgds,
Viktor

On 2010 Mar 11, at 09:10, Viktor Szakáts wrote:

 BTW, here is the full result matrix for mingw 4.4.1 and MSVC 2008:
 
 mingwmsvc
 C++  13.57   *13.59
 C   *14.2713.76
 
 (* is default build mode in Harbour)
 
 This means that in C++ mode msvc and mingw are very close, 
 in C mode msvc still leads, and in default Harbour builds, 
 msvc also leads.
 
 I have to correct mingw size increase results 
 (forgot to strip them), so mingw in C++ is about 
 0.3-1.5% larger than C counterpart. In practice,
 it's negligible.
 
 msvc and mingw sizes are a little fuzzy to compare:
 ---
 mingw C++ mingw C   msvc C++ msvc C
 harbour-21.dll   3.523.584   3.499.520  2.569.216  2.567.680
 harbourmt-21.dll 3.553.280   3.526.144  2.595.840  2.594.816
 harbour.exe577.024 568.832583.168583.168
 hbformat-dll.exe26.112  26.112 60.416 60.416
 hbformat.exe   745.984 744.448462.848462.848
 hbi18n-dll.exe  11.776  11.776 46.080 46.080
 hbi18n.exe 726.016 724.480446.464446.464
 hbmk2-dll.exe  696.320 689.152704.512704.512
 hbmk2.exe1.474.048   1.460.224  1.107.968  1.105.920
 hbpp.exe   133.632 130.560172.544172.544
 hbrun-dll.exe  591.872 585.216600.064600.064
 hbrun.exe3.393.536   3.372.032  2.589.184  2.584.576
 hbtest-dll.exe 373.760 374.272407.552407.552
 hbtest.exe   1.477.120   1.472.512  1.100.288  1.099.776
 ---
 
 Some binaries are smaller, some others are much 
 larger in mingw.
 
 Brgds,
 Viktor
 

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

2010-03-11 Thread Massimo Belgrano

Borland allow function to be replaceable so  you can replace a single
function without replace entire module
not good way but can be easy:

in my.lib other than other function
func stato
will be replaced
in myprg with simply
func stato
sequence link define result
2010/3/9 Maurilio Longo maurilio.lo...@libero.it

 Hi,

 which is the harbour recommended C compiler for the windows platform?

 best regards.

 --
  __
 |  |  | |__| Maurilio Longo
 |_|_|_|| farmaconsult s.r.l.


 ___
 Harbour mailing list (attachment size limit: 40KB)
 Harbour@harbour-project.org
 http://lists.harbour-project.org/mailman/listinfo/harbour




-- 
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] standalone .dll with full harbour RTL+VM

2010-03-11 Thread Massimo Belgrano

I suggest write a guideline
explain your problem with a sample
here few user explain use a sample but bad describe problem who have bad
understanding
a sample speak more that 1000 word so harbour sample can be more interesting
that harbour doc
i suggest an official reply for problem without sample
Your problem can't found easy help here because is required a reproducible
sample for verify

Still sorry for my bad English, but plesas undestrand what i can explain
2010/3/11 Przemysław Czerpak dru...@acn.waw.pl

 On Thu, 11 Mar 2010, Szak�ts Viktor wrote:

 Maurilio's messages are strongly confusing and it's hard to
 guess what he exactly does or even what it the exact problem.
 In this particular case he joined two different things.
 He disabled binding to GTWIN by defining defining HB_GTSYS
 and set default GT by using HB_GT_*_DEFAULT so I do not
 know what problem he resolved.

 Maurilio I know that we do not have good documentation
 but I strongly suggest to read at least these few peaces
 we have. In doc/gtapi.txt this is described and should
 help to understand how it works. IMHO it's much better
 method then trying different methods in the hope that
 some of them gives expected results because in such way
 you can unintentionally create sth what works only due
 to some side effects in current implementation and will
 not work in the future so you will report the problem to
 the list again. The code to select GTs in PRG code I
 implemented many years ago for xHarbour and only names
 has changed a little bit (i.e. now we have HB_GTSYS instead
 of original GTSYS). I think it's long enough period to find
 a while to read how it works to not have such problems in
 the future :-)


-- 
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

Hi,

 Borland allow function to be replaceable so  you can replace a single 
 function without replace entire module
 not good way but can be easy:
 
 in my.lib other than other function
 func stato
 will be replaced 
 in myprg with simply
 func stato
 sequence link define result

There is nothing to thank for bcc to hide 
important link-time problems caused by wrong 
coding / linking practices, like using multiple 
definitions of the same symbol. Such problems 
are best to be fixed in app code ASAP.

BTW, mingw also supports it, you only need to 
disable the fatal error using '-Wl,--allow-multiple-definition' 
option. Same goes for msvc.

We've been talking a lot about this on the 
list in the past, so I'm surprised there is 
still misunderstanding here.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14132] trunk/harbour

Revision: 14132
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14132view=rev
Author:   vszakats
Date: 2010-03-11 14:59:47 + (Thu, 11 Mar 2010)

Log Message:
---
2010-03-11 15:59 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
  * contrib/hbcurl/hbcurl.c
+ Added suggested workaround for potential security exploit 
  when used with libcurl  7.20.0.
  See details here:
 http://curl.haxx.se/docs/adv_20100209.html

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbcurl/hbcurl.c


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: SF.net SVN: harbour-project:[14128] trunk/harbour

Viktor Szakáts wrote:

Perhaps the GUI elements should use their own
colors instead of console ones, and the problem
is solved.

And perhaps it is forgotton that GTWVG is essentially
a GUI implementation of GTWVT. Some standards were
laid down in GTWVG only and were not the parts of
GTWVT at all. One... see below.

Anyhow it would be important to remove the
palette incompatibility. Leaving incompatibility
for all Harbour user base, just because there
is some local code, which you cannot modify
is not a very good solution for Harbour IMO.

I had to dig deep to gather facts about it.

Here is the changelog entries:

2010-02-25 16:03 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* contrib/hbziparc/hbziparc.prg
! Fixed HB_ZIPFILE() not working properly with a password set.

* include/hbgtinfo.ch
! Fixed comment for HB_GTI_PALETTE.

2009-02-20 13:18 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/vm/classes.c
* cleanup comment

* harbour/source/rtl/gttrm/gttrm.c
+ added support for HB_GTI_PALETTE - it's supported only by Linux
console
and PuTTY/PTerm

* harbour/source/rtl/gtxwc/gtxwc.c
* harbour/source/rtl/gtwvt/gtwvt.c
* harbour/contrib/gtwvg/gtwvg.c
! fixed indexes in
hb_gtInfo( HB_GTI_PALLETE, nIndex [, nNewRGBcolor ] )
They should be the same as in our screen buffer: 0-based not one
based.

2008-06-13 10:56 UTC+0800 Pritpal Bedi (prit...@vouchcac.com)
* harbour/source/rtl/gtwvt/gtwvt.c
* harbour/source/rtl/gtfunc.c
* harbour/include/hbapigt.h
+ Added Palette implementation by color index.
Hb_GtInfo( HB_GTI_PALETTE, nIndex[, nNewRGB ] ) - nOldRGB

* harbour/tests/wvtext.prg
* Updated to demonstrate above functionality.

2008-06-13 09:12 UTC+0800 Pritpal Bedi (prit...@vouchcac.com
* harbour/source/rtl/gtwvt/gtwvt.c
* harbour/include/hbgtinfo.ch
+ Added functionality to change Palette.
Hb_GtInfo( HB_GTI_PALETTE, aNewPalette ) - aOldPalette
aNewPalette must be of 16 elements containg RGB colors.

* harbour/tests/wvtext.prg
* Updated to demonstrate palette info.
; TODO : Hb_GtInfo( HB_GTI_PALETTEBYINDEX, nIndex[, nNewRGB ] ) -
nOldRGB
Needs deeper modifications in GT core. Needs additional parameter
in core setup. Will commit today.

Initially this feature was kept under
Wvt_set/getPalette() - aRGB

Consistency should always have priority over
local/personal reasons IMO. And the more we
delay it, the worse it gets.

Tell me who broke the consistancy ?

There is no concept of 0 base in Clipper code, is there ?
When I implemented it as HB_GTI_PALETTE call, I took
PRG code in perspective, to keep it consistent with
array assign/retreival. so that user could assign/retieve
either the whole palette or single color with one directive.

For example

#define COLOR_BLUE 2

aRGB := hb_gtInfo( HB_GTI_PALETTE )
aRGB[ COLOR_BLUE ] := nRGB
hb_gtInfo( HB_GTI_PALETTE, aRGB )

hb_gtInfo( HB_GTI_PALETTE, COLOR_BLUE, nRGB )

I presume, I was right when I introduced it first.
How it went the other way, I am still at a loss.

-
enjoy hbIDEing...
Pritpal Bedi
_a_student_of_software_analysis__design_
--
View this message in context:
http://n2.nabble.com/SF-net-SVN-harbour-project-14128-trunk-harbour-tp4713989p4716488.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: SF.net SVN: harbour-project:[14128] trunk/harbour

Hi Pritpal,

 Anyhow it would be important to remove the 
 palette incompatibility. Leaving incompatibility 
 for all Harbour user base, just because there 
 is some local code, which you cannot modify 
 is not a very good solution for Harbour IMO.
 
 
 I had to dig deep to gather facts about it.
 
 Here is the changelog entries:
 Consistency should always have priority over 
 local/personal reasons IMO. And the more we 
 delay it, the worse it gets.
 
 
 Tell me who broke the consistancy ?

You introduced a feature in SVN which used 
completely inconsistent numbering, using 1 
for black, which is historically zero.

Then someone (not me BTW) pointed out this error, 
and we corrected it, except GTWVG, which is now 
inconsistent.

 There is no concept of 0 base in Clipper code, is there ?

There is.

 When I implemented it as HB_GTI_PALETTE call, I took 
 PRG code in perspective, to keep it consistent with 
 array assign/retreival. so that user could assign/retieve
 either the whole palette or single color with one directive.
 
 For example 
 
 #define COLOR_BLUE  2
 
 aRGB := hb_gtInfo( HB_GTI_PALETTE )
 aRGB[ COLOR_BLUE ] := nRGB
 hb_gtInfo( HB_GTI_PALETTE, aRGB )
 
 OR
 
 hb_gtInfo( HB_GTI_PALETTE, COLOR_BLUE, nRGB )
 
 I presume, I was right when I introduced it first.
 How it went the other way, I am still at a loss. 

Try HB_DISPOUTAT(). Or most other past tools 
that referred to 16 supported colors with 
numerical value, or foreground/background 
color combination as an 8-bit value, they all 
used and uses 0x00 - 0x0F indexes to refer to 
colors.

I'm really not willing to open a long debate 
this time, we made a decision and for the sake 
of all Harbour users, you will just have to 
adapt your local codebase. Many of us have done 
this many times in the history of Harbour so there 
is nothing special in this practice, especially 
with features not yet matured. Our priority is 
simply to do the best for Harbour, not to save 
some personal time for a few users or one user. 

(you wouldn't believe how many days I've spent 
adapting my code to Harbour GT engine changes 
alone in the last 11 years, and the palette one 
doesn't look like a particularly complicated and 
time-consuming change to make).

Pls adapt.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] hbdoc2 compile errors

2010-03-11 Thread Heinz V Bergen


Thank-you, yes it compiles now.

Heinz



Pritpal Bedi wrote:
 
 
 
 Please check after r14127.
 
 
 -
  enjoy hbIDEing...
 Pritpal Bedi 
 _a_student_of_software_analysis__design_
 -- 
 View this message in context:
 http://n2.nabble.com/hbdoc2-compile-errors-tp4712945p4713957.html
 Sent from the harbour-devel mailing list archive at Nabble.com.
 ___
 Harbour mailing list (attachment size limit: 40KB)
 Harbour@harbour-project.org
 http://lists.harbour-project.org/mailman/listinfo/harbour
 
 

-- 
View this message in context: 
http://old.nabble.com/hbdoc2-compile-errors-tp27857112p27865636.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: SF.net SVN: harbour-project:[14128] trunk/harbour

 There is no concept of 0 base in Clipper code, is there ?
 
 There is.
 
 I think we are talking on two different planes.
 
 There is no concept of 0 base in Clipper code, is there ?

There is. Pls reread my msg. But anyway this is 
not strictly a Clipper compatibility issue.

 =
 There is no concept of 0 base in Clipper arrays.
 
 hb_gtInfo( HB_GTI_PALETTE ) numeric index and an array both.
 And here is where my logic resided, not that numeric 0 is not a 
 valid parameter.

There is no concept of storing colors in arrays 
anywhere in Clipper or Harbour, so there is no 
point to adapt the numbering to this one exception.

You won't be able to bend the whole world and 
modify well-known indexes to match 1 based 
arrays of Clipper/Harbour.

 Anyway this is not a big deal. I will change it but first 
 I have to serach my application if I ever used this feature
 with numeric indexes or not. A little later, now on hbIDE alone...

grep HB_GTI_PALETTE *.prg will tell you where 
to modify.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14133] trunk/harbour

Revision: 14133
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14133view=rev
Author:   vszakats
Date: 2010-03-11 17:29:38 + (Thu, 11 Mar 2010)

Log Message:
---
2010-03-11 18:29 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
  * src/rtl/hbtoken.c
* Marked function below with HB_LEGACY_LEVEL3:
__STRTOKEN():  change it to equivalent HB_TOKENGET()
__STRTKPTR():  change it to equivalent HB_TOKENPTR()
__STRTOKENCOUNT(): change it to equivalent HB_TOKENCOUNT()

  * contrib/hbmysql/tmysql.prg
+ Added ::nPort variable to TMYSQLSERVER class.
* Formatting.

  * contrib/hbmysql/tmysql.prg
  * examples/hbmsql/tmsql.prg
! __STRTOKEN() - HB_TOKENGET()

  * contrib/hbmysql/tsqlbrw.prg
* Formatting.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbmysql/tmysql.prg
trunk/harbour/contrib/hbmysql/tsqlbrw.prg
trunk/harbour/examples/hbmsql/tmsql.prg
trunk/harbour/src/rtl/hbtoken.c


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14134] trunk/harbour

2010-03-11 Thread vouchcac

Revision: 14134
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14134view=rev
Author:   vouchcac
Date: 2010-03-11 17:36:04 + (Thu, 11 Mar 2010)

Log Message:
---
2010-03-11 09:30 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * contrib/hbqt/doc/en/class_hbqplaintextedit.txt
  * contrib/hbqt/hbqt_hbqplaintextedit.cpp
  * contrib/hbqt/hbqt_hbqplaintextedit.h
  * contrib/hbqt/qtgui/HBQPlainTextEdit.cpp
  * contrib/hbqt/qtgui/THBQPlainTextEdit.prg
  * contrib/hbqt/qth/HBQPlainTextEdit.qth

  * contrib/hbide/resources/themesex.ui
  * contrib/hbide/resources/themesex.uic

  * contrib/hbide/ideeditor.prg
  * contrib/hbide/idethemes.prg
+ Reimplemented Themes.
  * Now it is possible to change current line and line area background
colors. Also synchronized the current colors for these areas 
with rest of the theme.
  * Now you can apply a particular theme globally to all tabs.
  * Made easy the way GUI elements are presented, it is more intuitive.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbide/ideeditor.prg
trunk/harbour/contrib/hbide/idethemes.prg
trunk/harbour/contrib/hbide/resources/themesex.ui
trunk/harbour/contrib/hbide/resources/themesex.uic
trunk/harbour/contrib/hbqt/doc/en/class_hbqplaintextedit.txt
trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.cpp
trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.h
trunk/harbour/contrib/hbqt/qtgui/HBQPlainTextEdit.cpp
trunk/harbour/contrib/hbqt/qtgui/THBQPlainTextEdit.prg
trunk/harbour/contrib/hbqt/qth/HBQPlainTextEdit.qth


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: SF.net SVN: harbour-project:[14134] trunk/harbour



vouchcac wrote:
 
 Revision: 14134
  
 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14134view=rev
 Author:   vouchcac
 Date: 2010-03-11 17:36:04 + (Thu, 11 Mar 2010)
 

Forget to mention that when changing the line and line-area colors
keep some actural source in vision, only then you will visualize it.
In the Themes dialog it is not possible to display it.


-
 enjoy hbIDEing...
Pritpal Bedi 
_a_student_of_software_analysis__design_
-- 
View this message in context: 
http://n2.nabble.com/SF-net-SVN-harbour-project-14134-trunk-harbour-tp4717401p4717451.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: SF.net SVN: harbour-project:[14128] trunk/harbour

2010-03-11 Thread Przemysław Czerpak

On Thu, 11 Mar 2010, Pritpal Bedi wrote:

Hi,

 I think we are talking on two different planes.
 There is no concept of 0 base in Clipper code, is there ?

Yes it is. Please read Clipper documentation.
Clipper uses indexes in range 0-15 for foreground and
background colors with the following meaning.
   0-black
   1-blue
   2-green
   3-cyan
   4-red
   5-magenta
   6-brown
   7-light gray
   8-gray
   9-light blue
  10-light green
  11-light cyan
  12-light red
  13-light magenta
  14-yellow
  15-white

You can select colors in Clipper using stringslike:
   4/1 = red/blue
   15/2 = white/green

In harbour/tests/gtcolors.prg you have code example which uses
such numeric indexes to select colors. Please be so kind and
comment the line 20 in this file (with HB_GTVERSION() functions)
and compile it using Clipper and check how it works.

Harbour fully respects such numeric indexes so I do not see any
reason why we should create execption for HB_GTI_PALETTE and add
1 to these indexes when in all other places (the numeric color
notation using indexes is accepted by _ALL_ functions using color
strings) we will use Clipper compatible 0 based color values.

If you know such reason then please tell us about them.
If not then IMO GTWVG should be fixed to be compatible with
color indexes used by Clipper.

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] hbIDE - Let's review


Hello Everybody

Today, on 11Mar2010, hbIDE is 3 months and 24 days old, 
and it's time to look at it from different angles.

I invite everybody to express himself as to 

what is left unfinished,
what more is needed, 
what needs to be addressed again,
in context to priorities and preferences.

I am really eager to listen to you.


-
 enjoy hbIDEing...
Pritpal Bedi 
_a_student_of_software_analysis__design_
-- 
View this message in context: 
http://n2.nabble.com/hbIDE-Let-s-review-tp4717833p4717833.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: SF.net SVN: harbour-project:[14128] trunk/harbour

Przemysław Czerpak wrote:

Yes it is. Please read Clipper documentation.
Clipper uses indexes in range 0-15 for foreground and
background colors with the following meaning.
0-black
1-blue
2-green
3-cyan
4-red
5-magenta
6-brown
7-light gray
8-gray
9-light blue
10-light green
11-light cyan
12-light red
13-light magenta
14-yellow
15-white

You can select colors in Clipper using stringslike:
4/1 = red/blue
15/2 = white/green

In harbour/tests/gtcolors.prg you have code example which uses
such numeric indexes to select colors. Please be so kind and
comment the line 20 in this file (with HB_GTVERSION() functions)
and compile it using Clipper and check how it works.

Harbour fully respects such numeric indexes so I do not see any
reason why we should create execption for HB_GTI_PALETTE and add
1 to these indexes when in all other places (the numeric color
notation using indexes is accepted by _ALL_ functions using color
strings) we will use Clipper compatible 0 based color values.

If you know such reason then please tell us about them.
If not then IMO GTWVG should be fixed to be compatible with
color indexes used by Clipper.

Now I am more aware about internals.
Thanks for this insight, I will fix GTWVG soon.

-
enjoy hbIDEing...
Pritpal Bedi
_a_student_of_software_analysis__design_
--
View this message in context:
http://n2.nabble.com/SF-net-SVN-harbour-project-14128-trunk-harbour-tp4713989p4717853.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

2010-03-11 Thread Przemysław Czerpak

On Thu, 11 Mar 2010, Szak�ts Viktor wrote:

Hi,

 Results in 64-bit mode using MSVC 2008 (same as 32-bit) 
 and mingw 4.4.4 20100129 (prerelease):
  mingw  msvc
 C++ 11.63
 C11.08
 mingw seems to be the winner here in default 
 Harbour builds, even though msvc had the advantage 
 of C++ mode.

Finally I installed for tests GCC 4.5 (devel version)
and in C++ mode with -flto it gives also better results
then in C mode so it's potentially the fastest code.
I have to say that I vary like how the meta code is
implemented. Unlike other compilers GCC can be used
with LTO without any complicated settings and programmer
can easy control if he wants or not link time optimization
using one link time switch.

 Plus, 64-bit mode has a clear advantage over 32-bit.

I have similar results in Linux.
64bit Harbour programs are faster then 32bit ones.

 I will make more tests, but it seems it's 
 worth switching to mingw also for 64-bit mode.

The very strong thing in GCC is really good performance
for different hardware. The optimization logic is not
hardcoded to one processor family so it can be easy adopt
to completely different CPUs. Anyhow I do not know what
it the quality of Win64 GCC ports so here you will have
to took the decision yourself. It's quite new port anyhow
I think that in short time it should be very stable and
efficient. 64big GCC ports for different *nixes have been
existing for _very_ long time.

Thank you for your tests.

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] GC Pointers - Anyway to detatch them ?


Hello Przemek

I am looking for a solution where is GC pointer is
detatched from freeing it, all other operations remaining 
the same. 

It is possible that I am not been able to explain what I need properly.

In hbQT we are been unable to know, at certain points, when 
Qt releases the pointer. As per inherent nature of pointers
C or C++ does not set the value of pointer variable to NULL.
And hence when it is subject to freeing, GC does not 
know if it has already been freed and hence GPF's.

I have a mechanism in place where all delete operations 
can be carried on as per Qt specs, I just want that the 
pointer is not freeed in GC. It will only detatch GC from it 
and will clear its stack.



-
 enjoy hbIDEing...
Pritpal Bedi 
_a_student_of_software_analysis__design_
-- 
View this message in context: 
http://n2.nabble.com/GC-Pointers-Anyway-to-detatch-them-tp4717974p4717974.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re[2]: [Harbour] Error in SDDFB

2010-03-11 Thread Luis R. Stach

English by Google

Marek Thanks for answering,

The same problem continues, it follows the same mistake

Regards,
Luis R. Stach


Thursday, March 11, 2010, 6:11:16 AM, you wrote:

 -Original Message-
 From: Luis R. Stach [mailto:luisrst...@yahoo.com.ar] 
 Sent: Wednesday, March 10, 2010 11:04 PM
 To: harbour@harbour-project.org
 Subject: [Harbour] Error in SDDFB

 English by Google

 Hi
 I'm trying to connect to Firebird but I can not, I get this error:

 Error SDDFB/1903 Prepare statement failed: SELECT * FROM agenda (DOS
 Error 335544569)

 What I do is this:

 ANNOUNCE RDDSYS
 REQUEST SQLMIX, SDDFB
 RDDSETDEFAULT( SQLMIX )

 hConn := RDDINFO( RDDI_CONNECT, { FIREBIRD,, SYSDBA, masterkey,
 192.168.0.1:d:\data\agenda.fdb } )
 MsgInfo( hConn )  //Return 1
 DBUSEAREA( .T.,, SELECT * FROM agenda ) //Line error
 I use Firebird 2.1.3.18185
 *---

 I use this so :
 dbUseArea( .T., SQLMIX, select pok, oddz from jednostki order by
 pok, JEDNOSTKI)

 with Oracle. Try so like I.


 Regards,
 Marek Horodyski


 ___
 Harbour mailing list (attachment size limit: 40KB)
 Harbour@harbour-project.org
 http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] hbIDE - Let's review

2010-03-11 Thread Massimo Belgrano

HBIDE is very good tool and imo is very near to xmate level but
I am using hbide as primary editor for harbour

Unfinished the sub project/multi project implementation

What can be done
 more simple create project like visual studio one click create
folder,prg,hbp
 visual define harbour/hbmk flag
 User defined keyboard mapping and user menu
 Project tree require too many click
 automatic tag of  project function lookup for search in seleted project
 when i select a souce of project automatically select this project as
current
 Made possible add documentation to harbour using hbide
 Simple keystroke for open harbour help (f1) and go to selected function
 mark breakpoint  visual debug
 column mode in editor
 extend intellisense capabillty

Follow are requested from other user  that i have received via mail
is Possible use with xharbour or xbase++?
is possible use via command line for edit a project or a prg or rc?
Is possible define the structure of file like fromfoxpro modi stru command?
 Integrate Dot prompt dbase functionaly

Feature can be classified
1) more easy for first time user (i vote this!)
2) more powerfull for advanced user




2010/3/11 Pritpal Bedi bediprit...@hotmail.com


 Hello Everybody

 Today, on 11Mar2010, hbIDE is 3 months and 24 days old,
 and it's time to look at it from different angles.

 I invite everybody to express himself as to

 what is left unfinished,
 what more is needed,
 what needs to be addressed again,
 in context to priorities and preferences.

 I am really eager to listen to you.


 -
 enjoy hbIDEing...
Pritpal Bedi
 _a_student_of_software_analysis__design_
 --
 View this message in context:
 http://n2.nabble.com/hbIDE-Let-s-review-tp4717833p4717833.html
 Sent from the harbour-devel mailing list archive at Nabble.com.
 ___
 Harbour mailing list (attachment size limit: 40KB)
 Harbour@harbour-project.org
 http://lists.harbour-project.org/mailman/listinfo/harbour




-- 
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] hbIDE - Let's review

Hi,

1) To fix the foundation and once and for all 
   the GPFs on all platforms / compiler 
   supported by hbide / QT.
2) To fix .ini file handling to be standard.
3) Related: Merge dangling secondary .ini and similar 
   config files into the central .ini.
4) Related: To solve storing settings on *nix 
   platforms. On these platforms you don't 
   store settings in .ini file in current dir.
5) To use hbmk2 for format conversion.
6) To make the decision: .ui or .uic and stick to 
   only one.
7) Future: To honor formatting and original comments 
   when saving .hbp files.

Brgds,
Viktor

On 2010 Mar 11, at 19:37, Pritpal Bedi wrote:

 
 Hello Everybody
 
 Today, on 11Mar2010, hbIDE is 3 months and 24 days old, 
 and it's time to look at it from different angles.
 
 I invite everybody to express himself as to 
 
 what is left unfinished,
 what more is needed, 
 what needs to be addressed again,
 in context to priorities and preferences.
 
 I am really eager to listen to you.
 
 
 -
 enjoy hbIDEing...
Pritpal Bedi 
 _a_student_of_software_analysis__design_
 -- 
 View this message in context: 
 http://n2.nabble.com/hbIDE-Let-s-review-tp4717833p4717833.html
 Sent from the harbour-devel mailing list archive at Nabble.com.
 ___
 Harbour mailing list (attachment size limit: 40KB)
 Harbour@harbour-project.org
 http://lists.harbour-project.org/mailman/listinfo/harbour

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Error with sample netiosrv.prg

2010-03-11 Thread Rossine


Hello Przemek,

I'm trying to compile the example NETIOSRV.PRG me and is experiencing this
error:

I'm using the svn harbour 14110

I compile this:

hbmk2 -trace -mt -info -n -shared -prgflag=-D__BCC__ netiosrv netiocmd 
comp.log

...and the result:

hbmk2: Processando op‡äes do ambiente: -compiler=bcc
hbmk2: Plataforma detectada: win
hbmk2: Usando Harbour: c:\hrb_bcc\bin c:\hrb_bcc\include c:\hrb_bcc\lib
   c:\hrb_bcc\lib
hbmk2: Usando compilador C: c:\bcc55\bin\bcc32.exe
hbmk2: Processando script local: hbmk.hbm
hbmk2: Processando arquivo de configura‡Æo: C:\hrb_bcc\bin\hbmk.cfg
hbmk2: Processando: ../hbnetio.hbc
hbmk2: Linha de comando do compilador Harbour: (interno)
(C:\hrb_bcc\bin\harbour.exe) -n2 netiosrv.prg netiocmd.prg -w3 -es2 -n
-D__BCC__ -oC:\TMP\ -ic:\hrb_bcc\include
hbmk2: Comando do compilador C/C++:
bcc32.exe -c -q -tWM -d -6 -O2 -OS -Ov -Oi -Oc -DHB_GC_AUTO
-DHB_FM_STATISTIC  -w -w-sig- -Q -nC:\TMP\ -Ic:\hrb_bcc\include
C:\TMP\netiosrv.c C:\TMP\netiocmd.c
C:\TMP\netiosrv.c:
C:\TMP\netiocmd.c:
hbmk2: Comando do Linkeditor:
ilink32.exe @C:\TMP\gyvp1t.lnk
hbmk2: Script do linkeditor:
-Gn -Tpe -Lc:\bcc55\Lib\PSDK;c:\hrb_bcc\lib  -ap c0x32.obj
C:\TMP\netiosrv.obj C:\TMP\netiocmd.obj, netiosrv.exe, nul, hbnetio.lib
hbmainstd.lib hbmainwin.lib hbcplr.lib hbdebug.lib kernel32.lib user32.lib
gdi32.lib advapi32.lib ws2_32.lib winspool.lib comctl32.lib comdlg32.lib
shell32.lib uuid.lib ole32.lib oleaut32.lib mpr.lib winmm.lib mapi32.lib
imm32.lib msimg32.lib wininet.lib harbourmt-21-bcc.lib  cw32mt.lib
import32.lib,, 
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
Error: Unresolved external '_hb_stackReturnItem' referenced from
C:\HRB_BCC\LIB\HBNETIO.LIB|netiosrv

What can be ?

Best regards,

Rossine.


-- 
View this message in context: 
http://old.nabble.com/Error-with-sample-netiosrv.prg-tp27869193p27869193.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14135] trunk/harbour

Revision: 14135
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14135view=rev
Author:   vszakats
Date: 2010-03-11 20:20:13 + (Thu, 11 Mar 2010)

Log Message:
---
2010-03-11 21:16 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
  * src/rtl/filesys.c
+ Using direct Windows API instead of compiler specific
  C RTL functions to get/set current disk.
; Please review.
- Deleted one Windows TODO: setmode() to be convered to
  direct Windows API call. This translation is done in
  C RTL, so Windows API cannot be used.
; There is no remaining non-standard (compiler specific)
  C RTL function usage on the Windows platform AFAICT.

  * contrib/hbmysql/tmysql.prg
* Formatting.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbmysql/tmysql.prg
trunk/harbour/src/rtl/filesys.c


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14136] trunk/harbour

2010-03-11 Thread druzus

Revision: 14136
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14136view=rev
Author:   druzus
Date: 2010-03-11 21:16:27 + (Thu, 11 Mar 2010)

Log Message:
---
2010-03-11 22:16 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/include/hbstack.h
* added HB_EXPORT to some hb_stack*() functions which can be needed
  for non core code

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/include/hbstack.h


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14137] trunk/harbour

2010-03-11 Thread vouchcac

Revision: 14137
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14137view=rev
Author:   vouchcac
Date: 2010-03-11 21:20:08 + (Thu, 11 Mar 2010)

Log Message:
---
2010-03-11 13:20 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * contrib/gtwvg/gtwvg.c
! Fixed the HB_GTI_PALETTE protocol uniform with other GT's.

  * contrib/gtwvg/tests/demowvg.prg
! ThreadID() - Hb_ThreadID()
  BTW ThreadID() is a Xbase++ compatible function.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/gtwvg/gtwvg.c
trunk/harbour/contrib/gtwvg/tests/demowvg.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14138] trunk/harbour

Revision: 14138
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14138view=rev
Author:   vszakats
Date: 2010-03-11 21:23:19 + (Thu, 11 Mar 2010)

Log Message:
---
2010-03-11 22:21 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
  * src/rtl/fssize.c
+ Using Harbour filefind API on win platforms (just
  like for wce) instead of using stat()/stat64() C RTL
  calls.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/src/rtl/fssize.c


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Error in SDDFB

2010-03-11 Thread Jacek Kubica

Hello Luis,

I can only confirm your bug raport
(the same error here).

IMHO sddfb is still buggy oposite to
sddoci which work just fine.

sddfb can only make connection
(I can see it on Flamerobin fb tool) and nothing more ;-(

... but maybe is someone on our list, who can
say - it work ??

Mindaugas, can you look at this problem and help us
to find solution ??

Regards

Jacek Kubica

LRS Thursday, March 11, 2010, 8:36:01 PM, you wrote:

LRS English by Google

LRS Marek Thanks for answering,

LRS The same problem continues, it follows the same mistake

LRS Regards,
LRS Luis R. Stach


LRS Thursday, March 11, 2010, 6:11:16 AM, you wrote:

 -Original Message-
 From: Luis R. Stach [mailto:luisrst...@yahoo.com.ar] 
 Sent: Wednesday, March 10, 2010 11:04 PM
 To: harbour@harbour-project.org
 Subject: [Harbour] Error in SDDFB

 English by Google

 Hi
 I'm trying to connect to Firebird but I can not, I get this error:

 Error SDDFB/1903 Prepare statement failed: SELECT * FROM agenda (DOS
 Error 335544569)

 What I do is this:

 ANNOUNCE RDDSYS
 REQUEST SQLMIX, SDDFB
 RDDSETDEFAULT( SQLMIX )

 hConn := RDDINFO( RDDI_CONNECT, { FIREBIRD,, SYSDBA, masterkey,
 192.168.0.1:d:\data\agenda.fdb } )
 MsgInfo( hConn )  //Return 1
 DBUSEAREA( .T.,, SELECT * FROM agenda ) //Line error
 I use Firebird 2.1.3.18185
 *---

 I use this so :
 dbUseArea( .T., SQLMIX, select pok, oddz from jednostki order by
 pok, JEDNOSTKI)

 with Oracle. Try so like I.



-- 
Best regards,
 Jacekmailto:clip...@wssk.wroc.pl


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14140] trunk/harbour

Revision: 14140
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14140view=rev
Author:   vszakats
Date: 2010-03-11 22:28:22 + (Thu, 11 Mar 2010)

Log Message:
---
2010-03-11 23:27 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
  * contrib/rddsql/sddfb/sddfb.c
! Few cleanups in the FB RDDSQL interface (macro and type usage).
; It's not an attempt to fix recently reported bugs on the list.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/rddsql/sddfb/sddfb.c


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: hbIDE - Let's review



Massimo Belgrano wrote:
 
 Unfinished the sub project/multi project implementation
 

Did you tried ?
IMO whatever is defined in .hbp is presented to hbMK2,
which has the capability of building sub-projects, 
Viktor, update me on this issue.



  more simple create project like visual studio one click create
 folder,prg,hbp
 

Ok.



  visual define harbour/hbmk flag
 

Visual design is easy, but what should go inside, 
I am not sure. Are you saying that all those flags,
placable in .hbp and forwarded on command-line be 
fetched visually ? If yes, then I need someone to 
provide me the list of all those flags, and the syntax
which must be verified.



  User defined keyboard mapping and user menu
 

Yep, but it will be the last action. All other 
publick actions needs to be known beforehand before 
initiating this process. A must have... is on my TODO list.


 Project tree require too many click


I have tried to simplify it and based on 
folders, what other methodology you suggest ?



  automatic tag of  project function lookup for search in seleted project
 

It is easy but as I explained earlier, it can be heavy.
I think we should wait for other users comments.



  when i select a souce of project automatically select this project as
 current
 

Understand that in hbIDE source editing and project management 
are two separate actions. BTW what purpose will it solve ?



  Made possible add documentation to harbour using hbide
 

I was waiting for Vailton's or Bacco's applications.
Ok, I will provide it here in hbIDE soon. Are anybody willing 
to have embedded documentation in sources ? And for that 
matter, such documentation will be pulled as prototypes are 
pulled and presented in same way as Harbour help does.



  Simple keystroke for open harbour help (f1) and go to selected function
 

How do you want F1 to work ? Either of the two actions can be 
carried out, open the help dialog and if current cursor is on some 
Harbour function name, that is brought to focus. Right ?




  mark breakpoint  visual debug
 

I have least knowledge of debugger feature in Harbour.
Someone has to help me in this direction.




  column mode in editor
 

This is the toughest part in hbIDE. In the past I have 
failed on few tries. Still I do not know how to. Infact it needs
extended lines which I have no clues, how to in Qt.



  extend intellisense capabillty
 

Please jot down all what should be there.
Prototype tooltip and functions completion is what I know
of, what others.



 Follow are requested from other user  that i have received via mail
 is Possible use with xharbour or xbase++?
 

Yes, this is next logical step to make hbIDE more useful.
Anybody to help in this direction ?



 is possible use via command line for edit a project or a prg or rc?
 

I do not understand what you mean by command-line.
Once hbIDE is on, bring any source you want to edit, what is the issue.



 Is possible define the structure of file like fromfoxpro modi stru
 command?
  Integrate Dot prompt dbase functionaly
 

I need detailed analysis what you are asking here?
Dot prompt ( hbRUN.exe ) can be implemented though, I will try.




-
 enjoy hbIDEing...
Pritpal Bedi 
_a_student_of_software_analysis__design_
-- 
View this message in context: 
http://n2.nabble.com/hbIDE-Let-s-review-tp4717833p4719223.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: hbIDE - Let's review



Viktor Szakáts wrote:
 
 1) To fix the foundation and once and for all 
the GPFs on all platforms / compiler 
supported by hbide / QT.
 

Here, perhaps, we need Przemek's help.
I did whatever I could thought. I have requested
Przemek for some clarifications, the answer to 
which may lead to resolving this issue.



 2) To fix .ini file handling to be standard.
 3) Related: Merge dangling secondary .ini and similar 
config files into the central .ini.
 

Why we are concerned about these points, BTW ?
It is an application and developer knows best his 
abilities/shortcomings. This is how I could implement 
all the coordinates I needed. Cassle is built and changing 
the foundation is difficult if not impossible. 

All other config files can  makeup into the central 
file. because of their different formats. .tag, .skl, .env
has some specific differences. May be someone can help
to merge them.



 4) Related: To solve storing settings on *nix 
platforms. On these platforms you don't 
store settings in .ini file in current dir.
 

I do not know the behavior of nixes in this regard.
If .ini extension is the concern, we can change
them to somethng else. Some nix user has to 
jump in.



 5) To use hbmk2 for format conversion.
 

This is not a big issue. I will do in next commit.



 6) To make the decision: .ui or .uic and stick to 
only one.
 

.uic. It is the only format in use currently.



 7) Future: To honor formatting and original comments 
when saving .hbp files.
 

Yep, absolutely needed.


-
 enjoy hbIDEing...
Pritpal Bedi 
_a_student_of_software_analysis__design_
-- 
View this message in context: 
http://n2.nabble.com/hbIDE-Let-s-review-tp4717833p4719288.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: hbIDE - Let's review

Hi,

1) To fix the foundation and once and for all
the GPFs on all platforms / compiler
supported by hbide / QT.

Here, perhaps, we need Przemek's help.
I did whatever I could thought. I have requested
Przemek for some clarifications, the answer to
which may lead to resolving this issue.

2) To fix .ini file handling to be standard.
3) Related: Merge dangling secondary .ini and similar
config files into the central .ini.

Why we are concerned about these points, BTW ?

Because this is what can make hbide different from
the other (loosely engineered) ide's that one can
find on the internet.

Because it shows that you/we pay attention to details,
and care about the product.

Because this is the spirit we follow when designing
other parts of Harbour.

Because current static update method doesn't play
when in multiuser scenarios. (f.e. hbide is shared
on a network drive, or used in a terminal server
environment)

Just to name four. BTW, you asked for improvements
requests, and this one is IMO an important one.

It is an application and developer knows best his
abilities/shortcomings. This is how I could implement
all the coordinates I needed. Cassle is built and changing
the foundation is difficult if not impossible.

Never impossible. Now it's a straight no brainer
as not many ppl are using hbide yet.

All other config files can makeup into the central
file. because of their different formats. .tag, .skl, .env
has some specific differences. May be someone can help
to merge them.

It's not an 'all or nothing' thing. Just don't use
additional files unless absolutely necessary, that's
all.

Did you try HB_INI*() functions?

BTW, we're not even obliged to use a relatively
complicated .ini format. A simple flat format
is much easier to handle. F.e. this one also
stays compatible with .ini standard:

F.e.:
---
[hbide]
global.MainWindowGeometry=-4,-4,1291,814,
global.ProjectTreeVisible=1
global.FunctionListVisible=0
global.RecentTabIndex=-1
global.CurrentProject=
global.GotoDialogGeometry=
global.FindDialogGeometry=
global.CurrentTheme=City Lights
global.CurrentCodec=
global.PathMk2=
global.PathEnv=
global.CurrentEnvironment=
global.CurrentFind=
global.CurrentFolderFind=
global.CurrentReplace=
global.CurrentView= Stats
CurrentHarbour=
PROJECTS=F:\work\harbour\harbour\contrib\hbide\config.hbp,...
FILES=
RECENTFILES=f:/work/harbour/harbour/contrib/hbide/idetags.prg;f:/work/harbour/harbour/contrib/hbide/ideeditor.prg;f:/work/harbour/harbour/contrib/hbide/idedocks.prg
RECENTPROJECTS=f:/work/harbour/harbour/contrib/hbide/hbide.hbp
---

You can easily add the QT settings to that format.

4) Related: To solve storing settings on *nix
platforms. On these platforms you don't
store settings in .ini file in current dir.

I do not know the behavior of nixes in this regard.
If .ini extension is the concern, we can change
them to somethng else. Some nix user has to
jump in.

It's not the extension, it's the placement.

Probably '${HOME}/.hbide' should be the dir
to store .ini-like stuff on *nix. On Windows,
this could be '%APPDATA%\.hbide' dir, on OS/2
I don't know.

As for resources stuff, I don't know, probably
best would be to incorporate all of them right
into the executable in some ways, otherwise hbide
will need an installer to place these to the
expected on platform location. Or some *nix
users will give better ideas.

5) To use hbmk2 for format conversion.

This is not a big issue. I will do in next commit.

Thanks.

6) To make the decision: .ui or .uic and stick to
only one.

.uic. It is the only format in use currently.

I can see .ui files in SVN. If they are not used,
maybe they can be deleted to avoid confusion.

7) Future: To honor formatting and original comments
when saving .hbp files.

Yep, absolutely needed.

OK.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14141] trunk/harbour

Revision: 14141
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14141view=rev
Author:   vszakats
Date: 2010-03-11 23:40:40 + (Thu, 11 Mar 2010)

Log Message:
---
2010-03-12 00:39 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
  * src/rtl/filesys.c
! Fixed fs_win_get_drive() to return zero (instead of -1) 
  when drive letter wasn't returned by Windows API.
  (it's not clear what is the proper error behavior here)
! Fixed fs_win_set_drive() to apply upper limit on input 
  parameter.

  * contrib/rddsql/sddfb/sddfb.c
* Minor formatting.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/rddsql/sddfb/sddfb.c
trunk/harbour/src/rtl/filesys.c


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: SF.net SVN: harbour-project:[14140] trunk/harbour

2010-03-11 Thread Jacek Kubica

Hello Viktor,

vusn Revision: 14140
vusn   
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14140view=rev
vusn Author:   vszakats
vusn Date: 2010-03-11 22:28:22 + (Thu, 11 Mar 2010)

vusn Log Message:
vusn ---
vusn 2010-03-11 23:27 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
vusn   * contrib/rddsql/sddfb/sddfb.c
vusn ! Few cleanups in the FB RDDSQL interface (macro and type usage).
vusn ; It's not an attempt to fix recently reported bugs on the list.

In fact - bug still exist, but now after error program exit
without neverending loop as previously.

Error SDDFB/1909  Fetch error (DOS Error 335544569)
Called from DBUSEAREA(0)
Called from MAIN(46)
c:\Harbour\contrib\rddsql\sddfb\tests

Thanks and regards!

Jacek Kubica


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[14142] trunk/harbour

Revision: 14142
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14142view=rev
Author:   vszakats
Date: 2010-03-12 01:11:58 + (Fri, 12 Mar 2010)

Log Message:
---
2010-03-12 02:10 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
  * contrib/hbssl/evpmd.c
! Disabled md2 support for = 1.0.0 OpenSSL versions.
  Seems they dropped it.

  * contrib/hbssl/ssl.c
  * contrib/hbssl/x509.c
  * contrib/hbssl/sslctx.c
! Disabled some code parts which didn't compile with
  = 1.0.0 OpenSSL versions. This is not the right fix,
  but I just can't figure what went wrong (or what
  has been changed) in OpenSSL which cases it. There
  is something wrong around 'X509_NAME' symbol.

  * utils/hbmk2/hbmk2.prg
  * config/beos/gcc.mk
  * config/bsd/gcc.mk
  * config/wce/mingwarm.mk
  * config/darwin/gcc.mk
  * config/hpux/gcc.mk
  * config/win/mingw.mk
  * config/win/cygwin.mk
  * config/linux/gcc.mk
  * config/linux/icc.mk
  * config/os2/gcc.mk
  * config/sunos/gcc.mk
- Deleted '-pipe' option. Efficient, but buggy. It didn't take
  too long to bump into the problem: On build error, the
  .o file is generated with some dummy content, so a second
  build attempt will silently make build errors ignored.

  * contrib/rddsql/sddfb/sddfb.c
* Minor formatting.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/config/beos/gcc.mk
trunk/harbour/config/bsd/gcc.mk
trunk/harbour/config/darwin/gcc.mk
trunk/harbour/config/hpux/gcc.mk
trunk/harbour/config/linux/gcc.mk
trunk/harbour/config/linux/icc.mk
trunk/harbour/config/os2/gcc.mk
trunk/harbour/config/sunos/gcc.mk
trunk/harbour/config/wce/mingwarm.mk
trunk/harbour/config/win/cygwin.mk
trunk/harbour/config/win/mingw.mk
trunk/harbour/contrib/hbssl/evpmd.c
trunk/harbour/contrib/hbssl/ssl.c
trunk/harbour/contrib/hbssl/sslctx.c
trunk/harbour/contrib/hbssl/x509.c
trunk/harbour/contrib/rddsql/sddfb/sddfb.c
trunk/harbour/utils/hbmk2/hbmk2.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: hbIDE - Let's review