[Harbour] Re: Documentation storm on user's list

[pete_westg]

στις 29/05/2010 00:42, O/H Pritpal Bedi έγραψε:



Ok, I commit to write documentation, how much you will pay ?


Certainly not less than the current market price[*] for similar products.

(and of course, I'd prefer it to be an under-official-leadership 
initiative.)




Users of Harbour can pledge how much one is willing to pay,
pledge only on this list, do not pay now, and if the total figure
will match my expectations, I will start writing.
You will pay when I will at certain stage.



For sure, your suggested terms are fairly reasonable, however..

> Accepted ?

..I'd prefer to we follow a "Harbour-Fund" financing model. That is, we 
start making donations to a common-treasure and let project leaders 
decide and make "hiring" agreements for manual creation, or whatever 
would help project's improvement.


But, of course, let's hear other harbour followers opinions.






[*] Okay! plus the beers, at the release-day feasts.
( 12 bottles maximum and no more.. ;) )

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

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

[Viktor Szakáts]

Hi,

> bcc32.exe   -I. -I../../../../../include -q -tWM -CP437 -w -Q -w-sig- -d -6
> -O2
> -OS -Ov -Oi -Oc -DHB_LEGACY_TYPES_OFF  -I"c:\bcc582\bin\bcc32.exe
> c:\bcc582\bin\
> ..\Include" -DHB_GC_AUTO -DHB_FM_STATISTIC  -ohbpp_dyn.obj -DHB_DYNLIB  -c
> ../..
> /../hbpp.c
> ../../../hbpp.c:
> ilink32.exe  -L"c:\bcc582\bin\bcc32.exe c:\bcc582\bin\..\Lib" 
> -L"c:\bcc582\bin\bcc32.exe c:\bcc582\bin\..\Lib\PSDK" 
> -L"..\..\..\..\..\lib\win\bcc" -Gn -Tpe  
> c0x32.obj hbpp.obj, "..\..\..\..\..\bin\win\bcc\hbpp.exe", nul, hbnortl
> hbcommon kernel32 user32 ws2_32 advapi32 gdi32 cw32mt import32,,

Again some weird local configuration problem.

Probably doubly included BCC dir in PATH. I've just 
updated INSTALL yesterday to highlight this very problem.

I'd like to ask all users to pay more attention to 
messages on this list, and particularly to INSTALL docs. 
Ppl cry for docs, but don't read what's available.

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:[14633] trunk/harbour

[vszakats]

Revision: 14633
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14633&view=rev
Author:   vszakats
Date: 2010-05-29 02:28:37 + (Sat, 29 May 2010)

Log Message:
---
2010-05-29 04:28 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * utils/hbmk2/hbmk2.prg
! Fixed silly variable initialization bug after last commit.

  * contrib/hbwin/wapi_shellapi.c
! Fixed WAPI_SHELLEXECUTE() having HB_PARSTRDEF() one 
  position off.

  * examples/rddado/tests/access1.prg
* Minor update. Still doesn't work.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbwin/wapi_shellapi.c
trunk/harbour/examples/rddado/tests/access1.prg
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

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

[Itamar Lins]

Em 28/5/2010 21:39, 
vouch...@users.sourceforge.net escreveu:

Revision: 14632
   
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14632&view=rev
Author:   vouchcac
Date: 2010-05-29 00:39:20 + (Sat, 29 May 2010)

Log Message:
---
2010-05-28 17:27 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
   + contrib/gtwvg/tests/demowvg.hbp
 + Project definition.

   + contrib/gtwvg/tests/wvgactivex.prg
   + contrib/gtwvg/tests/wvgcuigdialog.prg
   + contrib/gtwvg/tests/wvgdyndialogs.prg
   + contrib/gtwvg/tests/wvgmodal.prg
   + contrib/gtwvg/tests/wvgqt.prg
   + contrib/gtwvg/tests/wvgtbrowser.prg
   + contrib/gtwvg/tests/wvgutilities.prg
   + contrib/gtwvg/tests/wvgwvtclasses.prg
   + contrib/gtwvg/tests/wvgxbp.prg
 + Code organized in logical units.


Hi!
If possible make example of window maxmized, etc step by step, to future 
migration of users the WVW.


Best regards,
Itamar M. Lins Jr.

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

Re: [Harbour] Problem Building Harbour SVN 2010-05-28 17:27 UTC-0800

[Bruno Luciani]

Try using Mingw

Bruno

2010/5/28 Mario H. Sabado 

>
> Hi,
>
> I have encountered below problem when building above SVN.
>
> Thanks,
> Mario
> =
> ! Making shared version of Harbour binaries...
> ./bin/win/bcc\hbmk2 -quiet -lang=en -q0 -shared utils/hbformat/hbformat.hbp
> -o${HB_BIN_INSTALL}/hbformat-dll
> Error BASE/1068  Argument error: array access (Quit)
> Error BASE/1068  Argument error: array access
> Called from HBMK2(0)
> Called from MAIN(0)  ./bin/win/bcc\hbmk2 -quiet -lang=en -q0 -shared
> utils/hbi18n/hbi18n.hbp -o${HB_BIN_INSTALL}/hbi18n-dll
> Error BASE/1068  Argument error: array access (Quit)
> Error BASE/1068  Argument error: array access
> Called from HBMK2(0)
> Called from MAIN(0)  ./bin/win/bcc\hbmk2 -quiet -lang=en -q0 -shared
> utils/hbmk2/hbmk2.hbp -o${HB_BIN_INSTALL}/hbmk2-dll
> Error BASE/1068  Argument error: array access (Quit)
> Error BASE/1068  Argument error: array access
> Called from HBMK2(0)
> Called from MAIN(0)  ./bin/win/bcc\hbmk2 -quiet -lang=en -q0 -shared
> utils/hbrun/hbrun.hbp -o${HB_BIN_INSTALL}/hbrun-dll
> Error BASE/1068  Argument error: array access (Quit)
> Error BASE/1068  Argument error: array access
> Called from HBMK2(0)
> Called from MAIN(0)  ./bin/win/bcc\hbmk2 -quiet -lang=en -q0 -shared
> utils/hbtest/hbtest.hbp -o${HB_BIN_INSTALL}/hbtest-dll
> Error BASE/1068  Argument error: array access (Quit)
> Error BASE/1068  Argument error: array access
> Called from HBMK2(0)
> Called from MAIN(0)
> =
> ___
> 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] Problem Building Harbour SVN 2010-05-28 17:27 UTC-0800

[Mario H. Sabado]

Hi,

I have encountered below problem when building above SVN.

Thanks,
Mario
=
! Making shared version of Harbour binaries...
./bin/win/bcc\hbmk2 -quiet -lang=en -q0 -shared 
utils/hbformat/hbformat.hbp -o${HB_BIN_INSTALL}/hbformat-dll

Error BASE/1068  Argument error: array access (Quit)
Error BASE/1068  Argument error: array access
Called from HBMK2(0)
Called from MAIN(0)  ./bin/win/bcc\hbmk2 -quiet -lang=en -q0 -shared 
utils/hbi18n/hbi18n.hbp -o${HB_BIN_INSTALL}/hbi18n-dll

Error BASE/1068  Argument error: array access (Quit)
Error BASE/1068  Argument error: array access
Called from HBMK2(0)
Called from MAIN(0)  ./bin/win/bcc\hbmk2 -quiet -lang=en -q0 -shared 
utils/hbmk2/hbmk2.hbp -o${HB_BIN_INSTALL}/hbmk2-dll

Error BASE/1068  Argument error: array access (Quit)
Error BASE/1068  Argument error: array access
Called from HBMK2(0)
Called from MAIN(0)  ./bin/win/bcc\hbmk2 -quiet -lang=en -q0 -shared 
utils/hbrun/hbrun.hbp -o${HB_BIN_INSTALL}/hbrun-dll

Error BASE/1068  Argument error: array access (Quit)
Error BASE/1068  Argument error: array access
Called from HBMK2(0)
Called from MAIN(0)  ./bin/win/bcc\hbmk2 -quiet -lang=en -q0 -shared 
utils/hbtest/hbtest.hbp -o${HB_BIN_INSTALL}/hbtest-dll

Error BASE/1068  Argument error: array access (Quit)
Error BASE/1068  Argument error: array access
Called from HBMK2(0)
Called from MAIN(0)
=
___
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:[14632] trunk/harbour

[vouchcac]

Revision: 14632
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14632&view=rev
Author:   vouchcac
Date: 2010-05-29 00:39:20 + (Sat, 29 May 2010)

Log Message:
---
2010-05-28 17:27 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  + contrib/gtwvg/tests/demowvg.hbp
+ Project definition.

  + contrib/gtwvg/tests/wvgactivex.prg
  + contrib/gtwvg/tests/wvgcuigdialog.prg
  + contrib/gtwvg/tests/wvgdyndialogs.prg
  + contrib/gtwvg/tests/wvgmodal.prg
  + contrib/gtwvg/tests/wvgqt.prg
  + contrib/gtwvg/tests/wvgtbrowser.prg
  + contrib/gtwvg/tests/wvgutilities.prg
  + contrib/gtwvg/tests/wvgwvtclasses.prg
  + contrib/gtwvg/tests/wvgxbp.prg
+ Code organized in logical units.

  * contrib/gtwvg/tests/demowvg.prg
- Code moved to smaller modular sources as logical units.

This demo was written few years back and then at that point of time
no standradized make system was aavailable which led me to club
everything in one source. Now because we have an excellent hbMK2
in place so this move has been possible.

It is the first in series of reforms pertaining to GTWVG.
More are scheduled to be followed.

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

Added Paths:
---
trunk/harbour/contrib/gtwvg/tests/demowvg.hbp
trunk/harbour/contrib/gtwvg/tests/wvgactivex.prg
trunk/harbour/contrib/gtwvg/tests/wvgcuigdialog.prg
trunk/harbour/contrib/gtwvg/tests/wvgdyndialogs.prg
trunk/harbour/contrib/gtwvg/tests/wvgmodal.prg
trunk/harbour/contrib/gtwvg/tests/wvgqt.prg
trunk/harbour/contrib/gtwvg/tests/wvgtbrowser.prg
trunk/harbour/contrib/gtwvg/tests/wvgutilities.prg
trunk/harbour/contrib/gtwvg/tests/wvgwvtclasses.prg
trunk/harbour/contrib/gtwvg/tests/wvgxbp.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] Possible problem in wapi_shellexecute

[francesco perillo]

According to this microsoft page:
http://msdn.microsoft.com/en-us/library/bb762153%28VS.85%29.aspx
the third parameter (filename) is mandatory but in wapi_shellexecute
it is not...
HB_PARSTR( 3, &hFile  , NULL ),
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Documentation storm on user's list

[Pritpal Bedi]

pete_westg wrote:
> 
> (I don't know if this has been proposed before but) why don't you create 
> some kind of Harbour Fund? It could be used to accept donations, 
> contributions and, why not, for hired services (be it on-line help or 
> code-writing or support etc.)
> 

Ok, I commit to write documentation, how much you will pay ?

Users of Harbour can pledge how much one is willing to pay,
pledge only on this list, do not pay now, and if the total figure 
will match my expectations, I will start writing.

You will pay when I will at certain stage.

Accepted ?




-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/Documentation-storm-on-user-s-list-tp5107834p5114768.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: Documentation storm on user's list

[pete_westg]

στις 28/05/2010 15:23, O/H Viktor Szakáts έγραψε:



Pls remember that even such _quite well documented_, _fully open_
and long time known systems as Linux, have several companies
_earning_ large sums of money by supporting them (f.e. Red Hat),


(I don't know if this has been proposed before but) why don't you create 
some kind of Harbour Fund? It could be used to accept donations, 
contributions and, why not, for hired services (be it on-line help or 
code-writing or support etc.)



---
Pete

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

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

[Massimo Belgrano]

i have tried last version with mingw
compile without error but...
C:\harbour\contrib\hbide>hbmk2 hbide.hbp -rebuild
hbmk2: Processing environment options: -compiler=mingw
Error BASE/1068  Argument error: array access (Quit)
Error BASE/1068  Argument error: array access
Called from HBMK2(0)
Called from MAIN(0)


2010/5/28 Rossine :
>
> Hello Viktor,
>
> When compiling "harbour/contrib/hbmisc/tests/testcall.prg"  I see this
> errors:
>
> [ERROR]
> L 1       C 1      A     546k     c:\harbour\contrib\hbmisc\tests\comp.log
> 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:\bcc582\bin\bcc32.exe
> hbmk2: Processando script local: hbmk.hbm
> hbmk2: Processando arquivo de configuração: c:\hrb_bcc\bin\hbmk.cfg
> hbmk2: Processando: ..\hbmisc.hbc
> Error BASE/1068  Argument error: array access (Quit)
> <*** End of File ***>
> [\ERROR]
>
> Best Regards,
>
> Rossine.
>


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

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

[Rossine]

Hello Viktor,

When compiling "harbour/contrib/hbmisc/tests/testcall.prg"  I see this
errors:

[ERROR]
L 1   C 1  A 546k c:\harbour\contrib\hbmisc\tests\comp.log
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:\bcc582\bin\bcc32.exe
hbmk2: Processando script local: hbmk.hbm
hbmk2: Processando arquivo de configuração: c:\hrb_bcc\bin\hbmk.cfg
hbmk2: Processando: ..\hbmisc.hbc
Error BASE/1068  Argument error: array access (Quit)
<*** End of File ***>
[\ERROR]

Best Regards,

Rossine.

-- 
View this message in context: 
http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-14631--trunk-harbour-tp28709244p28711515.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] Searching info regarding xbase++ parts

[Massimo Belgrano]

Class Hierarchy
http://www.xbaseprogrammer.com/ClassHierarchy.cgi
Mastering Dialog Windows in Xbase++
http://www.cjcom.net/articles/artmdi1.htm
http://www.cjcom.net/articles/artmdi2.htm

ALASKA XBASE++ ACTIVEX EXAMPLE
http://www.scribd.com/doc/220151/alaska-xbase-activex-example

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

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

[Rossine]

Hello Viktor,

Compiling with this release i see this errors:

[ERRORS]

Warning: 'strwild' not found in library
1 arquivo(s) copiado(s).
bcc32.exe   -I. -I../../../../../include -q -tWM -CP437 -w -Q -w-sig- -d -6
-O2
-OS -Ov -Oi -Oc -DHB_LEGACY_TYPES_OFF  -I"c:\bcc582\bin\bcc32.exe
c:\bcc582\bin\
..\Include" -DHB_GC_AUTO -DHB_FM_STATISTIC  -onortl.obj  -c ../../../nortl.c
../../../nortl.c:
tlib.exe  /P128   "..\..\..\..\..\lib\win\bcc\hbnortl.lib" -+nortl.obj
TLIB 4.5 Copyright (c) 1987, 1998 Borland International
Warning: 'nortl' not found in library
1 arquivo(s) copiado(s).
bcc32.exe   -I. -I../../../../../include -q -tWM -CP437 -w -Q -w-sig- -d -6
-O2
-OS -Ov -Oi -Oc -DHB_LEGACY_TYPES_OFF  -I"c:\bcc582\bin\bcc32.exe
c:\bcc582\bin\
..\Include" -DHB_GC_AUTO -DHB_FM_STATISTIC  -ohbpp.obj  -c ../../../hbpp.c
../../../hbpp.c:
bcc32.exe   -I. -I../../../../../include -q -tWM -CP437 -w -Q -w-sig- -d -6
-O2
-OS -Ov -Oi -Oc -DHB_LEGACY_TYPES_OFF  -I"c:\bcc582\bin\bcc32.exe
c:\bcc582\bin\
..\Include" -DHB_GC_AUTO -DHB_FM_STATISTIC  -ohbpp_dyn.obj -DHB_DYNLIB  -c
../..
/../hbpp.c
../../../hbpp.c:
ilink32.exe  -L"c:\bcc582\bin\bcc32.exe c:\bcc582\bin\..\Lib"
-L"c:\bcc582\bin\b
cc32.exe c:\bcc582\bin\..\Lib\PSDK" -L"..\..\..\..\..\lib\win\bcc" -Gn -Tpe  
c0
x32.obj hbpp.obj, "..\..\..\..\..\bin\win\bcc\hbpp.exe", nul, hbnortl
hbcommon k
ernel32 user32 ws2_32 advapi32 gdi32 cw32mt import32,,
Turbo Incremental Link 5.69 Copyright (c) 1997-2005 Borland
Fatal: Unable to open file 'KERNEL32.LIB'
mingw32-make[3]: *** [hbpp.exe] Error 2
rm hbpp.obj
mingw32-make[2]: *** [descend] Error 2
mingw32-make[1]: *** [pp.inst] Error 2
mingw32-make: *** [src.inst] Error 2
[/ERRORS]

Best Regards,

Rossine.

-- 
View this message in context: 
http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-14631--trunk-harbour-tp28709244p28711390.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: WVG problem.

[Massimo Belgrano]

In gtwvt work ok displayn GTWVT each 80 row
in gtwvg display olny 40 col

I am using 1920*1200 resolution
http://shup.com/Shup/350916/gtwvgjpg

2010/5/28 Pritpal Bedi 

>
>
> Massimo Belgrano wrote:
> >
> > sorry pritpal but what i miss?
> > Why not dispay entire row?
> >
> > I try but in 19
> >
> >
> >
> >SETMODE(25,80)
> >clear
> >FOR A=0 TO 24
> >  @ a,0 say
> >
> "1234567890123456789012345678901234567890123456789012345678901234567890123456789"
> >next a
> >
> >wait
> >
> >
>
> Test the code with GTWVT also and let me know what's the behavior.
>
>
-- 
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[Viktor Szakáts]

Hi Rossine,

> With this change, i have GPF down:

Thanks for your report, I've made the 
necessary correction, pls check again after r14631.

[ it's possible some more tweaks will be needed, 
f.e. original CALLDLL32 is very unsafe by directly 
modifying string buffers, so in the new compatibility 
version, such string parameters will have to be passed by 
reference. ]

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:[14631] trunk/harbour

[vszakats]

Revision: 14631
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14631&view=rev
Author:   vszakats
Date: 2010-05-28 16:51:23 + (Fri, 28 May 2010)

Log Message:
---
2010-05-28 18:51 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * contrib/hbmisc/calldll.prg
! Fixed to use Windows system .dll calling convention
  (stdcall) by default, to emulate original function's
  behavior. Note that on non-Windows systems, calling 
  convention will be set to the default (cdecl).

  * contrib/hbmisc/tests/testcall.prg
* Replace examples with a Windows system .dll call.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbmisc/calldll.prg
trunk/harbour/contrib/hbmisc/tests/testcall.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:[14630] trunk/harbour

[vszakats]

Revision: 14630
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14630&view=rev
Author:   vszakats
Date: 2010-05-28 16:41:43 + (Fri, 28 May 2010)

Log Message:
---
2010-05-28 18:28 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * utils/hbmk2/hbmk2.prg
+ Added untested, experimental support for -reqpkg=/reqpkgs=
  (.hbp/.hbc) options. F.e. '-reqpkg=libcurl' option causes
  hbmk2 to query library, library path and include path
  information from 'pkg-config' tool and if not found using
  '*-config' script, and to automatically pass these information
  to C compiler/linker. In addition, it will automatically add
  a macro named HBMK2_HAS_LIBCURL to C compiler cmdline, so
  that the sources get to know that this package was found.
; NOTE: Nothing is finalized, it is still a question how to
setup obligatory and optional components, current
implementation is rather a mixture, but anyway pls
feel free to test it. It's also a question how to merge
this method with the -inctrypath/-reqheader one.
Later we can consider adopting extra C flags, too,
and it can be extended to know about more package
detection methods (even platform dependent ones can
be used if they adhere to more or less the same
principle of 'pkgname->IN incpaths/libpaths/libs->OUT')
Thanks to Tamas Tevesz for sparking the idea.

Modified Paths:
--
trunk/harbour/ChangeLog
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

[Harbour] Re: WVG problem.

[Pritpal Bedi]

Massimo Belgrano wrote:
> 
> sorry pritpal but what i miss?
> Why not dispay entire row?
> 
> I try but in 19
> 
> 
> 
>SETMODE(25,80)
>clear
>FOR A=0 TO 24
>  @ a,0 say
> "1234567890123456789012345678901234567890123456789012345678901234567890123456789"
>next a
> 
>wait
> 
> 

Test the code with GTWVT also and let me know what's the behavior.


-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/WVG-problem-tp5113392p5113806.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] SF.net SVN: harbour-project:[14621] trunk/harbour

[Rossine]

Hello Viktor,

With this change, i have GPF down:

[GPF]


Application Internal Error - C:\qi\WIN\objetos\EDITOR\qisystray.exe
Terminated at: 2010.05.28 13:18:58
Info: QI_Sistemas
Unrecoverable error 6005: Exception error: 

Exception Code:C027
Exception Address:7C80DEAC
EAX:  EBX:  ECX:  EDX:
ESI:  EDI:  EBP:0013F6CC
CS:EIP:001B:7C80DEAC  SS:ESP:7C800023:0013F6BC
DS:0023  ES:130023  FS:003B  GS:
Flags:0202
CS:EIP: 5D 5F 5E 5B 8B E5 5D C3 8B 4C 24 04 F7 41 04 06
SS:ESP: 0013F6CC 7C816FF0  0013FFE0 0013F6F0 7C839B65 0013FFE0
0013F6F0    0013F7DC 0013F7F8 0013F714 7C9032A8
0013F7DC

C stack:
EIP: EBP:   Frame: OldEBP, RetAddr, Params...
7C80DEAC 0013F6CC   0013F6F0 7C839B65 0013FFE0 0013F6F0 
  0013F7DC 0013F7F8
7C839B65 0013F6F0   0013F714 7C9032A8 0013F7DC 0013FFE0 0013F7F8
0013F7B0 0013FFB0 7C9032BC 0013FFE0
7C9032A8 0013F714   0013F7C4 7C90327A 0013F7DC 0013FFE0 0013F7F8
0013F7B0 7C839AF0 0001 0013F7DC 0013FFE0
7C90327A 0013F7C4   0013FAD8 7C90E48A  0013F7F8 0013F7DC
0013F7F8 C005   00697EE4
7C90E48A 0013FAD8   0013FAF0 0050FDD8 01A7DEC4  0001
01BB8AF0
0050FDD8 0013FAF0   0013FBC8 005169B7 01A7DEC4 0101 
0001   0004 01BB8AC4


Modules:
0x0040 0x004F6000 C:\qi\WIN\objetos\EDITOR\qisystray.exe
0x7C90 0x000B6000 C:\WINDOWS\system32\ntdll.dll
0x7C80 0x000FF000 C:\WINDOWS\system32\kernel32.dll
0x1217 0x0015F000 C:\WINDOWS\system32\ACE32.DLL
0x77BE 0x8000 C:\WINDOWS\system32\VERSION.dll
0x71AE 0x00012000 C:\WINDOWS\system32\MPR.dll
0x77F5 0x000AB000 C:\WINDOWS\system32\ADVAPI32.dll
0x77DB 0x00092000 C:\WINDOWS\system32\RPCRT4.dll
0x77F2 0x00011000 C:\WINDOWS\system32\Secur32.dll
0x7E36 0x0009 C:\WINDOWS\system32\USER32.dll
0x77E5 0x00048000 C:\WINDOWS\system32\GDI32.dll
0x71A9 0xA000 C:\WINDOWS\system32\WSOCK32.dll
0x71A7 0x00017000 C:\WINDOWS\system32\WS2_32.dll
0x77BF 0x00058000 C:\WINDOWS\system32\msvcrt.dll
0x71A6 0x8000 C:\WINDOWS\system32\WS2HELP.dll
0x773B 0x00103000
C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03\COMCTL32.DLL
0x77EA 0x00076000 C:\WINDOWS\system32\SHLWAPI.dll
0x7638 0x00048000 C:\WINDOWS\system32\COMDLG32.DLL
0x7C9C 0x0081D000 C:\WINDOWS\system32\SHELL32.dll
0x1000 0x00251000 C:\qi\WIN\objetos\EDITOR\FREEIMAGE.DLL
0x0090 0x0049B000 C:\ARQUIV~1\Griaule\FINGER~1\bin\GRFINGER.DLL
0x0036 0x00015000 C:\WINDOWS\system32\pthreadVC2.dll
0x76D4 0x00019000 C:\WINDOWS\system32\iphlpapi.dll
0x76BD 0xB000 C:\WINDOWS\system32\PSAPI.DLL
0x6310 0x00025000 C:\WINDOWS\system32\LIBPQ.DLL
0x1C00 0x6000 C:\WINDOWS\system32\comerr32.dll
0x00DA 0x00106000 C:\WINDOWS\system32\libeay32.dll
0x0038 0xD000 C:\WINDOWS\system32\libintl-2.dll
0x00EB 0x000DB000 C:\WINDOWS\system32\libiconv-2.dll
0x00F9 0x00081000 C:\WINDOWS\system32\krb5_32.dll
0x7676 0x9000 C:\WINDOWS\system32\SHFOLDER.DLL
0x0039 0x00032000 C:\WINDOWS\system32\ssleay32.dll
0x75B8 0x00021000 C:\WINDOWS\system32\MSVFW32.DLL
0x76B2 0x0002E000 C:\WINDOWS\system32\WINMM.dll
0x774C 0x0013D000 C:\WINDOWS\system32\OLE32.DLL
0x7710 0x0008B000 C:\WINDOWS\system32\OLEAUT32.DLL
0x72FB 0x00026000 C:\WINDOWS\system32\WINSPOOL.DRV
0x7636 0x0001D000 C:\WINDOWS\system32\IMM32.DLL
0x5B1C 0x00038000 C:\WINDOWS\system32\uxtheme.dll
0x746E 0x0004B000 C:\WINDOWS\system32\MSCTF.dll
0x634B 0x0001D000 C:\Documents and Settings\All Users\Dados de
aplicativos\Real\RealPlayer\BrowserRecordPlugin\Chrome\Hook\rpchromebrowserrecordhelper.dll
0x4EB6 0x001AB000
C:\WINDOWS\WinSxS\x86_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.6001.22319_x-ww_f0b4c2df\gdiplus.dll
0x7C3A 0x0007B000 C:\WINDOWS\system32\MSVCP71.dll
0x7C34 0x00056000 C:\WINDOWS\system32\MSVCR71.dll
0x7719 0x000A9000 C:\WINDOWS\system32\Wininet.dll
0x77A6 0x00095000 C:\WINDOWS\system32\CRYPT32.dll
0x77B0 0x00012000 C:\WINDOWS\system32\MSASN1.dll
0x76EC 0x0003C000 C:\WINDOWS\system32\RASAPI32.DLL
0x76E7 0x00012000 C:\WINDOWS\system32\rasman.dll
0x5BCB 0x00054000 C:\WINDOWS\system32\NETAPI32.dll
0x76E9 0x0002F000 C:\WINDOWS\system32\TAPI32.dll
0x76E6 0xE000 C:\WINDOWS\system32\rtutils.dll
0x77C5 0x00024000 C:\WINDOWS\system32\msv1_0.dll
0x7677 0xC000 C:\WINDOWS\system32\cryptdll.dll
0x769A 0x000B4000 C:\WINDOWS\system32\USERENV.dll
0x77B2 0x00022000 C:\WINDOWS\system32\Apphelp.dll

Called from HB_DYNCALL(0)
Called from HB_DYNACALL1(0) in ../../../calldll.prg
Called from CALLDLL32(0) in ../../../calldll.prg
Called from ISCONNECTED(6365) in ..\geral\qilibm.prg
Called from M

Re: [Harbour] Re: WVG problem.

[Massimo Belgrano]

sorry pritpal but what i miss?
Why not dispay entire row?

I try but in 19

// hbmk2 wvg.prg -gtwvg -gui
REQUEST HB_GT_WVG_DEFAULT
REQUEST HB_GT_WVG
#INCLUDE "HBGTINFO.CH"
function main
   set color to "N/W,N/BG,,,N/W*"
   cls
   SETMODE(25,80)
   hb_gtInfo( HB_GTI_ICONFILE, "sample.ico" )
   hb_gtInfo( HB_GTI_WINTITLE, "Programm Title" )
   Hb_GtInfo( HB_GTI_SELECTCOPY,.T.)
   Hb_GtInfo( HB_GTI_RESIZABLE, .T. )
   HB_GTINFO( HB_GTI_CLOSABLE, .T. )
   HB_GTINFO( HB_GTI_RESIZABLE, .T. )
   HB_GTINFO( HB_GTI_CODEPAGE, 255 )
   Hb_GTInfo(HB_GTI_MOUSESTATUS, 1 )
   screenWidth:= HB_GTINFO( HB_GTI_DESKTOPWIDTH )
   screenHEIGHT:=HB_GTINFO( HB_GTI_DESKTOPHEIGHT )
   HB_GTInfo(HB_GTI_FONTNAME, "Courier New")
   HB_GTInfo(HB_GTI_FONTQUALITY,HB_GTI_FONTQ_HIGH )
   if screenWidth >=  1920
Hb_GtInfo( HB_GTI_FONTWIDTH, 21  )
HB_GTInfo(HB_GTI_FONTSIZE, 40)
   ELSEIF screenWidth >= 1600   // 1280 *960
Hb_GtInfo( HB_GTI_FONTWIDTH, 18  )
  HB_GTInfo(HB_GTI_FONTSIZE, 32)
   elseif screenWidth >= 1280   // 1280 *960
Hb_GtInfo( HB_GTI_FONTWIDTH, 13  )
  HB_GTInfo(HB_GTI_FONTSIZE, 20) // 15*80=1200
36*25=900
   elseif screenWidth >= 1024   // 1024*760
Hb_GtInfo( HB_GTI_FONTWIDTH, 12.5  )
  HB_GTInfo(HB_GTI_FONTSIZE, 20)
   elseif screenWidth >= 800
Hb_GtInfo( HB_GTI_FONTWIDTH, 10  )
  HB_GTInfo(HB_GTI_FONTSIZE, 18)
   ELSE
  Hb_GtInfo( HB_GTI_FONTWIDTH, 14  )
  HB_GTInfo(HB_GTI_FONTSIZE, 8)
   ENDIF
   SETMODE(25,80)
   clear
   FOR A=0 TO 24
 @ a,0 say
"1234567890123456789012345678901234567890123456789012345678901234567890123456789"
   next a

   wait



2010/5/28 Pritpal Bedi 

>
> Hi
>
> A little update, I have examined the sources.
>
> 1. These two calls are not readonly. These also sets the SetMode()
>depending upon the width and height you supply as pixels. So beware.
>
> 2. The correct approach is:
>
>   To get the entire screen width/height
>
>   nScrWidth := hb_getInfo( HB_GTI_DESKTOPWIDTH )
>   nScrHeight := hb_gtInfo( HB_GTI_DESKTOPHEIGHT )
>
>   and then base your font parameters onto them.
>
>   HB_GTI_SCREENWIDTH/HEIGHT gives you, and optionally sets
>   ( which you must not unless you are aware what it will change ), the WVG
>   console width and height in pixels.
>
>
>
___
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:[14629] trunk/harbour

[vszakats]

Revision: 14629
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14629&view=rev
Author:   vszakats
Date: 2010-05-28 15:32:31 + (Fri, 28 May 2010)

Log Message:
---
2010-05-28 17:31 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * src/common/hbver.c
+ Fine tuned SunPro version detection.
  Patch submitted by Tamas Tevesz.

  * contrib/hbwin/win_shell.c
  * contrib/hbwin/tests/testcopy.prg
! WIN_SHFILEOPERATION() fixed after initial upload.
+ Added more test code.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbwin/tests/testcopy.prg
trunk/harbour/contrib/hbwin/win_shell.c
trunk/harbour/src/common/hbver.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: WVG problem.

[Pritpal Bedi]

Hi

A little update, I have examined the sources.

1. These two calls are not readonly. These also sets the SetMode() 
depending upon the width and height you supply as pixels. So beware.

2. The correct approach is:

   To get the entire screen width/height
   
   nScrWidth := hb_getInfo( HB_GTI_DESKTOPWIDTH )
   nScrHeight := hb_gtInfo( HB_GTI_DESKTOPHEIGHT )

   and then base your font parameters onto them.

   HB_GTI_SCREENWIDTH/HEIGHT gives you, and optionally sets 
   ( which you must not unless you are aware what it will change ), the WVG 
   console width and height in pixels.


-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/WVG-problem-tp5113392p5113581.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: WVG problem.

[Itamar Lins]

Em 28/5/2010 12:01, Pritpal Bedi escreveu:


SCWIDTH:=HB_GTINFO(HB_GTI_SCREENWIDTH) is readonly

scHEIGHT:=HB_GTINFO(HB_GTI_SCREENHEIGHT) is readonly

You cannot set the screenwidth/height of an console.
This can only be done in SetMode() or through font manipulation.

Yes.
But the return HB_GTINFO(HB_GTI_SCREENWIDTH) is correct ?
Because my desktop is 1280 pixels and return is 640 :-(

For example:
ANNOUNCE HB_GTSYS
REQUEST HB_GT_GUI
Function Main

...
   elseif screenWidth >= 1024   // 1024*760

Hb_GtInfo( HB_GTI_FONTWIDTH, 12.5  )
HB_GTInfo(HB_GTI_FONTSIZE, 20)

   elseif screenWidth >= 800

Hb_GtInfo( HB_GTI_FONTWIDTH, 10  )
HB_GTInfo(HB_GTI_FONTSIZE, 18)

   ELSE
...

Function HB_GTSYS()
   REQUEST HB_GT_WVG_DEFAULT
   REQUEST HB_GT_WVT
   REQUEST HB_GT_WGU
   Return NIL

Not working.

Best regards,
Itamar M. Lins Jr.


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

[Harbour] Re: WVG problem.

[Pritpal Bedi]

Itamar Lins-2 wrote:
> 
> 
> My desktop is 1280 X 800 pixels.
> I am using function:
> 
> SCWIDTH:=HB_GTINFO(HB_GTI_SCREENWIDTH, HB_GTINFO(HB_GTI_DESKTOPWIDTH))
> 
> scHEIGHT:=HB_GTINFO(HB_GTI_SCREENHEIGHT,HB_GTINFO(HB_GTI_DESKTOPHEIGHT)-50)
> 
> msginfo(str(scWIDTH)) //return 640
> msginfo(str(scHEIGHT)) //return 400
> 
> How to the function to get real 1280 x 800 ?
> 


SCWIDTH:=HB_GTINFO(HB_GTI_SCREENWIDTH) is readonly

scHEIGHT:=HB_GTINFO(HB_GTI_SCREENHEIGHT) is readonly

You cannot set the screenwidth/height of an console.
This can only be done in SetMode() or through font manipulation.




-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/WVG-problem-tp5113392p5113445.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] WVG problem.

[Itamar Lins]

Hi!
My desktop is 1280 X 800 pixels.
I am using function:

SCWIDTH:=HB_GTINFO(HB_GTI_SCREENWIDTH, HB_GTINFO(HB_GTI_DESKTOPWIDTH))

scHEIGHT:=HB_GTINFO(HB_GTI_SCREENHEIGHT,HB_GTINFO(HB_GTI_DESKTOPHEIGHT)-50)

msginfo(str(scWIDTH)) //return 640
msginfo(str(scHEIGHT)) //return 400

How to the function to get real 1280 x 800 ?


Best regards,
Itamar M. Lins Jr.

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

[Harbour] fix sunpro ident

[Tamas TEVESZ]

i think this takes care of sunpros >=0x5100 (studio 12).

have no earlier ones readily installed, but they should stay ok.

Index: src/common/hbver.c
===
--- src/common/hbver.c  (revision 14628)
+++ src/common/hbver.c  (working copy)
@@ -739,30 +739,29 @@
 #elif defined( __SUNPRO_C )
 
pszName = "Sun C";
-   #if __SUNPRO_C < 0x600
+   #if __SUNPRO_C < 0x1000
   iVerMajor = __SUNPRO_C / 0x100;
   iVerMinor = ( __SUNPRO_C & 0xff ) / 0x10;
   iVerPatch = __SUNPRO_C & 0xf;
#else
-  /* Until someone at Sun somes up with a reliable way of identifying
- Sun Studio releases >= about 11. */
-  iVerMajor = iVerMinor = iVerPatch = 0;
-  hb_snprintf( szSub, sizeof( szSub ) - 1, " (ident 0x%X)", __SUNPRO_C );
+  iVerMajor = __SUNPRO_C / 0x1000;
+  iVerMinor = __SUNPRO_C / 0x10 & 0xff;
+  iVerMinor = iVerMinor / 16 * 10 + iVerMinor % 16;
+  iVerPatch = __SUNPRO_C & 0xf;
#endif
 
 #elif defined( __SUNPRO_CC )
 
pszName = "Sun C++";
-   #if __SUNPRO_CC < 0x600
-  pszName = "Sun C++";
+   #if __SUNPRO_CC < 0x1000
   iVerMajor = __SUNPRO_CC / 0x100;
   iVerMinor = ( __SUNPRO_CC & 0xff ) / 0x10;
   iVerPatch = __SUNPRO_CC & 0xf;
#else
-  /* Until someone at Sun somes up with a reliable way of identifying
- Sun Studio releases >= about 11. */
-  iVerMajor = iVerMinor = iVerPatch = 0;
-  hb_snprintf( szSub, sizeof( szSub ) - 1, " (ident 0x%X)", __SUNPRO_CC );
+  iVerMajor = __SUNPRO_CC / 0x1000;
+  iVerMinor = __SUNPRO_CC / 0x10 & 0xff;
+  iVerMinor = iVerMinor / 16 * 10 + iVerMinor % 16;
+  iVerPatch = __SUNPRO_CC & 0xf;
#endif
 
 #else

-- 
[-]

mkdir /nonexistentIndex: src/common/hbver.c
===
--- src/common/hbver.c	(revision 14628)
+++ src/common/hbver.c	(working copy)
@@ -739,30 +739,29 @@
 #elif defined( __SUNPRO_C )
 
pszName = "Sun C";
-   #if __SUNPRO_C < 0x600
+   #if __SUNPRO_C < 0x1000
   iVerMajor = __SUNPRO_C / 0x100;
   iVerMinor = ( __SUNPRO_C & 0xff ) / 0x10;
   iVerPatch = __SUNPRO_C & 0xf;
#else
-  /* Until someone at Sun somes up with a reliable way of identifying
- Sun Studio releases >= about 11. */
-  iVerMajor = iVerMinor = iVerPatch = 0;
-  hb_snprintf( szSub, sizeof( szSub ) - 1, " (ident 0x%X)", __SUNPRO_C );
+  iVerMajor = __SUNPRO_C / 0x1000;
+  iVerMinor = __SUNPRO_C / 0x10 & 0xff;
+  iVerMinor = iVerMinor / 16 * 10 + iVerMinor % 16;
+  iVerPatch = __SUNPRO_C & 0xf;
#endif
 
 #elif defined( __SUNPRO_CC )
 
pszName = "Sun C++";
-   #if __SUNPRO_CC < 0x600
-  pszName = "Sun C++";
+   #if __SUNPRO_CC < 0x1000
   iVerMajor = __SUNPRO_CC / 0x100;
   iVerMinor = ( __SUNPRO_CC & 0xff ) / 0x10;
   iVerPatch = __SUNPRO_CC & 0xf;
#else
-  /* Until someone at Sun somes up with a reliable way of identifying
- Sun Studio releases >= about 11. */
-  iVerMajor = iVerMinor = iVerPatch = 0;
-  hb_snprintf( szSub, sizeof( szSub ) - 1, " (ident 0x%X)", __SUNPRO_CC );
+  iVerMajor = __SUNPRO_CC / 0x1000;
+  iVerMinor = __SUNPRO_CC / 0x10 & 0xff;
+  iVerMinor = iVerMinor / 16 * 10 + iVerMinor % 16;
+  iVerPatch = __SUNPRO_CC & 0xf;
#endif
 
 #else
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: Documentation storm on user's list

[Viktor Szakáts]

> To put it an other way, the crucial subject today, is not any  more the open 
> source code. It is (and always was) the open knowledge.

Nobody ever promised that knowledge or mastery will automatically 
fly into the users' brains, just by having access to the information, 
be it open source, blueprints, scientific papers or the wikipedia.

Pls remember that even such _quite well documented_, _fully open_ 
and long time known systems as Linux, have several companies 
_earning_ large sums of money by supporting them (f.e. Red Hat), 
selling workforce who do actually understand the system and 
_translates_ that to knowledge for the benefit of customers/users, 
even in the form of documentation.

All of these require an _effort_. You can do this effort yourself, 
or you can ask other to do that. In latter case, you either pay 
for it or motivate them by other means. Second option seems more 
complicated with documentation (than with code) as it is huge work 
and the one who does it doesn't benefit from it in too many ways.

Looks like it's not enough to give something for free to expect 
any sort of return for it.

> Why we have such a brilliant and huge amount of excellent code, like Harbour 
> has become thanks to your (and all of developers) tremendous efforts and not 
> an analogous documentation?

See above.

> We said, it is difficult to create documentation. but if we think it better, 
> difficulty is not the main reason. The main reason is that nobody wants 
> documentation so much, nobody is "burned" to create it. and the deeper cause 
> of this, is the lack of belief to the great value of a documentation, is the 
> lack of belief to the vital significance of a manual, it is because we are 
> much eager for

I think nobody ever questioned that documentation and samples 
are nice and useful, or even crucial. That was never a question.

> Viktor, i 'm not interest to bugging you, (i don't know what exactly the 
> "bugging" is, or means, but if it is related to the activity of a bug, then i 
> think it's my time to start feeling offended. However, feeling offended or 
> not, doesn't cure my real displeasure to feel almost guilty because i can't 
> find a practical way to effectively contribute documentation.

Bugging is: "write documentation friendly code", "create samples", 
"create good comments"

Did you notice I created INSTALL, with 330 updates in the last 
15 months? Did you notice Przemek creating lots of e-mails which 
are better than most written documentation, or not to mention 
xhb-diff.txt, which is almost like an academic paper? Or I could 
mention docs created by Pritpal for HBIDE. Can you imagine how 
much time does it take to create these thing? If you don't, just 
keep on asking for more, or telling what you tell, you risk that 
some will find it as "bugging".

Overall, I see no lack in "lead by example" here... The problem 
is there is nobody to follow.

Demanding more without appreciating work already done is 
probably the surest motivation killer [ especially in open source, 
where appreciation is the most important (or only) motivation factor ].

> ___
> P.S. Strangely enough, i see no reaction to the challenging idea of 
> harbour-xhb merging. Does the harbour community think it was a joke or this 
> deafening silence express their glacial indifference about the future of 
> Harbour?

It wasn't a joke.

Viktor

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

Re: [Harbour] HBMK2 problem

[Mindaugas Kavaliauskas]

Hi,


On 2010.05.28 14:28, Horodyski Marek (PZUZ) wrote:

Mindaugas, I link APP with MinGW and use CAIRIO with libcairo-2.dll.
What compiler made this dll ?


MinGW latest TDM build (if you are talking about lib build by me, from 
www.dbtopas.lt/hrb



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

[Harbour] Re: Documentation storm on user's list

[pete_westg]

στις 27/05/2010 23:33, O/H smu johnson έγραψε:

Some thoughts,

On Thu, May 27, 2010 at 12:18 PM, pete_westg
mailto:pete_we...@yahoo.gr>>
wrote:

are you sure you have understood my words? I 'm afraid you don't!
What I am not sure for, is the reason for this misunderstanding.
Perhaps, is it due to my bad English or what?


-  Stating that Harbour's lack of documention is "straightly against to
the spirit of open source initiative" can be considered offensive by
many.  Who made you the spokesperson of the Open Source movement?  It
could be interpreted that your statement means their years of work were
done improperly.



Please don't put  words in my mouth that i never said. Or please show me 
even one instance of the word "Harbour" into my first post to which you 
are referring. There is not one! You have just "tailored" a phrase, by 
mixing your assumptions with cut-n-past parts of my lines, to base your 
claim that this (the tailored) statement "can be considered offensive by 
many".
I wonder what is the purpose of this conversation. Is it to accuse me, 
for my comments being "offensive", "strange", "insulting", "bugging" or 
whatever?  I can't say to someone "do or don't feel offended".  All I 
can do is to explain my point, and wish that through understanding, the 
reasons that make someone to feel offended would vanish. So, i must make 
it clear, that when i wrote > (this is my unaltered phrase)  i was not referring 
specifically to Harbour but rather i was expressing a general point, 
regarding the whole opensource case. and I believe, you don't need to be 
a spokesperson of the OS movement to speak up your thoughts about it.
I have a sentiment that the problem in present days is not just the open 
source code. you don't need to be a specialist to see it. Trillions 
lines of very good code have been written and quadrillions will be 
written in the close future. It is really amazing and all the respect 
belongs to the great developers. On the other hand we can't ignore the 
fact that we already have an infinite ocean of source code inside which 
we (the community/society) could sink or we could sail. I vote to sail! 
and the ship to sail and not sink, you guess it, is the documents.
To put it an other way, the crucial subject today, is not any  more the 
open source code. It is (and always was) the open knowledge.
And knowledge without documentations is simply impossible. Documentation 
is the vehicle of knowledge. documenting is to securing the ability to 
be able to use the brilliant "machines" that brilliant developers-brains 
have created.

Now, Viktor will come and accuse me: "Empty words, again."
Yes, I see it. I see the emptiness in the absence of manual. I see the 
emptiness in my inability to be useful in the subject.
And the question is still here, as you Viktor, say. Why we have no 
documentation?
Why we have such a brilliant and huge amount of excellent code, like 
Harbour has become thanks to your (and all of developers) tremendous 
efforts and not an analogous documentation? We said, it is difficult to 
create documentation. but if we think it better, difficulty is not the 
main reason. The main reason is that nobody wants documentation so much, 
nobody is "burned" to create it. and the deeper cause of this, is the 
lack of belief to the great value of a documentation, is the lack of 
belief to the vital significance of a manual, it is because we are much 
eager for source code and we are not interested for documentation, 
perhaps because is not so glorious to write documents compared to 
code-writing. obviously we lack a "documenting culture"( similar to 
coding culture), and for this to happen, perhaps we need empty words, 
even to just have something to filling up, even to just have something 
to keep the spark alive. as i see it there two directions. to get rid 
off of this documentation blah-blah, which means that we'll immediately 
stop bugging you the developers, or to keep searching ways how the goal 
of documentation will become true. Honestly, Viktor, i 'm not interest 
to bugging you, (i don't know what exactly the "bugging" is, or means, 
but if it is related to the activity of a bug, then i think it's my time 
to start feeling offended. However, feeling offended or not, doesn't 
cure my real displeasure to feel almost guilty because i can't find a 
practical way to effectively contribute documentation.


___
P.S. Strangely enough, i see no reaction to the challenging idea of 
harbour-xhb merging. Does the harbour community think it was a joke or 
this deafening silence express their glacial indifference about the 
future of Harbour?


---
Pete

___
Harbour mailing list (attachment size limit: 40KB)

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

[Viktor Szakáts]

> Hi Viktor,
> 
>>> For me this are two different things.
>>> 1. broken watcom binaries due to forces stack calling convention.
>> It's broken either way. Default is broken for OLE servers, 
>> special build is broken for non-watcom Harbour .dlls.
> 
> The default build is broken for any OLE code and maybe some other
> type of code. And it's broken for very long time. The problem was
> reported few times to this list in the past, i.e. in last year Marek
> reported it and because we haven't fixed it then he droped OpenWatcom
> and switched to MinGW. Probably also many other users changed C compiler
> and now no one reports problems with OpenWatcom builds. In summary
> MS-Windows OpenWatcom builds has been not usable for users who need
> some functionality like OLE for over year.
> The problem with harbour.DLL exists only for users who want to
> mix C compilers and use harbour.dll compiled by different C compiler
> then the one used for static libraries and user code what is not
> a problem for users who do not plan to make such mix.

It's a problem for all users trying to use the unified 
Windows builds in watcom -shared mode. The other is a problem 
for users who want to use OLE. The point is: It's broken in both 
ways, just differently.

If it helps I can delete win/watcom target from unified 
package, which solves my concern, though it's far from a 
proper solution.

Viktor

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

RE: [Harbour] HBMK2 problem

[Horodyski Marek (PZUZ)]

> -Original Message-
> From: Przemysław Czerpak [mailto:dru...@acn.waw.pl]
> Sent: Friday, May 28, 2010 11:37 AM
> To: Harbour Project Main Developer List.
> Subject: Re: [Harbour] HBMK2 problem
 
[ ... ]

> what can cause corruption of some HVM structures. So I strongly
> suggest to never mix DLLs created by different compilers and
> I would like to know about such situation when anyone reports
> bugs.

Mindaugas, I link APP with MinGW and use CAIRIO with libcairo-2.dll.
What compiler made this dll ?
When app is exit, report problems started.

Regards,
Marek Horodyski

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

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

[Przemysław Czerpak]

On Fri, 28 May 2010, Szak�ts Viktor wrote:

Hi Viktor,

> > For me this are two different things.
> > 1. broken watcom binaries due to forces stack calling convention.
> It's broken either way. Default is broken for OLE servers, 
> special build is broken for non-watcom Harbour .dlls.

The default build is broken for any OLE code and maybe some other
type of code. And it's broken for very long time. The problem was
reported few times to this list in the past, i.e. in last year Marek
reported it and because we haven't fixed it then he droped OpenWatcom
and switched to MinGW. Probably also many other users changed C compiler
and now no one reports problems with OpenWatcom builds. In summary
MS-Windows OpenWatcom builds has been not usable for users who need
some functionality like OLE for over year.
The problem with harbour.DLL exists only for users who want to
mix C compilers and use harbour.dll compiled by different C compiler
then the one used for static libraries and user code what is not
a problem for users who do not plan to make such mix.

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

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

[Viktor Szakáts]

Hi Przemek,

>> I got a large number of unresolved externals. I think 
> 
> Because you haven't recompiled whole Harbour code with
> -r6 watcom compiler switch.

I know, I use default build. Most users will use default 
build, so that's what we shall make work.

>> we should handle the watcom problem as a whole. Until 
>> then hbolesrv.c can just be added after regular 
>> server sources to solve the multiple entry problem.
> 
> For me this are two different things.
> 1. broken watcom binaries due to forces stack calling convention.

It's broken either way. Default is broken for OLE servers, 
special build is broken for non-watcom Harbour .dlls.

> 2. chosing startup entry point for created binaries and interaciton
>   with existing hack with hb_forceLinkMainWin()/hb_forceLinkMainStd().

I never got that topic, so all I can add is that it would 
be great to drop any hack, including this one, if possible :)

>> Plus there is also the distribution problem. Overall 
>> it'd be much cleaner to have everything in hbwin lib, 
>> since it's required anyways.
> 
> I agree with having everything in hbwin lib. But for this we
> have to remove or update hb_forceLinkMainWin()/hb_forceLinkMainStd()
> bindings from hvm.c and adopt and if necessary adopt for this
> modification link command in GNU make system and  HBMK2.

Okay with me.

Viktor

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

Re: [Harbour] HBMK2 problem

[Viktor Szakáts]

Hi Przemek,

> It's hard for me to test current OpenWatcom behavior using WINE
> because some results can be strictly bound with Linux and WINE
> emulation so I cannot say if they are correct or not, i.e. the
> things I should test like detaching from terminal and allocating
> console windows works differently in WINE then in native Windows.
> I'll try but I cannot say I will have any valuable results.

I understand. [ my offer for remotely accessible Windows environment 
still stands though. Just tell me. ]

>>> The problem is only for users who will want to use harbour.dll
>>> created by Open Watcom with some other C languages so it's not
>>> very common. Probably we should ignore it now switch to register
>>> calling convention and then if possible look for some solutions
>>> which can force using C calling convention for exported Harbour
>>> functions.
>> It also causes that watcom builds cannot utilized 
>> harbour.dll created with non-watcom compiler, which 
>> is a problem, because in windows unified build I 
>> include harbour.dll built with mingw, so in effect 
>> watcom -shared mode doesn't work by default.
> 
> For me it's a feature because OpenWatcom harbour.dll used with
> other C compiler GPFs immediately. I strongly prefer such behavior
> instead of some strange bug reports for which I invest time looking
> the reason of problem and then I'm finding that it's caused by some
> small differences between used C compilers, i.e. BCC uses 8bytes
> alignment and most of other MS-Windows C compilers 4 bytes alignment
> what can cause corruption of some HVM structures. So I strongly
> suggest to never mix DLLs created by different compilers and
> I would like to know about such situation when anyone reports
> bugs.

To me such approach seems to defeat the almost whole point 
of having .dlls. I think .dlls should be able to interoperate, 
otherwise we lose one of their basic features. IMO when creating 
a .dll we should provide a standard and documented ABI, which 
means a standard set of available functions and a standard 
calling convention (and aligment). So far we're doing good and 
only bcc stands off from the pack, but bcc isn't such important 
(plus it very much seems impossible to bend it right) so it's okay. 
But, if there is any way to juggle settings to make this "dream" 
possible for as much targets we support, we should IMO try it.

F.e. this feature makes it possible to ship the "unified" 
Windows binary package in proper way. The shipped .dlls are 
mingw built which in turn works well with msvc, pocc and watcom.
Same is true if .dlls are built with msvc. And the same is 
true for x64 .dlls (currently built with msvc64, but by now 
also mingw64 works).

>> Do you see any notion or chance to fix the issue 
>> by using __cdelc for watcom?
> 
> This seems to be quite easy to introduce by small modification
> in HB_EXPORT macro so we can make some experiments when we restore
> original OpenWatcom calling convention.

That would be very nice. I reached a dead-end with my 
experiments, hopefully you can breath some fresh air into 
the matter :)

Viktor

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

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

[Przemysław Czerpak]

On Fri, 28 May 2010, Szak�ts Viktor wrote:

Hi Viktor,

> I got a large number of unresolved externals. I think 

Because you haven't recompiled whole Harbour code with
-r6 watcom compiler switch.

> we should handle the watcom problem as a whole. Until 
> then hbolesrv.c can just be added after regular 
> server sources to solve the multiple entry problem.

For me this are two different things.
1. broken watcom binaries due to forces stack calling convention.
2. chosing startup entry point for created binaries and interaciton
   with existing hack with hb_forceLinkMainWin()/hb_forceLinkMainStd().

> Plus there is also the distribution problem. Overall 
> it'd be much cleaner to have everything in hbwin lib, 
> since it's required anyways.

I agree with having everything in hbwin lib. But for this we
have to remove or update hb_forceLinkMainWin()/hb_forceLinkMainStd()
bindings from hvm.c and adopt and if necessary adopt for this
modification link command in GNU make system and  HBMK2.

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

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

[Viktor Szakáts]

Hi Przemek,

> Hi Viktor,
> 
>>; Tried to add hbolesrv.c as direct source 'sources=hbolesrv.c',
>>  but it requires this source (+ headers) to be distributed along
>>  the binaries, plus it didn't resolve the watcom issue, so
>>  I dropped it.
> 
> Using hbolesrv.c directly in the project resolves multiple entry point
> error in Watcom Builds. I tested it.

I got a large number of unresolved externals. I think 
we should handle the watcom problem as a whole. Until 
then hbolesrv.c can just be added after regular 
server sources to solve the multiple entry problem.

Plus there is also the distribution problem. Overall 
it'd be much cleaner to have everything in hbwin lib, 
since it's required anyways.

Viktor

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

Re: [Harbour] HBMK2 problem

[Przemysław Czerpak]

On Thu, 27 May 2010, Szak�ts Viktor wrote:

Hi Viktor,

> > Alternatively we can move WinMain() to separate library or remove strict
> > binding to HVM (hb_forceLinkMainWin()) and add some code to HBMK2 which
> > will force linking with WinMain() if necessary (GUI application is created).
> > hb_forceLinkMainWin reference was added to HVM code for quite old OpenWatcom
> > versions and maybe can be eliminated now or maybe it's enough to add some
> > commands to link script by HBMK2. Removing hb_forceLinkMainWin() reference
> > from watcom builds should resolve the problem. You only have to check if
> > HBMK2 can still create static GUI binaries for using OW.
> I'd appreciate if you could find some to make 
> some patches, I'll try to follow it with hbmk2.

It's hard for me to test current OpenWatcom behavior using WINE
because some results can be strictly bound with Linux and WINE
emulation so I cannot say if they are correct or not, i.e. the
things I should test like detaching from terminal and allocating
console windows works differently in WINE then in native Windows.
I'll try but I cannot say I will have any valuable results.

> > The problem is only for users who will want to use harbour.dll
> > created by Open Watcom with some other C languages so it's not
> > very common. Probably we should ignore it now switch to register
> > calling convention and then if possible look for some solutions
> > which can force using C calling convention for exported Harbour
> > functions.
> It also causes that watcom builds cannot utilized 
> harbour.dll created with non-watcom compiler, which 
> is a problem, because in windows unified build I 
> include harbour.dll built with mingw, so in effect 
> watcom -shared mode doesn't work by default.

For me it's a feature because OpenWatcom harbour.dll used with
other C compiler GPFs immediately. I strongly prefer such behavior
instead of some strange bug reports for which I invest time looking
the reason of problem and then I'm finding that it's caused by some
small differences between used C compilers, i.e. BCC uses 8bytes
alignment and most of other MS-Windows C compilers 4 bytes alignment
what can cause corruption of some HVM structures. So I strongly
suggest to never mix DLLs created by different compilers and
I would like to know about such situation when anyone reports
bugs.

> Do you see any notion or chance to fix the issue 
> by using __cdelc for watcom?

This seems to be quite easy to introduce by small modification
in HB_EXPORT macro so we can make some experiments when we restore
original OpenWatcom calling convention.

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

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

[Przemysław Czerpak]

On Fri, 28 May 2010, vszak...@users.sourceforge.net wrote:

Hi Viktor,

> ; Tried to add hbolesrv.c as direct source 'sources=hbolesrv.c',
>   but it requires this source (+ headers) to be distributed along
>   the binaries, plus it didn't resolve the watcom issue, so
>   I dropped it.

Using hbolesrv.c directly in the project resolves multiple entry point
error in Watcom Builds. I tested it.

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

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

[Massimo Belgrano]

Can i request to vailton made on official web site a page with
harbour/doc/xhb-diff.tx
?


2010/5/28 

> Revision: 14628
>
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14628&view=rev
> Author:   druzus
> Date: 2010-05-28 09:09:44 + (Fri, 28 May 2010)
>
> Log Message:
> ---
> 2010-05-28 11:09 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
>  * harbour/doc/xhb-diff.txt
>* updated information about hash arrays and associative arrays
>! added missing 'not'
>
>  * harbour/contrib/xhb/sprintf.prg
>  * harbour/contrib/xhb/dbgfx.prg
>! renamed hb_sprintf() PRG function to sprintf()
>
> Modified Paths:
> --
>trunk/harbour/ChangeLog
>trunk/harbour/contrib/xhb/dbgfx.prg
>trunk/harbour/contrib/xhb/sprintf.prg
>trunk/harbour/doc/xhb-diff.txt
>
>
> 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
>



-- 
Massimo Belgrano
___
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:[14628] trunk/harbour

[druzus]

Revision: 14628
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14628&view=rev
Author:   druzus
Date: 2010-05-28 09:09:44 + (Fri, 28 May 2010)

Log Message:
---
2010-05-28 11:09 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/doc/xhb-diff.txt
* updated information about hash arrays and associative arrays
! added missing 'not'

  * harbour/contrib/xhb/sprintf.prg
  * harbour/contrib/xhb/dbgfx.prg
! renamed hb_sprintf() PRG function to sprintf()

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/xhb/dbgfx.prg
trunk/harbour/contrib/xhb/sprintf.prg
trunk/harbour/doc/xhb-diff.txt


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: Documentation storm on user's list

[Horodyski Marek (PZUZ)]

> -Original Message-
> From: pete_westg [mailto:pete_we...@yahoo.gr]
> Sent: Thursday, May 27, 2010 9:19 PM
> To: harbour@harbour-project.org
> Subject: [Harbour] Re: Documentation storm on user's list

[...]

> When I am saying documentation is more valuable than coding, in no way
> mean that "coding is nothing".
> It just means that without documentation, many parts of code is almost
> unusable, for many people (users).

For me the most useful examples.
For now I miss examples how to bind query in OCILIB :)
Tomorrow I would like two parallel inquiries in OCILIB (there is no examples, 
but there should not be a problem in MT).
There is also an example of a LIBCAIRO to place their pictures.

Examples (tests) in this moment of development are more useful than the 
documentation.
The project is developing very quickly, and documentation would be quickly 
outdated.
And our ability to (at least mine) to adapt to what is already in the examples 
is delayed by about two years (eg in managing HTTP).
I am very happy with the examples, the more that I do not know English, and my 
contact with him is limited only to this group.
I could not understand the documentation, examples much faster.

Regards,
Marek Horodyski

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