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

[vszakats]

Revision: 14256
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14256&view=rev
Author:   vszakats
Date: 2010-03-29 07:54:12 + (Mon, 29 Mar 2010)

Log Message:
---
2010-03-29 09:52 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * Makefile
  - bin/postinst.prg
  + config/postinst.prg
* Moved postinst.prg from bin to config dir.

  * config/postinst.prg
+ Changed to automatically build all tools found in /utils,
  thus dropping hard-wired tool names from postinst.
* Minor cleanup.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/Makefile

Added Paths:
---
trunk/harbour/config/postinst.prg

Removed Paths:
-
trunk/harbour/bin/postinst.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: hbIDE - On-line documentation-cum-distro update

[Franček Prijatelj]

Hi

HbQt is a binding of Qt for Harbor.
It shares many problems and solutions with other C++ and Qt bindings.
There is pyside project (http://www.pyside.org/) , which is a binding for
Python.

Here is exract from Pyside presentation:
(http://www.pyside.org/2010/03/pyside-talk-on-bossa-conference-2010/)

Shiboken is the binding generator used to create
the PySide bindings. It can generate bindings not only for Qt, but for
any C++ library.


Things one must take care in the binding business:
• C++ object to Python wrapper association
• Inheritance
• Multiple inheritance and casting pointers
• Implicit type conversions
• Methods with multiple signatures
• Protected methods
• Function arguments that return values
• Virtual method overrides
• Object ownership

Harbour and Python are both dynamic interpreted GC languages.
IMHO we should take the same steps (maybe adapt some Shiboken
code, which is writen in C++).
We need hb_cppappi in Harbour , which can be used
for different C++ bindings (Qt,wxWidgets,...). 

BRGDS
 

-
brgs
Franček Prijatelj
-- 
View this message in context: 
http://n2.nabble.com/hbIDE-On-line-documentation-cum-distro-update-tp4812225p4816757.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] 14255 error on build

[Maurilio Longo]

Hi,

I get this on OS/2 + GCC


../../../../../bin/os2/gcc/harbour.exe ../../../dbgbrwsr.prg
-i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l
gcc   -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF
-odbgbrwsr.o -c dbgbrwsr.c
ar-M < __lib__.tmp & strip -S ../../../../../lib/os2/gcc/hbdebug.a &
..\..\..\..\..\config\os2rm -f __lib__.tmp
gcc  -shared -L../../../../../lib/os2/gcc  -o
../../../../../bin/os2/gcc/harbour.dll -Wl,@__dyn__.tmp __dyn__.def -lsocket -s
emximp -o ../../../../../lib/os2/gcc/harbour.a
../../../../../bin/os2/gcc/harbour.dll
gcc  -shared -L../../../../../../lib/os2/gcc  -o
../../../../../../bin/os2/gcc/harbourm.dll -Wl,@__dyn__.tmp __dyn__.def
-lsocket -s
emximp -o ../../../../../../lib/os2/gcc/harbourm.a
../../../../../../bin/os2/gcc/harbourm.dll
../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg
-i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l
gcc   -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF
-ohbrun.o -c hbrun.c
windres -O coff   -o hbrun.res ../../../hbrun.rc
windres: ../../../hbrun.rc:6: parse error
make[3]: *** [hbrun.res] Error 1
make[2]: *** [descend] Error 2
make[1]: *** [hbrun] Error 2
make: *** [utils] Error 2


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

Re: [Harbour] 14255 error on build

[Viktor Szakáts]

Hi,

Pls help finding out what is the proper .rc format 
to include an icon in OS/2.

I copied current logic from hbmk2, but it's possible 
nobody tried it even there, so it was wrong.

(Worth to try with single backslashes first.)

Brgds,
Viktor

On 2010 Mar 29, at 10:15, Maurilio Longo wrote:

> Hi,
> 
> I get this on OS/2 + GCC
> 
> 
> ../../../../../bin/os2/gcc/harbour.exe ../../../dbgbrwsr.prg
> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l
> gcc   -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF
> -odbgbrwsr.o -c dbgbrwsr.c
> ar-M < __lib__.tmp & strip -S ../../../../../lib/os2/gcc/hbdebug.a &
> ..\..\..\..\..\config\os2rm -f __lib__.tmp
> gcc  -shared -L../../../../../lib/os2/gcc  -o
> ../../../../../bin/os2/gcc/harbour.dll -Wl,@__dyn__.tmp __dyn__.def -lsocket 
> -s
> emximp -o ../../../../../lib/os2/gcc/harbour.a
> ../../../../../bin/os2/gcc/harbour.dll
> gcc  -shared -L../../../../../../lib/os2/gcc  -o
> ../../../../../../bin/os2/gcc/harbourm.dll -Wl,@__dyn__.tmp __dyn__.def
> -lsocket -s
> emximp -o ../../../../../../lib/os2/gcc/harbourm.a
> ../../../../../../bin/os2/gcc/harbourm.dll
> ../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg
> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l
> gcc   -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF
> -ohbrun.o -c hbrun.c
> windres -O coff   -o hbrun.res ../../../hbrun.rc
> windres: ../../../hbrun.rc:6: parse error
> make[3]: *** [hbrun.res] Error 1
> make[2]: *** [descend] Error 2
> make[1]: *** [hbrun] Error 2
> make: *** [utils] Error 2
> 
> 
> 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 mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 14255 error on build

[Maurilio Longo]

Viktor,

--8<---
Syntax:

  ICON icon-id  [load-option] [ mem-option] [codepage] filename


This form of the ICON statement defines an icon resource for an application.
An icon resource, typically created by using Icon Editor, is a bit map
defining the shape of the icon to be used for a given application. The ICON
statement copies the icon resource from the file specified in the filename
field and adds it to the application's other resources. An icon resource can
be loaded when creating a window by using the WinCreateStdWindow function with
the FS_ICON style.

You can provide any number of ICON statements in a resource script file, but
each statement must specify a unique icon-id value.

icon-id Specifies the icon-resource identifier. This value must be an unsigned
integer in the range of 1 through 65535, a simple expression that evaluates to
a value in these ranges, or a character string. An icon-id of 1 has a special
meaning; for details, see the "Comment" section.
load-option Specifies when the system loads the resource from the executable
file into memory. This value must be one of the following:
PRELOAD System loads the resource when the application starts.
LOADONCALL System loads the resource when the application calls the
WinCreateStdWindow function. This is the default option.
mem-option Specifies how the system manages the resource when it is in memory.
This value must be one or more of the following:
FIXED System keeps the resource at a fixed memory location.
MOVEABLE System moves the resource as necessary to compact memory.
DISCARDABLE System discards the resource if it is no longer needed. The
default setting is MOVEABLE and DISCARDABLE.
codepage Specifies a code page value. For a list of valid code pages see
CODEPAGE Statement.
filename Specifies the name of the file containing the icon resource. If the
file is not in the current directory, filename must be preceded by a full path.

Comments

An icon with an icon-id of 1 is the default icon. The RC program writes the
icon not only to the resources in your executable file, but also as the .ICON
extended attribute. File Manager will display this icon next to the name of
the executable file.

Example

This example defines an icon whose icon identifier is 11. The icon resource is
copied from the file custom.ico.

ICON 11 custom.ico
>8-

Now I'll try to remove double slashes.

Maurilio.


Viktor Szakáts wrote:
> Hi,
> 
> Pls help finding out what is the proper .rc format 
> to include an icon in OS/2.
> 
> I copied current logic from hbmk2, but it's possible 
> nobody tried it even there, so it was wrong.
> 
> (Worth to try with single backslashes first.)
> 
> Brgds,
> Viktor
> 
> On 2010 Mar 29, at 10:15, Maurilio Longo wrote:
> 
>> Hi,
>>
>> I get this on OS/2 + GCC
>>
>>
>> ../../../../../bin/os2/gcc/harbour.exe ../../../dbgbrwsr.prg
>> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l
>> gcc   -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF
>> -odbgbrwsr.o -c dbgbrwsr.c
>> ar-M < __lib__.tmp & strip -S ../../../../../lib/os2/gcc/hbdebug.a &
>> ..\..\..\..\..\config\os2rm -f __lib__.tmp
>> gcc  -shared -L../../../../../lib/os2/gcc  -o
>> ../../../../../bin/os2/gcc/harbour.dll -Wl,@__dyn__.tmp __dyn__.def -lsocket 
>> -s
>> emximp -o ../../../../../lib/os2/gcc/harbour.a
>> ../../../../../bin/os2/gcc/harbour.dll
>> gcc  -shared -L../../../../../../lib/os2/gcc  -o
>> ../../../../../../bin/os2/gcc/harbourm.dll -Wl,@__dyn__.tmp __dyn__.def
>> -lsocket -s
>> emximp -o ../../../../../../lib/os2/gcc/harbourm.a
>> ../../../../../../bin/os2/gcc/harbourm.dll
>> ../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg
>> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l
>> gcc   -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF
>> -ohbrun.o -c hbrun.c
>> windres -O coff   -o hbrun.res ../../../hbrun.rc
>> windres: ../../../hbrun.rc:6: parse error
>> make[3]: *** [hbrun.res] Error 1
>> make[2]: *** [descend] Error 2
>> make[1]: *** [hbrun] Error 2
>> make: *** [utils] Error 2
>>
>>
>> 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 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] 14255 error on build

[Maurilio Longo]

Viktor,

Using RC.EXE I can compile attached .rc file this way


(E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)rc -r -DOS2 ..\..\..\hbrun.rc
Operating System/2 Resource Compiler
Version 4.00.011 Oct 10 2000
(C) Copyright IBM Corporation 1988-2000
(C) Copyright Microsoft Corp. 1985-2000
All rights reserved.


Creating binary resource file ..\..\..\hbrun.RES
RC:  RCPP -E -D RC_INVOKED -D OS2 -W4 -f ..\..\..\hbrun.rc -ef D:\OS2\RCPP.ERR

..\..\..\hbrun.rc



I see you're calling windres, which I never knew it even exists .)

Anyway, it fails with a parse error, I don't know why.

Still investigating, though.

Maurilio.

Viktor Szakáts wrote:
> Hi,
> 
> Pls help finding out what is the proper .rc format 
> to include an icon in OS/2.
> 
> I copied current logic from hbmk2, but it's possible 
> nobody tried it even there, so it was wrong.
> 
> (Worth to try with single backslashes first.)
> 
> Brgds,
> Viktor
> 
> On 2010 Mar 29, at 10:15, Maurilio Longo wrote:
> 
>> Hi,
>>
>> I get this on OS/2 + GCC
>>
>>
>> ../../../../../bin/os2/gcc/harbour.exe ../../../dbgbrwsr.prg
>> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l
>> gcc   -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF
>> -odbgbrwsr.o -c dbgbrwsr.c
>> ar-M < __lib__.tmp & strip -S ../../../../../lib/os2/gcc/hbdebug.a &
>> ..\..\..\..\..\config\os2rm -f __lib__.tmp
>> gcc  -shared -L../../../../../lib/os2/gcc  -o
>> ../../../../../bin/os2/gcc/harbour.dll -Wl,@__dyn__.tmp __dyn__.def -lsocket 
>> -s
>> emximp -o ../../../../../lib/os2/gcc/harbour.a
>> ../../../../../bin/os2/gcc/harbour.dll
>> gcc  -shared -L../../../../../../lib/os2/gcc  -o
>> ../../../../../../bin/os2/gcc/harbourm.dll -Wl,@__dyn__.tmp __dyn__.def
>> -lsocket -s
>> emximp -o ../../../../../../lib/os2/gcc/harbourm.a
>> ../../../../../../bin/os2/gcc/harbourm.dll
>> ../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg
>> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l
>> gcc   -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF
>> -ohbrun.o -c hbrun.c
>> windres -O coff   -o hbrun.res ../../../hbrun.rc
>> windres: ../../../hbrun.rc:6: parse error
>> make[3]: *** [hbrun.res] Error 1
>> make[2]: *** [descend] Error 2
>> make[1]: *** [hbrun] Error 2
>> make: *** [utils] Error 2
>>
>>
>> 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 mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
> 

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


/*
 * $Id: hbrun.rc 14255 2010-03-28 17:23:00Z vszakats $
 */

#if defined( OS2 )
ICON 1 DISCARDABLE "..\\..\\..\\..\\..\\package\\harbour.ico"
#endif
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 14255 error on build

[Viktor Szakáts]

Hi,

> Using RC.EXE I can compile attached .rc file this way
> 
> 
> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)rc -r -DOS2 ..\..\..\hbrun.rc
> Operating System/2 Resource Compiler
> Version 4.00.011 Oct 10 2000
> (C) Copyright IBM Corporation 1988-2000
> (C) Copyright Microsoft Corp. 1985-2000
> All rights reserved.
> 
> 
> Creating binary resource file ..\..\..\hbrun.RES
> RC:  RCPP -E -D RC_INVOKED -D OS2 -W4 -f ..\..\..\hbrun.rc -ef D:\OS2\RCPP.ERR
> 
> ..\..\..\hbrun.rc

One question is if it can be linked by gcc.

Plus from here I can't tell what other limitation 
this system tool might have compared to windres.

Other question is with watcom. It's would good to 
define what is a generally accepted OS/2 .rc format 
understood and usable with all OS/2 compilers.

> I see you're calling windres, which I never knew it even exists .)
> 
> Anyway, it fails with a parse error, I don't know why.
> 
> Still investigating, though.

Okay.

Brgds,
Viktor

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

Re: [Harbour] 14255 error on build

[Maurilio Longo]

Viktor,

windres has a different syntax from rc, see attached file which I can compile 
with

(E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -r -DOS2 
..\..\..\hbrun.rc

Output goes to stdout, so you need a -o also.

Maurilio.



Viktor Szakáts wrote:
> Hi,
> 
>> Using RC.EXE I can compile attached .rc file this way
>>
>>
>> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)rc -r -DOS2 ..\..\..\hbrun.rc
>> Operating System/2 Resource Compiler
>> Version 4.00.011 Oct 10 2000
>> (C) Copyright IBM Corporation 1988-2000
>> (C) Copyright Microsoft Corp. 1985-2000
>> All rights reserved.
>>
>>
>> Creating binary resource file ..\..\..\hbrun.RES
>> RC:  RCPP -E -D RC_INVOKED -D OS2 -W4 -f ..\..\..\hbrun.rc -ef 
>> D:\OS2\RCPP.ERR
>>
>> ..\..\..\hbrun.rc
> 
> One question is if it can be linked by gcc.
> 
> Plus from here I can't tell what other limitation 
> this system tool might have compared to windres.
> 
> Other question is with watcom. It's would good to 
> define what is a generally accepted OS/2 .rc format 
> understood and usable with all OS/2 compilers.
> 
>> I see you're calling windres, which I never knew it even exists .)
>>
>> Anyway, it fails with a parse error, I don't know why.
>>
>> Still investigating, though.
> 
> Okay.
> 
> Brgds,
> Viktor
> 
> ___
> 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.


/*
 * $Id: hbrun.rc 14255 2010-03-28 17:23:00Z vszakats $
 */

#if defined( OS2 )
1 ICON  DISCARDABLE  "..\\..\\..\\..\\..\\package\\harbour.ico"
#endif
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 14255 error on build

[Maurilio Longo]

Viktor,

see this

http://www.cygwin.com/cygwin-ug-net/windres.html

Maurilio.


Maurilio Longo wrote:
> Viktor,
> 
> windres has a different syntax from rc, see attached file which I can compile 
> with
> 
> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -r -DOS2 
> ..\..\..\hbrun.rc
> 
> Output goes to stdout, so you need a -o also.
> 
> Maurilio.
> 
> 
> 
> Viktor Szakáts wrote:
>> Hi,
>>
>>> Using RC.EXE I can compile attached .rc file this way
>>>
>>>
>>> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)rc -r -DOS2 ..\..\..\hbrun.rc
>>> Operating System/2 Resource Compiler
>>> Version 4.00.011 Oct 10 2000
>>> (C) Copyright IBM Corporation 1988-2000
>>> (C) Copyright Microsoft Corp. 1985-2000
>>> All rights reserved.
>>>
>>>
>>> Creating binary resource file ..\..\..\hbrun.RES
>>> RC:  RCPP -E -D RC_INVOKED -D OS2 -W4 -f ..\..\..\hbrun.rc -ef 
>>> D:\OS2\RCPP.ERR
>>>
>>> ..\..\..\hbrun.rc
>> One question is if it can be linked by gcc.
>>
>> Plus from here I can't tell what other limitation 
>> this system tool might have compared to windres.
>>
>> Other question is with watcom. It's would good to 
>> define what is a generally accepted OS/2 .rc format 
>> understood and usable with all OS/2 compilers.
>>
>>> I see you're calling windres, which I never knew it even exists .)
>>>
>>> Anyway, it fails with a parse error, I don't know why.
>>>
>>> Still investigating, though.
>> Okay.
>>
>> Brgds,
>> Viktor
>>
>> ___
>> 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

-- 
 __
|  |  | |__| 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] Re: Ask help for run time error ...

[Shum]

Hi All,

Solved !

Now... facing other kind of error


Shum
-- 
View this message in context: 
http://n2.nabble.com/Ask-help-for-run-time-error-tp4816267p4816993.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] 14255 error on build

[Viktor Szakáts]

> windres has a different syntax from rc, see attached file which I can compile 
> with
> 
> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -r -DOS2 
> ..\..\..\hbrun.rc

Can you try two things with included .rc file:
1. Does it work with standard windres command-line?
windres -O [omf|coff] -o hbrun.res hbrun.rc
2. Does this .rc format work with watcom?

--- hbrun.rc
#if defined( OS2 ) || defined( __OS2__ ) || defined( OS_2 )
#if defined( __GNUC__ )
/* os2/gcc */
1 ICON DISCARDABLE "..\\..\\..\\..\\..\\package\\harbour.ico"
#else
/* os2/watom */
ICON 1 DISCARDABLE "..\\..\\..\\..\\..\\package\\harbour.ico"
#endif
#elif defined( __BORLANDC__ )
/* win/bcc */
ICON1 ICON DISCARDABLE "..\..\..\..\..\package\harbour.ico"
#else
/* win */
ICON1 ICON DISCARDABLE "..\\..\\..\\..\\..\\package\\harbour.ico"
#endif
---

[ Quite nicely standardized format. not. ]

Brgds,
Viktor

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

Re: [Harbour] 14255 error on build

[Maurilio Longo]

Viktor,

Viktor Szakáts wrote:
> Can you try two things with included .rc file:
> 1. Does it work with standard windres command-line?
> windres -O [omf|coff] -o hbrun.res hbrun.rc

Without -O it works, otherwise I get an error:

(E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -o hbrun.res
..\..\..\hbrun.rc

(E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)dir

The volume label in drive E is Dati.
The Volume Serial Number is 812E:D5C2.
Directory of E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc

29/03/10 12:00  124   .
29/03/10 10:10  124   ..
29/03/10 10:10 15.390124 a---  hbrun.c
29/03/10 10:10  8.211124 a---  hbrun.o
29/03/10 12:00  9.344124 a---  hbrun.res
5 file(s)  32.945 bytes used
  179.062.521 K bytes free

(E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -Oomf -o hbrun.res
..\..\..\hbrun.rc
windres: unknown format type `omf'
windres: supported formats: rc res coff

(E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -Ocoff -o hbrun.res
..\..\..\hbrun.rc
windres: can't get BFD_RELOC_RVA relocation type: Error 0

> 2. Does this .rc format work with watcom?
> 

I don't have it installed and working, I hope David can do this test.


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

Re: [Harbour] 14255 error on build

[Viktor Szakáts]

Trying to lessen the mess, can you try this one?:

---
/*
 * $Id: hbrun.rc 14255 2010-03-28 17:23:00Z vszakats $
 */

#if ( defined( OS2 ) || defined( __OS2__ ) || defined( OS_2 ) ) && ! defined( 
__GNUC__ )
/* os2/watcom */
  ICON DISCARDABLE "../../../../../package/harbour.ico"
#else
ICON1 ICON DISCARDABLE "../../../../../package/harbour.ico"
#endif
---

Also if the icon is indeed visible as app icon.

Brgds,
Viktor

On 2010 Mar 29, at 11:54, Viktor Szakáts wrote:

>> windres has a different syntax from rc, see attached file which I can 
>> compile with
>> 
>> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -r -DOS2 
>> ..\..\..\hbrun.rc
> 
> Can you try two things with included .rc file:
> 1. Does it work with standard windres command-line?
>windres -O [omf|coff] -o hbrun.res hbrun.rc
> 2. Does this .rc format work with watcom?
> 
> --- hbrun.rc
> #if defined( OS2 ) || defined( __OS2__ ) || defined( OS_2 )
> #if defined( __GNUC__ )
> /* os2/gcc */
> 1 ICON DISCARDABLE "..\\..\\..\\..\\..\\package\\harbour.ico"
> #else
> /* os2/watom */
> ICON 1 DISCARDABLE "..\\..\\..\\..\\..\\package\\harbour.ico"
> #endif
> #elif defined( __BORLANDC__ )
> /* win/bcc */
> ICON1 ICON DISCARDABLE "..\..\..\..\..\package\harbour.ico"
> #else
> /* win */
> ICON1 ICON DISCARDABLE "..\\..\\..\\..\\..\\package\\harbour.ico"
> #endif
> ---
> 
> [ Quite nicely standardized format. not. ]
> 
> Brgds,
> Viktor
> 

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

[Harbour] Re: How can i Print BMP?

[Massimo Belgrano]

Imagemagick wikk read, convert and write images in a 100 formas with
interface with same programming language.
Anybody know if exist an harbour wrapper for
http://www.imagemagick.org/script/index.php


Resolved  with follow copy function ..Here all seem work fine


  Log_Handle := fopen(x_prnfile,0)
  cStr=space(1000)
  x_letti := Fread(Log_Handle,@cStr,1000)
 if left(cStr,2)=CHR(27)+"E"
 cstr=substr(cstr,3,998)
  endif
x_fileprint=x_fileprint + cstr
  x_letti=1000
  do while x_letti=1000
cStr=space(1000)
x_letti := Fread(Log_Handle,@cStr,1000)
if x_letti<>1000
   // ALTD()
   if substr(cStr,x_letti-1,2)=CHR(27)+"E"
  cstr=substr(cstr,1,x_letti-2)
   endif
endif
x_fileprint=x_fileprint + cstr
  ENDDO
  fclose(log_handle)



2010/3/8 Massimo Belgrano 

> I try resolve with imagemagik using command line convert (via shell)
> convert "G:\myimage.bmp" -rotate 180 -resize 400x250 -density 300x300
> "c:\aa.pcl"
>  ?  ?? chr(K_ESC) ..
>  x_prnfile="g:\clip52\lavori\massimo\arca\AA.pcl"
>  TYPE &X_PRNFILE to print
> The image break during printing and page eject
> may be that type is not able find end of file (26)
>
>
>
> 2010/3/1 Massimo Belgrano :
> > I need the capability print a bmp inside a harbour application
> > who print plc . is a old clipper application
> >
> > I Have found a routine who Print .PCX To Laserjet, but need BMP
> >
> >
> > I search a conversion BMP2PCX or printing BMP in pcl
> > (I need also rotate image)
> >
> >
> > http://www.karland.com/code/clipper/
> > function LoadPCX(cFile)
> >
> >
> //
> >   // AUTHOR: Denis A. Sarrazin (Tue 10-11-1994)
> >   // PURPOSE:to load the PCX into a special array
> >   // PARAMETERS: cFile <-- the name of the PCX file to load
> >   // RETURNS:array (see list of #define in MINIPCX.CH and format
> below)
> >   // NOTES:  Format of a .PCX header shown below:
> >   //
> >   //Byte  ItemSize Description/Comments
> >   //  --- 
> > -
> >   //0 Manufacturer  1  Constant Flag  10 = ZSoft .PCX
> >   //1 Version   1  Version information:
> >   // 0 = Version 2.5
> >   // 2 = Version 2.8 w/palette
> information
> >   // 3 = Version 2.8 w/o palette
> > information
> >   // 5 = Version 3.0
> >   //2 Encoding  1  1 = .PCX run length encoding
> >   //3 Bits per pixel1  Number of bits/pixel per plane
> >   //4 Window8  Picture Dimensions
> >   // (Xmin, Ymin) - (Xmax - Ymax)
> >   // in pixels, inclusive
> >   //12HRes  2  Horizontal Resolution of creating
> device
> >   //14VRes  2  Vertical Resolution of creating
> device
> >   //16Colormap 48  Color palette setting, see text
> >   //64Reserved  1
> >   //65NPlanes   1  Number of color planes
> >   //66Bytes per Line2  Number of bytes per scan line per
> >   // color plane (always even for
> > .PCX files)
> >   //68Palette Info  2  How to interpret palette - 1 =
> color/BW,
> >   //  2 =
> grayscale
> >   //70Filler   58  blank to fill out 128 byte header
> >   //
> >   //IMPORTANT:
> >   //  All sizes are measured in BYTES.
> >   //  All variables of size 2 are integers.
> >   //
> >
> //
> >   local aPCX
> >   local cBuffer
> >   local hPCX
> >   local nRead
> >   local nFileLength
> >
> >   if !file(cFile)
> >
> >  aPCX := {}
> >
> >   else
> >
> >  aPCX:= array(PCX_LENGTH)
> >  hPCX:= fopen(cFile)
> >  nFileLength := FLEN(hPCX)
> >
> >  cBuffer := space(HEADER_SIZE)
> >  nRead   := fread(hPCX,@cBuffer,HEADER_SIZE)   // load PCX
> header
> >
> >  aPCX[ PCX_MANUFACTURER ]   := asc(substr(cBuffer,1,1))
> >  aPCX[ PCX_VERSION ]:= asc(substr(cBuffer,2,1))
> >  aPCX[ PCX_ENCODING ]   := asc(substr(cBuffer,3,1))
> >  aPCX[ PCX_BITS_PER_PIXEL ] := asc(substr(cBuffer,4,1))
> >  aPCX[ PCX_WINDOW ] := {bin2i(substr(cBuffer,5,2)),;
> >  bin2i(substr(cBuffer,7,2)),;
> >  bin2i(substr(cBuffer,9,2)),;
> >  bin2i(su

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

[Przemysław Czerpak]

On Fri, 26 Mar 2010, Maurilio Longo wrote:

Hi,

> > Can you check the performance of above functions in some simple loop?
> See attached code, it gives these results on my PC when compiled with
> gcc -O3 -Wall -o gettid.exe gettid.c
> 
> (E:\harbour\test)gettid
> Time _hb_gettid() 688
> Time _gettid() 1787
> The numers are in milliseconds for a 100 million times loop.

Thank you very much.
Such results can be a little bit change by autoinlining when -O3 is used
so it would be nice if you can also test this function:

   ULONG _hb_gettid2( void )
   {
  ULONG tid = 0;
  PTIB  ptib = NULL;

  if( DosGetInfoBlocks( &ptib, NULL ) == NO_ERROR )
 tid = ptib->tib_ptib2->tib2_ultid;

  return tid;
   }

in your code. Just for information about real cost of DosGetInfoBlocks().
Maybe it's not such big and it internally makes exactly the same operations.

> > When threads ends then it's TLS area is freed so such information will be
> > lost in a while.
> Yes, but if we have an object on HVM, this object could have those numbers
> and they'll stay there until the object is disposed.

Yes it is and it's good place to store such information but it's not TLS
area :-)

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

Re: [Harbour] 14255 error on build

[Viktor Szakáts]

>> Can you try two things with included .rc file:
>> 1. Does it work with standard windres command-line?
>>windres -O [omf|coff] -o hbrun.res hbrun.rc
> 
> Without -O it works, otherwise I get an error:
> 
> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -o hbrun.res
> ..\..\..\hbrun.rc
> 
> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)dir
> 
> The volume label in drive E is Dati.
> The Volume Serial Number is 812E:D5C2.
> Directory of E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc
> 
> 29/03/10 12:00  124   .
> 29/03/10 10:10  124   ..
> 29/03/10 10:10 15.390124 a---  hbrun.c
> 29/03/10 10:10  8.211124 a---  hbrun.o
> 29/03/10 12:00  9.344124 a---  hbrun.res
>5 file(s)  32.945 bytes used
>  179.062.521 K bytes free
> 
> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -Oomf -o hbrun.res
> ..\..\..\hbrun.rc
> windres: unknown format type `omf'
> windres: supported formats: rc res coff
> 
> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -Ocoff -o hbrun.res
> ..\..\..\hbrun.rc
> windres: can't get BFD_RELOC_RVA relocation type: Error 0

'-O coff' should be the right option for your gcc version, 
it seems supported, but yet it gives this error? Can it be that 
the space is missing in your test?

'-O omf' is for gccomf.

Brgds,
Viktor

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

[Harbour] increase harbour popularity: wiki?

[chris lueders]

hi,

Saturday, March 27, 2010, 19:45:18, "Viktor Szakáts" wrote:

> BTW, by googling it I've found that very few 
> Xbase++ developers even know about Harbour, 
> and even those who know totally confuse it with 
> xHarbour, which is a pretty large mistake to make 
> for multiple reasons.

> Dunno how to change that, but current situation 
> is not very good for us and for Harbour in 
> general.

> Maybe existing users should do something to 
> spread the word.

i'm new to harbour, but even though the project is a great help for me
i find the web presence and especially the documentation not very
complete.  my usual way of helping myself is to grep .lib files, the
harbour source code and googling.  but this is not a good solution for
the uninitiated.

what i would like to see is a wiki where everyone can enter all
harbour/clipper/xbase info, functions, commands, compatibility with
different versions, etc.

i don't know of any such site on the net.  if we would launch such a
thing, maybe in time we could make it the #1 source of xbase infos
with a strong link to and presence of harbour.  that should increase
knowledge and popularity for harbour.

i think it's important that it is a wiki, since the beauty of a wiki
is that everyone can enter information very easily.  it takes more
interest to checkout the svn repos, understand the doc format/whatever
and finally write some of it yourself.  that might be a too much of an
obstacle for many contributors.  plus, we could draw contributors from
other xbase lingos (xharbour, clipper 5.x, flagship) as well even
though they are not interested in harbour at all.

...or is that a typical idea of a newcomer to the project? :)

-- 
/chris/

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

Re: [Harbour] increase harbour popularity: wiki?

[Massimo Belgrano]

Now Harbour have with hbide the tool for made documentation
HARBOUR SEARCH 
y
ou!
I invite to collaborate anyone who is interested in harbour language and is
able to make a contribution. We are looking for  developer,documentation
writer, sponsors, sympathizers and friends. Any kind of collaboration is
welcome. Possibly you may have some suggestions, we will be glad to hear
from you.
For now we offer a good professional experiences .

http://harbourlanguage.blogspot.com/

bidirectional wiki integration will be a way but also launchpad offer very
intresting feature


2010/3/29 chris lueders 

> hi,
>
> Saturday, March 27, 2010, 19:45:18, "Viktor Szakáts" wrote:
>
> > BTW, by googling it I've found that very few
> > Xbase++ developers even know about Harbour,
> > and even those who know totally confuse it with
> > xHarbour, which is a pretty large mistake to make
> > for multiple reasons.
>
> > Dunno how to change that, but current situation
> > is not very good for us and for Harbour in
> > general.
>
> > Maybe existing users should do something to
> > spread the word.
>
> i'm new to harbour, but even though the project is a great help for me
> i find the web presence and especially the documentation not very
> complete.  my usual way of helping myself is to grep .lib files, the
> harbour source code and googling.  but this is not a good solution for
> the uninitiated.
>
> what i would like to see is a wiki where everyone can enter all
> harbour/clipper/xbase info, functions, commands, compatibility with
> different versions, etc.
>
> i don't know of any such site on the net.  if we would launch such a
> thing, maybe in time we could make it the #1 source of xbase infos
> with a strong link to and presence of harbour.  that should increase
> knowledge and popularity for harbour.
>
> i think it's important that it is a wiki, since the beauty of a wiki
> is that everyone can enter information very easily.  it takes more
> interest to checkout the svn repos, understand the doc format/whatever
> and finally write some of it yourself.  that might be a too much of an
> obstacle for many contributors.  plus, we could draw contributors from
> other xbase lingos (xharbour, clipper 5.x, flagship) as well even
> though they are not interested in harbour at all.
>
> ...or is that a typical idea of a newcomer to the project? :)
>
> --
> /chris/
>
> ___
> 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] increase harbour popularity: wiki?

[Viktor Szakáts]

Hi,

> i'm new to harbour, but even though the project is a great help for me
> i find the web presence and especially the documentation not very
> complete.  my usual way of helping myself is to grep .lib files, the
> harbour source code and googling.  but this is not a good solution for
> the uninitiated.
> 
> what i would like to see is a wiki where everyone can enter all
> harbour/clipper/xbase info, functions, commands, compatibility with
> different versions, etc.
> 
> i don't know of any such site on the net.  if we would launch such a
> thing, maybe in time we could make it the #1 source of xbase infos
> with a strong link to and presence of harbour.  that should increase
> knowledge and popularity for harbour.
> 
> i think it's important that it is a wiki, since the beauty of a wiki
> is that everyone can enter information very easily.  it takes more
> interest to checkout the svn repos, understand the doc format/whatever
> and finally write some of it yourself.  that might be a too much of an
> obstacle for many contributors.  plus, we could draw contributors from
> other xbase lingos (xharbour, clipper 5.x, flagship) as well even
> though they are not interested in harbour at all.
> 
> ...or is that a typical idea of a newcomer to the project? :)

We have/had several wikis since years. Just nobody cares 
to update them.

For a start we have a quite shameful IMO wikipedia entry:
   http://en.wikipedia.org/wiki/Harbour_(software)

Brgds,
Viktor

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

Re: [Harbour] 14255 error on build

[Maurilio Longo]

Viktor,

no, same error:

(E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -O coff -o hbrun.res
..\..\..\hbrun.rc
windres: can't get BFD_RELOC_RVA relocation type: Error 0


Maurilio.

Viktor Szakáts wrote:
>>> Can you try two things with included .rc file:
>>> 1. Does it work with standard windres command-line?
>>>windres -O [omf|coff] -o hbrun.res hbrun.rc
>> Without -O it works, otherwise I get an error:
>>
>> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -o hbrun.res
>> ..\..\..\hbrun.rc
>>
>> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)dir
>>
>> The volume label in drive E is Dati.
>> The Volume Serial Number is 812E:D5C2.
>> Directory of E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc
>>
>> 29/03/10 12:00  124   .
>> 29/03/10 10:10  124   ..
>> 29/03/10 10:10 15.390124 a---  hbrun.c
>> 29/03/10 10:10  8.211124 a---  hbrun.o
>> 29/03/10 12:00  9.344124 a---  hbrun.res
>>5 file(s)  32.945 bytes used
>>  179.062.521 K bytes free
>>
>> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -Oomf -o hbrun.res
>> ..\..\..\hbrun.rc
>> windres: unknown format type `omf'
>> windres: supported formats: rc res coff
>>
>> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -Ocoff -o hbrun.res
>> ..\..\..\hbrun.rc
>> windres: can't get BFD_RELOC_RVA relocation type: Error 0
> 
> '-O coff' should be the right option for your gcc version, 
> it seems supported, but yet it gives this error? Can it be that 
> the space is missing in your test?
> 
> '-O omf' is for gccomf.
> 
> Brgds,
> Viktor
> 
> ___
> 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] 14255 error on build

[Maurilio Longo]

Viktor.

> ---
> /*
>  * $Id: hbrun.rc 14255 2010-03-28 17:23:00Z vszakats $
>  */
> 
> #if ( defined( OS2 ) || defined( __OS2__ ) || defined( OS_2 ) ) && ! defined( 
> __GNUC__ )
> /* os2/watcom */
>   ICON DISCARDABLE "../../../../../package/harbour.ico"
> #else
> ICON1 ICON DISCARDABLE "../../../../../package/harbour.ico"
> #endif
> ---
> 

without icon ID for the os2/watcom line?

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

Re: [Harbour] 14255 error on build

[Maurilio Longo]

No way:

! Component: 'zlib' found in E:/REPOSITORY/HARBOUR/external/zlib (local)
! Component: 'pcre' found in E:/REPOSITORY/HARBOUR/external/pcre (local)
! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL.
! Component: 'gpm' not supported on os2 platform
! Component: 'slang' not found. Configure with HB_WITH_SLANG.
! Component: 'curses' not supported on os2 platform
! Component: 'x11' not found. Configure with HB_WITH_X11.
! Component: 'wattcp/watt-32' not supported on os2 platform
! HB_INSTALL_PREFIX automatically set to: E:\REPOSITORY\HARBOUR
../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg  -i../../../../../incl
ude -n1 -q0 -w3 -es2 -kmo -i- -l
gcc   -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF
-ohbrun.o -c hbrun.c
windres -O coff   -o hbrun.res ../../../hbrun.rc
windres: can't get BFD_RELOC_RVA relocation type: No such file or directory
make[1]: *** [hbrun.res] Error 1
make: *** [descend] Error 2

Maurilio.

Viktor Szakáts wrote:
> Trying to lessen the mess, can you try this one?:
> 
> ---
> /*
>  * $Id: hbrun.rc 14255 2010-03-28 17:23:00Z vszakats $
>  */
> 
> #if ( defined( OS2 ) || defined( __OS2__ ) || defined( OS_2 ) ) && ! defined( 
> __GNUC__ )
> /* os2/watcom */
>   ICON DISCARDABLE "../../../../../package/harbour.ico"
> #else
> ICON1 ICON DISCARDABLE "../../../../../package/harbour.ico"
> #endif
> ---
> 
> Also if the icon is indeed visible as app icon.
> 
> Brgds,
> Viktor
> 
> On 2010 Mar 29, at 11:54, Viktor Szakáts wrote:
> 
>>> windres has a different syntax from rc, see attached file which I can 
>>> compile with
>>>
>>> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -r -DOS2 
>>> ..\..\..\hbrun.rc
>> Can you try two things with included .rc file:
>> 1. Does it work with standard windres command-line?
>>windres -O [omf|coff] -o hbrun.res hbrun.rc
>> 2. Does this .rc format work with watcom?
>>
>> --- hbrun.rc
>> #if defined( OS2 ) || defined( __OS2__ ) || defined( OS_2 )
>> #if defined( __GNUC__ )
>> /* os2/gcc */
>> 1 ICON DISCARDABLE "..\\..\\..\\..\\..\\package\\harbour.ico"
>> #else
>> /* os2/watom */
>> ICON 1 DISCARDABLE "..\\..\\..\\..\\..\\package\\harbour.ico"
>> #endif
>> #elif defined( __BORLANDC__ )
>> /* win/bcc */
>> ICON1 ICON DISCARDABLE "..\..\..\..\..\package\harbour.ico"
>> #else
>> /* win */
>> ICON1 ICON DISCARDABLE "..\\..\\..\\..\\..\\package\\harbour.ico"
>> #endif
>> ---
>>
>> [ Quite nicely standardized format. not. ]
>>
>> Brgds,
>> Viktor
>>
> 
> ___
> 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] 14255 error on build

[Viktor Szakáts]

>> ---
>> /*
>> * $Id: hbrun.rc 14255 2010-03-28 17:23:00Z vszakats $
>> */
>> 
>> #if ( defined( OS2 ) || defined( __OS2__ ) || defined( OS_2 ) ) && ! 
>> defined( __GNUC__ )
>> /* os2/watcom */
>>  ICON DISCARDABLE "../../../../../package/harbour.ico"
>> #else
>> ICON1 ICON DISCARDABLE "../../../../../package/harbour.ico"
>> #endif
>> ---
>> 
> 
> without icon ID for the os2/watcom line?

Yes.

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

[vszakats]

Revision: 14257
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14257&view=rev
Author:   vszakats
Date: 2010-03-29 11:51:42 + (Mon, 29 Mar 2010)

Log Message:
---
2010-03-29 13:50 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * utils/hbmk2/hbmk2.prg
  * config/os2/gcc.mk
! Fixed to not use '-O coff'. It generates strange error.
  '-O omf' is still used, pls test it.

  * utils/hbrun/hbrun.rc
* Trying to make it work for OS/2 and at the same time
  lessen the chaos (f.e. using forward slashes in filenames).

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/config/os2/gcc.mk
trunk/harbour/utils/hbmk2/hbmk2.prg
trunk/harbour/utils/hbrun/hbrun.rc


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] SF.net SVN: harbour-project:[14257] trunk/harbour

[Maurilio Longo]

Viktor,

it doesn't work either:

! HB_COMPILER: gcc
! Component: 'zlib' found in E:/REPOSITORY/HARBOUR/external/zlib (local)
! Component: 'pcre' found in E:/REPOSITORY/HARBOUR/external/pcre (local)
! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL.
! Component: 'gpm' not supported on os2 platform
! Component: 'slang' not found. Configure with HB_WITH_SLANG.
! Component: 'curses' not supported on os2 platform
! Component: 'x11' not found. Configure with HB_WITH_X11.
! Component: 'wattcp/watt-32' not supported on os2 platform
! HB_INSTALL_PREFIX automatically set to: E:\REPOSITORY\HARBOUR
../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg
-i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l
gcc   -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF
-ohbrun.o -c hbrun.c
windres -O omf   -o hbrun.res ../../../hbrun.rc
windres: unknown format type `omf'
windres: supported formats: rc res coff
make[1]: *** [hbrun.res] Error 1
make: *** [descend] Error 2

Maurilio.

vszak...@users.sourceforge.net wrote:
> Revision: 14257
>   
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14257&view=rev
> Author:   vszakats
> Date: 2010-03-29 11:51:42 + (Mon, 29 Mar 2010)
> 
> Log Message:
> ---
> 2010-03-29 13:50 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
>   * utils/hbmk2/hbmk2.prg
>   * config/os2/gcc.mk
> ! Fixed to not use '-O coff'. It generates strange error.
>   '-O omf' is still used, pls test it.
> 
>   * utils/hbrun/hbrun.rc
> * Trying to make it work for OS/2 and at the same time
>   lessen the chaos (f.e. using forward slashes in filenames).
> 
> Modified Paths:
> --
> trunk/harbour/ChangeLog
> trunk/harbour/config/os2/gcc.mk
> trunk/harbour/utils/hbmk2/hbmk2.prg
> trunk/harbour/utils/hbrun/hbrun.rc
> 
> 
> 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
> 

-- 
 __
|  |  | |__| 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] SF.net SVN: harbour-project:[14257] trunk/harbour

[Viktor Szakáts]

Hi,

> ! HB_COMPILER: gcc
> ! Component: 'zlib' found in E:/REPOSITORY/HARBOUR/external/zlib (local)
> ! Component: 'pcre' found in E:/REPOSITORY/HARBOUR/external/pcre (local)
> ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL.
> ! Component: 'gpm' not supported on os2 platform
> ! Component: 'slang' not found. Configure with HB_WITH_SLANG.
> ! Component: 'curses' not supported on os2 platform
> ! Component: 'x11' not found. Configure with HB_WITH_X11.
> ! Component: 'wattcp/watt-32' not supported on os2 platform
> ! HB_INSTALL_PREFIX automatically set to: E:\REPOSITORY\HARBOUR
> ../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg
> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l
> gcc   -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF
> -ohbrun.o -c hbrun.c
> windres -O omf   -o hbrun.res ../../../hbrun.rc
> windres: unknown format type `omf'
> windres: supported formats: rc res coff

I don't understand this scenario. '-O omf' 
is only used in gccomf mode, and you're using 
gcc here.

Could be typo on my part, but it looks alright 
in config/os2/gcc.mk.

Brgds,
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:[14257] trunk/harbour

[Maurilio Longo]

Viktor,

I'm not using OMF mode, I'm using .a out mode. Maybe the issue is this.

Maurilio.


Viktor Szakáts wrote:
> Hi,
> 
>> ! HB_COMPILER: gcc
>> ! Component: 'zlib' found in E:/REPOSITORY/HARBOUR/external/zlib (local)
>> ! Component: 'pcre' found in E:/REPOSITORY/HARBOUR/external/pcre (local)
>> ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL.
>> ! Component: 'gpm' not supported on os2 platform
>> ! Component: 'slang' not found. Configure with HB_WITH_SLANG.
>> ! Component: 'curses' not supported on os2 platform
>> ! Component: 'x11' not found. Configure with HB_WITH_X11.
>> ! Component: 'wattcp/watt-32' not supported on os2 platform
>> ! HB_INSTALL_PREFIX automatically set to: E:\REPOSITORY\HARBOUR
>> ../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg
>> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l
>> gcc   -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF
>> -ohbrun.o -c hbrun.c
>> windres -O omf   -o hbrun.res ../../../hbrun.rc
>> windres: unknown format type `omf'
>> windres: supported formats: rc res coff
> 
> I don't understand this scenario. '-O omf' 
> is only used in gccomf mode, and you're using 
> gcc here.
> 
> Could be typo on my part, but it looks alright 
> in config/os2/gcc.mk.
> 
> Brgds,
> Viktor
> 
> ___
> 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] SF.net SVN: harbour-project:[14257] trunk/harbour

[Maurilio Longo]

Viktor,

I was not at latest svn commit, here it is after latest upgrade:

! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL.
! Component: 'gpm' not supported on os2 platform
! Component: 'slang' not found. Configure with HB_WITH_SLANG.
! Component: 'curses' not supported on os2 platform
! Component: 'x11' not found. Configure with HB_WITH_X11.
! Component: 'wattcp/watt-32' not supported on os2 platform
! HB_INSTALL_PREFIX automatically set to: E:\REPOSITORY\HARBOUR
../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg  -i../../../../../incl
ude -n1 -q0 -w3 -es2 -kmo -i- -l
gcc   -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF
-ohbrun.o -c hbrun.c
windres-o hbrun.res ../../../hbrun.rc
gcc  -L../../../../../lib/os2/gcc   -o ..\..\..\..\..\bin\os2\gcc\hbrun.exe
hbrun.o hbrun.res -lhbcplr -lhbpp -lhbcommon -lhbcplr -lhbdebug -lhbmainstd
-lharbour -s
emxbind: invalid binary resource file
E:/Sviluppo/gcc/v3.3.5/usr/i386-pc-os2-emx/bin/ld.exe: emxbind failed

make[1]: *** [hbrun.exe] Error 1
make: *** [descend] Error 2


Not working, anyway.

Maurilio.



Viktor Szakáts wrote:
> Hi,
> 
>> ! HB_COMPILER: gcc
>> ! Component: 'zlib' found in E:/REPOSITORY/HARBOUR/external/zlib (local)
>> ! Component: 'pcre' found in E:/REPOSITORY/HARBOUR/external/pcre (local)
>> ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL.
>> ! Component: 'gpm' not supported on os2 platform
>> ! Component: 'slang' not found. Configure with HB_WITH_SLANG.
>> ! Component: 'curses' not supported on os2 platform
>> ! Component: 'x11' not found. Configure with HB_WITH_X11.
>> ! Component: 'wattcp/watt-32' not supported on os2 platform
>> ! HB_INSTALL_PREFIX automatically set to: E:\REPOSITORY\HARBOUR
>> ../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg
>> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l
>> gcc   -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF
>> -ohbrun.o -c hbrun.c
>> windres -O omf   -o hbrun.res ../../../hbrun.rc
>> windres: unknown format type `omf'
>> windres: supported formats: rc res coff
> 
> I don't understand this scenario. '-O omf' 
> is only used in gccomf mode, and you're using 
> gcc here.
> 
> Could be typo on my part, but it looks alright 
> in config/os2/gcc.mk.
> 
> Brgds,
> Viktor
> 
> ___
> 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] SF.net SVN: harbour-project:[14257] trunk/harbour

[Viktor Szakáts]

> Viktor,
> 
> I was not at latest svn commit, here it is after latest upgrade:
> 
> ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL.
> ! Component: 'gpm' not supported on os2 platform
> ! Component: 'slang' not found. Configure with HB_WITH_SLANG.
> ! Component: 'curses' not supported on os2 platform
> ! Component: 'x11' not found. Configure with HB_WITH_X11.
> ! Component: 'wattcp/watt-32' not supported on os2 platform
> ! HB_INSTALL_PREFIX automatically set to: E:\REPOSITORY\HARBOUR
> ../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg  
> -i../../../../../incl
> ude -n1 -q0 -w3 -es2 -kmo -i- -l
> gcc   -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF
> -ohbrun.o -c hbrun.c
> windres-o hbrun.res ../../../hbrun.rc
> gcc  -L../../../../../lib/os2/gcc   -o ..\..\..\..\..\bin\os2\gcc\hbrun.exe
> hbrun.o hbrun.res -lhbcplr -lhbpp -lhbcommon -lhbcplr -lhbdebug -lhbmainstd
> -lharbour -s
> emxbind: invalid binary resource file
> E:/Sviluppo/gcc/v3.3.5/usr/i386-pc-os2-emx/bin/ld.exe: emxbind failed
> 
> make[1]: *** [hbrun.exe] Error 1
> make: *** [descend] Error 2

goto 10. So -o coff is required, but it doesn't work.

Maybe this should be fixed in the environment?:
  windres: can't get BFD_RELOC_RVA relocation type: No such file or directory

Doesn't look like a normal output for a correct 
cmdline :/

Anyhow I'm out of guesses.

Brgds,
Viktor

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

[Harbour] WVW

[Itamar Lins]

Hi!
Many Brazilians are expecting or have not moved to the harbour because 
the wvw is not fully functional in the harbour.

Testing the file wvwtest9 is not possible to open the browse dbf.
More than 100 people waiting likely.

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] mingw 4.5.0 benchmarks

[Mindaugas Kavaliauskas]

You can also try to reduce the optimization level, i.e. you can use -Os
in MinGW flags. It should reduce the compilation time and final binaries
will be slower then the one created by BCC though still faster.


I'm trying another approach :) Upgrading from Celeron to Core i5. It 
should help a little. :)



Hi,


in ChangeLog I found some -j option for parallel compile jobs. How 
can it use it?


I'm trying:
  win-make.exe -j4
but I see no compile speed improvement.


Regards,
Mindaugas

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

[Maurilio Longo]

Viktor,

> goto 10. So -o coff is required, but it doesn't work.
> 
> Maybe this should be fixed in the environment?:
>   windres: can't get BFD_RELOC_RVA relocation type: No such file or directory
> 
Looking for this error on google it seems a problem of windres on certain
platforms.

> Doesn't look like a normal output for a correct 
> cmdline :/
> 
> Anyhow I'm out of guesses.
> 

Me too, I don't even know whether using RC.EXE is enough to be able to link
the .res to the .exe.

Maurilio.

> Brgds,
> Viktor
> 
> ___
> 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] WVW

[Viktor Szakáts]

> Many Brazilians are expecting or have not moved to the harbour because the 
> wvw is not fully functional in the harbour.
> Testing the file wvwtest9 is not possible to open the browse dbf.
> More than 100 people waiting likely.

That's good because maybe from those 100 users, 
there is a higher chance that someone will be 
able to fix the problems.

If this request was targeted to me, I'm sorry 
but I cannot help more. Wasted too much time 
with stuff just for the sake of making Harbour 
look better. Was too much being the red cross.

So, ppl, jump on it and fix it.

Brgds,
Viktor

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

Re: Re: [Harbour] Ask Str2Poniter() and Pointer2Str() function pair ....

[Rossine]

Hi,

I'm trying to use the function of you and me errors occur below:

[CODE]
function Main

  LOCAL pFunc := ( @Test() )

  cls

  ? Valtype( pFunc )

  ? POINTER2STRING( pFunc )

return NIL

function Test

   ? "hello word"

return NIL

#pragma begindump

#include "hbapi.h"

HB_FUNC( STRING2POINTER )
{
   PHB_ITEM s = hb_param( 1, HB_IT_STRING );
   if( s )
   hb_retptr( (void *) hb_itemGetCPtr( s ) );
} 

HB_FUNC( POINTER2STRING )
{
   PHB_ITEM p = hb_param( 1, HB_IT_POINTER );

   if( p )
 {
PHB_ITEM s = hb_itemNew( NULL );
PHB_ITEM n = hb_param( 2, HB_IT_NUMERIC );
hb_itemPutCL( s, hb_itemGetPtr( p ), n ? hb_itemGetNI( n ) : strlen(
hb_itemGetPtr( p ) ) );
hb_itemReturnRelease( s );
 }
}

#pragma enddump
[/CODE]

[ERROR]

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 arquivo de configuração: c:\hrb_bcc\bin\hbmk.cfg
hbmk2: Linha de comando do compilador Harbour: (interno)
(c:\hrb_bcc\bin\harbour.exe) -n2 point1.prg -n -D__BCC__ -oC:\TMP\
-ic:\hrb_bcc\
hbmk2: Comando do compilador C/C++:
bcc32.exe -c -q -tWM -d -6 -O2 -OS -Ov -Oi -Oc -DHB_GC_AUTO
-DHB_FM_STATISTIC  -
C:\TMP\point1.c:
Warning W8065 point1.prg 27: Call to function 'hb_itemGetCPtr' with no
prototype
Warning W8065 point1.prg 36: Call to function 'hb_itemNew' with no prototype
in
Warning W8069 point1.prg 36: Nonportable pointer conversion in function
HB_FUN_P
Warning W8065 point1.prg 38: Call to function 'hb_itemGetPtr' with no
prototype
Warning W8065 point1.prg 38: Call to function 'hb_itemGetNI' with no
prototype i
Warning W8065 point1.prg 38: Call to function 'hb_itemGetPtr' with no
prototype
Error E2342 point1.prg 38: Type mismatch in parameter '__s' (wanted 'const
signe
Warning W8065 point1.prg 38: Call to function 'hb_itemPutCL' with no
prototype i
Warning W8065 point1.prg 39: Call to function 'hb_itemReturnRelease' with no
pro
*** 1 errors in Compile ***
[/ERROR]

I need to do for the above example work ?

Best Regards,

Rossine.


-- 
View this message in context: 
http://old.nabble.com/Ask-Str2Poniter%28%29-and-Pointer2Str%28%29-function-pair--tp28042446p28069776.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] Re: WVW

[Itamar Lins]

Em 29/3/2010 11:01, Viktor Szakáts escreveu:

That's good because maybe from those 100 users,
there is a higher chance that someone will be
able to fix the problems.

If this request was targeted to me, I'm sorry
but I cannot help more. Wasted too much time
with stuff just for the sake of making Harbour
look better. Was too much being the red cross.

So, ppl, jump on it and fix it.

Hi!
I understand your situation, the users were the Brazilians who made the 
fix for the xHarbour 1.2.1.
So here is this newsletter. The staff starting with the WVW and then 
merges or changes to Hwgui or Mnigui, Fivewin...


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: Re: [Harbour] Ask Str2Poniter() and Pointer2Str() function pair ....

[Vailton Renato]

Hi!

The code does not compile because it contains errors. What is the
purpose of these functions? I really could not understand it.
= (

[code]
FUNCTION Main
 LOCAL pFunc := ( @Test() )

 cls
 ? Valtype( pFunc )
 ? POINTER2STRING( pFunc )
 ?
   RETURN NIL

function Test

  ? "hello word"

return NIL

#pragma begindump

#include "hbapi.h"
#include "hbapiitm.h"

HB_FUNC( STRING2POINTER )
{
  PHB_ITEM s = hb_param( 1, HB_IT_STRING );
  if( s )
  hb_retptr( (void *) hb_itemGetCPtr( s ) );
}

HB_FUNC( POINTER2STRING )
{
  PHB_ITEM p = hb_param( 1, HB_IT_POINTER );

  if( p )
{
   PHB_ITEM s = hb_itemNew( NULL );
   PHB_ITEM n = hb_param( 2, HB_IT_NUMERIC );
   hb_itemPutCL( s, hb_itemGetPtr( p ), n ? hb_itemGetNI( n ) : strlen(
hb_itemGetPtr( p ) ) );
   hb_itemReturnRelease( s );
}
}

#pragma enddump
[/code]

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

Re: [Harbour] Ask Str2Poniter() and Pointer2Str() function pair ....

[Viktor Szakáts]

> The code does not compile because it contains errors. What is the
> purpose of these functions? I really could not understand it.
> = (

It's a pretty bad notion from recent days, and I'd still strongly 
suggest everyone to not use such functions unless the goal is to 
create random crashes and HVM corruption.

Harbour's built-in .dll call support doesn't need such tricks 
to pass strings or binary structures to low-level code. They 
can and should be passed directly or by reference.

Brgds,
Viktor

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

Re: [Harbour] Re: WVW

[Massimo Belgrano]

as you seen gtwvw is not in contrib but in examples because have A Rudimentary
port
C:\harbour\examples\gtwvw
seem also Incompatible with hbwin
where is updated last gtwvw source in xharbour?

I suggest you see as alternative at GTWVG
Another way is emulate gtwvw in  gtwvt/gtwvg/XWC /gtqtc
IMO either gtwvg and gtqtc will allow this
follow is my incomplete idea for made easy the conversion

// Experiment for Emulating *gtwvw* with gtwvt/gtwvg/XWC /gtqtc
#IFDEF __PLATFORM__WINDOWS
  REQUEST HB_GT_WVT_DEFAULT
  #DEFINE THREAD_GT "WVT"
#ELSE
  REQUEST HB_GT_STD_DEFAULT
  #DEFINE THREAD_GT "XWC"
#ENDIF
#COMMAND DEFAULT  TO  [,  TO  ]=>
IF(()=NIL,:=,NIL) [; IF(()=NIL,:=,NIL)]
STATIC S_Ocrt:={}
STATIC S_setmaincoord:=.f.
#XTRANSLATE setpos(   => setpos2(

FUNCTION main
   local X_Number:=9
   cls
   wvw_setmaincoord(.t.)
   WINDO=WVW_nOpenWindow("", 5, 5, 7, 40)
   @ 5,5 ,7,40 box ""
   @ 6,6 SAY "Number" get number
   READ
   WVW_lCloseWindow(WINDO)
RETURN

FUNCTION  WVW_nOpenWindow(X_title,x_top,x_left,x_bottom,x_right)
   local ocrt
   x_ocrt := hb_gtCreate( THREAD_GT )

   setmode(x_bottom-x_top+1,x_right-x_left+1)
//? x_bottom-x_top,x_right-x_left
   x_oCrt := hb_gtSelect()
   aadd(s_ocrt,{x_ocrt,X_title,x_top,x_left,x_bottom,x_right})
   x_ret=len(s_ocrt)
   RETURN x_ret

FUNCTION WVW_lCloseWindow(x_pos)
default x_pos to len(s_ocrt)
   s_ocrt[x_pos,1]=nil
   adel(s_ocrt,x_pos,.t.)
   RETURN

FUNCTION wvw_setmaincoord(x_coord)
   s_setmaincoord:=x_coord
   RETURN

#XUNTRANSLATE setpos(   =>
FUNCTION SetPos2( x_row, x_col )
   local x_pos:=len(s_ocrt)
   // altd()
   if s_setmaincoord
  setpos(x_row-s_ocrt[x_pos,3],x_col-s_ocrt[x_pos,5])
   else
  setpos(x_row,x_col)
   endif
   RETURN



2010/3/29 Itamar Lins 

> Em 29/3/2010 11:01, Viktor Szakáts escreveu:
>
>  That's good because maybe from those 100 users,
>> there is a higher chance that someone will be
>> able to fix the problems.
>>
>> If this request was targeted to me, I'm sorry
>> but I cannot help more. Wasted too much time
>> with stuff just for the sake of making Harbour
>> look better. Was too much being the red cross.
>>
>> So, ppl, jump on it and fix it.
>>
> Hi!
> I understand your situation, the users were the Brazilians who made the fix
> for the xHarbour 1.2.1.
> So here is this newsletter. The staff starting with the WVW and then merges
> or changes to Hwgui or Mnigui, Fivewin...
>
>
> Best regards,
> Itamar M. Lins Jr.
>
>
-- 
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: WVW

[Viktor Szakáts]

Hi Itamar,

>> If this request was targeted to me, I'm sorry
>> but I cannot help more. Wasted too much time
>> with stuff just for the sake of making Harbour
>> look better. Was too much being the red cross.
>> 
>> So, ppl, jump on it and fix it.
> Hi!
> I understand your situation, the users were the Brazilians who made the fix 
> for the xHarbour 1.2.1.

It's not a situation, it's a decision.

> So here is this newsletter. The staff starting with the WVW and then merges 
> or changes to Hwgui or Mnigui, Fivewin...

Sorry, I don't understand. I've made 
the porting work with GTWVW so that it at 
least builds with Harbour and demos more 
or less run, but rest of steps have to be 
done by those who need these features.

Keyboard handling uses some strange xhb 
method which don't seem to be present in 
Harbour, but the rest is pretty mechanical 
bugfixing and applying usual cleaning/fixing 
steps we used to have in Harbour-quality code.
The code is quite large so it needs time if 
someone wants to take the job seriously.

Brgds,
Viktor

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

Re: [Harbour] mingw 4.5.0 benchmarks

[Przemysław Czerpak]

On Mon, 29 Mar 2010, Mindaugas Kavaliauskas wrote:

Hi,

> in ChangeLog I found some -j option for parallel compile jobs.
> How can it use it?
> I'm trying:
>   win-make.exe -j4
> but I see no compile speed improvement.

This option enables simultaneous compilation of different files.
It means that it will not change the compilation of single file
at all but when many files have to be compiled and -j is passed
as GNU make parameter then it creates upto  processes and each
of them is used to compile different files. So the total compilation
time of is greatly reduced on multi CPU machine.
Personally I'm using -j4 or -j5 on my 3 CPU machine and it reduces
total Harbour compilation time about 3 times.

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

Re: [Harbour] mingw 4.5.0 benchmarks

[Mindaugas Kavaliauskas]

Przemysław Czerpak wrote:

This option enables simultaneous compilation of different files.
It means that it will not change the compilation of single file
at all but when many files have to be compiled and -j is passed
as GNU make parameter then it creates upto  processes and each
of them is used to compile different files. So the total compilation
time of is greatly reduced on multi CPU machine.
Personally I'm using -j4 or -j5 on my 3 CPU machine and it reduces
total Harbour compilation time about 3 times.


Hi,


I'm trying to compile the whole Harbour on Core i5 (2 cores + 
hyper-threading, so, 4 virtual CPU are visible to the system). But I see 
no speed improvement of -j4 using:

  win-make.exe -j4
Is this correct way to pass -j4 option? I though, that maybe I need to 
pass in a different way:

  set HB_MAKE_OPTIONS=-j4
or something like that, to make -j work


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

Re: [Harbour] Ask Str2Poniter() and Pointer2Str() function pair ....

[Vailton Renato]

Hi!

I agree with Viktor that this type of access is not recommended
because it represents a great risk to system stability. But just to
illustrate, if you want to get the memory address of a particular
variable (I do not see much use in it but ..) this is an example:

[TEST.PRG]
#include "simpleio.ch"

FUNCTION Main
 LOCAL a, b, c, d, e, f, g

 a := b := "A single text"
 h := 'Other text'

 c := d := {}
 e := ( @qqout() )
 f := e
 g := @date()

 cls
 ? 'string :', _GETADDRESS(a), _GETADDRESS(b), _GETADDRESS(h)
 ?
 ? 'arrays :',_GETADDRESS(c), _GETADDRESS(d)
 ?
 ? 'pointer (1):', _GETADDRESS(e), _GETADDRESS(f)
 ?
 ? 'pointer (2):', _GETADDRESS(g), _GETADDRESS( @date() )
 ?
   RETURN NIL
// end of file

[GETADDRESS.C]
#include "hbvmopt.h"
#include "hbapi.h"
#include "hbapiitm.h"
#include "hbstack.h"

HB_FUNC( _GETADDRESS )
{
   PHB_ITEM pItem = hb_param( 1, HB_IT_ANY );
   char buffer[ 16 ];

   memset( buffer, 0, sizeof( buffer ) );

   switch( hb_itemType( pItem ) )
   {
  case HB_IT_ARRAY:
 hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
)->item.asArray.value );
 break;

  case HB_IT_STRING:
  case HB_IT_MEMO:
 hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
)->item.asString.value );
 break;

  case HB_IT_SYMBOL:
 hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
)->item.asSymbol.value->value.pFunPtr );
 break;

  case HB_IT_POINTER:
 hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
)->item.asPointer.value );
 break;

  default:
 hb_snprintf( buffer, sizeof( buffer ), "%p", 0 );
 break;
   }

   hb_retc( buffer );
}
// end of file
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: WVW

[Pritpal Bedi]

Itamar Lins-2 wrote:
> 
> I understand your situation, the users were the Brazilians who made the 
> fix for the xHarbour 1.2.1.
> 

How ill-informed I remained so long.

I was under the impression that "they" were "Clipper heads" who fixed
but infact they were "Brazilians"...




-
 enjoy hbIDEing...
Pritpal Bedi 
_a_student_of_software_analysis_&_design_
-- 
View this message in context: http://n2.nabble.com/WVW-tp4817934p4818597.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: WVW

[Przemysław Czerpak]

On Mon, 29 Mar 2010, Szak�ts Viktor wrote:

Hi,

> Keyboard handling uses some strange xhb 
> method which don't seem to be present in 
> Harbour, but the rest is pretty mechanical 
> bugfixing and applying usual cleaning/fixing 
> steps we used to have in Harbour-quality code.
> The code is quite large so it needs time if 
> someone wants to take the job seriously.

I'm afraid it's not such simple.
This code either in Harbour or xHarbour ports has
bugs which have to be fixed to make it production
ready. In most of cases these are the same errors
in both projects because the code in Harbour SVN is
in practice the same as in xHarbour CVS and Viktor
only updated it to compile cleanly with Harbour API
and cleaned some small part of this code removing
redundant constructions.
But it does not mean that it will work correctly with
Harbour or that it works correctly with xHarbour.
In both cases it's broken, i.e. things like s_iCursorStyle
cannot work properly when more then one window is created.
Many methods should not be overloaded at at all (in general
this code does not try to benefit from new GT API at all.
Ne GT API allows to greatly simplify it and probably remove
about 50% of the core WVW code.
Some things in this library looks like copy and past from
different project and the author didn't understand what
exactly the code he collected does, i.e.
  TEXT( (char*) hb_parvcx( 1,11 ) )
is complete technical nonsense and this probably causes
that non of use wants to touch it at all because to change
sth it's necessary to check each line which can be broken
and it's a to big risk that one fix will exploit new bugs.
IMO it's much easier to write new GT driver with similar
functionality from scratch then start updating this code
which in current state it's not production ready. It doesn't
matter you are using Harbour or xHarbour.

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

Re: [Harbour] mingw 4.5.0 benchmarks

[Przemysław Czerpak]

On Mon, 29 Mar 2010, Mindaugas Kavaliauskas wrote:

Hi,

> I'm trying to compile the whole Harbour on Core i5 (2 cores +
> hyper-threading, so, 4 virtual CPU are visible to the system). But I
> see no speed improvement of -j4 using:
>   win-make.exe -j4
> Is this correct way to pass -j4 option? I though, that maybe I need

For me it's enough. I'm using:
   make -j5
I even tested MinGW cross build and it works very nice
but maybe this win-make.exe does not support it.

> to pass in a different way:
>   set HB_MAKE_OPTIONS=-j4
> or something like that, to make -j work

I do not know about it. Maybe Viktor can help.

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

Re: [Harbour] Re: hbIDE - On-line documentation-cum-distro update

[francesco perillo]

Pritpal,
can you please spend some time trying to write some documentation on
the internals of the interface to Qt ?


It would give others a quick start ...

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

[Harbour] Re: hbIDE - On-line documentation-cum-distro update

[Pritpal Bedi]

francesco perillo wrote:
> 
> can you please spend some time trying to write some documentation on
> the internals of the interface to Qt ?
> 

One such document is under topic "hbQT - GC - Qt Object Destruction"
at http://hbide.vouch.info/.

This is not the best way to express what I wanted but still...

Przemek, can you look at this topic ?


-
 enjoy hbIDEing...
Pritpal Bedi 
_a_student_of_software_analysis_&_design_
-- 
View this message in context: 
http://n2.nabble.com/hbIDE-On-line-documentation-cum-distro-update-tp4812225p4819176.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] Ask Str2Poniter() and Pointer2Str() function pair ....

[Rossine]

Hello Vailton,

It´s works fine :)

Many thank´s,

Rossine.


Vailton Renato wrote:
> 
> Hi!
> 
> I agree with Viktor that this type of access is not recommended
> because it represents a great risk to system stability. But just to
> illustrate, if you want to get the memory address of a particular
> variable (I do not see much use in it but ..) this is an example:
> 
> [TEST.PRG]
> #include "simpleio.ch"
> 
> FUNCTION Main
>  LOCAL a, b, c, d, e, f, g
> 
>  a := b := "A single text"
>  h := 'Other text'
> 
>  c := d := {}
>  e := ( @qqout() )
>  f := e
>  g := @date()
> 
>  cls
>  ? 'string :', _GETADDRESS(a), _GETADDRESS(b), _GETADDRESS(h)
>  ?
>  ? 'arrays :',_GETADDRESS(c), _GETADDRESS(d)
>  ?
>  ? 'pointer (1):', _GETADDRESS(e), _GETADDRESS(f)
>  ?
>  ? 'pointer (2):', _GETADDRESS(g), _GETADDRESS( @date() )
>  ?
>RETURN NIL
> // end of file
> 
> [GETADDRESS.C]
> #include "hbvmopt.h"
> #include "hbapi.h"
> #include "hbapiitm.h"
> #include "hbstack.h"
> 
> HB_FUNC( _GETADDRESS )
> {
>PHB_ITEM pItem = hb_param( 1, HB_IT_ANY );
>char buffer[ 16 ];
> 
>memset( buffer, 0, sizeof( buffer ) );
> 
>switch( hb_itemType( pItem ) )
>{
>   case HB_IT_ARRAY:
>  hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
> )->item.asArray.value );
>  break;
> 
>   case HB_IT_STRING:
>   case HB_IT_MEMO:
>  hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
> )->item.asString.value );
>  break;
> 
>   case HB_IT_SYMBOL:
>  hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
> )->item.asSymbol.value->value.pFunPtr );
>  break;
> 
>   case HB_IT_POINTER:
>  hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
> )->item.asPointer.value );
>  break;
> 
>   default:
>  hb_snprintf( buffer, sizeof( buffer ), "%p", 0 );
>  break;
>}
> 
>hb_retc( buffer );
> }
> 

-- 
View this message in context: 
http://old.nabble.com/Ask-Str2Poniter%28%29-and-Pointer2Str%28%29-function-pair--tp28042446p28072444.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] Re: WVW

[Itamar Lins]

Em 29/3/2010 12:22, Pritpal Bedi escreveu:



Itamar Lins-2 wrote:


I understand your situation, the users were the Brazilians who made the
fix for the xHarbour 1.2.1.



How ill-informed I remained so long.

I was under the impression that "they" were "Clipper heads" who fixed
but infact they were "Brazilians"...




-
  enjoy hbIDEing...
 Pritpal Bedi
_a_student_of_software_analysis_&_design_

The update was made by the Brazilian:
Cristiam Azambuja.

cristiamazamb...@gmail.com

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] mingw 4.5.0 benchmarks

[Viktor Szakáts]

>> I'm trying to compile the whole Harbour on Core i5 (2 cores +
>> hyper-threading, so, 4 virtual CPU are visible to the system). But I
>> see no speed improvement of -j4 using:
>>  win-make.exe -j4
>> Is this correct way to pass -j4 option? I though, that maybe I need
> 
> For me it's enough. I'm using:
>   make -j5
> I even tested MinGW cross build and it works very nice
> but maybe this win-make.exe does not support it.

It should support it. It's standard 3.81 build.

>> to pass in a different way:
>>  set HB_MAKE_OPTIONS=-j4
>> or something like that, to make -j work
> 
> I do not know about it. Maybe Viktor can help.

No such trick is needed.

Brgds,
Viktor

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

[Harbour] Re: WVW

[Itamar Lins]

Em 29/3/2010 11:36, Viktor Szakáts escreveu:

Hi Itamar,


If this request was targeted to me, I'm sorry
but I cannot help more. Wasted too much time
with stuff just for the sake of making Harbour
look better. Was too much being the red cross.

So, ppl, jump on it and fix it.

Hi!
I understand your situation, the users were the Brazilians who made the fix for 
the xHarbour 1.2.1.


It's not a situation, it's a decision.


So here is this newsletter. The staff starting with the WVW and then merges or 
changes to Hwgui or Mnigui, Fivewin...


Sorry, I don't understand. I've made
the porting work with GTWVW so that it at
least builds with Harbour and demos more
or less run, but rest of steps have to be
done by those who need these features.

Keyboard handling uses some strange xhb
method which don't seem to be present in
Harbour, but the rest is pretty mechanical
bugfixing and applying usual cleaning/fixing
steps we used to have in Harbour-quality code.
The code is quite large so it needs time if
someone wants to take the job seriously.

Brgds,
Viktor


Hi! I am not user of WVW.
It's hard for me sometimes to bridge the gap between the real users.

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] Re: WVW

[Viktor Szakáts]

>> Keyboard handling uses some strange xhb 
>> method which don't seem to be present in 
>> Harbour, but the rest is pretty mechanical 
>> bugfixing and applying usual cleaning/fixing 
>> steps we used to have in Harbour-quality code.
>> The code is quite large so it needs time if 
>> someone wants to take the job seriously.
> 
> I'm afraid it's not such simple.
> This code either in Harbour or xHarbour ports has
> bugs which have to be fixed to make it production
> ready. In most of cases these are the same errors
> in both projects because the code in Harbour SVN is
> in practice the same as in xHarbour CVS and Viktor
> only updated it to compile cleanly with Harbour API
> and cleaned some small part of this code removing
> redundant constructions.
> But it does not mean that it will work correctly with
> Harbour or that it works correctly with xHarbour.
> In both cases it's broken, i.e. things like s_iCursorStyle
> cannot work properly when more then one window is created.
> Many methods should not be overloaded at at all (in general
> this code does not try to benefit from new GT API at all.
> Ne GT API allows to greatly simplify it and probably remove
> about 50% of the core WVW code.
> Some things in this library looks like copy and past from
> different project and the author didn't understand what
> exactly the code he collected does, i.e.
>  TEXT( (char*) hb_parvcx( 1,11 ) )
> is complete technical nonsense and this probably causes
> that non of use wants to touch it at all because to change
> sth it's necessary to check each line which can be broken
> and it's a to big risk that one fix will exploit new bugs.
> IMO it's much easier to write new GT driver with similar
> functionality from scratch then start updating this code
> which in current state it's not production ready. It doesn't
> matter you are using Harbour or xHarbour.

That sums it up pretty nicely. To me it's also a 
big wonder how users can use such clumsy code in 
real applications, and not even a single one cares 
enough to fix at least the bigger bugs.

F.e. in case of GTWVW, it's enough to turn on 
warnings to reveal a huge amount of problems to fix.

Anyway, it's not my problem.

Brgds,
Viktor

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

Re: [Harbour] Ask Str2Poniter() and Pointer2Str() function pair ....

[Vailton Renato]

Hi!

To support MT need this:

[GETADDRESS.C]
#include "hbvmopt.h"
#include "hbapi.h"
#include "hbapiitm.h"
#include "hbstack.h"

HB_FUNC( _GETADDRESS )
{
   PHB_ITEM pItem   = hb_param( 1, HB_IT_ANY );
   PHB_ITEM pResult = hb_itemNew( NULL );
   char buffer[ 16 ];

   memset( buffer, 0, sizeof( buffer ) );

   switch( hb_itemType( pItem ) )
   {
  case HB_IT_ARRAY:
 hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
)->item.asArray.value );
 break;

  case HB_IT_STRING:
  case HB_IT_MEMO:
 hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
)->item.asString.value );
 break;

  case HB_IT_SYMBOL:
 hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
)->item.asSymbol.value->value.pFunPtr );
 break;

  case HB_IT_POINTER:
 hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
)->item.asPointer.value );
 break;

  default:
 hb_snprintf( buffer, sizeof( buffer ), "%p", 0 );
 break;
   }

   hb_itemPutC( pResult, buffer );
   hb_itemReturnRelease( pResult );
}
// end of file
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Ask Str2Poniter() and Pointer2Str() function pair ....

[Rossine]

Hi Vailton,

Great :)

Many, many thanks :)

Rossine.


Vailton Renato wrote:
> 
> Hi!
> 
> To support MT need this:
> 
> [GETADDRESS.C]
> #include "hbvmopt.h"
> #include "hbapi.h"
> #include "hbapiitm.h"
> #include "hbstack.h"
> 
> HB_FUNC( _GETADDRESS )
> {
>PHB_ITEM pItem   = hb_param( 1, HB_IT_ANY );
>PHB_ITEM pResult = hb_itemNew( NULL );
>char buffer[ 16 ];
> 
>memset( buffer, 0, sizeof( buffer ) );
> 
>switch( hb_itemType( pItem ) )
>{
>   case HB_IT_ARRAY:
>  hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
> )->item.asArray.value );
>  break;
> 
>   case HB_IT_STRING:
>   case HB_IT_MEMO:
>  hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
> )->item.asString.value );
>  break;
> 
>   case HB_IT_SYMBOL:
>  hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
> )->item.asSymbol.value->value.pFunPtr );
>  break;
> 
>   case HB_IT_POINTER:
>  hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
> )->item.asPointer.value );
>  break;
> 
>   default:
>  hb_snprintf( buffer, sizeof( buffer ), "%p", 0 );
>  break;
>}
> 
>hb_itemPutC( pResult, buffer );
>hb_itemReturnRelease( pResult );
> }
> // end of file
> ___
> 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/Ask-Str2Poniter%28%29-and-Pointer2Str%28%29-function-pair--tp28042446p28074185.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] Ask Str2Poniter() and Pointer2Str() function pair ....

[Viktor Szakáts]

This code uses internals, which it a total no-no, 
for user code.

Brgds,
Viktor

On 2010 Mar 29, at 21:15, Vailton Renato wrote:

> Hi!
> 
> To support MT need this:
> 
> [GETADDRESS.C]
> #include "hbvmopt.h"
> #include "hbapi.h"
> #include "hbapiitm.h"
> #include "hbstack.h"
> 
> HB_FUNC( _GETADDRESS )
> {
>   PHB_ITEM pItem   = hb_param( 1, HB_IT_ANY );
>   PHB_ITEM pResult = hb_itemNew( NULL );
>   char buffer[ 16 ];
> 
>   memset( buffer, 0, sizeof( buffer ) );
> 
>   switch( hb_itemType( pItem ) )
>   {
>  case HB_IT_ARRAY:
> hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
> )->item.asArray.value );
> break;
> 
>  case HB_IT_STRING:
>  case HB_IT_MEMO:
> hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
> )->item.asString.value );
> break;
> 
>  case HB_IT_SYMBOL:
> hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
> )->item.asSymbol.value->value.pFunPtr );
> break;
> 
>  case HB_IT_POINTER:
> hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
> )->item.asPointer.value );
> break;
> 
>  default:
> hb_snprintf( buffer, sizeof( buffer ), "%p", 0 );
> break;
>   }
> 
>   hb_itemPutC( pResult, buffer );
>   hb_itemReturnRelease( pResult );
> }
> // end of file
> ___
> 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] Ask Str2Poniter() and Pointer2Str() function pair ....

[Viktor Szakáts]

Looks like we're starting to resemble xhb.

Brgds,
Viktor

On 2010 Mar 29, at 21:43, Rossine wrote:

> 
> Hi Vailton,
> 
> Great :)
> 
> Many, many thanks :)
> 
> Rossine.
> 
> 
> Vailton Renato wrote:
>> 
>> Hi!
>> 
>> To support MT need this:
>> 
>> [GETADDRESS.C]
>> #include "hbvmopt.h"
>> #include "hbapi.h"
>> #include "hbapiitm.h"
>> #include "hbstack.h"
>> 
>> HB_FUNC( _GETADDRESS )
>> {
>>   PHB_ITEM pItem   = hb_param( 1, HB_IT_ANY );
>>   PHB_ITEM pResult = hb_itemNew( NULL );
>>   char buffer[ 16 ];
>> 
>>   memset( buffer, 0, sizeof( buffer ) );
>> 
>>   switch( hb_itemType( pItem ) )
>>   {
>>  case HB_IT_ARRAY:
>> hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
>> )->item.asArray.value );
>> break;
>> 
>>  case HB_IT_STRING:
>>  case HB_IT_MEMO:
>> hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
>> )->item.asString.value );
>> break;
>> 
>>  case HB_IT_SYMBOL:
>> hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
>> )->item.asSymbol.value->value.pFunPtr );
>> break;
>> 
>>  case HB_IT_POINTER:
>> hb_snprintf( buffer, sizeof( buffer ), "%p", ( pItem
>> )->item.asPointer.value );
>> break;
>> 
>>  default:
>> hb_snprintf( buffer, sizeof( buffer ), "%p", 0 );
>> break;
>>   }
>> 
>>   hb_itemPutC( pResult, buffer );
>>   hb_itemReturnRelease( pResult );
>> }
>> // end of file
>> ___
>> 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/Ask-Str2Poniter%28%29-and-Pointer2Str%28%29-function-pair--tp28042446p28074185.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 mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 14255 error on build

[Przemysław Czerpak]

On Mon, 29 Mar 2010, Szak�ts Viktor wrote:

Hi,

> >> /*
> >> * $Id: hbrun.rc 14255 2010-03-28 17:23:00Z vszakats $
> >> */
> >> #if ( defined( OS2 ) || defined( __OS2__ ) || defined( OS_2 ) ) && ! 
> >> defined( __GNUC__ )
> >> /* os2/watcom */
> >>  ICON DISCARDABLE "../../../../../package/harbour.ico"
> >> #else
> >> ICON1 ICON DISCARDABLE "../../../../../package/harbour.ico"
> >> #endif
> >> ---
> > without icon ID for the os2/watcom line?
> Yes.

OS2 OW resource compiler (wrc) accepts only numeric IDs which have to be
given explicitly or indirectly by #define macros. It also uses a little
bit different syntax and it needs resource type at the beginning of
definition instead of resource ID, i.e.:

   ICON   1 DISCARDABLE "icon1.ico"
   ICON   2 DISCARDABLE "icon2.ico"
   BITMAP 1 DISCARDABLE "bitmap1.bmp"
   BITMAP 2 DISCARDABLE "bitmap2.bmp"

so the correct definition should look like:

   ICON 1 DISCARDABLE "../../../../../package/harbour.ico"

You can use also:

   #define ICON1  1
   ICON ICON1 DISCARDABLE "../../../../../package/harbour.ico"

It should be more readable for windows users and allow to easy extract
IDs used in resource file, i.e. they can be moved to some .h or .ch file
which is included from the source code and .rc file.

I have no idea what means:

   ICON DISCARDABLE "../../../../../package/harbour.ico"

Maybe DISCARDABLE is preprocessed by wrc to some numeric value which
is later used as icon ID?

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

Re: [Harbour] 14255 error on build

[Viktor Szakáts]

Hi Przemek,

 * $Id: hbrun.rc 14255 2010-03-28 17:23:00Z vszakats $
 */
 #if ( defined( OS2 ) || defined( __OS2__ ) || defined( OS_2 ) ) && ! 
 defined( __GNUC__ )
 /* os2/watcom */
 ICON DISCARDABLE "../../../../../package/harbour.ico"
 #else
 ICON1 ICON DISCARDABLE "../../../../../package/harbour.ico"
 #endif
 ---
>>> without icon ID for the os2/watcom line?
>> Yes.
> 
> OS2 OW resource compiler (wrc) accepts only numeric IDs which have to be
> given explicitly or indirectly by #define macros. It also uses a little
> bit different syntax and it needs resource type at the beginning of
> definition instead of resource ID, i.e.:
> 
>   ICON   1 DISCARDABLE "icon1.ico"
>   ICON   2 DISCARDABLE "icon2.ico"
>   BITMAP 1 DISCARDABLE "bitmap1.bmp"
>   BITMAP 2 DISCARDABLE "bitmap2.bmp"
> 
> so the correct definition should look like:
> 
>   ICON 1 DISCARDABLE "../../../../../package/harbour.ico"
> 
> You can use also:
> 
>   #define ICON1  1
>   ICON ICON1 DISCARDABLE "../../../../../package/harbour.ico"
> 
> It should be more readable for windows users and allow to easy extract
> IDs used in resource file, i.e. they can be moved to some .h or .ch file
> which is included from the source code and .rc file.
> 
> I have no idea what means:
> 
>   ICON DISCARDABLE "../../../../../package/harbour.ico"
> 
> Maybe DISCARDABLE is preprocessed by wrc to some numeric value which
> is later used as icon ID?

Can be, I don't know. For sure, after your suggestions now 
I'm back to original commit for OS/2 (which matches hbmk2), 
with the only difference that forwards slashes are used.

This was reported by Maurilio to fail with gcc, but maybe 
it was the slashes. I'll commit it and we will see.

This is current version:
---
#if defined( OS2 ) || defined( __OS2__ ) || defined( OS_2 )
ICON 1 DISCARDABLE "../../../../../package/harbour.ico"
#else
ICON1 ICON DISCARDABLE "../../../../../package/harbour.ico"
#endif
---

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

[vszakats]

Revision: 14258
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14258&view=rev
Author:   vszakats
Date: 2010-03-29 20:36:08 + (Mon, 29 Mar 2010)

Log Message:
---
2010-03-29 22:34 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * utils/hbmk2/hbmk2.prg
! Fixed to always convert pathseps in icon filename to forward 
  slashes.

  * utils/hbrun/hbrun.rc
* Cleaned. Now back to original commit with purely forward 
  slashes. Should see if this works with OS/2 GCC windres.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/utils/hbmk2/hbmk2.prg
trunk/harbour/utils/hbrun/hbrun.rc


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] Ask Str2Poniter() and Pointer2Str() function pair ....

[Przemysław Czerpak]

On Mon, 29 Mar 2010, Szak�ts Viktor wrote:

Hi,

> Looks like we're starting to resemble xhb.

I hope not.
xHarbour reach the level where core developers have serious
problems to control the code and understand/know all hacks
inside and all internal dependencies created by direct accessing
of HVM structures.

I hope that sth like that will not happen with Harbour.
It's very important to use only documented API (BTW this code example
can be written using only document API functions)

In the worst case we will have to create list of users using such
hacks to ignore any bug reports from them.
I do not plan to wast my time looking for GPF or any other problems
if they can be caused by none core code accessing HVM internals.
I still remember how I was working on xHarbour core code and I'm very
happy that now I do not have to spend most of my devel time looking
for the any interactions with any other code accessing HVM internals
when I wanted to change sth or looking for reasons of some GPFs or
or other unexpected problems reported by users.
Current Harbour core code is still not perfect but for sure much much
better then xHarbour one so working on core code is much more efficient.

best regards,
Przemek
___
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:[14259] trunk/harbour

[druzus]

Revision: 14259
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14259&view=rev
Author:   druzus
Date: 2010-03-29 20:43:03 + (Mon, 29 Mar 2010)

Log Message:
---
2010-03-29 22:42 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/include/hbthread.h
  * harbour/src/vm/thread.c
% use thread local memory to optimize _hb_gettid()
% use _hb_gettid() instead of _gettid() in OS2 GCC builds

  * harbour/src/vm/hvm.c
% minor speed improvement

  * harbour/src/vm/memvars.c
! cleaned local vars detaching code

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/include/hbthread.h
trunk/harbour/src/vm/hvm.c
trunk/harbour/src/vm/memvars.c
trunk/harbour/src/vm/thread.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:[14260] trunk/harbour

[vszakats]

Revision: 14260
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14260&view=rev
Author:   vszakats
Date: 2010-03-29 20:54:13 + (Mon, 29 Mar 2010)

Log Message:
---
2010-03-29 22:53 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * config/os2/gcc.mk
+ Readded OS/2 windres call in coff mode. Commented the whole 
  thing with NOTE. Seems like windres bug.
  I left gccomf branch active, maybe they fixed it in those 
  more recent versions.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/config/os2/gcc.mk


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

Re: [Harbour] Ask Str2Poniter() and Pointer2Str() function pair ....

[Vailton Renato]

Hi,

I myself would not use on a daily basis something like this, but I do
not know for sure to which particular need it would be useful. It's
just an example and as I mentioned above, I agree with Viktor that
something of this kind is strongly discouraged.

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

Re: [Harbour] Ask Str2Poniter() and Pointer2Str() function pair ....

[Viktor Szakáts]

Hi,

> I myself would not use on a daily basis something like this, but I do
> not know for sure to which particular need it would be useful. It's
> just an example and as I mentioned above, I agree with Viktor that
> something of this kind is strongly discouraged.

In such case it may be better solution to first ask what 
the intention/goal of the poster is. This way we can 
present proper solution and effectively discourage such 
bad examples leaking to users.

I'm almost certain that such dangerous hacks are not 
necessary for any normal Harbour application. Or if they 
are for some reason, we may try to develop something proper 
to address it. We will never know now.

[ F.e. nobody even cared to try or explore recently 
rewritten .dll handling. But since we don't know the 
goal, maybe it's not the solution anyway. ]

[ BTW, someone falsely stated somewhere that .dll calls 
is Windows only solution in Harbour. This is false, they 
are now part of core and portable. ]

Brgds,
Viktor

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

[Harbour] Harbour-made Win9x .EXE's running slow?

[smu johnson]

Hi,

We have a little benchmarking section in a Clipper program we wrote that
gives a percentage of how fast it's running overall.  I believe it is doing
500 SIXCDX row creates etc...

For Win98 programs, are 32-bit .EXE's compiled with Harbour + TDM Mingw have
around 25% on that list, whereas when they are around 200%+ when compiled as
16-bit with cl52e.

This problem doesn't happen with XP and above.

So, I'm wondering if for Win98, the Harbour-made .EXEs... have to emulate
some 32-bit mode?  Or maybe the processors in most Win98 machines are 16-bit
CPUs?  I really have no idea... I wish I knew more about this... but in a
nutshell, our test is running WAY slower than cl52e + Win98.

Thank you for reading.

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

[Harbour] Re: WVW

[Itamar Lins]

Hi!

The fact is that many people are waiting, changes in xHarbour, which in 
my opinion is already a dying project.
Through forums Brazilians can see that only the WVW and RDDSQL 
xHarbour.com hold some of Brazilian users with the xHarbour persists.
Because since the departure of Mr Przmek, there were no significant 
changes in the code.
We are currently looking for more examples and documentation for using 
the fb.

This simple code shows a problem with the WVW + HBCT in harbour

#include   'common.ch'
PROCEDURE Main

WVW_SetMainCoord( .t. )
WVW_SetCodePage(,255)
SETMODE(25, 80)
nWin := WOPEN( 2, 10, 22, 70, .T. )
WSelect(nWin)
@ 1, 1 SAY "TESTE..." //Should draw on the coordinates of wopen
INKEY(0)
WAClose()
INKEY(0)

RETURN NIL


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] Re: WVW

[Bruno Luciani]

This is an only windows library

Is that wright ?

Bruno

2010/3/29 Itamar Lins 

> Hi!
>
> The fact is that many people are waiting, changes in xHarbour, which in my
> opinion is already a dying project.
> Through forums Brazilians can see that only the WVW and RDDSQL xHarbour.com
> hold some of Brazilian users with the xHarbour persists.
> Because since the departure of Mr Przmek, there were no significant changes
> in the code.
> We are currently looking for more examples and documentation for using the
> fb.
> This simple code shows a problem with the WVW + HBCT in harbour
>
> #include   'common.ch'
> PROCEDURE Main
>
>WVW_SetMainCoord( .t. )
>WVW_SetCodePage(,255)
>SETMODE(25, 80)
>nWin := WOPEN( 2, 10, 22, 70, .T. )
>WSelect(nWin)
>@ 1, 1 SAY "TESTE..." //Should draw on the coordinates of wopen
>INKEY(0)
>WAClose()
>INKEY(0)
>
>RETURN NIL
>
>
>
> 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 mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: WVW

[Itamar Lins]

Em 29/3/2010 20:30, Bruno Luciani escreveu:

This is an only windows library

Is that wright ?

Bruno

Yes. Unfortunately there are many systems done with it.

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] LIB hbmysql

[JOEL - YAHOO]

Hi
Please, give me some information.
The LIB hbmysql is available for version 5.0.89?
I'm trying to write a small application with MinGW32 and I'm having the 
carriage return below.
Attached the header of imported LIB command -->> "dlltool-D libmysql.dll 
libmysql.def-d-l-k libmysql.a "



/harbour/lib/libhbmysql.a(mysql.o):mysql.c:(.text+0xa4): undefined 
reference to

`mysql_escape_str...@12'
/harbour/lib/libhbmysql.a(mysql.o):mysql.c:(.text+0x115): undefined 
reference to

 `mysql_escape_str...@12'
/harbour/lib/libhbmysql.a(mysql.o):mysql.c:(.text+0x156): undefined 
reference to

 `mysql_cl...@4'
/harbour/lib/libhbmysql.a(mysql.o):mysql.c:(.text+0x199): undefined 
reference to

 `mysql_cl...@4'
/harbour/lib/libhbmysql.a(mysql.o):mysql.c:(.text+0x1c6): undefined 
reference to

 `mysql_free_res...@4'
/harbour/lib/libhbmysql.a(mysql.o):mysql.c:(.text+0x209): undefined 
reference to

 `mysql_free_res...@4'
/harbour/lib/libhbmysql.a(mysql.o):mysql.c:(.text+0x2be): undefined 
reference to

 `mysql_i...@4'
...

Best Regards
Joel Bernardes

LIBRARY LIBMYSQL.DLL

EXPORTS
_dig_vec_lower @1   ; _dig_vec_lower
_dig_vec_upper @2   ; _dig_vec_upper
bmove_upp  @3   ; bmove_upp
client_errors  @4   ; client_errors
delete_dynamic @5   ; delete_dynamic
free_defaults  @6   ; free_defaults
get_defaults_options   @7   ; get_defaults_options
getopt_compare_strings @8   ; getopt_compare_strings
getopt_ull_limit_value @9   ; getopt_ull_limit_value
handle_options @10  ; handle_options
init_dynamic_array @11  ; init_dynamic_array
insert_dynamic @12  ; insert_dynamic
int2str@13  ; int2str
is_prefix  @14  ; is_prefix
list_add   @15  ; list_add
list_delete@16  ; list_delete
load_defaults  @17  ; load_defaults
modify_defaults_file   @18  ; modify_defaults_file
my_end @19  ; my_end
my_getopt_print_errors @20  ; my_getopt_print_errors
my_init@21  ; my_init
my_malloc  @22  ; my_malloc
my_memdup  @23  ; my_memdup
my_no_flags_free   @24  ; my_no_flags_free
my_path@25  ; my_path
my_print_help  @26  ; my_print_help
my_print_variables @27  ; my_print_variables
my_realloc @28  ; my_realloc
my_strdup  @29  ; my_strdup
myodbc_remove_escape   @30  ; myodbc_remove_escape
mysql_affected_rows@31  ; mysql_affected_rows
mysql_autocommit   @32  ; mysql_autocommit
mysql_change_user  @33  ; mysql_change_user
mysql_character_set_name   @34  ; mysql_character_set_name
mysql_close@35  ; mysql_close
mysql_commit   @36  ; mysql_commit
mysql_data_seek@37  ; mysql_data_seek
mysql_debug@38  ; mysql_debug
mysql_disable_reads_from_master @39  ; mysql_disable_reads_from_master
mysql_disable_rpl_parse@40  ; mysql_disable_rpl_parse
mysql_dump_debug_info  @41  ; mysql_dump_debug_info
mysql_embedded @42  ; mysql_embedded
mysql_enable_reads_from_master @43  ; mysql_enable_reads_from_master
mysql_enable_rpl_parse @44  ; mysql_enable_rpl_parse
mysql_eof  @45  ; mysql_eof
mysql_errno@46  ; mysql_errno
mysql_error@47  ; mysql_error
mysql_escape_string@48  ; mysql_escape_string
mysql_fetch_field  @49  ; mysql_fetch_field
mysql_fetch_field_direct   @50  ; mysql_fetch_field_direct
mysql_fetch_fields @51  ; mysql_fetch_fields
mysql_fetch_lengths@52  ; mysql_fetch_lengths
mysql_fetch_row@53  ; mysql_fetch_row
mysql_field_count  @54  ; mysql_field_count
mysql_field_seek   @55  ; mysql_field_seek
mysql_field_tell   @56  ; mysql_field_tell
mysql_free_result  @57  ; mysql_free_result
mysql_get_character_set_info   @58  ; mysql_get_character_set_info
mysql_get_client_info  @59  ; mysql_get_client_info
mysql_get_client_version   @60  ; mysql_get_client_version
mysql_get_host_info@61  ; mysql_get_host_info
mysql_get_parameters   @62  ; mysql_get_parameters
mysql_get_proto_info   @63  ; mysql_get_proto_info
mysql_get_server_info  @64  ; mysql_get_server_info
mysql_get_server_version   @65  ; mysql_get_server_version
mysql_get_ssl_cipher   @66  ; mysql_get_ssl_cipher

Re: [Harbour] Ask Str2Poniter() and Pointer2Str() function pair ....

[Teo Fonrouge]

Hello Rossine,

This functions are for a special need for Shum, and in no way
are required in a normal Harbour programming session.

Bellow you'll find a sample that illustrates of what they do.

On Mar 29, 2010, at 8:04 AM, Rossine wrote:

> 
> Hi,
> 
> I'm trying to use the function of you and me errors occur below:

My fault, a missed header ("hbapiitm.h").

> 
> [CODE]


[snip]




FUNCTION Main()
LOCAL s
LOCAL p

s := "a simple string..."

p := String2Pointer( s )

? "string:", s

? "pointer:", p

? "String from pointer:", Pointer2String( p )

WAIT

RETURN NIL

#pragma begindump

#include "hbapi.h"
#include "hbapiitm.h"

HB_FUNC( STRING2POINTER )
{
PHB_ITEM s = hb_param( 1, HB_IT_STRING );

if( s )
hb_retptr( (void *) hb_itemGetCPtr( s ) );
}

HB_FUNC( POINTER2STRING )
{
PHB_ITEM p = hb_param( 1, HB_IT_POINTER );

if( p )
{
PHB_ITEM s = hb_itemNew( NULL );
PHB_ITEM n = hb_param( 2, HB_IT_NUMERIC );
hb_itemPutCL( s, hb_itemGetPtr( p ), n ? hb_itemGetNI( n ) : 
strlen( hb_itemGetPtr( p ) ) );
hb_itemReturnRelease( s );
}

}

#pragma enddump



best regards,

Teo



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

[Harbour] Re: Harbour-made Win9x .EXE's running slow?

[smu johnson]

Update:  I am running on a hunch, then when you use DEVOUT to print integers
to a screen in something like a 1 to 300 count, it is that printing to the
screen that is holding everything up... and cl52e is winning this race.  I
will try to prove it with a hello world example to see if this theory is
correct...

But making it display to modulus 50 instead of every single integer improved
the speed by about 3 times in this test on Win98.

On Mon, Mar 29, 2010 at 3:58 PM, smu johnson  wrote:

> Hi,
>
> We have a little benchmarking section in a Clipper program we wrote that
> gives a percentage of how fast it's running overall.  I believe it is doing
> 500 SIXCDX row creates etc...
>
> For Win98 programs, are 32-bit .EXE's compiled with Harbour + TDM Mingw
> have around 25% on that list, whereas when they are around 200%+ when
> compiled as 16-bit with cl52e.
>
> This problem doesn't happen with XP and above.
>
> So, I'm wondering if for Win98, the Harbour-made .EXEs... have to emulate
> some 32-bit mode?  Or maybe the processors in most Win98 machines are 16-bit
> CPUs?  I really have no idea... I wish I knew more about this... but in a
> nutshell, our test is running WAY slower than cl52e + Win98.
>
> Thank you for reading.
>
> --
> smu johnson 
>
>


-- 
smu johnson 
___
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:[14261] trunk/harbour

[jarabal]

Revision: 14261
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14261&view=rev
Author:   jarabal
Date: 2010-03-30 03:18:17 + (Tue, 30 Mar 2010)

Log Message:
---
2010-03-30 05:17 UTC+0200 Xavi (jarabal/at/gmail.com)
  * harbour/src/rtl/teditor.prg
! Fixed typo in K_CTRL_PGDN.

  * harbour/src/rtl/memoedit.prg
% Adjust nLineLength, SCOREBOAR to present as Clipper.

  PROCEDURE MAIN
 CLEAR SCREEN
 @ 1,0 TO 5,11
 SET SCOREBOARD ON
 MemoEdit( "12345678901", 2, 1, 4, 10, .T. )
  RETURN

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/src/rtl/memoedit.prg
trunk/harbour/src/rtl/teditor.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] Ghost cursor with GTWVT

[Xavi]

Hi all,

Sometimes GTWVT leaves the previous mark of cursor. Attached picture to 
illustrate the issue.
This happens because the pre-cursor position not is marked with InvalidateRect (RedrawDiff not find differences) getting knocked 
out of WM_PAINT.


In GTWVG not happen because overwrite PutChar and for each character insert call TouchCell and force RedrawDiff to find 
differences although they are the same characters and atributes.


IMHO is more effective in Windows marking only the previous cursor position.
I would like to commit the following patch to the repository.

Index: gtwvt.c
===
--- gtwvt.c (revision 14260)
+++ gtwvt.c (working copy)
@@ -1683,15 +1683,19 @@

 case WM_QUERYENDSESSION: /* Closing down computer */
hb_vmRequestQuit();
- return 0;
+ break;   /* DefWindowProc return TRUE [jarabal] */

 case WM_CLOSE:  /* Clicked 'X' on system menu */
- if( hb_gt_wvt_FireEvent( pWVT, HB_GTE_CLOSE ) == 0 )
{
+#if 0 /* Avoid irregular shutdown if SetCancel( .F. ) [jarabal] */
+if( hb_setGetCancel() )
+   hb_vmRequestCancel();
+#else
   PHB_ITEM pItem = hb_itemPutL( NULL, HB_TRUE );
   hb_setSetItem( HB_SET_CANCEL, pItem );
   hb_itemRelease( pItem );
   hb_vmRequestCancel();
+#endif
}
return 0;

@@ -2939,7 +2943,20 @@
   }

   /* ** */
+/* Avoid the possible remnant mark of cursor in some cases [jarabal] */
+static void hb_gt_wvt_SetPos( PHB_GT pGT, int iRow, int iCol )
+{
+   PHB_GTWVT pWVT = HB_GTWVT_GET( pGT );

+   if( pWVT && pWVT->CaretExist && !pWVT->CaretHidden )
+  HB_GTSELF_REDRAW( pGT, pGT->iRow, pGT->iCol, 1 );
+
+   pGT->iRow = iRow;
+   pGT->iCol = iCol;
+}
+
+/* ** */
+
   static HB_BOOL hb_gt_wvt_SetDispCP( PHB_GT pGT, const char * pszTermCDP, 
const char * pszHostCDP, HB_BOOL fBox )
   {
  HB_GTSUPER_SETDISPCP( pGT, pszTermCDP, pszHostCDP, fBox );
@@ -3046,6 +3063,7 @@
  pFuncTable->SetMode  = hb_gt_wvt_SetMode;
  pFuncTable->Redraw   = hb_gt_wvt_Redraw;
  pFuncTable->Refresh  = hb_gt_wvt_Refresh;
+   pFuncTable->SetPos   = hb_gt_wvt_SetPos;
  pFuncTable->Version  = hb_gt_wvt_Version;
  pFuncTable->Tone = hb_gt_wvt_Tone;
  pFuncTable->Info = hb_gt_wvt_Info;

--
Xavi

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

Re: [Harbour] Ghost cursor with GTWVT

[Viktor Szakáts]

Hi Xavi,

My only comment is that some sort of "setcancel" patch 
is mixed into your attached patches, which should definitely 
be deleted.

Brgds,
Viktor

On 2010 Mar 30, at 05:28, Xavi wrote:

> Hi all,
> 
> Sometimes GTWVT leaves the previous mark of cursor. Attached picture to 
> illustrate the issue.
> This happens because the pre-cursor position not is marked with 
> InvalidateRect (RedrawDiff not find differences) getting knocked out of 
> WM_PAINT.
> 
> In GTWVG not happen because overwrite PutChar and for each character insert 
> call TouchCell and force RedrawDiff to find differences although they are the 
> same characters and atributes.
> 
> IMHO is more effective in Windows marking only the previous cursor position.
> I would like to commit the following patch to the repository.
> 
> Index: gtwvt.c
> ===
> --- gtwvt.c   (revision 14260)
> +++ gtwvt.c   (working copy)
> @@ -1683,15 +1683,19 @@
> 
> case WM_QUERYENDSESSION: /* Closing down computer */
>hb_vmRequestQuit();
> - return 0;
> + break;   /* DefWindowProc return TRUE [jarabal] */
> 
> case WM_CLOSE:  /* Clicked 'X' on system menu */
> - if( hb_gt_wvt_FireEvent( pWVT, HB_GTE_CLOSE ) == 0 )
>{
> +#if 0 /* Avoid irregular shutdown if SetCancel( .F. ) [jarabal] */
> +if( hb_setGetCancel() )
> +   hb_vmRequestCancel();
> +#else
>   PHB_ITEM pItem = hb_itemPutL( NULL, HB_TRUE );
>   hb_setSetItem( HB_SET_CANCEL, pItem );
>   hb_itemRelease( pItem );
>   hb_vmRequestCancel();
> +#endif
>}
>return 0;
> 
> @@ -2939,7 +2943,20 @@
>   }
> 
>   /* ** */
> +/* Avoid the possible remnant mark of cursor in some cases [jarabal] */
> +static void hb_gt_wvt_SetPos( PHB_GT pGT, int iRow, int iCol )
> +{
> +   PHB_GTWVT pWVT = HB_GTWVT_GET( pGT );
> 
> +   if( pWVT && pWVT->CaretExist && !pWVT->CaretHidden )
> +  HB_GTSELF_REDRAW( pGT, pGT->iRow, pGT->iCol, 1 );
> +
> +   pGT->iRow = iRow;
> +   pGT->iCol = iCol;
> +}
> +
> +/* ** */
> +
>   static HB_BOOL hb_gt_wvt_SetDispCP( PHB_GT pGT, const char * pszTermCDP, 
> const char * pszHostCDP, HB_BOOL fBox )
>   {
>  HB_GTSUPER_SETDISPCP( pGT, pszTermCDP, pszHostCDP, fBox );
> @@ -3046,6 +3063,7 @@
>  pFuncTable->SetMode  = hb_gt_wvt_SetMode;
>  pFuncTable->Redraw   = hb_gt_wvt_Redraw;
>  pFuncTable->Refresh  = hb_gt_wvt_Refresh;
> +   pFuncTable->SetPos   = hb_gt_wvt_SetPos;
>  pFuncTable->Version  = hb_gt_wvt_Version;
>  pFuncTable->Tone = hb_gt_wvt_Tone;
>  pFuncTable->Info = hb_gt_wvt_Info;
> 
> -- 
> Xavi
> 
> ___
> 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] Ask Str2Poniter() and Pointer2Str() function pair ....

[Viktor Szakáts]

> Hello Rossine,
> 
> This functions are for a special need for Shum, and in no way

As per Shum he only needs it to make Xbase++ program _link_.

So I believe he could just use these simple dummies until the 
code is fixed properly:

FUNCTION String2Pointer()
  RETURN 0

FUNCTION Pointer2String()
  RETURN ""

Brgds,
Viktor

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

[Harbour] UPX for ADS

[Robert Skowronek(o2)]

Hi,

Is UPX compression (-compr) allowed for ADS applications? 

 

In my case compression causes exe file corruption with following error


"The application failed to initialize properly (0*c005). Click on Ok to 
terminate the application"

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

Re: [Harbour] LIB hbmysql

[Viktor Szakáts]

Hi,

Use HB_BUILD_IMPLIB=yes at build time (or hbmk2 -mkimplib anytime) 
to create working implibs.

Brgds,
Viktor

On 2010 Mar 30, at 02:49, JOEL - YAHOO wrote:

> Hi
> Please, give me some information.
> The LIB hbmysql is available for version 5.0.89?
> I'm trying to write a small application with MinGW32 and I'm having the 
> carriage return below.
> Attached the header of imported LIB command -->> "dlltool-D libmysql.dll 
> libmysql.def-d-l-k libmysql.a "
> 
> 
> /harbour/lib/libhbmysql.a(mysql.o):mysql.c:(.text+0xa4): undefined reference 
> to
> `mysql_escape_str...@12'
> /harbour/lib/libhbmysql.a(mysql.o):mysql.c:(.text+0x115): undefined reference 
> to
>  `mysql_escape_str...@12'
> /harbour/lib/libhbmysql.a(mysql.o):mysql.c:(.text+0x156): undefined reference 
> to
>  `mysql_cl...@4'
> /harbour/lib/libhbmysql.a(mysql.o):mysql.c:(.text+0x199): undefined reference 
> to
>  `mysql_cl...@4'
> /harbour/lib/libhbmysql.a(mysql.o):mysql.c:(.text+0x1c6): undefined reference 
> to
>  `mysql_free_res...@4'
> /harbour/lib/libhbmysql.a(mysql.o):mysql.c:(.text+0x209): undefined reference 
> to
>  `mysql_free_res...@4'
> /harbour/lib/libhbmysql.a(mysql.o):mysql.c:(.text+0x2be): undefined reference 
> to
>  `mysql_i...@4'
> ...
> 
> Best Regards
> Joel Bernardes
> 
> ___
> 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