Re: [Harbour] Re: about function AT()

2008-11-20 Thread Szakáts Viktor
Hi WenSheng, hb_At() is the preferred and recommended method, so you are okay. Brgds, Viktor On 2008.11.20., at 7:49, WenSheng wrote: I'm try use AT() function like: AT( cChar, cString, nStart, nEnd ) but occur error when compiler my AP To be compatible with Clipper the function is define

[Harbour] news regarding letodb

2008-11-20 Thread Massimo Belgrano
Have somebody updated news regarding letodb? Kresin who is founders for letodb and hwgui seem in last period a little inactive on his project -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander S.Kresin Sent: Wednesday, March 26, 2008 5:46 PM To: Har

RE: [Harbour] news regarding letodb

2008-11-20 Thread Massimo Belgrano
Thanks for clarification Do you think that letodb can be used for easy port a harbour application to client server (like ads) ? Wich are future implementation? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Massimo Belgrano Sent: Monday, November 17, 2008

Re: [Harbour] 2008-11-18 00:43 UTC-0800 Pritpal Bedi ([EMAIL PROTECTED])

2008-11-20 Thread Szakáts Viktor
Hi Pritpal, After recent changes, new BCC warnings appeared, and it's not anymore possible to build demowvg in ST mode, due to unresolved external 'hb_vmThreadState'. MSVC C++ build of GTWVG still cannot compile due to errors. Brgds, Viktor On 2008.11.18., at 9:45, Pritpal Bedi wrote: 2008-

Re: [Harbour] RE: about function AT()

2008-11-20 Thread WenSheng
> > > I add switch -DHB_EXTENSION to compile my AP, still occur error message > > You need to re-compile *Harbour* itself with that switch, not your > application. > I had reCompiler Harbour and still can't compiler my AP. ___ Harbour mailing list Ha

Re: [Harbour] Clipper RL compilation problem

2008-11-20 Thread Przemyslaw Czerpak
On Tue, 11 Nov 2008, Szak�ts Viktor wrote: Hi Viktor, >> I do not know the RL tool and it's internal format used >> in .frm but for .mem files we can introduce new format >> which will allow to store memvars with unlimited variable >> name size. > Of course, but how would you solve two way compat

Re: [Harbour] OSX (and Linux) and dyn libs

2008-11-20 Thread Lost
Hi Viktor, On 2008/11/19 Szakáts Viktor <[EMAIL PROTECTED]> wrote: > All my questions were aimed towards a binary distribution. > F.e. our current 1.0.1 for OSX package on sf.net download > page. > > [ I know these can be controlled when building from source > and running 'make install', this is

[Harbour] Default support for shared library in MacOSX build

2008-11-20 Thread Przemyslaw Czerpak
Hi All, I would like to hear group decision about default support for shard libraries in binaries created for MacOSX. I want to keep it enabled by default like in all other *nixes so standard build scripts will create compatible binaries in all *nix like systems. These is related to two things: hb

Re: [Harbour] Default support for shared library in MacOSX build

2008-11-20 Thread Lost
Hi, people On 2008/11/20 Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote: > Hi All, > > I would like to hear group decision about default support for > shard libraries in binaries created for MacOSX. > I want to keep it enabled by default like in all other *nixes > so standard build scripts will cre

Re: [Harbour] Default support for shared library in MacOSX build

2008-11-20 Thread Szakáts Viktor
I vote to use current settings (static hbrun and -static default for hbmk) when mpkg_tgz.sh is used. And shared setting for both when mpkg_osx.sh (to be done). Also, I vote to remove the self-extracting logic from mpkg_tgz.sh for OSX, as this is a solution unknown on the OSX scene, and makes it un

Re: [Harbour] Default support for shared library in MacOSX build

2008-11-20 Thread Teo Fonrouge
On Thursday 20 November 2008 12:30:37 pm Przemyslaw Czerpak wrote: > Hi All, > > I would like to hear group decision about default support for > shard libraries in binaries created for MacOSX. > I want to keep it enabled by default like in all other *nixes > so standard build scripts will create co

Re: [Harbour] OSX (and Linux) and dyn libs

2008-11-20 Thread Szakáts Viktor
All my questions were aimed towards a binary distribution. F.e. our current 1.0.1 for OSX package on sf.net download page. [ I know these can be controlled when building from source and running 'make install', this is exactly how it's working here locally on OS X, Linux and Windows. ] For the re

Re: [Harbour] OSX (and Linux) and dyn libs

2008-11-20 Thread Lost
Hello Viktor, On 2008/11/20 Szakáts Viktor <[EMAIL PROTECTED]> wrote: >> >> Well, then I'd guess that the rpath should be embedded into the >> harbour executable and the executables generated by it. Adding >> "--rpath=" (or maybe "-Wl,rpath,> path>", not tested) to the gcc command line should do

Re: [Harbour] Default support for shared library in MacOSX build

2008-11-20 Thread Szakáts Viktor
Folks, Consider other options too, these two are not the only possible options, but the whole mail is written to make it look like there are no other options and option 2 is the only one. See f.e. no 3. It's rather funny how non OSX users want to decide something for an OS they don't know, and t

Re: [Harbour] Default support for shared library in MacOSX build

2008-11-20 Thread Lorenzo Fiorini
On Thu, Nov 20, 2008 at 7:30 PM, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote: > I would like to hear group decision about default support for > shard libraries in binaries created for MacOSX. > ... > I'm voting for 1. +1 best regards, Lorenzo ___ Harb

Re: [Harbour] Default support for shared library in MacOSX build

2008-11-20 Thread Lorenzo Fiorini
On Thu, Nov 20, 2008 at 9:01 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote: > I vote to give _options_. And I vote to offer working > environments, and to respect the target OS's users and > customs. Viktor, I voted that way because for me Harbour should hide the differences between the 3 platform

Re: [Harbour] 2008-11-18 00:43 UTC-0800 Pritpal Bedi ([EMAIL PROTECTED])

2008-11-20 Thread Pritpal Bedi
Viktor Szakáts Viktor wrote: > > After recent changes, new BCC warnings appeared, > and it's not anymore possible to build demowvg > in ST mode, due to unresolved external 'hb_vmThreadState'. > > MSVC C++ build of GTWVG still cannot compile due > to errors. > Can you show me the logs? Regar

[Harbour] GT - Parent | Child Relation

2008-11-20 Thread Pritpal Bedi
Hello Przemek I am wondering if there is a way to typecast according to its origin. To clarify my point: static HWND hb_gt_wvt_CreateWindow( PHB_GTWVT pWVT ) { ... ... hWndParent = NULL; if( pWVT->pPP->bConfigured ) { PHB_GT pGTp = hb_gt_ItemBase( pWVT->pPP->pParentGT );

[Harbour] MT and hb_gtInfo() - Appln Locks

2008-11-20 Thread Pritpal Bedi
Hello Przemek Function Main() hb_threadStart( {|| First() } ) hb_threadStart( {|| Second() } ) do while .t. nKey := inkey( 0.2 ) if nKey == 27 exit endif enddo Return nil Function First() hb_gtInfo( HB_GTI_WINTITLE, 'My First Function' ) // App