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

[vszakats]

Revision: 14547
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14547&view=rev
Author:   vszakats
Date: 2010-05-21 06:52:49 + (Fri, 21 May 2010)

Log Message:
---
2010-05-21 08:52 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * contrib/hbwin/win_svc.c
+ WIN_SERVICEINSTALL(): Extended to accept 3rd parameter
  for the full filename of the service executable. This
  makes it possible to install other .exes not just self.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbwin/win_svc.c


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

Re: [Harbour] Problem with upper and lower based on CDP

[Viktor Szakáts]

Hi Leandro,

>> These are internal structures, so there if is any notion
>> of writing stable code I strongly suggest to not use
>> them directly at all.
> 
>> I think the bug here is that you can access these members
>> at all. IMO they should be protected like HB_ITEM members.
>> 
> 
> You must be right. The .C code was just an attempt to illustrate what we 
> thought that could help to find a solution if you guys at "Houston" agree 
> that "we have a problem" ;)
> 
> The real problem I want to ask you about is, shouldn't Upper() and Lower() 
> consider the selected codepage?  It is important (at least for latin codepage 
> users like PT850) to have case change functionality based upon the selected 
> codepage and not just the default codepage, because in our language we have 
> to use lots of accents. Upper() and Lower() prg level functions seems to have 
> been written to fullfill this need, but if they are then they are not working 
> well... :(

UPPER() and LOWER() are considering CP setting.

> 
> procedure main()
> REQUEST HB_LANG_PT
> REQUEST HB_CODEPAGE_PT850
> hb_CDPselect("PT850")
> ? upper("coração")
> quit
> 
> 
> This example shows "CORAþÒO", but shouldn't it show "CORAÇÃO"?

This is impossible to tell when pasted to an e-mail.

Anyhow I've checked it locally directly in the source 
and to me the PT850 looks alright.

Try to open src/codepage/cppt850.c with an editor 
which you can set to 850 CP, or your browser. Or 
do the same with above test after your write the 
result in a file instead of showing it on screen.

The problem is probably in your display or output 
settings.

Viktor

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

Re: [Harbour] Problem with upper and lower based on CDP

[2D Info - Leandro Damasio]

Nothing missing nor bug. UPPER(CHR(0)) ir CHR(0), and CHR(0) is end of 
string symbol.


Sorry Mindaugas, but I couldn't understand what you mean. Can you give me a 
hand please? :)
Leandro 


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

Re: [Harbour] Problem with upper and lower based on CDP

[2D Info - Leandro Damasio]

Hi Viktor


These are internal structures, so there if is any notion
of writing stable code I strongly suggest to not use
them directly at all.



I think the bug here is that you can access these members
at all. IMO they should be protected like HB_ITEM members.



You must be right. The .C code was just an attempt to illustrate what we 
thought that could help to find a solution if you guys at "Houston" agree 
that "we have a problem" ;)


The real problem I want to ask you about is, shouldn't Upper() and Lower() 
consider the selected codepage?  It is important (at least for latin 
codepage users like PT850) to have case change functionality based upon the 
selected codepage and not just the default codepage, because in our language 
we have to use lots of accents. Upper() and Lower() prg level functions 
seems to have been written to fullfill this need, but if they are then they 
are not working well... :(


Please look at this prg example:


procedure main()
REQUEST HB_LANG_PT
REQUEST HB_CODEPAGE_PT850
hb_CDPselect("PT850")
? upper("coração")
quit


This example shows "CORAþÒO", but shouldn't it show "CORAÇÃO"?

Regards
Leandro






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

[vouchcac]

Revision: 14546
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14546&view=rev
Author:   vouchcac
Date: 2010-05-20 23:50:49 + (Thu, 20 May 2010)

Log Message:
---
2010-05-20 16:49 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * contrib/hbqt/generator/hbqtgen.prg
! Two small fixes. No code regeneration required.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbqt/generator/hbqtgen.prg


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

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

[vszakats]

Revision: 14545
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14545&view=rev
Author:   vszakats
Date: 2010-05-20 23:06:29 + (Thu, 20 May 2010)

Log Message:
---
2010-05-21 01:05 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * config/global.mk
+ Showing warning when HB_BUILD_IMPLIB=yes is used without
  'install' make option.

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 (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about Curl detection during compile process

[smu johnson]

Alright, will do.

On Thu, May 20, 2010 at 3:44 PM, Viktor Szakáts wrote:

> What can I say? A lib can be used if it's present in one of
> the passed lib dirs (-L options).
>
> Apparently curldll lib (the implib) is not there.
>
> Why? I cannot tell you; and I have told everything that can
> I could tell about this whole topic. Probably some blatant
> mistake or overlook along the process.
>
> I suggest to reread the thread and INSTALL and just start
> over from a clean state.
>
> Viktor
>
>
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Problem with upper and lower based on CDP

[Viktor Szakáts]

> HB_FUNC( _2D_CURRENTCODEPAGE )
> {
>const char * cdpID = hb_cdpID();
>PHB_CODEPAGE cdp   = hb_cdpFind(cdpID);
>   
>MessageBox(NULL,cdp->lower,'test',MB_OK);
> 
>hb_reta(4) ; 
>hb_storvc( cdp->lower, -1, 1 );
>hb_storvc( cdp->upper , -1, 2 );
>hb_storvc( cdpID  , -1, 3 );
>hb_storvc( cdp->info  , -1, 4 );
> }
>  
> After requesting:
>  
> REQUEST HB_LANG_PT
> REQUEST HB_CODEPAGE_PT850
> hb_CDPselect("PT850")
> We have noticed that the cdp structure loaded through hb_cdpSelect() does 
> really select the wanted CDP because the cdpInfo and cdpID members return 
> respectively "Portuguese CP850" and "PT850", but the lower and upper members 
> return empty strings.
>  
> We have also debuged the cdp->lower and cdp->upper members and they are 
> empty, so it is not a matter of hb_storvc usage.
>  
> Our guess is that this members are not being properly filled when the 
> codepage is registered through hb_cdpRegister(), because all the functions 
> that treat string cases are failing trating cases in the selected cdp. The 
> final problem is that:  UPPER("ãõéíóaeiou") returns "ãõéíóAEIOU" not 
> regarding to the selected cdp.
>  
> Can somebody check if we are missing something or if it is a harbour bug?

These are internal structures, so there if is any notion 
of writing stable code I strongly suggest to not use 
them directly at all.

I think the bug here is that you can access these members 
at all. IMO they should be protected like HB_ITEM members.

Viktor

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

Re: [Harbour] Problem with upper and lower based on CDP

[Mindaugas Kavaliauskas]

Hi,



We have also debuged the cdp->lower and cdp->upper members and they are
empty, so it is not a matter of hb_storvc usage.
Can somebody check if we are missing something or if it is a harbour bug?


Nothing missing nor bug. UPPER(CHR(0)) ir CHR(0), and CHR(0) is end of 
string symbol.


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

Re: [Harbour] Question about Curl detection during compile process

[Viktor Szakáts]

What can I say? A lib can be used if it's present in one of 
the passed lib dirs (-L options). 

Apparently curldll lib (the implib) is not there.

Why? I cannot tell you; and I have told everything that can 
I could tell about this whole topic. Probably some blatant 
mistake or overlook along the process.

I suggest to reread the thread and INSTALL and just start 
over from a clean state.

Viktor

On 2010 May 21, at 00:27, smu johnson wrote:

> Hello Viktor,
> 
> Well, having followed every step that was proper, I still cannot get this to 
> work.  No more Perl gcc, no more old revisions, no more forgetting HB_* 
> flags, etc... everything has been tried by me.
> 
> Unless you can (please) share some more of your Harbour internal knowledge 
> and assist me out of pity, I think I might throw on in the towel ;)
> 
> -- latest error --
> 
> C:\hbm>g:\harbour\bin\hbmk2 hello.PRG g:\harbour\contrib\hbcurl\hbcurl.hbc
> hbmk2: Processing configuration: g:\harbour\bin\hbmk.cfg
> Harbour 2.1.0beta1 (Rev. 14528)
> Copyright (c) 1999-2010, http://www.harbour-project.org/
> Compiling 'hello.PRG'...
> Lines 675, Functions/Procedures 1
> Generating C source output to 
> 'C:\Users\sjohnson\AppData\Local\Temp\hello.c'...
> Done.
> c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: cannot 
> fin
> d -lcurldll
> collect2: ld returned 1 exit status
> hbmk2: Error: Running linker. 1
> gcc.exe C:\Users\sjohnson\AppData\Local\Temp\hello.o 
> C:\Users\sjohnson\AppData\L
> ocal\Temp\hbmk_ivti53.o-mconsole -Wl,--start-group -lhbcurl -lcurldll 
> -lhbex
> tern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd 
> -lgtwin
>  -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd -lrddntx -lrddcdx -lrddnsx 
> -lrddf
> pt -lhbrdd -lhbhsx -lhbsix -lhbmacro -lhbcplr -lhbpp -lhbcommon -lhbmainstd 
> -lke
> rnel32 -luser32 -lgdi32 -ladvapi32 -lws2_32 -lwinspool -lcomctl32 -lcomdlg32 
> -ls
> hell32 -luuid -lole32 -loleaut32 -lmpr -lwinmm -lmapi32 -limm32 -lmsimg32 
> -lwini
> net -lhbpcre -lhbzlib  -Wl,--end-group -ohello.exe -Lg:/harbour/lib/win/mingw
> 
> On Thu, May 20, 2010 at 2:24 PM, smu johnson  wrote:
> 
> < posts about many attempts met with failure trying to get HBCURL to work >
>  
> 
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour

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

[Harbour] Problem with upper and lower based on CDP

[2D Info - Leandro Damasio]

Hello,

See code below:

HB_FUNC( _2D_CURRENTCODEPAGE )
{
   const char * cdpID = hb_cdpID();
   PHB_CODEPAGE cdp   = hb_cdpFind(cdpID);
  
   MessageBox(NULL,cdp->lower,'test',MB_OK);

   hb_reta(4) ; 
   hb_storvc( cdp->lower, -1, 1 );
   hb_storvc( cdp->upper , -1, 2 );
   hb_storvc( cdpID  , -1, 3 );
   hb_storvc( cdp->info  , -1, 4 );
}

After requesting:

REQUEST HB_LANG_PT
REQUEST HB_CODEPAGE_PT850
hb_CDPselect("PT850")

We have noticed that the cdp structure loaded through hb_cdpSelect() does 
really select the wanted CDP because the cdpInfo and cdpID members return 
respectively "Portuguese CP850" and "PT850", but the lower and upper members 
return empty strings.

We have also debuged the cdp->lower and cdp->upper members and they are empty, 
so it is not a matter of hb_storvc usage.

Our guess is that this members are not being properly filled when the codepage 
is registered through hb_cdpRegister(), because all the functions that treat 
string cases are failing trating cases in the selected cdp. The final problem 
is that:  UPPER("ãõéíóaeiou") returns "ãõéíóAEIOU" not regarding to the 
selected cdp.

Can somebody check if we are missing something or if it is a harbour bug?

Thanks 

Best regards,
Leandro Damásio and Ted Dirickson - 2D Info ___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about Curl detection during compile process

[smu johnson]

Hello Viktor,

Well, having followed every step that was proper, I still cannot get this to
work.  No more Perl gcc, no more old revisions, no more forgetting HB_*
flags, etc... everything has been tried by me.

Unless you can (please) share some more of your Harbour internal knowledge
and assist me out of pity, I think I might throw on in the towel ;)

-- latest error --

C:\hbm>g:\harbour\bin\hbmk2 hello.PRG g:\harbour\contrib\hbcurl\hbcurl.hbc
hbmk2: Processing configuration: g:\harbour\bin\hbmk.cfg
Harbour 2.1.0beta1 (Rev. 14528)
Copyright (c) 1999-2010, http://www.harbour-project.org/
Compiling 'hello.PRG'...
Lines 675, Functions/Procedures 1
Generating C source output to
'C:\Users\sjohnson\AppData\Local\Temp\hello.c'...
Done.
c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: cannot
fin
d -lcurldll
collect2: ld returned 1 exit status
hbmk2: Error: Running linker. 1
gcc.exe C:\Users\sjohnson\AppData\Local\Temp\hello.o
C:\Users\sjohnson\AppData\L
ocal\Temp\hbmk_ivti53.o-mconsole -Wl,--start-group -lhbcurl -lcurldll
-lhbex
tern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd
-lgtwin
 -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd -lrddntx -lrddcdx -lrddnsx
-lrddf
pt -lhbrdd -lhbhsx -lhbsix -lhbmacro -lhbcplr -lhbpp -lhbcommon -lhbmainstd
-lke
rnel32 -luser32 -lgdi32 -ladvapi32 -lws2_32 -lwinspool -lcomctl32 -lcomdlg32
-ls
hell32 -luuid -lole32 -loleaut32 -lmpr -lwinmm -lmapi32 -limm32 -lmsimg32
-lwini
net -lhbpcre -lhbzlib  -Wl,--end-group -ohello.exe
-Lg:/harbour/lib/win/mingw

On Thu, May 20, 2010 at 2:24 PM, smu johnson  wrote:

>
> < posts about many attempts met with failure trying to get HBCURL to work >
>
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] sunpro-compiled hbrun doesn't work anymore

[Tamas TEVESZ]

On Thu, 20 May 2010, Przemysław Czerpak wrote:

hi,

 > Linux SUNPRO port has very serious bug. It does not correctly generate
 > code for all constructors. We are exploiting this problem from time to
 > time. It probably depends on total binary size which may interact with
 > the contents of some uninitialized memory. I do not know exectly where

thanks for the explanation.

 > due to this problem. Now I've tested current builds and it works OK.
 > I can executed without any problems hbtest and hbrun. I'm using
 > suse1...@x86_64. Anyhow I expect that it can stop to work in any moment
 > when some modification change total memory alignment and the problem
 > will be exploited again. Looks that in your system is still exploited.

strange. it was working fine with the previous, and maybe the one 
before ubuntus, now it turns out it doesn't work even with a rather 
older one either. this must either be a stupid one in sunpro, or mean 
that linux changes frequently :)

anyway, thanks for explaining this, let's see what oracle does with 
the lot (i'm not holding my breath though).


-- 
[-]

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

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

[Pritpal Bedi]

francesco perillo wrote:
> 
> You can download and install the gui and cli program from here:
> http://sourceforge.net/projects/tortoisehg/
> 
> There are 3 types of repository:
> public: everybody can pull (checkout) /push (commit and push)
> readonly: everybody can read, only authorized people can push
> private: only authorized people can access
> 
> I can provide a preadonly or private repository.
> 
> 
> Official mercurial site is here: http://mercurial.selenic.com/
> To have a crash-course you can start from here: http://hginit.com/
> 

Ok, send me a private repository .



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

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

[francesco perillo]

You can download and install the gui and cli program from here:
http://sourceforge.net/projects/tortoisehg/

There are 3 types of repository:
public: everybody can pull (checkout) /push (commit and push)
readonly: everybody can read, only authorized people can push
private: only authorized people can access

I can provide a preadonly or private repository.


Official mercurial site is here: http://mercurial.selenic.com/
To have a crash-course you can start from here: http://hginit.com/
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[vszakats]

Revision: 14544
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14544&view=rev
Author:   vszakats
Date: 2010-05-20 21:35:20 + (Thu, 20 May 2010)

Log Message:
---
2010-05-20 23:34 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * utils/hbmk2/hbmk2.prg
! Fixed overlook in recent modification (put .def file macros
  in normal linker command template)
! Fixed missing '-nologo' option in msvc -hbdyn[vm] linker 
  command template.

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


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

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

[Pritpal Bedi]

francesco perillo wrote:
> 
>> Because I was simply starting to explore, and my development times are
>> never
>> on the same macine ever, I want it to be resident of hbide/qscintilla so
>> I
>> could
>> access it on whatever I machine I am currently with.
> 
> If you want I can provide access to a Mercurial repository that can be
> public or password-protected. Mercurial is a distributed version
> control very easy to use...
> 

This will be nice. Does it work with Windows?
If yes, please send a lonk with few notes how I 
setup the just deleted commit.


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

[Vailton Renato]

Hi!

The hbmk2 has made a mistake when trying to link any application,
here's an sample:


c:\harbour\tests>hbmk2 -run while.prg
hbmk2: Processando opções do ambiente: -compiler=msvc
hbmk2: Processando arquivo de configuração: C:\hbmsvc\bin\hbmk.cfg
Harbour 2.1.0beta1 (Rev. 14542)
Copyright (c) 1999-2010, http://www.harbour-project.org/
Compiling 'while.prg'...
Lines 15, Functions/Procedures 1
Generating C source output to 'C:\Users\VAILTO~1\AppData\Local\Temp\while.c'...
Done.
while.c
LINK : fatal error LNK1181: cannot open input file '{IM}.obj'
hbmk2: Erro: Executando linkeditor. 1181
link.exe -nologo -out:while.exe C:\Users\VAILTO~1\AppData\Local\Temp\while.obj -
libpath:C:\hbmsvc\lib\win\msvc  -subsystem:console {IM} hbextern.lib hbdebug.lib
 hbvm.lib hbrtl.lib hblang.lib hbcpage.lib gtcgi.lib gtpca.lib gtstd.lib gtwin.l
ib gtwvt.lib gtgui.lib hbrdd.lib hbuddall.lib hbusrrdd.lib rddntx.lib rddcdx.lib
 rddnsx.lib rddfpt.lib hbrdd.lib hbhsx.lib hbsix.lib hbmacro.lib hbcplr.lib hbpp
.lib hbcommon.lib kernel32.lib user32.lib gdi32.lib advapi32.lib ws2_32.lib wins
pool.lib comctl32.lib comdlg32.lib shell32.lib uuid.lib ole32.lib oleaut32.lib m
pr.lib winmm.lib mapi32.lib imm32.lib msimg32.lib wininet.lib hbpcre.lib hbzlib.
lib

c:\harbour\tests>

Note the "{IM}" option on command line above... Even the very process
of compiling the Harbour was not successful because of this error. Any
suggestions?

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

[Harbour] Error building Harbour with last svn

[Lautaro Moreira]

When I' build harbour with last svn :
---
! Making E:\HARBOUR_PRUEBAS\HARBOUR\bin\hbmk.cfg...
! Making shared version of Harbour binaries...
./bin/win/msvc\hbmk2 -quiet -lang=en -q0 -shared 
utils/hbformat/hbformat.hbp -o$

{HB_BIN_INSTALL}/hbformat-dll
hbformat.c
hbformac.c
Generando código...
LINK : fatal error LNK1181: no se puede abrir el archivo de entrada 
'{IM}.obj'

hbmk2: Error: Running linker. 1181
./bin/win/msvc\hbmk2 -quiet -lang=en -q0 -shared utils/hbi18n/hbi18n.hbp 
-o${HB_

BIN_INSTALL}/hbi18n-dll
hbi18n.c
LINK : fatal error LNK1181: no se puede abrir el archivo de entrada 
'{IM}.obj'

hbmk2: Error: Running linker. 1181
./bin/win/msvc\hbmk2 -quiet -lang=en -q0 -shared utils/hbmk2/hbmk2.hbp 
-o${HB_BI

N_INSTALL}/hbmk2-dll
hbmk2.c
LINK : fatal error LNK1181: no se puede abrir el archivo de entrada 
'{IM}.obj'

hbmk2: Error: Running linker. 1181
./bin/win/msvc\hbmk2 -quiet -lang=en -q0 -shared utils/hbrun/hbrun.hbp 
-o${HB_BI

N_INSTALL}/hbrun-dll
Microsoft (R) Windows (R) Resource Compiler Version 6.0.5724.0
Copyright (C) Microsoft Corporation.  All rights reserved.

hbrun.c
LINK : fatal error LNK1181: no se puede abrir el archivo de entrada 
'{IM}.obj'

hbmk2: Error: Running linker. 1181
./bin/win/msvc\hbmk2 -quiet -lang=en -q0 -shared utils/hbtest/hbtest.hbp 
-o${HB_

BIN_INSTALL}/hbtest-dll
hbtest.c
rt_array.c
rt_date.c
rt_file.c
rt_hvm.c
rt_hvma.c
rt_math.c
rt_misc.c
rt_mt.c
rt_str.c
rt_stra.c
rt_trans.c
rt_class.c
rt_miscc.c
Generando código...
LINK : fatal error LNK1181: no se puede abrir el archivo de entrada 
'{IM}.obj'

hbmk2: Error: Running linker. 1181


My enviroment :

! Building Harbour 2.1.0beta1 from source - http://www.harbour-project.org
! MAKE: win-make 3.81 sh.exe clean
! HB_INSTALL_PREFIX: E:\HARBOUR_PRUEBAS\HARBOUR
! HB_HOST_PLAT: win (x86)  HB_SHELL: nt
! HB_PLATFORM: win (x86) (autodetected)
! HB_COMPILER: msvc (v900) (autodetected: C:/Program Files/Microsoft 
Visual Stud

io 9.0/VC/bin/)
! Component: 'zlib' found in 
E:/Harbour_Pruebas/harbour-svn/trunk/harbour/extern

al/zlib (local)
! Component: 'pcre' found in 
E:/Harbour_Pruebas/harbour-svn/trunk/harbour/extern

al/pcre (local)
! Component: 'openssl' found in E:\OPENSSL\98L\INCLUDE
! Component: 'gpm' not supported on win platform
! Component: 'slang' not found. Configure with HB_WITH_SLANG.
! Component: 'curses' not found. Configure with HB_WITH_CURSES.
! Component: 'x11' not found. Configure with HB_WITH_X11.
! Component: 'wattcp/watt-32' not supported on win platform
! REVISION :  14542


Atte.,

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

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

[Antonio Maniero]

>
>
> 2. go past into the virtual space, I mean end of line, which again
>   is a question in the dark as I did not find any Qt/QScintilla based
> editor
>   having this capability. In Windows it is easy, even I can simulate it.
>

I am not sure if virtual space is a goo thing. Maybe. I think it's
subjective.


> But don't worry, I have the setup in order on my laptop and will be
> experimenting,
> though in a limited manner as access time to that resource is limited. And
> when I will be in a position to show to the list the improvements, then we
> will
> decide where it goes.
>
> Good to know.


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

Re: [Harbour] Question about Curl detection during compile process

[smu johnson]

Thank you for clearing that up and your infinite patience.  Looks like I'm
going to have to right some quick and dirty .bat or perl scripts to toggle
which compiler is to be used.

On Thu, May 20, 2010 at 2:14 PM, Viktor Szakáts wrote:

> I'm afraid not. In general it's not very good to mix
> different compilers in PATH, but it's especially not
> good mix two different gcc versions in PATH at the same
> time. INSTALL doc makes this very clear.
>
> There is no compiler selector logic in our build system,
> since it would be a complete nightmare to test (hundreds
> of different combinations) and maintain just to sort out
> otherwise not very likely configurations as above. Notice
> that mixing compilers is not only bad for Harbour, but it's
> generally bad practice on Windows systems.
>
> 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:[14543] trunk/harbour

[vszakats]

Revision: 14543
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14543&view=rev
Author:   vszakats
Date: 2010-05-20 21:18:46 + (Thu, 20 May 2010)

Log Message:
---
2010-05-20 23:18 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * utils/hbmk2/hbmk2.prg
! Fixed filter evaluation to not let envvar names colliding
  with built-in filter keywords influence the results.
  (f.e. '{watcom}' while having properly configured watcom
  compiler defining WATCOM envvar and using a non-watcom
  compiler for the actual hbmk2 session).
% Optimized filter evaluation.
; Thanks to Przemek for the patches.

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


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

Re: [Harbour] sunpro-compiled hbrun doesn't work anymore

[Przemysław Czerpak]

On Thu, 20 May 2010, Tamas TEVESZ wrote:

Hi,

> as $subject says. i have bisected the problem to have been introduced  
> in r12466 (r12465 is fine).
> r12466 only says segmentation fault, leaving an empty hb_out.log; 
> r14542 is a bit more verbose with:
> Application Internal Error - 
> /home/ice/w/xhb/hbci/harbour-bisect/harbour/inst/linux/sunpro/c/bin/hbrun
> Terminated at: 2010.05.20 22:26:52
> Unrecoverable error 6005: Exception SIGSEGV at address 0x1b800ad5268
> Called from GET(73)
> Called from GETNEW(1978)
> Called from __GET(70)
> Called from HB_DOTPROMPT(162) in ../../../hbrun.prg
> Called from _APPMAIN(124) in ../../../hbrun.prg
> 
> (backtraces for both cases are below).
> this only happens if hbrun is requested to run interactively (eg. 
> using the dot console); if it is to run a program (at least a simple 
> one), it's ok. i also have not been able to find anything similar with 
> the other compilers i'm testing with.
> build environment is ubuntu 10.04/x64 and ubuntu 6.06/i386, with the 
> following settings:

Linux SUNPRO port has very serious bug. It does not correctly generate
code for all constructors. We are exploiting this problem from time to
time. It probably depends on total binary size which may interact with
the contents of some uninitialized memory. I do not know exectly where
inside SUNPRO the problem is but I've checked the final results in
harbour application. Startup code for some PRG modules is not executed
so they are not registered in HVM and their symbol tables are not
initialized but other modules contains references to functions from
unregistered modules and when they are executed application GPFs when
trying to access PHB_DYNS pointers in symbol tables.
In the past I reported few times that in my SunPRO builds hbtest GPFs
due to this problem. Now I've tested current builds and it works OK.
I can executed without any problems hbtest and hbrun. I'm using
suse1...@x86_64. Anyhow I expect that it can stop to work in any moment
when some modification change total memory alignment and the problem
will be exploited again. Looks that in your system is still exploited.

> Program received signal SIGSEGV, Segmentation fault.
> 0x00429ae1 in hb_vmPushStatic (uiStatic=1) at ../../../hvm.c:6960
> 6960 pStatic = ( ( PHB_ITEM ) hb_stackGetStaticsBase() 
> )->item.asArray.value->pItems + uiStatic - 1;

The symbol table of executed module was not registered so static frame
was not initialized and now executed code tries to access the array
of static variables using NULL pointer and GPFs.
I know what's the reason of problem but I'm afraid that I cannot resolve
it well. It has to be fixed inside SunPRO compiler/linker code. It's
probably only in Linux port. I've never exploited it in SunOS.

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

Re: [Harbour] Question about Curl detection during compile process

[Viktor Szakáts]

> Ah.  Correct again!  I thought if the gcc version I wanted to use before any 
> other was first in the windows path, it would only be used... but I am 
> incorrect.
> 
> # proper
> ! HB_COMPILER: mingw (v44) (autodetected: c:/mingw/bin/)
> 
> # problematic
> ! HB_COMPILER: mingw (v45) (autodetected: c:/mingw/bin/gcc.exe 
> C:/strawberry/c/bin/)
> 
> If it detected Strawberry Perl's gcc version after mine, which it seems like 
> it did as it comes 2nd on the above printout can't the version detect / 
> only use the first one, c:/mingw/bin/gcc.exe?

I'm afraid not. In general it's not very good to mix 
different compilers in PATH, but it's especially not 
good mix two different gcc versions in PATH at the same 
time. INSTALL doc makes this very clear.

There is no compiler selector logic in our build system, 
since it would be a complete nightmare to test (hundreds 
of different combinations) and maintain just to sort out 
otherwise not very likely configurations as above. Notice 
that mixing compilers is not only bad for Harbour, but it's 
generally bad practice on Windows systems.

Viktor

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

Re: [Harbour] Question about Curl detection during compile process

[smu johnson]

Ah.  Correct again!  I thought if the gcc version I wanted to use before any
other was first in the windows path, it would only be used... but I am
incorrect.

# proper
! HB_COMPILER: mingw (v44) (autodetected: c:/mingw/bin/)

# problematic
! HB_COMPILER: mingw (v45) (autodetected: c:/mingw/bin/gcc.exe
C:/strawberry/c/bin/)

If it detected Strawberry Perl's gcc version after mine, which it seems like
it did as it comes 2nd on the above printout can't the version detect /
only use the first one, c:/mingw/bin/gcc.exe?

This time, I was reading other threads about problems like these... but
perhaps I made too big of an assumption this time.


On Thu, May 20, 2010 at 1:55 PM, Viktor Szakáts wrote:

> I can just guess without seeing the beginning of your log output.
> Maybe you manually set HB_COMPILER (without setting HB_COMPILER_VER).
>
> Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[francesco perillo]

> Because I was simply starting to explore, and my development times are never
> on the same macine ever, I want it to be resident of hbide/qscintilla so I
> could
> access it on whatever I machine I am currently with.

If you want I can provide access to a Mercurial repository that can be
public or password-protected. Mercurial is a distributed version
control very easy to use...
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about Curl detection during compile process

[Viktor Szakáts]

I can just guess without seeing the beginning of your log output.
Maybe you manually set HB_COMPILER (without setting HB_COMPILER_VER).

Viktor

On 2010 May 20, at 22:47, smu johnson wrote:

> Well, it looks like it is not my destiny is to not get CURL to work.
> 
> r14528 is now not compiling.
> 
> 1.  compile string:  win-make HB_BUILD_UNICODE=no HB_BUILD_IMPLIB=yes 
> HB_WITH_CURL=\ver10\curl-7.20.1-devel-mingw32\include install
> 2.  Error text:
> 
> gcc   -I. -I../../../../../include -W -Wall -O3 -fomit-frame-pointer 
> -march=i586
>  -mtune=pentiumpro -DHB_LEGACY_TYPES_OFF   -ohbpp.o -c ../../../hbpp.c
> gcc  -Wl,--nxcompat -Wl,--dynamicbase -L../../../../../lib/win/mingw   -o 
> ..\..\
> ..\..\..\bin\win\mingw\hbpp.exe hbpp.o -lhbnortl -lhbcommon -lkernel32 
> -luser32
> -lws2_32 -ladvapi32 -lgdi32
> c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: 
> unrecogniz
> ed option '--nxcompat'
> c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: use the 
> --
> help option for usage information
> collect2: ld returned 1 exit status
> win-make[3]: *** [hbpp.exe] Error 1
> rm hbpp.o
> win-make[2]: *** [descend] Error 2
> win-make[1]: *** [pp.inst] Error 2
> win-make: *** [src.inst] Error 2
> 
> 3. Proof of using correct GCC:
> 
> G:\harbour>gcc -v
> Using built-in specs.
> Target: mingw32
> Configured with: ../../gcc-4.4.1/configure --prefix=/mingw --build=mingw32 
> --ena
> ble-languages=c,ada,c++,fortran,objc,obj-c++ --disable-nls 
> --disable-win32-regis
> try --enable-libgomp --enable-cxx-flags='-fno-function-sections 
> -fno-data-sectio
> ns' --disable-werror --enable-threads --disable-symvers 
> --enable-version-specifi
> c-runtime-libs --enable-fully-dynamic-string --with-pkgversion='TDM-2 
> mingw32' -
> -enable-sjlj-exceptions 
> --with-bugurl=http://www.tdragon.net/recentgcc/bugs.php
> Thread model: win32
> gcc version 4.4.1 (TDM-2 mingw32)
> 
> :(
> 
> On Thu, May 20, 2010 at 1:37 PM, smu johnson  wrote:
> Uh oh.  When you said check the change log for .hbi, you weren't joking!  I 
> think my problem is due to an old revision.  Sorry to beat this poor dead 
> horse.
> 
> 
> ___
> 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: SF.net SVN: harbour-project:[14538] trunk/harbour

[Pritpal Bedi]

Antonio Maniero wrote:
> 
> agree with him about this issue.
> 
> You are the master of HbIDE, you need to care about HbIDE. Because you are
> the master and not me, you need take decisions to take HbIDE to best
> result.
> I can't say what you should do to the best interest of HbIDE, you need to
> think about what you want to its future, what problems you will face in
> future, how you will find solutions to them.
> 
> You often state about QPlainTextEdit and other widgets as a limitation to
> implement some features. QScintilla brings new possibilities? You need
> think
> about this. You need looking for a solution to HbIDE, not a solution to
> Harbour, this will be the consequence. You need to decide only thinking
> about HbIDE requirements. Do what HbIDE needs. Are you sure the QScintilla
> is the solution? Are you sure you can achieve all HbIDE goals without
> QScintilla?
> 
> You don't ask to anyone what they think about QScintilla, it's ok, it's
> your
> call, but it looks like you decide without thinking and give up without
> balance and search alternatives when you found an obstacle. Pick
> QScintilla
> or not is a very important strategic decision to make.
> 
> Viktor didn't close the doors, just put some rules. If they are too much,
> you have alternatives to make HbIDE a terrific product. I am afraid you
> are
> making decisions without balance the technical needs.
> 
> If HbIDE fails I will use generic editors to handling Harbour code or I
> will
> need write my own editor. Both are bad solutions to me. I need HbIDE in
> right direction. In moments when you refuse some feature without a good
> reason denying the obvious solution I see the wrong direction. In moments
> like this topic I see no direction to HbIDE.
> 
> I would use QScintilla to build a code editor, but only you can say if
> QScintilla is the answer to HbIDE requirements. What's the best to HbIDE?
> 

I agree what Viktor did and also agree that this decision was somewhat 
not on firm grounds as I was begining to explore the possibilities to use 
QScintilla or not.

Because I was simply starting to explore, and my development times are never 
on the same macine ever, I want it to be resident of hbide/qscintilla so I
could
access it on whatever I machine I am currently with. 

I am not sure it is the best bet but for reasons I wanted to give it a try
are:

1. get rid of QSyntaxHighlighter and use QScintilla's lexer interface;
2. go past into the virtual space, I mean end of line, which again 
   is a question in the dark as I did not find any Qt/QScintilla based
editor
   having this capability. In Windows it is easy, even I can simulate it. 
3. Code folding/wrapping, which if I take it at my own, will take long to
mature.
4. Speed, which due to QSyntaxHighter() overhead is always a question,
specifically
   on large files.

We could have deleted the code once it gets matured, then, only providing a
.dll
with sources somewhere. In development process it is hard to synchronize 
code on different machines and times unless it is not at some central
location.

You may point-out the other alternatives, but then...

But don't worry, I have the setup in order on my laptop and will be
experimenting,
though in a limited manner as access time to that resource is limited. And
when I will be in a position to show to the list the improvements, then we
will 
decide where it goes.



-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/SF-net-SVN-harbour-project-14538-trunk-harbour-tp5079892p5081559.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] Question about Curl detection during compile process

[smu johnson]

Well, it looks like it is not my destiny is to not get CURL to work.

r14528 is now not compiling.

1.  compile string:  win-make HB_BUILD_UNICODE=no HB_BUILD_IMPLIB=yes
HB_WITH_CURL=\ver10\curl-7.20.1-devel-mingw32\include install
2.  Error text:

gcc   -I. -I../../../../../include -W -Wall -O3 -fomit-frame-pointer
-march=i586
 -mtune=pentiumpro -DHB_LEGACY_TYPES_OFF   -ohbpp.o -c ../../../hbpp.c
gcc  -Wl,--nxcompat -Wl,--dynamicbase -L../../../../../lib/win/mingw   -o
..\..\
..\..\..\bin\win\mingw\hbpp.exe hbpp.o -lhbnortl -lhbcommon -lkernel32
-luser32
-lws2_32 -ladvapi32 -lgdi32
c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe:
unrecogniz
ed option '--nxcompat'
c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: use
the --
help option for usage information
collect2: ld returned 1 exit status
win-make[3]: *** [hbpp.exe] Error 1
rm hbpp.o
win-make[2]: *** [descend] Error 2
win-make[1]: *** [pp.inst] Error 2
win-make: *** [src.inst] Error 2

3. Proof of using correct GCC:

G:\harbour>gcc -v
Using built-in specs.
Target: mingw32
Configured with: ../../gcc-4.4.1/configure --prefix=/mingw --build=mingw32
--ena
ble-languages=c,ada,c++,fortran,objc,obj-c++ --disable-nls
--disable-win32-regis
try --enable-libgomp --enable-cxx-flags='-fno-function-sections
-fno-data-sectio
ns' --disable-werror --enable-threads --disable-symvers
--enable-version-specifi
c-runtime-libs --enable-fully-dynamic-string --with-pkgversion='TDM-2
mingw32' -
-enable-sjlj-exceptions --with-bugurl=
http://www.tdragon.net/recentgcc/bugs.php
Thread model: win32
gcc version 4.4.1 (TDM-2 mingw32)

:(

On Thu, May 20, 2010 at 1:37 PM, smu johnson  wrote:

> Uh oh.  When you said check the change log for .hbi, you weren't joking!  I
> think my problem is due to an old revision.  Sorry to beat this poor dead
> horse.
>
>
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[Viktor Szakáts]

>; NOTE 2: I've checked win/watcom -6s option, but it's still not 
>  good because it appends '_' to exported symbols, so 
>  watcom -shared executables stop working with mingw/msvc 
>  Harbour .dll. Any idea how to solve that?

I've found information regarding this issue on this link:
   http://www.azillionmonkeys.com/qed/watfaq.shtml#25

quote:
---
- WATCOM will, by default, use registers for its parameter passing
convention which makes it incompatible with regular COFF format libraries
and object files.  However, adding the extra declaration information via
"#pragma aux  frame;" will force WATCOM to pass parameters to
the function via the stack.  
---

Maybe it's useful.

Here's some relevant watcom doc, but it's not extremely helpful:
   http://www.openwatcom.org/index.php/Calling_Conventions

I also recommend this link for calling convention topic in general:
   http://www.agner.org/optimize/calling_conventions.pdf

Viktor

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

Re: [Harbour] To Harbour linux experts

[Bruno Luciani]

thanks Viktor

Bruno

2010/5/20 Viktor Szakáts 

> > $? returns the errorlevel set by the program, not just 0 and 1... 0 is
> > the standard for error-less returns.
> >
> >> But when I run an external aplicattion this variable don't generate a
> >> usefull value
> >>
> >> in example an hbmk2 command .
> >>
> >> Anybody have an idea in how to achieve this task ?
> >
> > I don't really understand what you mean
> >
> > hbmk2 should return a value, we may ask Viktor what to return the
> > value the external program returns... let's say gcc returns 1 to
> > signal a problem, hbmk2 should return 1
>
> hbmk2 returns various non-zero values on failure depending
> on the stage where the build failed. For successful runs
> it returns zero or the when -run option is used, the return
> value of target executable.
>
> 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

[Harbour] sunpro-compiled hbrun doesn't work anymore

[Tamas TEVESZ]

hi,

as $subject says. i have bisected the problem to have been introduced  
in r12466 (r12465 is fine).

r12466 only says segmentation fault, leaving an empty hb_out.log; 
r14542 is a bit more verbose with:

Application Internal Error - 
/home/ice/w/xhb/hbci/harbour-bisect/harbour/inst/linux/sunpro/c/bin/hbrun
Terminated at: 2010.05.20 22:26:52
Unrecoverable error 6005: Exception SIGSEGV at address 0x1b800ad5268
Called from GET(73)
Called from GETNEW(1978)
Called from __GET(70)
Called from HB_DOTPROMPT(162) in ../../../hbrun.prg
Called from _APPMAIN(124) in ../../../hbrun.prg


(backtraces for both cases are below).

this only happens if hbrun is requested to run interactively (eg. 
using the dot console); if it is to run a program (at least a simple 
one), it's ok. i also have not been able to find anything similar with 
the other compilers i'm testing with.

build environment is ubuntu 10.04/x64 and ubuntu 6.06/i386, with the 
following settings:

unset ${!HB_*}
export HB_BUILD_DEBUG=yes
export HB_COMMERCE=yes
export HB_BUILD_OPTIM=no
export HB_CONTRIBLIBS=no
export HB_WITH_PCRE=yes
export HB_WITH_ZLIB=yes
export HB_PLATFORM=linux
export HB_COMPILER=sunpro
export HB_BUILD_MODE=cpp
export HB_INSTALL_PREFIX=$appdir/inst/$HB_PLATFORM/$HB_COMPILER/$HB_BUILD_MODE

(HB_WITH_PCRE and HB_WITH_ZLIB are not present when building head)

sunpro is cc: Sun C 5.10 Linux_i386 2009/06/03 (CC doesn't work for a 
while, barfing on some system headers).

here's what gdb has to say about this (this particular one being 
ubuntu 10.04/x64; 6.06/i386 is essentially the same, save for the 
addresses):

this is the backtrace for r12466, where the problem originally was 
introduced:

pinky:~/w/xhb/hbci/harbour-bisect/harbour-r12466$ gdb 
./inst/linux/sunpro/c/bin/hbrun
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from 
/home/ice/w/xhb/hbci/harbour-bisect/harbour-r12466/inst/linux/sunpro/c/bin/hbrun...done.
(gdb) run
Starting program: 
/home/ice/w/xhb/hbci/harbour-bisect/harbour-r12466/inst/linux/sunpro/c/bin/hbrun
 
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x00429ae1 in hb_vmPushStatic (uiStatic=1) at ../../../hvm.c:6960
6960   pStatic = ( ( PHB_ITEM ) hb_stackGetStaticsBase() 
)->item.asArray.value->pItems + uiStatic - 1;
(gdb) bt full
#0  0x00429ae1 in hb_vmPushStatic (uiStatic=1) at ../../../hvm.c:6960
pStatic = 0xb6f788
#1  0x004304a2 in hb_xvmPushStatic (uiStatic=1) at ../../../hvm.c:9037
No locals.
#2  0x005cd8fc in HB_FUN_GET () at tget.c:408
fValue = 32767
#3  0x00425c0c in hb_vmProc (uiParams=0) at ../../../hvm.c:5720
sStackState = {lBaseItem = 29, ulPrivateBase = 0, pStatics = 0xb93418, 
uiClass = 0, uiMethod = 0, uiLineNo = 73, 
  fDebugging = 0}
pSym = 0xaf1c60
#4  0x0042fb2d in hb_xvmFunction (uiParams=0) at ../../../hvm.c:8918
No locals.
#5  0x005f538e in HB_FUN_GETNEW () at tget.c:9369
No locals.
#6  0x00425c0c in hb_vmProc (uiParams=5) at ../../../hvm.c:5720
sStackState = {lBaseItem = 21, ulPrivateBase = 0, pStatics = 0xb93418, 
uiClass = 0, uiMethod = 0, uiLineNo = 1975, 
  fDebugging = 0}
pSym = 0xaf3e70
#7  0x0042fb2d in hb_xvmFunction (uiParams=5) at ../../../hvm.c:8918
No locals.
#8  0x005f6690 in HB_FUN___GET () at tgetint.c:124
fValue = 0
#9  0x00425c0c in hb_vmProc (uiParams=5) at ../../../hvm.c:5720
sStackState = {lBaseItem = 6, ulPrivateBase = 0, pStatics = 0xb93418, 
uiClass = 0, uiMethod = 0, uiLineNo = 70, 
  fDebugging = 0}
pSym = 0xad49c8
#10 0x00414fad in hb_vmExecute (pCode=0x80a31e 
"\f\005\024\002\060\034", pSymbols=0xad4688) at ../../../hvm.c:1629
bCanRecover = 0
bDynCode = 0
piKeyPolls = 0xb4a880
#11 0x00412ac7 in HB_FUN_HB_DOTPROMPT () at hbrun.c:280
pcode = 
"\r\t\001tJ\000$\210\000\260\r\000\024\000\260\016\000yy\024\002$\211\000\260\017\000\\
 
j\004OFF\000\024\002$\212\000\004\000\000P\002$\213\000\260\020\000j\005quit\000]\000\001\f\002\004\001\000P\006$\214\000\\\002P\a$\216\000\260\021\000_\001\f\001\034,$\217\000\260\003\000_\006\260\020\000_\001]\000\001\f\002\024\002$\220\000\260\022\000_\001\024\001$\221\000\260\023\000_\001\024\001\031\n$\223\000j\001\000P\001$\230\000_\003d\b\034\017$\231\000\260\024\000]\000\001\f\001P\003$\234\000\260\022\000_\001\024\001$\236\000\260\025\000\f\000P\004$\237\

Re: [Harbour] Question about Curl detection during compile process

[smu johnson]

Uh oh.  When you said check the change log for .hbi, you weren't joking!  I
think my problem is due to an old revision.  Sorry to beat this poor dead
horse.


On Thu, May 20, 2010 at 1:34 PM, smu johnson  wrote:

> :(
>
> I come bearing more bad news.  Despite doing all of the above...
>
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about Curl detection during compile process

[smu johnson]

:(

I come bearing more bad news.  Despite doing all of the above...

I did this, and got this:

C:\hbm>g:\harbour\bin\hbmk2 hello.PRG g:\harbour\contrib\hbcurl\hbcurl.hbc
hbmk2: Processing configuration: g:\harbour\bin\hbmk.cfg
Harbour 2.1.0beta1 (Rev. 14434)
Copyright (c) 1999-2010, http://www.harbour-project.org/
Compiling 'hello.PRG'...
Lines 669, Functions/Procedures 1
Generating C source output to
'C:\Users\sjohnson\AppData\Local\Temp\hello.c'...
Done.
c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: cannot
fin
d -lcurldll
collect2: ld returned 1 exit status
hbmk2: Error: Running linker. 1
gcc.exe C:\Users\sjohnson\AppData\Local\Temp\hello.o
C:\Users\sjohnson\AppData\L
ocal\Temp\hbmk_yx8lre.o-mconsole -Wl,--start-group -lhbcurl -lcurldll
-lhbex
tern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd
-lgtwin
 -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd -lrddntx -lrddcdx -lrddnsx
-lrddf
pt -lhbrdd -lhbhsx -lhbsix -lhbmacro -lhbcplr -lhbpp -lhbcommon -lhbmainstd
-lke
rnel32 -luser32 -lgdi32 -ladvapi32 -lws2_32 -lwinspool -lcomctl32 -lcomdlg32
-ls
hell32 -luuid -lole32 -loleaut32 -lmpr -lwinmm -lmapi32 -limm32 -lmsimg32
-lwini
net -lhbpcre -lhbzlib  -Wl,--end-group -ohello.exe
-Lg:/harbour/lib/win/mingw

Any final hints?  *puppy dog eyes*

Thank you

On Wed, May 19, 2010 at 5:19 PM, Viktor Szakáts wrote:

> > This was my command I tried... feel free to laugh at me!
>  C:\hbm>g:\harbour\bin\hbmk2.exe g:\harbour\contrib\hbcurl\hbcurl.hbc
> .\hello.prg -lhbcurl
>
> Why do you insist on -lhbcurl? ;) It's not needed.
> Otherwise it's right.
>
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[Antonio Maniero]

>
>
> Anyhow, I am dropping the idea to base anything on QScintilla.
> I will try to add features with my existing thought of
> development.
>
> Viktor is just caring about Harbour project, it is his job and I totally
agree with him about this issue.

You are the master of HbIDE, you need to care about HbIDE. Because you are
the master and not me, you need take decisions to take HbIDE to best result.
I can't say what you should do to the best interest of HbIDE, you need to
think about what you want to its future, what problems you will face in
future, how you will find solutions to them.

You often state about QPlainTextEdit and other widgets as a limitation to
implement some features. QScintilla brings new possibilities? You need think
about this. You need looking for a solution to HbIDE, not a solution to
Harbour, this will be the consequence. You need to decide only thinking
about HbIDE requirements. Do what HbIDE needs. Are you sure the QScintilla
is the solution? Are you sure you can achieve all HbIDE goals without
QScintilla?

You don't ask to anyone what they think about QScintilla, it's ok, it's your
call, but it looks like you decide without thinking and give up without
balance and search alternatives when you found an obstacle. Pick QScintilla
or not is a very important strategic decision to make.

Viktor didn't close the doors, just put some rules. If they are too much,
you have alternatives to make HbIDE a terrific product. I am afraid you are
making decisions without balance the technical needs.

If HbIDE fails I will use generic editors to handling Harbour code or I will
need write my own editor. Both are bad solutions to me. I need HbIDE in
right direction. In moments when you refuse some feature without a good
reason denying the obvious solution I see the wrong direction. In moments
like this topic I see no direction to HbIDE.

I would use QScintilla to build a code editor, but only you can say if
QScintilla is the answer to HbIDE requirements. What's the best to HbIDE?

[]'s Maniero
___
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:[14542] trunk/harbour

[druzus]

Revision: 14542
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14542&view=rev
Author:   druzus
Date: 2010-05-20 19:15:11 + (Thu, 20 May 2010)

Log Message:
---
2010-05-20 21:14 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/include/hbthread.h
* cover some functions and HB_THREADSTATE structure by _HB_API_INTERNAL_
* export hb_threadReleaseCPU() function

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


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

Re: [Harbour] To Harbour linux experts

[Viktor Szakáts]

> $? returns the errorlevel set by the program, not just 0 and 1... 0 is
> the standard for error-less returns.
> 
>> But when I run an external aplicattion this variable don't generate a
>> usefull value
>> 
>> in example an hbmk2 command .
>> 
>> Anybody have an idea in how to achieve this task ?
> 
> I don't really understand what you mean
> 
> hbmk2 should return a value, we may ask Viktor what to return the
> value the external program returns... let's say gcc returns 1 to
> signal a problem, hbmk2 should return 1

hbmk2 returns various non-zero values on failure depending 
on the stage where the build failed. For successful runs 
it returns zero or the when -run option is used, the return 
value of target executable.

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

[vszakats]

Revision: 14541
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14541&view=rev
Author:   vszakats
Date: 2010-05-20 19:07:59 + (Thu, 20 May 2010)

Log Message:
---
2010-05-20 21:07 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * config/global.mk
  * config/rules.mk
  * external/pcre/Makefile
+ Added HB_CFLAGS_STA variable to hold C compiler options 
  passed solely when compiling for static lib.
* Change PCRE setup to use HB_CFLAGS_STA instead of -U 
  trick at the same time silencing msvc warning.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/config/global.mk
trunk/harbour/config/rules.mk
trunk/harbour/external/pcre/Makefile


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

[vszakats]

Revision: 14540
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14540&view=rev
Author:   vszakats
Date: 2010-05-20 18:58:21 + (Thu, 20 May 2010)

Log Message:
---
2010-05-20 20:33 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * config/global.mk
  * config/rules.mk
+ Added HB_CFLAGS_DYN variable to pass lib specific options
  specially directed to compilation phase when building
  to create a .dll. Currently this affects pcre and zlib since
  these are included in harbour .dll.

  * external/libhpdf/Makefile
  * external/pcre/Makefile
  * external/png/Makefile
  * external/zlib/Makefile
+ Configured HB_CFLAGS_DYN for these libs to properly create
  exported symbols in harbour .dll. This was a problem so far
  for any non-mingw made harbour .dll.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/config/global.mk
trunk/harbour/config/rules.mk
trunk/harbour/external/libhpdf/Makefile
trunk/harbour/external/pcre/Makefile
trunk/harbour/external/png/Makefile
trunk/harbour/external/zlib/Makefile


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] To Harbour linux experts

[Bruno Luciani]

Ok I try this

Bruno

2010/5/20 francesco perillo 

> Hi Bruno,
>
> $? returns the errorlevel set by the program, not just 0 and 1... 0 is
> the standard for error-less returns.
>
> > But when I run an external aplicattion this variable don't generate a
> > usefull value
> >
> > in example an hbmk2 command .
> >
> > Anybody have an idea in how to achieve this task ?
>
> I don't really understand what you mean
>
> hbmk2 should return a value, we may ask Viktor what to return the
> value the external program returns... let's say gcc returns 1 to
> signal a problem, hbmk2 should return 1
> ___
> 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] To Harbour linux experts

[francesco perillo]

Hi Bruno,

$? returns the errorlevel set by the program, not just 0 and 1... 0 is
the standard for error-less returns.

> But when I run an external aplicattion this variable don't generate a
> usefull value
>
> in example an hbmk2 command .
>
> Anybody have an idea in how to achieve this task ?

I don't really understand what you mean

hbmk2 should return a value, we may ask Viktor what to return the
value the external program returns... let's say gcc returns 1 to
signal a problem, hbmk2 should return 1
___
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:[14539] trunk/harbour

[druzus]

Revision: 14539
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14539&view=rev
Author:   druzus
Date: 2010-05-20 17:50:09 + (Thu, 20 May 2010)

Log Message:
---
2010-05-20 19:49 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/src/rdd/dbf1.c
* minor cleanup

  * harbour/include/hbapi.h
+ added new macro HB_IS_EVALITEM() - returns true for items which can
  understand EVAL message i.e. CODEBLOCK and SYMBOL items.

  * harbour/contrib/hbwin/axcore.c
  * harbour/contrib/hbwin/olecore.c
  * harbour/contrib/hbwin/hbwinole.h
* modified hb_oleDispInvoke() function to accept as additional
  parameter pointer to HVM item instead of pointer to DISPID.
  Such version is more universal.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbwin/axcore.c
trunk/harbour/contrib/hbwin/hbwinole.h
trunk/harbour/contrib/hbwin/olecore.c
trunk/harbour/include/hbapi.h
trunk/harbour/src/rdd/dbf1.c


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

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

[Viktor Szakáts]

>> The solution for this is to create wrapper lib 
>> inside contrib HBQT named hbqscintilla which 
>> depends on 3rd party lib qscintilla, and where 
>> the latter remains hosted in its original location 
>> (not in Harbour SVN, due to its size, maintenance 
>> needs and even potential licensing issues). One 
>> alternative is to place HBQSCINTILLA right inside 
>> contrib instead of having it inside HBQT.
>> 
> 
> Wrapper lib is of no use if .dll and .a is not there.
> QScintilla does not provide binary distro.

That's not Harbour problem. It would be interesting 
to know what is the reason behind this property of 
QSCINTILLA.

> More, as of now QScintilla needs an overhaul to 
> adopt to Harboud or say hbIDE needs which is not possible
> with their distro as of now.
> 
> Anyhow, I am dropping the idea to base anything on QScintilla.
> I will try to add features with my existing thought of 
> development.

Okay.

Viktor

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

[Harbour] To Harbour linux experts

[Bruno Luciani]

I am trying to make an .sh file to run several hbmk2 commands

But I need to confirm if each of it was sucessfully executed

When i use bash programming , and run console commands

running echo $?  giveme an idea if the command was or not sucessfully ( take
0 or 1 values )

But when I run an external aplicattion this variable don't generate a
usefull value

in example an hbmk2 command .

Anybody have an idea in how to achieve this task ?

Thanks in advance

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

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

[Pritpal Bedi]

Viktor Szakáts wrote:
> 
> The solution for this is to create wrapper lib 
> inside contrib HBQT named hbqscintilla which 
> depends on 3rd party lib qscintilla, and where 
> the latter remains hosted in its original location 
> (not in Harbour SVN, due to its size, maintenance 
> needs and even potential licensing issues). One 
> alternative is to place HBQSCINTILLA right inside 
> contrib instead of having it inside HBQT.
> 

Wrapper lib is of no use if .dll and .a is not there.
QScintilla does not provide binary distro.



> [ As I wrote in a previous e-mail, which went 
> pbly unnoticed. ]
> 
> Any other solution is wrong for one reason or 
> another.
> 

Not unnoticed, but for sure I understood it wrong.



> The only part which casts a shadow on all this is 
> the fact that QSCINTILLA doesn't seem to have a 
> proper binary (either .dll or static lib) based 
> distribution, which makes the whole process much 
> more painful than with existing dependency cases.
> But, this isn't a Harbour problem, so it's not 
> our objective to solve it.
> 

As above.

More, as of now QScintilla needs an overhaul to 
adopt to Harboud or say hbIDE needs which is not possible
with their distro as of now.

Anyhow, I am dropping the idea to base anything on QScintilla.
I will try to add features with my existing thought of 
development.

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

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

[Viktor Szakáts]

Hi Pritpal,

>> Log Message:
>> ---
>> 2010-05-20 16:22 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
>>  * contrib/hbide/qscintilla
>>- Deleted this hosted foreign code for reasons explained 
>> 
> 
> It is ok, no problems.
> 
>> (but apparently not understood).
> 
> For sure I did not understand.
> I thought it should not go inside Harbour build engine,
> so should not be inside hbQT. Probbaly I misread some lines.

The solution for this is to create wrapper lib 
inside contrib HBQT named hbqscintilla which 
depends on 3rd party lib qscintilla, and where 
the latter remains hosted in its original location 
(not in Harbour SVN, due to its size, maintenance 
needs and even potential licensing issues). One 
alternative is to place HBQSCINTILLA right inside 
contrib instead of having it inside HBQT.

[ As I wrote in a previous e-mail, which went 
pbly unnoticed. ]

Any other solution is wrong for one reason or 
another.

The only part which casts a shadow on all this is 
the fact that QSCINTILLA doesn't seem to have a 
proper binary (either .dll or static lib) based 
distribution, which makes the whole process much 
more painful than with existing dependency cases.
But, this isn't a Harbour problem, so it's not 
our objective to solve it.

Again: These are Harbour rules, so in case HBIDE 
is hosted anywhere else, you have the freedom 
to solve it in any ways you see fit.

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

[Viktor Szakáts]

Sorry Pritpal, but I will remove this from SVN.

Viktor

On 2010 May 20, at 16:13, vouch...@users.sourceforge.net wrote:

> Revision: 14536
>  
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14536&view=rev
> Author:   vouchcac
> Date: 2010-05-20 14:13:24 + (Thu, 20 May 2010)
> 
> Log Message:
> ---
> 2010-05-20 06:56 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
>  + contrib/hbide/qscintilla
>+ contrib/hbide/qscintilla/qt
> 
>  Initial port of QScintilla ( 
> http://www.riverbankcomputing.co.uk/software/qscintilla/intro )
> 
>  This port is greatly trimmed one excluding all lexer code
>  except CPP and FLAGSHIP which are relevant to Xbase code 
>  at present. Also directory structure is normalized and sources
>  are modified to respect them. SVN properties are eol:native, 
>  I am not sure what other properties should go inside.
>  QScintilla actually is divided into two libs but for sake
>  of convinience I have kept them as one.
> 
>  It is a base commit. In the next days a Harbour wrapped 
>  is scheduled to be built onto it and then actual application 
>  experiments will follow. On success, current edit component
>  of hbIDE will be transferred.
> 
>  I am poor in looking at licensing, so please feel free to 
>  delete this commit if it does not confirm to original intent.
> 
>  I have also touched the sources to suppress a lot of warnings
>  and library seems to be working fine after these changes. Still
>  some warnings are there which I could not supress, please look.
> 
>  To build the lib qscintilla.hbp is there, just issue 
>  hbmk2 qscintilla.hbp while residing in hbide/qscintilla.
> 
> Modified Paths:
> --
>trunk/harbour/ChangeLog
> 
> Added Paths:
> ---
>trunk/harbour/contrib/hbide/qscintilla/
>trunk/harbour/contrib/hbide/qscintilla/Accessor.h
>trunk/harbour/contrib/hbide/qscintilla/AutoComplete.cpp
>trunk/harbour/contrib/hbide/qscintilla/AutoComplete.h
>trunk/harbour/contrib/hbide/qscintilla/CallTip.cpp
>trunk/harbour/contrib/hbide/qscintilla/CallTip.h
>trunk/harbour/contrib/hbide/qscintilla/CellBuffer.cpp
>trunk/harbour/contrib/hbide/qscintilla/CellBuffer.h
>trunk/harbour/contrib/hbide/qscintilla/CharClassify.cpp
>trunk/harbour/contrib/hbide/qscintilla/CharClassify.h
>trunk/harbour/contrib/hbide/qscintilla/CharacterSet.h
>trunk/harbour/contrib/hbide/qscintilla/ContractionState.cpp
>trunk/harbour/contrib/hbide/qscintilla/ContractionState.h
>trunk/harbour/contrib/hbide/qscintilla/Decoration.cpp
>trunk/harbour/contrib/hbide/qscintilla/Decoration.h
>trunk/harbour/contrib/hbide/qscintilla/Document.cpp
>trunk/harbour/contrib/hbide/qscintilla/Document.h
>trunk/harbour/contrib/hbide/qscintilla/DocumentAccessor.cpp
>trunk/harbour/contrib/hbide/qscintilla/DocumentAccessor.h
>trunk/harbour/contrib/hbide/qscintilla/Editor.cpp
>trunk/harbour/contrib/hbide/qscintilla/Editor.h
>trunk/harbour/contrib/hbide/qscintilla/ExternalLexer.cpp
>trunk/harbour/contrib/hbide/qscintilla/ExternalLexer.h
>trunk/harbour/contrib/hbide/qscintilla/Indicator.cpp
>trunk/harbour/contrib/hbide/qscintilla/Indicator.h
>trunk/harbour/contrib/hbide/qscintilla/KeyMap.cpp
>trunk/harbour/contrib/hbide/qscintilla/KeyMap.h
>trunk/harbour/contrib/hbide/qscintilla/KeyWords.cpp
>trunk/harbour/contrib/hbide/qscintilla/KeyWords.h
>trunk/harbour/contrib/hbide/qscintilla/LexCPP.cpp
>trunk/harbour/contrib/hbide/qscintilla/LexFlagship.cpp
>trunk/harbour/contrib/hbide/qscintilla/License.txt
>trunk/harbour/contrib/hbide/qscintilla/LineMarker.cpp
>trunk/harbour/contrib/hbide/qscintilla/LineMarker.h
>trunk/harbour/contrib/hbide/qscintilla/Partitioning.h
>trunk/harbour/contrib/hbide/qscintilla/PerLine.cpp
>trunk/harbour/contrib/hbide/qscintilla/PerLine.h
>trunk/harbour/contrib/hbide/qscintilla/Platform.h
>trunk/harbour/contrib/hbide/qscintilla/PositionCache.cpp
>trunk/harbour/contrib/hbide/qscintilla/PositionCache.h
>trunk/harbour/contrib/hbide/qscintilla/PropSet.cpp
>trunk/harbour/contrib/hbide/qscintilla/PropSet.h
>trunk/harbour/contrib/hbide/qscintilla/RESearch.cpp
>trunk/harbour/contrib/hbide/qscintilla/RESearch.h
>trunk/harbour/contrib/hbide/qscintilla/RunStyles.cpp
>trunk/harbour/contrib/hbide/qscintilla/RunStyles.h
>trunk/harbour/contrib/hbide/qscintilla/SString.h
>trunk/harbour/contrib/hbide/qscintilla/SVector.h
>trunk/harbour/contrib/hbide/qscintilla/SciLexer.h
>trunk/harbour/contrib/hbide/qscintilla/Scintilla.h
>trunk/harbour/contrib/hbide/qscintilla/ScintillaBase.cpp
>trunk/harbour/contrib/hbide/qscintilla/ScintillaBase.h
>trunk/harbour/contrib/hbide/qscintilla/ScintillaWidget.h
>trunk/harbour/contrib/hbide/qscintilla/SplitVector.h
>trunk/harbour/contrib/hbide/qscintilla/Style.cpp

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

[Pritpal Bedi]

vszakats wrote:
> 
> Log Message:
> ---
> 2010-05-20 16:22 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
>   * contrib/hbide/qscintilla
> - Deleted this hosted foreign code for reasons explained 
> 

It is ok, no problems.

>  (but apparently not understood).

For sure I did not understand.
I thought it should not go inside Harbour build engine,
so should not be inside hbQT. Probbaly I misread some lines.


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

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

[Viktor Szakáts]

Hi Pritpal,

Please move HBIDE hosting to a separate repository, 
because by now it grew just large and popular enough 
to stand on its own feet, takes a huge portion of SVN 
and communication of our core development list, and 
in general has not much to do with out primary goals, 
and the two projects have apparently quite different 
and colliding goals.

Viktor

On 2010 May 20, at 16:18, vouch...@users.sourceforge.net wrote:

> Revision: 14537
>  
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14537&view=rev
> Author:   vouchcac
> Date: 2010-05-20 14:18:25 + (Thu, 20 May 2010)
> 
> Log Message:
> ---
> 2010-05-20 07:14 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
>  * contrib/hbide/ideprojmanager.prg
>  * contrib/hbide/idesources.prg
>% Modified: to present the project location folder to 
>  select sources in the "Project Properties" dialog.
> 
> Modified Paths:
> --
>trunk/harbour/ChangeLog
>trunk/harbour/contrib/hbide/ideprojmanager.prg
>trunk/harbour/contrib/hbide/idesources.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 mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[vszakats]

Revision: 14538
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14538&view=rev
Author:   vszakats
Date: 2010-05-20 14:23:00 + (Thu, 20 May 2010)

Log Message:
---
2010-05-20 16:22 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * contrib/hbide/qscintilla
- Deleted this hosted foreign code for reasons explained 
  (but apparently not understood).

Modified Paths:
--
trunk/harbour/ChangeLog

Removed Paths:
-
trunk/harbour/contrib/hbide/qscintilla/


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

[vouchcac]

Revision: 14537
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14537&view=rev
Author:   vouchcac
Date: 2010-05-20 14:18:25 + (Thu, 20 May 2010)

Log Message:
---
2010-05-20 07:14 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * contrib/hbide/ideprojmanager.prg
  * contrib/hbide/idesources.prg
% Modified: to present the project location folder to 
  select sources in the "Project Properties" dialog.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbide/ideprojmanager.prg
trunk/harbour/contrib/hbide/idesources.prg


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

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

[vouchcac]

Revision: 14536
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14536&view=rev
Author:   vouchcac
Date: 2010-05-20 14:13:24 + (Thu, 20 May 2010)

Log Message:
---
2010-05-20 06:56 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  + contrib/hbide/qscintilla
+ contrib/hbide/qscintilla/qt

  Initial port of QScintilla ( 
http://www.riverbankcomputing.co.uk/software/qscintilla/intro )

  This port is greatly trimmed one excluding all lexer code
  except CPP and FLAGSHIP which are relevant to Xbase code 
  at present. Also directory structure is normalized and sources
  are modified to respect them. SVN properties are eol:native, 
  I am not sure what other properties should go inside.
  QScintilla actually is divided into two libs but for sake
  of convinience I have kept them as one.

  It is a base commit. In the next days a Harbour wrapped 
  is scheduled to be built onto it and then actual application 
  experiments will follow. On success, current edit component
  of hbIDE will be transferred.

  I am poor in looking at licensing, so please feel free to 
  delete this commit if it does not confirm to original intent.

  I have also touched the sources to suppress a lot of warnings
  and library seems to be working fine after these changes. Still
  some warnings are there which I could not supress, please look.

  To build the lib qscintilla.hbp is there, just issue 
  hbmk2 qscintilla.hbp while residing in hbide/qscintilla.

Modified Paths:
--
trunk/harbour/ChangeLog

Added Paths:
---
trunk/harbour/contrib/hbide/qscintilla/
trunk/harbour/contrib/hbide/qscintilla/Accessor.h
trunk/harbour/contrib/hbide/qscintilla/AutoComplete.cpp
trunk/harbour/contrib/hbide/qscintilla/AutoComplete.h
trunk/harbour/contrib/hbide/qscintilla/CallTip.cpp
trunk/harbour/contrib/hbide/qscintilla/CallTip.h
trunk/harbour/contrib/hbide/qscintilla/CellBuffer.cpp
trunk/harbour/contrib/hbide/qscintilla/CellBuffer.h
trunk/harbour/contrib/hbide/qscintilla/CharClassify.cpp
trunk/harbour/contrib/hbide/qscintilla/CharClassify.h
trunk/harbour/contrib/hbide/qscintilla/CharacterSet.h
trunk/harbour/contrib/hbide/qscintilla/ContractionState.cpp
trunk/harbour/contrib/hbide/qscintilla/ContractionState.h
trunk/harbour/contrib/hbide/qscintilla/Decoration.cpp
trunk/harbour/contrib/hbide/qscintilla/Decoration.h
trunk/harbour/contrib/hbide/qscintilla/Document.cpp
trunk/harbour/contrib/hbide/qscintilla/Document.h
trunk/harbour/contrib/hbide/qscintilla/DocumentAccessor.cpp
trunk/harbour/contrib/hbide/qscintilla/DocumentAccessor.h
trunk/harbour/contrib/hbide/qscintilla/Editor.cpp
trunk/harbour/contrib/hbide/qscintilla/Editor.h
trunk/harbour/contrib/hbide/qscintilla/ExternalLexer.cpp
trunk/harbour/contrib/hbide/qscintilla/ExternalLexer.h
trunk/harbour/contrib/hbide/qscintilla/Indicator.cpp
trunk/harbour/contrib/hbide/qscintilla/Indicator.h
trunk/harbour/contrib/hbide/qscintilla/KeyMap.cpp
trunk/harbour/contrib/hbide/qscintilla/KeyMap.h
trunk/harbour/contrib/hbide/qscintilla/KeyWords.cpp
trunk/harbour/contrib/hbide/qscintilla/KeyWords.h
trunk/harbour/contrib/hbide/qscintilla/LexCPP.cpp
trunk/harbour/contrib/hbide/qscintilla/LexFlagship.cpp
trunk/harbour/contrib/hbide/qscintilla/License.txt
trunk/harbour/contrib/hbide/qscintilla/LineMarker.cpp
trunk/harbour/contrib/hbide/qscintilla/LineMarker.h
trunk/harbour/contrib/hbide/qscintilla/Partitioning.h
trunk/harbour/contrib/hbide/qscintilla/PerLine.cpp
trunk/harbour/contrib/hbide/qscintilla/PerLine.h
trunk/harbour/contrib/hbide/qscintilla/Platform.h
trunk/harbour/contrib/hbide/qscintilla/PositionCache.cpp
trunk/harbour/contrib/hbide/qscintilla/PositionCache.h
trunk/harbour/contrib/hbide/qscintilla/PropSet.cpp
trunk/harbour/contrib/hbide/qscintilla/PropSet.h
trunk/harbour/contrib/hbide/qscintilla/RESearch.cpp
trunk/harbour/contrib/hbide/qscintilla/RESearch.h
trunk/harbour/contrib/hbide/qscintilla/RunStyles.cpp
trunk/harbour/contrib/hbide/qscintilla/RunStyles.h
trunk/harbour/contrib/hbide/qscintilla/SString.h
trunk/harbour/contrib/hbide/qscintilla/SVector.h
trunk/harbour/contrib/hbide/qscintilla/SciLexer.h
trunk/harbour/contrib/hbide/qscintilla/Scintilla.h
trunk/harbour/contrib/hbide/qscintilla/ScintillaBase.cpp
trunk/harbour/contrib/hbide/qscintilla/ScintillaBase.h
trunk/harbour/contrib/hbide/qscintilla/ScintillaWidget.h
trunk/harbour/contrib/hbide/qscintilla/SplitVector.h
trunk/harbour/contrib/hbide/qscintilla/Style.cpp
trunk/harbour/contrib/hbide/qscintilla/Style.h
trunk/harbour/contrib/hbide/qscintilla/StyleContext.cpp
trunk/harbour/contrib/hbide/qscintilla/StyleContext.h
trunk/harbour/contrib/hbide/qscintilla/UniConversion.cpp
trunk/ha

[Harbour] Re: OS/2: Harbour 14525 - hbqt

[Pritpal Bedi]

David Arturo Macias Corona wrote:
> 
> Pritpal:
> 
>  >Try changing idetools.prg#135:
> 
>  > oAct:setMenu( QMenu():new() )
>  >=>
>  > oAct:setMenu( QMenu():new( oAct ) )
> 
>  >I am not sure, but let's try.
> 
> I changed:
> 
>//DAVID: oAct:setMenu( QMenu():new() )
>oAct:setMenu( QMenu():new( oAct ) )
> 
> so line moved to 136
> 
> New GPF is:
> 
> -
> Exception c005 at address 0x1d15c37a
> 
>  Exception Code:C005
>  Exception Address:1D15C37A
>  EAX:02EF42BC  EBX:0008  ECX:  EDX:1D0ACC48
>  ESI:00A36B60  EDI:02F3D3A4  EBP:0062FA08
>  CS:EIP:005B:1D15C37A  SS:ESP:0053:0062F9D0
>  DS:0053  ES:0053  FS:150B  GS:
>  Flags:00010202
> Called from QT_QMENU(0)
> Called from QMENU:NEW(0) in ../../../TQMenu.prg
> Called from IDETOOLSMANAGER:CREATE(136) in idetools.prg
> Called from HBIDE:CREATE(412) in hbide.prg
> Called from MAIN(102) in hbide.prg
> 
> Killed by SIGSEGV
> pid=0x004f ppid=0x004c tid=0x0001 slot=0x008f pri=0x0200 mc=0x0001
> E:\HARBOUR105\HARBOUR\CONTRIB\HBIDE\HBIDE.EXE
> QTGUI4 0:000bc37a
> cs:eip=005b:1d15c37a  ss:esp=0053:0062f9d0  ebp=0062fa08
>   ds=0053  es=0053  fs=150b  gs= efl=00010202
> eax=02ef42bc ebx=0008 ecx= edx=1d0acc48 edi=02f3d3a4 
> esi=00a36b60
> Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
> -
> 
> 
> Previous was:
> 
> Called from QACTION:SETMENU(0) in ../../../TQAction.prg
> Called from IDETOOLSMANAGER:CREATE(135) in idetools.prg
> 

My assertion was wrong.

QMenu():new() somehow is broken.

Can you try changing hbqt/qtgui/QMenu.cpp

HB_FUNC( QT_QMENU )
{
   QMenu * pObj = NULL;

   if( hb_pcount() >= 1 && HB_ISCHAR( 1 ) )
   {
  pObj =  new QMenu( hbqt_par_QString( 1 ), hbqt_par_QWidget( 2 ) ) ;
   }
   else
   {
  pObj =  new QMenu( hbqt_par_QWidget( 1 ) ) ;
   }

   hb_retptrGC( hbqt_gcAllocate_QMenu( ( void * ) pObj, true ) );
}


=>


HB_FUNC( QT_QMENU )
{
   QMenu * pObj = NULL;

   if( hb_pcount() >= 1 && HB_ISCHAR( 1 ) )
   {
  pObj =  new QMenu( hbqt_par_QString( 1 ), hbqt_par_QWidget( 2 ) ) ;
   }
   else if( hb_pcount() >= 1 && HB_ISPOINTER( 1 ) )
   {
  pObj =  new QMenu( hbqt_par_QWidget( 1 ) ) ;
   }
   else
   {
  pObj =  new QMenu() ;
   }

   hb_retptrGC( hbqt_gcAllocate_QMenu( ( void * ) pObj, true ) );
}

Also remove previous try. I hope it should work.

-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/OS-2-Harbour-14525-hbqt-tp5078729p5079677.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] hb_rexexlike and hb_regexhas not work

[Przemysław Czerpak]

On Thu, 20 May 2010, Adam Lubszczyk wrote:

Hi!

> Try sample:
> 
> FUNCTION main()
> LOCAL reg := hb_regexcomp(".*B.*")
> LOCAL cText := "ABC"
> LOCAL x
> ? hb_regexlike(reg,cText)
> ? hb_regexhas(reg,cText)
> IF VALTYPE(x:=hb_regex(reg,cText)) == "A" 
>? "FOUND:",x[1]
> ENDIF
> RETURN nil
> 
> Write: 
> .F.
> .F.
> FOUND: ABC
> Harbour ver: 2.1.0beta1 (Rev. 14520)
> hbpcre.lib ver: 8.02 2010-03-19

.T.
.T.
FOUND: ABC

So all is correct.
10 against 1 that you created the problem yourself by linking
application "manually" using wrong library order so the very
old PCRE library which is part of BCC CRTL used to emulate POSIX
regex is partially linked instead of HBPCRE.
Please use HBMK2.

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

[Harbour] Re: OS/2: Harbour 14525 - hbqt

[David Arturo Macias Corona]

Pritpal:

>Try changing idetools.prg#135:

> oAct:setMenu( QMenu():new() )
>=>
> oAct:setMenu( QMenu():new( oAct ) )

>I am not sure, but let's try.

I changed:

  //DAVID: oAct:setMenu( QMenu():new() )
  oAct:setMenu( QMenu():new( oAct ) )

so line moved to 136

New GPF is:

-
Exception c005 at address 0x1d15c37a

Exception Code:C005
Exception Address:1D15C37A
EAX:02EF42BC  EBX:0008  ECX:  EDX:1D0ACC48
ESI:00A36B60  EDI:02F3D3A4  EBP:0062FA08
CS:EIP:005B:1D15C37A  SS:ESP:0053:0062F9D0
DS:0053  ES:0053  FS:150B  GS:
Flags:00010202
Called from QT_QMENU(0)
Called from QMENU:NEW(0) in ../../../TQMenu.prg
Called from IDETOOLSMANAGER:CREATE(136) in idetools.prg
Called from HBIDE:CREATE(412) in hbide.prg
Called from MAIN(102) in hbide.prg

Killed by SIGSEGV
pid=0x004f ppid=0x004c tid=0x0001 slot=0x008f pri=0x0200 mc=0x0001
E:\HARBOUR105\HARBOUR\CONTRIB\HBIDE\HBIDE.EXE
QTGUI4 0:000bc37a
cs:eip=005b:1d15c37a  ss:esp=0053:0062f9d0  ebp=0062fa08
 ds=0053  es=0053  fs=150b  gs= efl=00010202
eax=02ef42bc ebx=0008 ecx= edx=1d0acc48 edi=02f3d3a4 
esi=00a36b60

Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
-


Previous was:

Called from QACTION:SETMENU(0) in ../../../TQAction.prg
Called from IDETOOLSMANAGER:CREATE(135) in idetools.prg

David Macias



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

[Harbour] hb_rexexlike and hb_regexhas not work

[Adam Lubszczyk]

Hi!
Try sample:

FUNCTION main()
LOCAL reg := hb_regexcomp(".*B.*")
LOCAL cText := "ABC"
LOCAL x
? hb_regexlike(reg,cText)
? hb_regexhas(reg,cText)
IF VALTYPE(x:=hb_regex(reg,cText)) == "A" 
   ? "FOUND:",x[1]
ENDIF
RETURN nil

Write: 
.F.
.F.
FOUND: ABC

Harbour ver: 2.1.0beta1 (Rev. 14520)
hbpcre.lib ver: 8.02 2010-03-19

Adam
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/hb-rexexlike-and-hb-regexhas-not-work-tp5079453p5079453.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: hbMK2 - Command Line vs hbIDE - difference

[Pritpal Bedi]

Viktor Szakáts wrote:
> 
> Thanks, it seems mingw is sensitive to ending pathseps 
> in -I options. Pls retry with r14535.
> 

Now works fine after r14535, thanks.




-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/hbMK2-Command-Line-vs-hbIDE-difference-tp5078595p5079444.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] hbMK2 - Command Line vs hbIDE - difference

[Viktor Szakáts]

Hi Prital,

Thanks, it seems mingw is sensitive to ending pathseps 
in -I options. Pls retry with r14535.

Viktor

On 2010 May 20, at 09:46, Pritpal Bedi wrote:

> 
> Hello Viktor
> 
> I defined QScintilla ( greatly trimmed ) library project from hbIDE 
> and could build the library properly. Then I tried the same .hbp from 
> command line. Below are the results for one of the files:
> 
> hbMK2 direct from command line:
> ---
> hbmk2: Compiling C++...
> hbmk2: C/C++ compiler command:
> g++.exe -c -O3 -march=i586 -mtune=pentiumpro -fomit-frame-pointer  -W -Wall
> -pipe -IC:/harbour_dev/harbour/mingw/include -I./ -Iqt -IC:/qt/4
> .6.2/qt/include -IC:/qt/4.6.2/qt/include/qtcore
> -IC:/qt/4.6.2/qt/include/qtgui -IC:/qt/4.6.2/qt/include/qtnetwork
> -I../../hbqt qt/ListBoxQt.
> cpp -o .hbmk/win/mingw/ListBoxQt.o
> In file included from qt/ListBoxQt.cpp:32:
> qt/ListBoxQt.h:36:22: error: Platform.h: No such file or directory
> 
> 
> hbIDE executing same .hbp
> --
> hbmk2: Compiling C++...
> hbmk2: C/C++ compiler command:
> g++.exe -c -O3 -march=i586 -mtune=pentiumpro -fomit-frame-pointer -W -Wall
> -pipe -IC:/harbour_dev/harbour/mingw/include
> -IC:/harbour/contrib/hbide/qscintilla
> -IC:/harbour/contrib/hbide/qscintilla/qt -IC:/qt/4.6.2/qt/include
> -IC:/qt/4.6.2/qt/include/qtcore -IC:/qt/4.6.2/qt/include/qtgui
> -IC:/qt/4.6.2/qt/include/qtnetwork -IC:/harbour/contrib/hbqt
> C:/harbour/contrib/hbide/qscintilla/qt/ListBoxQt.cpp -o
> C:/harbour/contrib/hbide/qscintilla/.hbmk/win/mingw/ListBoxQt.o
> 
> 
> Here is QScintilla.hbp
> 
> -3rd=hbide_version=1.0
> -3rd=hbide_type=Lib
> -3rd=hbide_title=qscintilla
> -3rd=hbide_location=C:\harbour\contrib\hbide\qscintilla\
> -3rd=hbide_workingfolder=
> -3rd=hbide_destinationfolder=
> -3rd=hbide_output=qscintilla
> -3rd=hbide_launchparams=
> -3rd=hbide_launchprogram=
> -3rd=hbide_backupfolder=
> -3rd=hbide_xhb=NO
> -3rd=hbide_xpp=NO
> -3rd=hbide_clp=NO
> 
> -inc
> -w2
> -es2
> -incpath=.
> -incpath=./qt
> -incpath=${HB_WITH_QT}/include
> -incpath=${HB_WITH_QT}/include/qtcore
> -incpath=${HB_WITH_QT}/include/qtgui
> -incpath=${HB_WITH_QT}/include/qtnetwork
> -oqscintilla
> 
> ../../hbqt/hbqt.hbc
> AutoComplete.cpp
> CallTip.cpp
> Decoration.cpp
> Document.cpp
> DocumentAccessor.cpp
> Editor.cpp
> ExternalLexer.cpp
> Indicator.cpp
> KeyMap.cpp
> KeyWords.cpp
> LexCPP.cpp
> LexFlagship.cpp
> LineMarker.cpp
> CellBuffer.cpp
> CharClassify.cpp
> ContractionState.cpp
> PerLine.cpp
> PositionCache.cpp
> PropSet.cpp
> RESearch.cpp
> RunStyles.cpp
> ScintillaBase.cpp
> Style.cpp
> StyleContext.cpp
> UniConversion.cpp
> ViewStyle.cpp
> WindowAccessor.cpp
> XPM.cpp
> qt/ListBoxQt.cpp
> qt/moc_qscilexer.cpp
> qt/moc_qscilexercpp.cpp
> qt/moc_qsciscintilla.cpp
> qt/moc_qsciscintillabase.cpp
> qt/moc_SciClasses.cpp
> qt/PlatQt.cpp
> qt/qsciabstractapis.cpp
> qt/qsciapis.cpp
> qt/qscicommand.cpp
> qt/qscicommandset.cpp
> qt/qscidocument.cpp
> qt/qscilexer.cpp
> qt/qscilexercpp.cpp
> qt/qscimacro.cpp
> qt/qsciprinter.cpp
> qt/qsciscintilla.cpp
> qt/qsciscintillabase.cpp
> qt/qscistyle.cpp
> qt/qscistyledtext.cpp
> qt/SciClasses.cpp
> qt/ScintillaQt.cpp
> 
> 
> 
> 
> -
> enjoy hbIDEing...
>Pritpal Bedi 
> http://hbide.vouch.info/
> -- 
> View this message in context: 
> http://harbour-devel.1590103.n2.nabble.com/hbMK2-Command-Line-vs-hbIDE-difference-tp5078595p5078595.html
> Sent from the harbour-devel mailing list archive at Nabble.com.
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour

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

Re: [Harbour] SF.net SVN: harbour-project:[14518]

[Viktor Szakáts]

> 
> 
>> Though for this to be true the editor is best to support
>> moving past EOL. Something which is not supported
>> by HBIDE and several other editors (f.e. vi, MSVS).
> 
> I had just found recently how to set it in MSVS2005:
> Tools | Options | Text Editor | All Languages (or just the lang you want)
> There is the checkbox which the cryptic name "Enable virtual space"
> when checked it allow you to freely move the keyboard cursor.
> 
> 

Oh indeed, it works (tried in MSVS 2010).
Thanks Chen.

Viktor

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

[Harbour] Re: OS/2: Harbour 14525 - hbqt

[Pritpal Bedi]

David Arturo Macias Corona wrote:
> 
> hbide build fine
> Running hbide.exe GPF as before with:
> 
> -
> Exception c005 at address 0x1ddd69ca
> 
>  Exception Code:C005
>  Exception Address:1DDD69CA
>  EAX:0001  EBX:02F3D39C  ECX:02F3D3A4  EDX:0001
>  ESI:  EDI:  EBP:0062FBB8
>  CS:EIP:005B:1DDD69CA  SS:ESP:0053:0062FBA0
>  DS:0053  ES:0053  FS:150B  GS:
>  Flags:00010246
> Called from QACTION:SETMENU(0) in ../../../TQAction.prg
> Called from IDETOOLSMANAGER:CREATE(135) in idetools.prg
> Called from HBIDE:CREATE(412) in hbide.prg
> Called from MAIN(102) in hbide.prg
> 
> Killed by SIGSEGV
> pid=0x81c9 ppid=0x00ad tid=0x0001 slot=0x00c4 pri=0x0200 mc=0x0001
> E:\HARBOUR105\HARBOUR\CONTRIB\HBIDE\HBIDE.EXE
> LIBC063 0:000669ca
> cs:eip=005b:1ddd69ca  ss:esp=0053:0062fba0  ebp=0062fbb8
>   ds=0053  es=0053  fs=150b  gs= efl=00010246
> eax=0001 ebx=02f3d39c ecx=02f3d3a4 edx=0001 edi= 
> esi=
> Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
> -
> 
> Any hint to continue tests ?
> 

Try changing idetools.prg#135:

 oAct:setMenu( QMenu():new() ) 
=> 
 oAct:setMenu( QMenu():new( oAct ) )

I am not sure, but let's try.


-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/OS-2-Harbour-14525-hbqt-tp5078729p5079370.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] file path delimiter

[sali]

- Original Message - 
From: "Viktor Szakáts" 

To: "Harbour Project Main Developer List." 
Sent: Thursday, May 20, 2010 1:55 PM
Subject: Re: [Harbour] file path delimiter



The only thing some may wonder is why such workaround
is good for you, when you can get much better coverage
for the problem by adding 1-2 lines of .prg code. You can


thnx, i shall try

it is a good info that there is a solution, and i have not to search/replace 
the whole code base looking for implicit and explicit back-slash '\'



___
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:[14518]

[Chen Kedem]

Viktor ,



> Though for this to be true the editor is best to support
> moving past EOL. Something which is not supported
> by HBIDE and several other editors (f.e. vi, MSVS).

I had just found recently how to set it in MSVS2005:
Tools | Options | Text Editor | All Languages (or just the lang you want)
There is the checkbox which the cryptic name "Enable virtual space"
when checked it allow you to freely move the keyboard cursor.



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

Re: [Harbour] file path delimiter

[Viktor Szakáts]

>>> use <(db)> => dbusearea(,,linux(<(db)>),...)
>> 
>> Such modification is still only workaround for the problem which
>> is hardcoded in some other place. You should switch to "/" or use
>> hb_osPathSeparator() if you want to eliminate any filename conversions.
> 
> yes, unfortunately it is just a workaround, but its advance is that, once 
> developed, is immediately applicable to all other, yet not ported apps

The only thing some may wonder is why such workaround 
is good for you, when you can get much better coverage 
for the problem by adding 1-2 lines of .prg code. You can 
add it even in a new .prg as INIT PROC and simply link 
it to your app, so only the make file have to changed by 
adding this one new .prg.

Viktor

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

Re: [Harbour] file path delimiter

[sali]

- Original Message - 
From: "Przemysław Czerpak" 

To: "Harbour Project Main Developer List." 
Sent: Thursday, May 20, 2010 1:16 PM
Subject: Re: [Harbour] file path delimiter



use <(db)> => dbusearea(,,linux(<(db)>),...)


Such modification is still only workaround for the problem which
is hardcoded in some other place. You should switch to "/" or use
hb_osPathSeparator() if you want to eliminate any filename conversions.


yes, unfortunately it is just a workaround, but its advance is that, once 
developed, is immediately applicable to all other, yet not ported apps


thnx


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

[vszakats]

Revision: 14535
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14535&view=rev
Author:   vszakats
Date: 2010-05-20 11:40:30 + (Thu, 20 May 2010)

Log Message:
---
2010-05-20 13:40 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * utils/hbmk2/hbmk2.prg
! Fixed to ignore .cpp files in main entry detection function.
! Fixed to strip ending pathsep in header and lib path options 
  passed to compiler tools.

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


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

Re: [Harbour] file path delimiter

[Przemysław Czerpak]

On Thu, 20 May 2010, sali wrote:

Hi,

> >>my second thought is to tweak at pp-level
> >Everything what can be done on PP level can also be done in source
> >code so there is no reason to make such things on PP level.
> thnx for the tips
> just to explain, regarding pp, of course that it can be done in
> source, but tweaking pp, i may have prg source totaly  untouched
> [which is important to keep application compatibility, no need for
> additional quality testing]
> like this part replacing std.ch
> ...
> use <(db)> => dbusearea(,,linux(<(db)>),...)
> ...

Such modification is still only workaround for the problem which
is hardcoded in some other place. You should switch to "/" or use
hb_osPathSeparator() if you want to eliminate any filename conversions.

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

Re: [Harbour] file path delimiter

[sali]

- Original Message - 
From: "Przemysław Czerpak" 

To: "Harbour Project Main Developer List." 
Sent: Thursday, May 20, 2010 12:17 PM
Subject: Re: [Harbour] file path delimiter



my second thought is to tweak at pp-level


Everything what can be done on PP level can also be done in source
code so there is no reason to make such things on PP level.


thnx for the tips

just to explain, regarding pp, of course that it can be done in source, but 
tweaking pp, i may have prg source totaly  untouched [which is important to 
keep application compatibility, no need for additional quality testing]

like this part replacing std.ch

...
use <(db)> => dbusearea(,,linux(<(db)>),...)
...

and with 'clipper -u xx.ch' i may have just a few required definitions 
altered


so this additional function 'linux()' may at run-time adjust 
db-open-filename string
internaly, 'linux()' function may each time check the platform and adjust if 
neccessary

or check only the first time, and later just use the static status

thnx again

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

Re: [Harbour] file path delimiter

[Przemysław Czerpak]

On Thu, 20 May 2010, sali wrote:

Hi,

> porting big app from clipper/win to harbour/linux, and having lot of
> hard-coded and/or composed file/index paths with back-slash '\' embedded
> is there some 'set' setting to at 'run-time-level' replace [convert]
> windows-style '\' to linux-style '/' paths
> directly changing source is not an option,

It's always the best option.
"/" as path separator works in all systems.

> my second thought is to tweak at pp-level

Everything what can be done on PP level can also be done in source
code so there is no reason to make such things on PP level.

> any suggestion?

   SET( _SET_DIRSEPARATOR, "\" )

makes what you need inside Harbour code but please remember that if
you pass some parameters to externally executed commands then you
should make conversion to native OS directory separator.
You may also have similar problems with file case. In *nixes file
systems are case sensitive.

   SET( _SET_FILECASE, "LOWER" | "UPPER" | "MIXED" )
   SET( _SET_DIRCASE, "LOWER" | "UPPER" | "MIXED" )

can be used to enable (disable) conversions arbitrary conversions
of all file/dir names used inside Harbour code.

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

[vszakats]

Revision: 14534
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14534&view=rev
Author:   vszakats
Date: 2010-05-20 09:40:08 + (Thu, 20 May 2010)

Log Message:
---
2010-05-20 11:39 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
  * include/hbthread.h
! Added missing HB_EXPORT, and in some place 'extern'
  qualifier to thread/atomic Harbour API declarations.

  * ChangeLog
! Fixed entry header in previous commit (again).

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


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

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

[vszakats]

Revision: 14533
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14533&view=rev
Author:   vszakats
Date: 2010-05-20 09:35:08 + (Thu, 20 May 2010)

Log Message:
---
2010-05-20 11:21 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * utils/hbmk2/hbmk2.prg
+ Added hbmk2 level support for multiple input .def files.
  NOTE: Multiple .def files are only supported by gcc family
compilers (mingw/cygwin) (and maybe watcom, but I can't 
tell by looking at the output), so for portable scripts,
stick to using only one .def file per .dll. bcc,
msvc, pocc will either ignore some of them, or
stop with error.

  * ChangeLog
- Deleted accented (UTF8) char.
! Deleted UTF8 file marked added by subsequent committer's editor.

; --- Pls remember to use ASCII 7-bit chars in our files ---

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


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

[Harbour] file path delimiter

[sali]

hi,

porting big app from clipper/win to harbour/linux, and having lot of
hard-coded and/or composed file/index paths with back-slash '\' embedded
is there some 'set' setting to at 'run-time-level' replace [convert]
windows-style '\' to linux-style '/' paths

directly changing source is not an option, my second thought is to tweak at
pp-level

any suggestion?

thnx!


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

[Harbour] OS/2: Harbour 14525 - hbqt

[David Arturo Macias Corona]

Pritpal:

hbqt* libraries build fine

*** Now using official release of Qt462 for OS/2 ***

Errors are basically same reported before for Harbour 14433


demoqt build / run fine but with GPF closing dialogs/windows


hbide build fine
Running hbide.exe GPF as before with:

-
Exception c005 at address 0x1ddd69ca

Exception Code:C005
Exception Address:1DDD69CA
EAX:0001  EBX:02F3D39C  ECX:02F3D3A4  EDX:0001
ESI:  EDI:  EBP:0062FBB8
CS:EIP:005B:1DDD69CA  SS:ESP:0053:0062FBA0
DS:0053  ES:0053  FS:150B  GS:
Flags:00010246
Called from QACTION:SETMENU(0) in ../../../TQAction.prg
Called from IDETOOLSMANAGER:CREATE(135) in idetools.prg
Called from HBIDE:CREATE(412) in hbide.prg
Called from MAIN(102) in hbide.prg

Killed by SIGSEGV
pid=0x81c9 ppid=0x00ad tid=0x0001 slot=0x00c4 pri=0x0200 mc=0x0001
E:\HARBOUR105\HARBOUR\CONTRIB\HBIDE\HBIDE.EXE
LIBC063 0:000669ca
cs:eip=005b:1ddd69ca  ss:esp=0053:0062fba0  ebp=0062fbb8
 ds=0053  es=0053  fs=150b  gs= efl=00010246
eax=0001 ebx=02f3d39c ecx=02f3d3a4 edx=0001 edi= 
esi=

Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
-

Any hint to continue tests ?



demoxbp build fine but running it GPF with:

-
Exception c005 at address 0x1dd569ca

Exception Code:C005
Exception Address:1DD569CA
EAX:0001  EBX:02A9BFB4  ECX:02A9BFBC  EDX:0001
ESI:  EDI:02A9BF7C  EBP:003AF728
CS:EIP:005B:1DD569CA  SS:ESP:0053:003AF710
DS:0053  ES:0053  FS:150B  GS:
Flags:00010246
Called from QPIXMAP:SCALED(0) in ../../../TQPixmap.prg
Called from XBPSTATUSBAR:SETPOINTER(0) in ../../../xbpwindow.prg
Called from BUILD_STATUSBAR(508) in demoxbp.prg
Called from BUILDADIALOG(158) in demoxbp.prg
Called from _BUILDADIALOG(107) in demoxbp.prg
Called from MAIN(98) in demoxbp.prg

Killed by SIGSEGV
pid=0x007d ppid=0x005a tid=0x0001 slot=0x00b4 pri=0x0200 mc=0x0001
E:\HARBOUR105\HARBOUR\CONTRIB\HBXBP\TESTS\DEMOXBP.EXE
LIBC063 0:000669ca
cs:eip=005b:1dd569ca  ss:esp=0053:003af710  ebp=003af728
 ds=0053  es=0053  fs=150b  gs= efl=00010246
eax=0001 ebx=02a9bfb4 ecx=02a9bfbc edx=0001 edi=02a9bf7c 
esi=

Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
-

David Macias


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

[Harbour] OS/2: Harbour 14525

[David Arturo Macias Corona]

Now tested with:

 * $Id: ChangeLog 14525 2010-05-19 02:09:52Z vouchcac $
 2010-05-18 18:55 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)


Harbour build/run entirely with
- os2gcc442omf
- os2gcc335aout
- OpenWatcom

Most significative warning is in os2gcc*:

../../../ioapi.c: In function 'fopen64_file_func':
../../../ioapi.c:122: warning: assignment makes pointer from integer 
without a cast


David Macias


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

Re: [Harbour] Question about Curl detection during compile process

[smu johnson]

Thanks Viktor.  Your knowledge of Clipper and Harbour is impressive!

On Thu, May 20, 2010 at 12:55 AM, Viktor Szakáts wrote:

> > # looks like a problem
> > hbmk2: Warning: Source dynamic library not found:
>  /ver10/curl-7.20.1-devel-mingw32/include/../libcurl.dll
> >
> > # looks like it worked?
> > hbmk2: Created import library: G:/harbour/lib/win/mingw/liblibcurl.a <=
>  /ver10/curl-7.20.1-devel-mingw32/include/../bin/libcurl.dll
>
> It's normal. There are multiple places Harbour
> will look for the .dll.
>
> Viktor
>
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>



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

Re: [Harbour] Question about Curl detection during compile process

[Viktor Szakáts]

> # looks like a problem
> hbmk2: Warning: Source dynamic library not found:
> /ver10/curl-7.20.1-devel-mingw32/include/../libcurl.dll
> 
> # looks like it worked?
> hbmk2: Created import library: G:/harbour/lib/win/mingw/liblibcurl.a <=   
>  /ver10/curl-7.20.1-devel-mingw32/include/../bin/libcurl.dll

It's normal. There are multiple places Harbour 
will look for the .dll.

Viktor

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

RE: [Harbour] New page in PDF file with cairo.

[Horodyski Marek (PZUZ)]

> -Original Message-
> From: Mindaugas Kavaliauskas [mailto:dbto...@dbtopas.lt]
> Sent: Wednesday, May 19, 2010 9:00 PM
> To: Harbour Project Main Developer List.
> Subject: Re: [Harbour] New page in PDF file with cairo.
> 
> Hi,
> 
> 
> On 2010.05.19 19:40, Horodyski Marek (PZUZ) wrote:
> > In c:\harbour\contrib\hbhpdf\ is class :
> >
> > pdf := HPDF_New()
> >
> > and in this class is :
> > page   := HPDF_AddPage( pdf)
> >
> > Cairo is nice, but in cairo we are do not can make this (adds page).
> 
> Why not to look at lightning.prg that produces 20 pages pdf file.


He struck me by lightning and had not noticed :)

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

[Harbour] hbMK2 - Command Line vs hbIDE - difference

[Pritpal Bedi]

Hello Viktor

I defined QScintilla ( greatly trimmed ) library project from hbIDE 
and could build the library properly. Then I tried the same .hbp from 
command line. Below are the results for one of the files:

hbMK2 direct from command line:
---
hbmk2: Compiling C++...
hbmk2: C/C++ compiler command:
g++.exe -c -O3 -march=i586 -mtune=pentiumpro -fomit-frame-pointer  -W -Wall
-pipe -IC:/harbour_dev/harbour/mingw/include -I./ -Iqt -IC:/qt/4
.6.2/qt/include -IC:/qt/4.6.2/qt/include/qtcore
-IC:/qt/4.6.2/qt/include/qtgui -IC:/qt/4.6.2/qt/include/qtnetwork
-I../../hbqt qt/ListBoxQt.
cpp -o .hbmk/win/mingw/ListBoxQt.o
In file included from qt/ListBoxQt.cpp:32:
qt/ListBoxQt.h:36:22: error: Platform.h: No such file or directory


hbIDE executing same .hbp
--
hbmk2: Compiling C++...
hbmk2: C/C++ compiler command:
g++.exe -c -O3 -march=i586 -mtune=pentiumpro -fomit-frame-pointer -W -Wall
-pipe -IC:/harbour_dev/harbour/mingw/include
-IC:/harbour/contrib/hbide/qscintilla
-IC:/harbour/contrib/hbide/qscintilla/qt -IC:/qt/4.6.2/qt/include
-IC:/qt/4.6.2/qt/include/qtcore -IC:/qt/4.6.2/qt/include/qtgui
-IC:/qt/4.6.2/qt/include/qtnetwork -IC:/harbour/contrib/hbqt
C:/harbour/contrib/hbide/qscintilla/qt/ListBoxQt.cpp -o
C:/harbour/contrib/hbide/qscintilla/.hbmk/win/mingw/ListBoxQt.o


Here is QScintilla.hbp

-3rd=hbide_version=1.0
-3rd=hbide_type=Lib
-3rd=hbide_title=qscintilla
-3rd=hbide_location=C:\harbour\contrib\hbide\qscintilla\
-3rd=hbide_workingfolder=
-3rd=hbide_destinationfolder=
-3rd=hbide_output=qscintilla
-3rd=hbide_launchparams=
-3rd=hbide_launchprogram=
-3rd=hbide_backupfolder=
-3rd=hbide_xhb=NO
-3rd=hbide_xpp=NO
-3rd=hbide_clp=NO
 
-inc
-w2
-es2
-incpath=.
-incpath=./qt
-incpath=${HB_WITH_QT}/include
-incpath=${HB_WITH_QT}/include/qtcore
-incpath=${HB_WITH_QT}/include/qtgui
-incpath=${HB_WITH_QT}/include/qtnetwork
-oqscintilla
 
../../hbqt/hbqt.hbc
AutoComplete.cpp
CallTip.cpp
Decoration.cpp
Document.cpp
DocumentAccessor.cpp
Editor.cpp
ExternalLexer.cpp
Indicator.cpp
KeyMap.cpp
KeyWords.cpp
LexCPP.cpp
LexFlagship.cpp
LineMarker.cpp
CellBuffer.cpp
CharClassify.cpp
ContractionState.cpp
PerLine.cpp
PositionCache.cpp
PropSet.cpp
RESearch.cpp
RunStyles.cpp
ScintillaBase.cpp
Style.cpp
StyleContext.cpp
UniConversion.cpp
ViewStyle.cpp
WindowAccessor.cpp
XPM.cpp
qt/ListBoxQt.cpp
qt/moc_qscilexer.cpp
qt/moc_qscilexercpp.cpp
qt/moc_qsciscintilla.cpp
qt/moc_qsciscintillabase.cpp
qt/moc_SciClasses.cpp
qt/PlatQt.cpp
qt/qsciabstractapis.cpp
qt/qsciapis.cpp
qt/qscicommand.cpp
qt/qscicommandset.cpp
qt/qscidocument.cpp
qt/qscilexer.cpp
qt/qscilexercpp.cpp
qt/qscimacro.cpp
qt/qsciprinter.cpp
qt/qsciscintilla.cpp
qt/qsciscintillabase.cpp
qt/qscistyle.cpp
qt/qscistyledtext.cpp
qt/SciClasses.cpp
qt/ScintillaQt.cpp
 



-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/hbMK2-Command-Line-vs-hbIDE-difference-tp5078595p5078595.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: hbIDE - http://hbide.vouch.info/ - Needed your Reviews

[Pritpal Bedi]

Antonio Maniero wrote:
> 
>> I will try but for now I can't run HbIDE. Do you have a clue?
> ---
> Run-time Error!
> ---
> Error BASE/1005  Message not found: XBPTABWIDGET:_QCORNERWIDGET
> Called from __ERRRT_SBASE(0)
> Called from XBPTABWIDGET:ERROR(0)
> Called from (b)HBOBJECT(0)
> Called from XBPTABWIDGET:MSGNOTFOUND(0)
> Called from XBPTABWIDGET:_QCORNERWIDGET(0)
> Called from IDEDOCKS:BUILDVIEWWIDGET(459)
> Called from IDEDOCKS:BUILDDIALOG(250)
> Called from HBIDE:CREATE(408)
> Called from MAIN(102)
> ---
> OK
> ---
> 
> I just do a clean full build to R14532.
> 

Something is not proper on your machine if you did 
clean build of Harbour at r14532. Try building only hbXBP.
If it does not solve, then update afresh from SVN.
Above error shows that you have older xbptabpage.prg.


>  BTW, FYI
> i just read these pages:
> http://nickgravgaard.com/elastictabstops/
>  
>
> http://www.instantfundas.com/2009/10/minimap-plugin-for-visual-studio-jedit.html
>
>
> First is based on Jave applet and so out of implementation.
>

???


Later realized it is not what I got with quick look.



-
 enjoy hbIDEing...
Pritpal Bedi 
http://hbide.vouch.info/
-- 
View this message in context: 
http://harbour-devel.1590103.n2.nabble.com/hbIDE-http-hbide-vouch-info-Needed-your-Reviews-tp4925834p5078425.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