Re: [Harbour] HOWTO about codepage in HbQt

[Przemyslaw Czerpak]

On Wed, 09 Sep 2009, Alexandr Okhotnikov wrote:

Hi,

> Function working with files a lot (several dozen) and each must write
> a wrapper, given codepage each platform and each locale? Nuance:

No, you haven't.
You wrote that you cannot open existing files with national
characters what is not true and I sent the example to illustrate it.

> passing a string (UTF8) in the function (eg, strfile ()), we may face
> a situation where the called function (do not understand UTF8)
> incorrectly processes the string.

Exactly. But the same we can say about using UTF8 in file names at all.
Some 3-rd part programs may not understand it correctly, i.e. it creates
very serious problems when you have to share the same files using SMB
volumes with MS-Windows stations.
Any arbitrary translations to UTF8 or locale is very bad idea.
It has to be programmer choice otherwise it may cause more troubles
then help and create situations when Harbour really will not be able
to open existing files.

I know that you are asking about automatic UTF8<->HVM-CP conversions
and of course as an option it's interesting solution though it does
not resolve the problem in many cases, i.e. it will not enable any
automatic translations in 3-rd party libraries linked with Harbour
application but it can work only for our own code which operates
on file system names so your above problem will still exists in
applications using some 3-rd party extensions. Such translation
will block opening files which are not valid UTF8 names or cannot
be translated to HVM CP. It also does not resolve the problem with
source code using UTF8 encoding. In fact we should have support for
CP translation also in compiler so programmer can define encoding
in source code as one of compile time switches.

Now I do not have time and enough motivation to rewrite our CP code
so if no one else does it then we will have to leave with it yet but
I'll add hack with pseudo codepage called "UTF8" which can be used
only for translations so you can set it as _SET_OSCODEPAGE.

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] HOWTO about codepage in HbQt

[Alexandr Okhotnikov]

2009/9/8 Przemyslaw Czerpak :
> On Tue, 08 Sep 2009, Alexandr Okhotnikov wrote:
>
> Who's forbidden you to use hb_strtoutf8() function?
>
>   proc main()
>      local cFile
>      request hb_codepage_PLISO
>      set( _SET_CODEPAGE, "PLISO" )
>      cFile := "b��dz�cy-���w"
>      memowrit( cFile, "test1" )
>      memowrit( hb_strToUTF8( cFile ), "test2" )
>   return

Function working with files a lot (several dozen) and each must write
a wrapper, given codepage each platform and each locale? Nuance:
passing a string (UTF8) in the function (eg, strfile ()), we may face
a situation where the called function (do not understand UTF8)
incorrectly processes the string.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[Tamas TEVESZ]

On Tue, 8 Sep 2009, vszak...@users.sourceforge.net wrote:

hi,

 >   * utils/hbmk2/hbmk2.prg

 > + Added sunpro compiler support. (not tested, bazaar style)

no time for more extensive tests (it just finished building, and i'm 
about to fall asleep standing), but it does seem to be in perfect 
working order:

i...@rygel:~/harbour-build/tests$ export LD_LIBRARY_PATH=/opt/hb/lib/harbour 
i...@rygel:~/harbour-build/tests$ hbmk2 speedtst.prg 
hbmk2: Processing configuration: /opt/hb/bin/hbmk.cfg  
Harbour 2.0.0beta3 (Rev. 12446)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 'speedtst.prg'...
Lines 1204, Functions/Procedures 79
Generating C source output to 'speedtst.c'... Done.
cc: Warning: -xarch=native has been explicitly specified, or implicitly 
specified by a macro option, -xarch=native on this architecture implies 
-xarch=sparcvis which generates code that does not run on pre UltraSPARC 
processors
i...@rygel:~/harbour-build/tests$ ./speedtst 
   
2009.09.09 05:19:46 SunOS 5.10 sun4u
   
Harbour 2.0.0beta3 (Rev. 12446) Sun C 5.9 (32-bit) Sparc/32
THREADS: 0 
N_LOOPS: 100
[ T000: empty loop overhead ]...1.20

[ T001: x := L_C ]..1.02
[ T002: x := L_N ]..0.82

etc.

thanks!

-- 
[-]

mkdir /nonexistent
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[druzus]

Revision: 12446
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12446&view=rev
Author:   druzus
Date: 2009-09-09 00:24:54 + (Wed, 09 Sep 2009)

Log Message:
---
2009-09-09 02:24 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/bin/hb-func.sh
* updated hb* script to work with import library and new
  harbour.dll names.
+ added workaround for problem with shared linking in gui mode caused
  by wrong import library in MinGW builds - without it hb* scripts
  can work only with pure .DLLs
  TOFIX: shared linking in gui mode does not work in hbmk2 at least
 with MinGW cross builds I have in my Linux box, i.e.:
/*** tst.prg ***/
? "TEST"; WAIT
 hbmk2 tst.prg -shared -gtwvt -mwindows
 ./tst.exe
   -> Unrecoverable error 10001: It's not a GUI program

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/bin/hb-func.sh


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

[Harbour] Harbour clang static analyzer results

[Viktor Szakáts]

Hi All,

Running clang in static analyser mode on darwin (x86-64) resulted in these
messages:
(http://clang-analyzer.llvm.org/)

Maybe some of them are worth to verify.

---
../../../ppcore.c:1785:21: warning: Dereference of null pointer
 pState->pMap[ HB_PP_HASHID( pMatch ) ] |= id;
   ^
../../../../../include/hbpp.h:407:43: note: instantiated from:
#define HB_PP_HASHID(t)   ( ( UCHAR ) HB_PP_UPPER( (t)->value[0] ) )
 ^
../../../../../include/hbpp.h:455:34: note: instantiated from:
#define HB_PP_UPPER(c)   HB_TOUPPER( c )
^
../../../ppcore.c:1785:21: note: instantiated from:
 pState->pMap[ HB_PP_HASHID( pMatch ) ] |= id;
   ^
../../../../../include/hbpp.h:407:43: note: instantiated from:
#define HB_PP_HASHID(t)   ( ( UCHAR ) HB_PP_UPPER( (t)->value[0] ) )
 ^
../../../ppcore.c:1785:21: note: instantiated from:
 pState->pMap[ HB_PP_HASHID( pMatch ) ] |= id;
   ^
../../../../../include/hbpp.h:407:61: note: instantiated from:
#define HB_PP_HASHID(t)   ( ( UCHAR ) HB_PP_UPPER( (t)->value[0] ) )
   ^
../../../ppcore.c:3420:47: warning: Dereference of null pointer
  if( HB_PP_TOKEN_ISEOC( pToken ) && pToken->pNext &&
 ^
../../../ppcore.c:3469:17: warning: Dereference of null pointer
 curtype = HB_PP_TOKEN_TYPE( pToken->type );
   ^
../../../ppcore.c:3469:43: note: instantiated from:
 curtype = HB_PP_TOKEN_TYPE( pToken->type );
 ^
3 diagnostics generated.

../../../errint.c:69:8: warning: Dereference of null pointer
  *pGPF = 0;
  ^
1 diagnostic generated.

../../../hbcrc.c:219:14: warning: Result of operation is undefined.
 mask = ( HB_LONG ) 1 << ( bits - 1 );
^
1 diagnostic generated.

../../../hbstrfmt.c:220:17: warning: Dereference of null pointer
   if( HB_IS_NUMERIC( pItem ) )
   ^
../../../../../include/hbapi.h:214:35: note: instantiated from:
#define HB_IS_NUMERIC( p )( ( HB_ITEM_TYPERAW( p ) & HB_IT_NUMERIC ) !=
0 )
 ^
../../../../../include/hbvmpub.h:170:36: note: instantiated from:
#  define HB_ITEM_TYPERAW( p )   ( * ( HB_TYPE * ) ( p ) )
  ^
../../../hbstrfmt.c:325:17: warning: Dereference of null pointer
   if( HB_IS_NUMERIC( pItem ) )
   ^
../../../../../include/hbapi.h:214:35: note: instantiated from:
#define HB_IS_NUMERIC( p )( ( HB_ITEM_TYPERAW( p ) & HB_IT_NUMERIC ) !=
0 )
 ^
../../../../../include/hbvmpub.h:170:36: note: instantiated from:
#  define HB_ITEM_TYPERAW( p )   ( * ( HB_TYPE * ) ( p ) )
  ^
2 diagnostics generated.

../../../gtcrs.c:399:20: warning: Although the value stored to 'pid' is used
in the enclosing expression, the value is never actually read from 'pid'
while ( ( pid = waitpid( -1, &stat, WNOHANG ) ) > 0 ) ;
  ^ ~
../../../gtcrs.c:780:4: warning: Value stored to 'nKey' is never read
  nKey = esc = n = i = 0;
  ^  ~~~
../../../gtcrs.c:861:10: warning: Value stored to 'nKey' is never read
nKey = 0;
^  ~
3 diagnostics generated.

../../../gtstd.c:141:20: warning: Although the value stored to 'pid' is used
in the enclosing expression, the value is never actually read from 'pid'
while ( ( pid = waitpid( -1, &stat, WNOHANG ) ) > 0 ) ;
  ^ ~
1 diagnostic generated.

../../../gttrm.c:617:19: warning: Although the value stored to 'pid' is used
in the enclosing expression, the value is never actually read from 'pid'
while( ( pid = waitpid( -1, &stat, WNOHANG ) ) > 0 ) { ; }
 ^ ~
../../../gttrm.c:1347:4: warning: Value stored to 'nKey' is never read
  nKey = esc = n = i = 0;
  ^  ~~~
../../../gttrm.c:1427:10: warning: Value stored to 'nKey' is never read
nKey = 0;
^  ~
3 diagnostics generated.

../../../gtxwc.c::7: warning: Value stored to 'whiteColor' is never read
 whiteColor = WhitePixel( wnd->dpy, DefaultScreen( wnd->dpy ) );
 ^~
1 diagnostic generated.

../../../wafunc.c:864:11: warning: Dereference of null pointer
 if( * szField == '\0' )
 ^
1 diagnostic generated.

../../../dbf1.c:3262:10: warning: Dereference of null pointer
pBuffer[ ulSize - 2 ] = '\r';
^
../../../dbf1.c:2983:19: warning: Dereference of null pointer
 pThisField->bFieldFlags = ( BYTE ) pField->uiFlags;
 ^
../../../dbf1.c:3259:10: warning: Dereference of null pointer
pBuffer[ ulSize - 1 ] = '\r';
^

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

[vszakats]

Revision: 12445
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12445&view=rev
Author:   vszakats
Date: 2009-09-08 21:25:24 + (Tue, 08 Sep 2009)

Log Message:
---
2009-09-08 23:23 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * utils/hbmk2/hbmk2.prg
! Fixed to use 'rc' AR cmd on sunos. (instead of 'rcs')
+ Added -hbdyn support for gcc family of compilers. (very light testing 
with mingw)
+ Added sunpro compiler support. (not tested, bazaar style)
! Basic CPU detection fixed for clang.
+ Added TOFIX for CPU detection for *nix based gcc, icc, clang, sunpro
  compilers.

  * config/wce/mingwarm.mk
  * config/hpux/gcc.mk
  * config/win/mingw.mk
  * config/linux/gcc.mk
  * config/linux/icc.mk
  * config/linux/sunpro.mk
  * config/sunos/gcc.mk
  * config/sunos/sunpro.mk
* Minor: AR cmd chars reordered to be in sync with hbmk2.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/config/hpux/gcc.mk
trunk/harbour/config/linux/gcc.mk
trunk/harbour/config/linux/icc.mk
trunk/harbour/config/linux/sunpro.mk
trunk/harbour/config/sunos/gcc.mk
trunk/harbour/config/sunos/sunpro.mk
trunk/harbour/config/wce/mingwarm.mk
trunk/harbour/config/win/mingw.mk
trunk/harbour/utils/hbmk2/hbmk2.prg


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

[Harbour] Signals in HbQt

[CarozoDeQuilmes]

Hi Pritpal, could you add the following signals to HbQt


For Class QTableWidget:

I need them:

   - void 
*cellActivated
   * ( int *row*, int *column* )
   - void 
*cellChanged
   * ( int *row*, int *column* )
   - void 
*cellClicked
   * ( int *row*, int *column* )
   - void 
*cellDoubleClicked
   * ( int *row*, int *column* )
   - void 
*cellEntered
   * ( int *row*, int *column* )
   - void 
*cellPressed
   * ( int *row*, int *column* )
   - void 
*currentCellChanged
   * ( int *currentRow*, int *currentColumn*, int *previousRow*, int *
   previousColumn* )

Optionals (I think that I don't need them):

   - void 
*currentItemChanged
   * ( QTableWidgetItem * *current*, QTableWidgetItem * *previous* )
   - void 
*itemActivated
   * ( QTableWidgetItem * *item* )
   - void 
*itemChanged
   * ( QTableWidgetItem * *item* )
   - void 
*itemClicked
   * ( QTableWidgetItem * *item* )
   - void 
*itemDoubleClicked
   * ( QTableWidgetItem * *item* )
   - void 
*itemEntered
   * ( QTableWidgetItem * *item* )
   - void 
*itemPressed
   * ( QTableWidgetItem * *item* )
   - void 
*itemSelectionChanged
   * ()



Thanks in advance

CdQ
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Exist PICTURE for password with GET?

[Guillermo Varona Silupú]

Thanks Mario.

Best Regards
GVS

Mario H. Sabado escribió:

Hi GVS,

Viktor Szakáts escribió:
  

> Hi,
> Please check the end of source/rtl/tget.prg, there you
> can find which parameters need to be passed to hb_get():new()
> to create a new instance. The parameters are the same as
> for GetNew(), you can find a GetNew() example in tests/rto_get.prg.
> Then you can add the created get object to GetList and
> use READ.
  

Thanks Viktor
The example was as follows:

PROCEDURE Main
LOCAL cVar1 := cVar2 := SPAC(10), oPsw //, GetList
SETMODE(25,80)
CLS
@ 10, 10 SAY "Entrada con GET Normal:" GET cVar1
@ 11, 10 SAY "Entrada con PSW ..:"
* Creo una nueva instancia
oPsw := HB_GET():new(11, 34, { | x | iif( x == NIL, cVar2, cVar2 := x ) 
}, "cVar2",, "W+/N,BG/N" )

oPsw:hideInput := .T.
AADD(GetList, oPsw)
READ
return

Just an observation:
Why not work with getList LOCAL?
TIA

Best Regards
GVS


I think GetList should be initialized with empty array (GetList:={})

Regards,
Mario
  



___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
  


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Capture errors messages in hb_compilebuf() at runtime

[David MS]

Hi all,

There is a way to capture error messages generated by hb_compilebuf() or 
hb_compilefrombuf() at runtime?


Best Regards,
David Montaño. 


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] clang vs gcc (on Darwin)

[Viktor Szakáts]

Snippet from this article:
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/9

"Clang brings with it the two headline attributes you expect in a hot,  
new compiler: shorter compile times and faster executables. In Apple's  
testing with its own applications such as iCal, Address Book, and  
Xcode itself, plus third-party applications like Adium and Growl,  
Clang compiles nearly three times faster than GCC 4.2. As for the  
speed of the finished product, the LLVM back-end, whether used in  
Clang or in LLVM-GCC, produces executables that are 5-25% faster than  
those generated by GCC 4.2."


clang seems like a good choice for newer darwin systems.
I didn't make any speed measurements yet, but for sure the
compile times are incredibly shorter, and the resulting
executables noticeable smaller.

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Exist PICTURE for password with GET?

[Mario H. Sabado]

Hi GVS,

Viktor Szakáts escribió:


> Hi,
> Please check the end of source/rtl/tget.prg, there you
> can find which parameters need to be passed to hb_get():new()
> to create a new instance. The parameters are the same as
> for GetNew(), you can find a GetNew() example in tests/rto_get.prg.
> Then you can add the created get object to GetList and
> use READ.
  

Thanks Viktor
The example was as follows:

PROCEDURE Main
LOCAL cVar1 := cVar2 := SPAC(10), oPsw //, GetList
SETMODE(25,80)
CLS
@ 10, 10 SAY "Entrada con GET Normal:" GET cVar1
@ 11, 10 SAY "Entrada con PSW ..:"
* Creo una nueva instancia
oPsw := HB_GET():new(11, 34, { | x | iif( x == NIL, cVar2, cVar2 := x ) 
}, "cVar2",, "W+/N,BG/N" )

oPsw:hideInput := .T.
AADD(GetList, oPsw)
READ
return

Just an observation:
Why not work with getList LOCAL?
TIA

Best Regards
GVS


I think GetList should be initialized with empty array (GetList:={})

Regards,
Mario

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] win_prt.c and win_tprt.prg

[Viktor Szakáts]

Hi Alex,

On 2009.09.08., at 5:16, Alex Strickland wrote:


Hi Viktor

I have changed a few things here, made it a bit more consistent  
(setting queue size and timeouts) and added to your parameter  
checking (initialised the port handles to -1). I have changed the  
name of the Error() method to ErrorText() (I discovered was an  
unfortunate choice). I dropped restoring the parameters, and a few  
other small things. It seems to work ok in a small test.


Initialization is better be done dynamically if we want to
avoid consuming a relatively large amount of space in .exe files.
This needs some extra logic. Of course the while thing could
get dynamically allocated COM port structures to really
make it scalable.

Two questions, do you think 256 ports is necessary, it seems a lot,  
maybe 32 or 64 would be ok? win_prt.c and win_tprt.prg makes me  
think of printer - maybe something like win_comm.c and win_tcom.prg?


256 is the maximum offered by NT systems, so if we don't
to create an artificial Harbour limit, we should support
all of them. COM numbers aren't necessary assigned sequentially,
so it's possible to have a higher numbered one on any systems.

As for the naming, the class name is WIN_PORT, and the API
prefix is also WIN_PORT*() so, while I don't like 'prt' in
the filenames (reminds me of 'printer'), if we do some renaming,
we should do it consistently. Probably WIN_COM*() would be
better overall. Probably not a huge compatibility concern
yet, so maybe we should do it now.


Can I send you the source?


Yes, please do.

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Getting errors and warnings in MinGW compile

[Maurizio la Cecilia]

I receive the messages below trying to compile latest CVS versions with
MinGW.

hbmk2: Error: Running Harbour compiler (internal). 1
hbi18n.o:hbi18n.c:(.text+0x2c): undefined reference to
`hb_vmProcessSymbolsEx'

c:/CVS/harbour/bin/../utils/hbmk2/hbmk2.prg(845) Warning W0001  Ambiguous
reference 'HB_VERSION_BUILD_PLAT'

c:/CVS/harbour/bin/../utils/hbmk2/hbmk2.prg(1102) Warning W0001  Ambiguous
reference 'HB_VERSION_BUILD_COMP'

c:/CVS/harbour/bin/../utils/hbmk2/hbmk2.prg(5832) Warning W0001  Ambiguous
reference 'HB_VERSION_BUILD_PLAT'

c:/include\common.ch(85) Warning W0001  Redefinition or duplicate definition
of #define HB_SYMBOL_UNUSED

The commands given to compile are:

Win-make clean
Win-make install

TIA for your answer.

Maurizio la Cecilia   

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] win_prt.c and win_tprt.prg

[Alex Strickland]

Hi Viktor

I have changed a few things here, made it a bit more consistent (setting queue 
size and timeouts) and added to your parameter checking (initialised the port 
handles to -1). I have changed the name of the Error() method to ErrorText() (I 
discovered was an unfortunate choice). I dropped restoring the parameters, and a 
few other small things. It seems to work ok in a small test.


Two questions, do you think 256 ports is necessary, it seems a lot, maybe 32 or 
64 would be ok? win_prt.c and win_tprt.prg makes me think of printer - maybe 
something like win_comm.c and win_tcom.prg?


Can I send you the source?

Regards
Alex
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Exist PICTURE for password with GET?

[Guillermo Varona Silupú]

Przemyslaw Czerpak escribió:

On Tue, 08 Sep 2009, Guillermo Varona Silupú wrote:
  

PROCEDURE Main
LOCAL cVar1 := cVar2 := SPAC(10), oPsw //, GetList


[...]
  

AADD(GetList, oPsw)


[...]
  

Just an observation:
Why not work with getList LOCAL?



Because it's NIL. You have to initialize it to be an array:
   local GetList := {}
  

Thanks Pzremek.
now work fine.

Best Regards
GVS
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Exist PICTURE for password with GET?

[Przemyslaw Czerpak]

On Tue, 08 Sep 2009, Guillermo Varona Silupú wrote:
> PROCEDURE Main
> LOCAL cVar1 := cVar2 := SPAC(10), oPsw //, GetList
[...]
> AADD(GetList, oPsw)
[...]
> Just an observation:
> Why not work with getList LOCAL?

Because it's NIL. You have to initialize it to be an array:
   local GetList := {}

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Exist PICTURE for password with GET?

[Guillermo Varona Silupú]

Viktor Szakáts escribió:

Hi,
Please check the end of source/rtl/tget.prg, there you
can find which parameters need to be passed to hb_get():new()
to create a new instance. The parameters are the same as
for GetNew(), you can find a GetNew() example in tests/rto_get.prg.
Then you can add the created get object to GetList and
use READ.

Thanks Viktor
The example was as follows:

PROCEDURE Main
LOCAL cVar1 := cVar2 := SPAC(10), oPsw //, GetList
SETMODE(25,80)
CLS
@ 10, 10 SAY "Entrada con GET Normal:" GET cVar1
@ 11, 10 SAY "Entrada con PSW ..:"
* Creo una nueva instancia
oPsw := HB_GET():new(11, 34, { | x | iif( x == NIL, cVar2, cVar2 := x ) 
}, "cVar2",, "W+/N,BG/N" )

oPsw:hideInput := .T.
AADD(GetList, oPsw)
READ
return

Just an observation:
Why not work with getList LOCAL?
TIA

Best Regards
GVS
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] HOWTO about codepage in HbQt

[Przemyslaw Czerpak]

On Tue, 08 Sep 2009, Alexandr Okhotnikov wrote:

Hi,

> It's not about application portability, I just can not open existing
> files with national characters. For example, the user's home directory
> is the analogue of "Pictures" - "Рисунки" (in Russian)

Who's forbidden you to use hb_strtoutf8() function?

   proc main()
  local cFile
  request hb_codepage_PLISO
  set( _SET_CODEPAGE, "PLISO" )
  cFile := "b��dz�cy-���w"
  memowrit( cFile, "test1" )
  memowrit( hb_strToUTF8( cFile ), "test2" )
   return

Please note that in both cases files are created with raw names specified
by user and both are valid.

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[vszakats]

Revision: 12444
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12444&view=rev
Author:   vszakats
Date: 2009-09-08 12:59:02 + (Tue, 08 Sep 2009)

Log Message:
---
2009-09-08 14:56 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * config/darwin/clang.mk
+ Added comment with option to force C++ mode with clang.

  * utils/hbmk2/hbmk2.prg
+ Added (not yet tested) darwin/clang support.
  Probably it could be added for other platforms, too. Also
  for GNU Make. clang cmdline is compatible with GCC for the most
  part, so it's easy to do and if the few differences can be sorted out,
  it can be done without duplicating .mk file logic.

  * config/darwin/gcc.mk
- Disabled '-no-cpp-precomp' option for darwin/gcc. Most probably
  it's not needed anymore. For users using older darwin systems, this
  can be added manually.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/config/darwin/clang.mk
trunk/harbour/config/darwin/gcc.mk
trunk/harbour/utils/hbmk2/hbmk2.prg


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

Re: [Harbour] HOWTO about codepage in HbQt

[Alexandr Okhotnikov]

Hi

It's not about application portability, I just can not open existing
files with national characters. For example, the user's home directory
is the analogue of "Pictures" - "Рисунки" (in Russian)

2009/9/8 Franček Prijatelj :
>
> Hi Alexandr
>
> Yes this is another solution.
> If we want to be portable we shuldn't use
> spaces and national characters in file names.
>
>
> BRGS
> Franček
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[Viktor Szakáts]

Harbour builds cleanly with clang now. To try, use:

$ make HB_CCPREFIX=/Developer/usr/bin/ HB_COMPILER=clang

This frontend is much faster than gcc (especially than latest 4.2.1).

Brgds,
Viktor

On 2009.09.08., at 2:09, vszak...@users.sourceforge.net wrote:


Revision: 12443
 
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12443&view=rev
Author:   vszakats
Date: 2009-09-08 12:09:22 + (Tue, 08 Sep 2009)

Log Message:
---
2009-09-08 14:06 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
 * include/hbsetup.h
 * config/darwin/clang.mk
   + Added manual compiler macro HB_CC_CLANG until we find the  
official

 predefined macro to detect this compiler.
 Actually we could roll our own HB_CC_ set of macros to do  
compiler
 detection in central headers and clean compiler specific macros  
from

 code.
   ! Fixed '__attribute (( flatten ))' not being supported with clang.
 (Thanks Przemek)
   ! Deleted extra parameters from libtool command line.

 * INSTALL
   + Added clang to the darwin compiler list.

Modified Paths:
--
   trunk/harbour/ChangeLog
   trunk/harbour/INSTALL
   trunk/harbour/config/darwin/clang.mk
   trunk/harbour/include/hbsetup.h


This was sent by the SourceForge.net collaborative development  
platform, the world's largest Open Source development site.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[vszakats]

Revision: 12443
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12443&view=rev
Author:   vszakats
Date: 2009-09-08 12:09:22 + (Tue, 08 Sep 2009)

Log Message:
---
2009-09-08 14:06 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * include/hbsetup.h
  * config/darwin/clang.mk
+ Added manual compiler macro HB_CC_CLANG until we find the official
  predefined macro to detect this compiler.
  Actually we could roll our own HB_CC_ set of macros to do compiler
  detection in central headers and clean compiler specific macros from
  code.
! Fixed '__attribute (( flatten ))' not being supported with clang.
  (Thanks Przemek)
! Deleted extra parameters from libtool command line.

  * INSTALL
+ Added clang to the darwin compiler list.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/INSTALL
trunk/harbour/config/darwin/clang.mk
trunk/harbour/include/hbsetup.h


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

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

[Viktor Szakáts]

Thank you.

[ Couldn't yet find the compiler identification macro for clang. ]

Brgds,
Viktor

On 2009.09.08., at 1:32, Przemyslaw Czerpak wrote:


On Tue, 08 Sep 2009, vszak...@users.sourceforge.net wrote:

Hi,


2009-09-08 13:25 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
 + config/darwin/clang.mk
   + Added experimental support for clang compiler frontend on
 Snow Leopard + new XCode systems. (it's unclear which of them
 exactly is required for this feature)
   ; TOFIX: '__attribute (( flatten ))' is complained about by clang.


Add to include/hbsetup.h[514] valid
  && !defined( ... )
to disable it for clang.

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[Przemyslaw Czerpak]

On Tue, 08 Sep 2009, vszak...@users.sourceforge.net wrote:

Hi,

> 2009-09-08 13:25 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
>   + config/darwin/clang.mk
> + Added experimental support for clang compiler frontend on
>   Snow Leopard + new XCode systems. (it's unclear which of them
>   exactly is required for this feature)
> ; TOFIX: '__attribute (( flatten ))' is complained about by clang.

Add to include/hbsetup.h[514] valid
   && !defined( ... )
to disable it for clang.

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] ActiveX

[Przemyslaw Czerpak]

On Mon, 07 Sep 2009, Alex Strickland wrote:

Hi,

> Do you think it is worth having a function to manually shut down the 
> connection point, as HWGUI does?

No, we should not have anything like that - it's potential GPF trap.
In Harbour Release() is called automatically when all variables
holding pointer to AX control are cleared so it's not necessary
to call it automatically.

> It seems that Release() is never called, for whatever reason.

few weeks ago I sent a small peace of code (see below) to test it and
Toninho confirmed (BTW thanks) that now AX controls are removed.
You can test it yourself and check if destructor is executed.
Please only remember that inside Release() is reference counter
which is updated also by C code so destructor is executed when
the last owner (code which executed AddRef() directly or indirectly
by some other method) calls Release().
If you will find any problems in Harbour code then please inform
us and we try to fix it but calling Release() by our code as workaround
for some other buggy code which does not call it it's very bad idea.

best regards,
Przemek



   proc test( hWnd )
  local oAx
  if valtype( hWnd ) == "N"
 hWnd := win_n2p( hWnd )
  endif
  ? "start"
  oAx := WIN_AxGetControl( hWnd, mk_cblock( mycls():new() ) )
  ? "ax control created:", oAx
  oAx := NIL
  ? "ax control destroyed"
   return

   func mk_cblock( obj )
  return {|| obj }

   class mycls
  destructor dtor
   endclass

   method procedure dtor()
  ? "*** destructor executed ***"
   return
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[vszakats]

Revision: 12442
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12442&view=rev
Author:   vszakats
Date: 2009-09-08 11:26:25 + (Tue, 08 Sep 2009)

Log Message:
---
2009-09-08 13:25 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  + config/darwin/clang.mk
+ Added experimental support for clang compiler frontend on
  Snow Leopard + new XCode systems. (it's unclear which of them
  exactly is required for this feature)
; TOFIX: '__attribute (( flatten ))' is complained about by clang.

Modified Paths:
--
trunk/harbour/ChangeLog

Added Paths:
---
trunk/harbour/config/darwin/clang.mk


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

Re: [Harbour] HOWTO about codepage in HbQt

[Przemyslaw Czerpak]

On Tue, 08 Sep 2009, Szak�ts Viktor wrote:

Hi,

> Actually, Harbour has the basics for such filename conversion
> support, but internally UTF-8 isn't yet supported in these
> conversions yet. Same goes for terminal output f.e..

Terminal output depends on used GTs. GTTRM and GTSLN supports
utf8 mode but GTCRS does not and it's caused by curses internals
not Harbour code and I doubt that we will ever add support for
unicode mode to this GT.
GTs which do not use escape control codes to detect terminal settings
like GTCGI or GTSTD cannot detect utf8 terminal mode though we can
add some hardcoded solutions, i.e. set UTF8 output depending on
LANG envvar but it can help in some programs but create problems for
others so it's also not ideal solution.
For UTF-8 translation in some procedures like filename translation
or GTSTD/GTCGI we can introduce pseudo codepage "UTF8" though probably
the best way is to remove current lang and codepage libraries and
reimplement them from scratch to work well with mulitbyte character
sets, translations between languages and eliminate repeated msg* modules
for the same country but with different encoding.

BTW the Alexandr's method used to inform QT about string encoding in
HVM is very good and simple solution though later we can eliminate using
Unicode base API i.e. hb_parc_utf8(). Now I suggest to use it.

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[druzus]

Revision: 12441
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12441&view=rev
Author:   druzus
Date: 2009-09-08 10:10:24 + (Tue, 08 Sep 2009)

Log Message:
---
2009-09-08 12:09 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/source/vm/thread.c
* removed HB_MT() function body

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/source/vm/thread.c


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

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

[Przemyslaw Czerpak]

On Tue, 08 Sep 2009, Phil Krylov wrote:

Hi,

> On Tue, Sep 8, 2009 at 12:30 AM,  wrote:
> > 2009-09-07 22:29 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> >  * harbour/source/vm/thread.c
> >    + added HB_MT() PRG function which exists only in MT HVM version and
> >      can be REQUESTed from .prg code to force linking MT HVM.
> I think it misses a HB_STACK_TLS_PRELOAD:
> gcc  -I. -I../../../../../../include -no-cpp-precomp -fno-common -Wall
> -W -O3  -DHB_MT_VM  -o hvmall.o -c ../../../../hvmall.c
> In file included from ../../../../hvmall.c:89:
> ../../../../thread.c: In function ‘HB_FUN_HB_MT’:
> ../../../../thread.c:2512: error: ‘_hb_stack_ptr_’ undeclared (first
> use in this function)
> ../../../../thread.c:2512: error: (Each undeclared identifier is
> reported only once
> ../../../../thread.c:2512: error: for each function it appears in.)

Yes, my fault - I left
   hb_retl( TRUE );
and I committed it unintentionally. This functions should be empty
and used only in REQUEST statement.

Thanks for the info and to Viktor for adding HB_STACK_TLS_PRELOAD as
workaround.

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] HOWTO about codepage in HbQt

[Viktor Szakáts]

Actually, Harbour has the basics for such filename conversion
support, but internally UTF-8 isn't yet supported in these
conversions yet. Same goes for terminal output f.e..

Brgds,
Viktor

On 2009.09.08., at 11:50, Franček Prijatelj wrote:



Hi Alexandr

Yes this is another solution.
If we want to be portable we shuldn't use
spaces and national characters in file names.


BRGS
Franček



Alexandr Okhotnikov wrote:


Hi

example: (for Russian, all *.prg in codepage 1251)

INIT PROCEDURE Qt_Start()
   LOCAL lang
   qt_qapplication()

   lang := QTextCodec():new()
   lang:setCodecForCStrings( lang:codecForName_1("Windows-1251") )

   HB_SETCODEPAGE( "RU1251" )
RETURN

All messages are displayed correctly in QT
My problem in the other - in Linux (UTF8) incorrectly creates files
with national characters in name
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour




--
View this message in context: 
http://www.nabble.com/HOWTO-about-codepage-in-HbQt-tp25334628p25343020.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[druzus]

Revision: 12440
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12440&view=rev
Author:   druzus
Date: 2009-09-08 10:03:24 + (Tue, 08 Sep 2009)

Log Message:
---
2009-09-08 12:03 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/include/hbstack.h
  * harbour/source/vm/estack.c
* small cleanup in some macros definitions

  * harbour/source/vm/hvm.c
* pacified ICC++ warnings

  * harbour/source/vm/mainstd.c
! do not force main() declaration as extern "C"

  * harbour/include/hbdefs.h
  * harbour/include/hbsetup.h
* modified HB_FUNC*() macros declarations to respect global extern "C"
  settings

  * harbour/source/vm/classes.c
* use HB_FUNC*() macros to declare harbour functions

  * harbour/source/common/hbprintf.c
* added workaround for some missing C99 math macros in SunOS GCC used in
  C++ mode. Warning C++ mode in SunOS-GCC disables C99 extensions.

  * harbour/contrib/gtalleg/gtalleg.c
* hack for compilation with SunPRO C

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/gtalleg/gtalleg.c
trunk/harbour/include/hbdefs.h
trunk/harbour/include/hbsetup.h
trunk/harbour/include/hbstack.h
trunk/harbour/source/common/hbprintf.c
trunk/harbour/source/vm/classes.c
trunk/harbour/source/vm/estack.c
trunk/harbour/source/vm/hvm.c
trunk/harbour/source/vm/mainstd.c


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

Re: [Harbour] Wrong autodetection in Eclipse

[Lorenzo Fiorini]

On Tue, Sep 8, 2009 at 11:51 AM, Massimo Belgrano wrote:

> which ecliple you use: http://www.eclipse.org/downloads/
>
> you use eclipse as ide?

Yes, Eclipse IDE for C/C++ developers.

best regards,
Lorenzo
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Wrong autodetection in Eclipse

[Massimo Belgrano]

which ecliple you use: http://www.eclipse.org/downloads/

you use eclipse as ide?


2009/9/8 Lorenzo Fiorini :
> On Tue, Sep 8, 2009 at 11:23 AM, Viktor Szakáts wrote:
>
>> Pls first try after 12439. Maybe it fixes the problem.
>
> Many thanks, it works now.
>
> best regards,
> Lorenzo
> ___
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>



-- 
Massimo Belgrano
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] HOWTO about codepage in HbQt

[Franček Prijatelj]

Hi Alexandr

Yes this is another solution.
If we want to be portable we shuldn't use
spaces and national characters in file names.


BRGS
Franček



Alexandr Okhotnikov wrote:
> 
> Hi
> 
> example: (for Russian, all *.prg in codepage 1251)
> 
> INIT PROCEDURE Qt_Start()
> LOCAL lang
> qt_qapplication()
> 
> lang := QTextCodec():new()
> lang:setCodecForCStrings( lang:codecForName_1("Windows-1251") )
> 
> HB_SETCODEPAGE( "RU1251" )
> RETURN
> 
> All messages are displayed correctly in QT
> My problem in the other - in Linux (UTF8) incorrectly creates files
> with national characters in name
> ___
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
> 
> 

-- 
View this message in context: 
http://www.nabble.com/HOWTO-about-codepage-in-HbQt-tp25334628p25343020.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Wrong autodetection in Eclipse

[Lorenzo Fiorini]

On Tue, Sep 8, 2009 at 11:23 AM, Viktor Szakáts wrote:

> Pls first try after 12439. Maybe it fixes the problem.

Many thanks, it works now.

best regards,
Lorenzo
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: Harbour under OS/2 - eCS 12437

[Viktor Szakáts]

Thank you.

Brgds,
Viktor

On 2009.09.08., at 11:37, David Arturo Macias Corona wrote:


Thanks Viktor

>Pls try with 12439.

It work fine now

David Macias




___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Harbour under OS/2 - eCS 12437

[David Arturo Macias Corona]

Thanks Viktor

>Pls try with 12439.

It work fine now

David Macias




___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Wrong autodetection in Eclipse

[Viktor Szakáts]

Pls first try after 12439. Maybe it fixes the problem.

Brgds,
Viktor

On 2009.09.08., at 11:21, Lorenzo Fiorini wrote:


I've always built harbour using Eclipse. Today I removed sh
./make_gnu.sh and I get:

 Build of configuration Linux GCC for project harbour 

make clean
!HB_PLATFORM: linux
! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org
! MAKE: make 3.81 /bin/sh clean
make: command.com: Command not found
! HB_HOST_PLAT: dos (x86)  HB_SHELL: dos
config/global.mk:802: *** ! HB_COMPILER not set, could not  
autodetect.  Stop.


I've also set HB_PLATFORM to linux ( see !HB_PLATFORM: linux line )
but it doesn't help.

Any idea?

best regards,
Lorenzo
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Wrong autodetection in Eclipse

[Lorenzo Fiorini]

I've always built harbour using Eclipse. Today I removed sh
./make_gnu.sh and I get:

 Build of configuration Linux GCC for project harbour 

make clean
!HB_PLATFORM: linux
! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org
! MAKE: make 3.81 /bin/sh clean
make: command.com: Command not found
! HB_HOST_PLAT: dos (x86)  HB_SHELL: dos
config/global.mk:802: *** ! HB_COMPILER not set, could not autodetect.  Stop.

I've also set HB_PLATFORM to linux ( see !HB_PLATFORM: linux line )
but it doesn't help.

Any idea?

best regards,
Lorenzo
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Harbour under OS/2 - eCS 12437

[Viktor Szakáts]

Hi David,

Pls try with 12439.

Brgds,
Viktor

On 2009.09.08., at 10:55, David Arturo Macias Corona wrote:


Harbour build fine with gcc433 on Sep 5, now with
 * $Id: ChangeLog 12437 2009-09-08 00:45:56Z vszakats $
 2009-09-08 02:44 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
it fail with error:
---
[E:\harbour909c\harbour]make -r -w   1>make_gnu.log
SYS1003: The syntax of the command is incorrect.
Error occurred while processing: /q.
make[3]: *** [hbcplr.lib] Error 1
make[2]: *** [descend] Error 2
make[1]: *** [compiler] Error 2
make: *** [source] Error 2
---

make_gnu.log does not show any reference of error

Error is happening in this line and does not fail excluding it:
-
  $(if $(wildcard $(subst /,$(DIRSEP),$(LIB_FILE))),@$(RM) $(subst
/,$(DIRSEP),$(LIB_FILE)),)
-

so maybe @$(RM) is wrong

config\globsh.mk contain /q only for NT:
-
ifeq ($(HB_SHELL),nt)
RM := del /q /f
-

Something was mixed in last two days

make_gnu.log headers show "HB_SHELL: nt":
-
! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org
! MAKE: make 3.81 E:\OS2\CMD.EXE  wr
! HB_USER_CFLAGS: -DTCPV40HDRS -DHB_FM_STATISTICS_OFF
! HB_USER_LDFLAGS: -Le:\usr\lib\tcpipv4
! HB_INSTALL_PREFIX: \harbour909c\harbour
! HB_BIN_INSTALL: \harbour909c\harbour\bin
! HB_LIB_INSTALL: \harbour909c\harbour\lib\\gcc
! HB_INC_INSTALL: \harbour909c\harbour\include
! HB_DOC_INSTALL: \harbour909c\harbour\doc
! HB_HOST_PLAT: os2 (x86)  HB_SHELL: nt
! HB_PLATFORM: os2 (x86)
-

and this seem wrong too:

\harbour909c\harbour\lib\\gcc


David Macias



___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[vszakats]

Revision: 12439
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12439&view=rev
Author:   vszakats
Date: 2009-09-08 09:13:47 + (Tue, 08 Sep 2009)

Log Message:
---
2009-09-08 11:13 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * config/global.mk
! Corrected typo in de-xmastree patch. Symptom was broken
  shell detection on os2.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/config/global.mk


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

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

[David Arturo Macias Corona]

>2009-09-07 10:52 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
>  * harbour/source/rtl/hbsocket.c
>+ added support for setting non blocking IO mode in OpenWatcom OS2
>  builds - please test.

How can be tested ?

David Macias

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Harbour under OS/2 - eCS 12437

[David Arturo Macias Corona]

Harbour build fine with gcc433 on Sep 5, now with
  * $Id: ChangeLog 12437 2009-09-08 00:45:56Z vszakats $
  2009-09-08 02:44 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
it fail with error:
---
[E:\harbour909c\harbour]make -r -w   1>make_gnu.log
SYS1003: The syntax of the command is incorrect.
Error occurred while processing: /q.
make[3]: *** [hbcplr.lib] Error 1
make[2]: *** [descend] Error 2
make[1]: *** [compiler] Error 2
make: *** [source] Error 2
---

make_gnu.log does not show any reference of error

Error is happening in this line and does not fail excluding it:
-
   $(if $(wildcard $(subst /,$(DIRSEP),$(LIB_FILE))),@$(RM) $(subst
/,$(DIRSEP),$(LIB_FILE)),)
-

so maybe @$(RM) is wrong

config\globsh.mk contain /q only for NT:
-
ifeq ($(HB_SHELL),nt)
RM := del /q /f
-

Something was mixed in last two days

make_gnu.log headers show "HB_SHELL: nt":
-
! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org
! MAKE: make 3.81 E:\OS2\CMD.EXE  wr
! HB_USER_CFLAGS: -DTCPV40HDRS -DHB_FM_STATISTICS_OFF
! HB_USER_LDFLAGS: -Le:\usr\lib\tcpipv4
! HB_INSTALL_PREFIX: \harbour909c\harbour
! HB_BIN_INSTALL: \harbour909c\harbour\bin
! HB_LIB_INSTALL: \harbour909c\harbour\lib\\gcc
! HB_INC_INSTALL: \harbour909c\harbour\include
! HB_DOC_INSTALL: \harbour909c\harbour\doc
! HB_HOST_PLAT: os2 (x86)  HB_SHELL: nt
! HB_PLATFORM: os2 (x86)
-

and this seem wrong too:

\harbour909c\harbour\lib\\gcc


David Macias



___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Exist PICTURE for password with GET?

[Viktor Szakáts]

Hi,

Please check the end of source/rtl/tget.prg, there you
can find which parameters need to be passed to hb_get():new()
to create a new instance. The parameters are the same as
for GetNew(), you can find a GetNew() example in tests/rto_get.prg.
Then you can add the created get object to GetList and
use READ.

Brgds,
Viktor

On 2009.09.07., at 10:39, Guillermo Varona Silupú wrote:


Hi
¿Alguién tendrá algun ejemplo del uso de la clase HB_GET?

[Powered by Google]
Does anyone have any example of using class HB_GET?

TIA

Best Regars
GVS


gvarona escribió:

Viktor Szakáts escribió:

Harbour has an extended GET class called HB_GET, which
has this functionality. It can be enabled via ::hideInput( .T. )
method call.


Hi Viktor, How use this extended?
I have this, but not work.
PROCEDURE Main
LOCAL cVar := SPAC(10)
oGet := HB_GET()
oGet:name := "cVar"
oGet:row := 10
oGet:col := 10
oGet:hideInput := .T.
oGet:style := "#"
? oget:name
? oget:style
wait
READ
READMODAL({oGet})
? cVar
return
Help please
TIA
Best regards
GVS
---
EC Red Internet g...@tis
Inscríbete en www.ec-red.com
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour




___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] HOWTO about codepage in HbQt

[Alexandr Okhotnikov]

Hi

example: (for Russian, all *.prg in codepage 1251)

INIT PROCEDURE Qt_Start()
LOCAL lang
qt_qapplication()

lang := QTextCodec():new()
lang:setCodecForCStrings( lang:codecForName_1("Windows-1251") )

HB_SETCODEPAGE( "RU1251" )
RETURN

All messages are displayed correctly in QT
My problem in the other - in Linux (UTF8) incorrectly creates files
with national characters in name
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[vszakats]

Revision: 12438
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12438&view=rev
Author:   vszakats
Date: 2009-09-08 08:07:12 + (Tue, 08 Sep 2009)

Log Message:
---
2009-09-08 10:04 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * contrib/hbnetio/utils/netiosrv.prg
+ Added 'root' cmdline parameter.

  * utils/hbmk2/hbmk2.prg
+ Small steps towards msvcmips and msvcsh support.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbnetio/utils/netiosrv.prg
trunk/harbour/utils/hbmk2/hbmk2.prg


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

Re: [Harbour] HOWTO about codepage in HbQt

[Franček Prijatelj]

Hi Pritpal

Obviously we need Qstring implementation (not nedded for begining).
Instead of using char* we have to use QString and its methods.
By default Qstring uses "fromAscii()" method on char* assignement.

You should change in hbqt.h (for begining)

#define hbqt_par_QString( n )( ( QString ) hb_parcx( n ) )
to
#define hbqt_par_QString( n )   (QString::fromLocal8Bit(
hb_parcx( n )))

I have tried it with demoqt, and it works.

Of course we need more sofisticated system.
For example  I intend to use utf-8 encoding for all UI 
so there should be ::fromUtf8 method instead of ::fromLocal8bit.
It would be very simple to write universal function that depends
on some  "SET QT_CP    " seting.


Here is naive example in cpp how to use local encoding .
We should use it by default.

#include 
#include 
#include 

int main(int argc, char* argv[])
{
QApplication app(argc, argv);
//-   wrong -
//char * cBtnCapt= "Qu čšž";
//---   
QString cBtnCapt= QString::fromLocal8Bit( "Qu čšž");
QPushButton quit(cBtnCapt);

quit.resize(75, 30);
quit.setFont(QFont("Times", 18, QFont::Bold));

QObject::connect(&quit, SIGNAL(clicked()), &app, SLOT(quit()));

quit.show();

return app.exec();
}





Pritpal Bedi wrote:
> 
> Hi
> 
> 
> Franček Prijatelj wrote:
>> 
>> Is there a function equivalent of  HB_SetCodePage("SLWIN") in HbQt.
>> I would like to use  cp1250 tekst on buttons:
>> 
>> oBtn := QPushButton():new( QT_PTROF( oWnd ) )
>> oBtn:setText( "Push Button čČšŠžŽ" )
>> 
> 
> This is still a gray area for me.
> Infact I have not looked into it deeply yet.
> Documentation suggests that they have all classes in place 
> but I am unable to figure-out how those classes can be 
> made functional with HB_SetCodePage("SLWIN")  call.
> 
> Anyone to suggest something on the subject?
> 
> Regards
> Pritpal Bedi
> 
> 

-- 
View this message in context: 
http://www.nabble.com/HOWTO-about-codepage-in-HbQt-tp25334628p25340944.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour