date:20100312

Hi Antonio,

 I need to modify behavior a function. I use the next code... but is a bit
 ugly... something alternative ?
 Anything future inconveniences ?

Use MY_ORDLISTADD() for your own stub and leave ORDLISTADD() as is, 
then add #xtranslate ORDLISTADD(x,...) = MY_ORDLISTADD(x) to 
your app header. You can add such header with -u+myheader.ch 
compiler switch, or just #include it in every .prg.

It's never a safe or good practice to create wrapper with 
original name but different behavior in real applications.

[ Moreover, you have to carefully check the licensing 
issues and requirements when including modified Harbour 
source code in your closed-source application. ]

Brgds,
Viktor

 Regards
 
 INI CODE 
 //-/
 /
 FUNCTION OrdListAdd(cPathFile)
 Local cPathDbf
 Local cPathFile2:= cPathFile
 Local cNtx
 *
 cPathDbf:= PathFile( DbInfo(DBI_FULLPATH) )
 cNtx:= FileNoPath(cPathFile)
 cPathFile2:= cPathDbf+ \+ cNtx
 RETURN ORDLISTADDBIS(cPathFile2)
 *
 *
 *
 #IFDEF __HARBOUR__
   #IFNDEF __XHARBOUR__
  #PRAGMA BEGINDUMP
 #include hbapi.h
 #include hbapirdd.h
 #include hbapierr.h
 #include hbapiitm.h
 #include hbvm.h
 #include hbset.h
 HB_FUNC( ORDLISTADDBIS )
 {
AREAP pArea = ( AREAP ) hb_rddGetCurrentWorkAreaPointer();
if( pArea )
{
   DBORDERINFO pOrderInfo;
   HB_ERRCODE errCode;
   /* Clipper clears NETERR flag when index is open */
   hb_rddSetNetErr( FALSE );
   memset( pOrderInfo, 0, sizeof( DBORDERINFO ) );
   pOrderInfo.atomBagName = hb_param( 1, HB_IT_STRING );
   pOrderInfo.itmOrder= hb_param( 2, HB_IT_STRING );
   if( !pOrderInfo.atomBagName )
   {
  if( ! HB_ISNIL( 1 ) )
 hb_errRT_DBCMD( EG_ARG, EDBCMD_ORDLSTADD_BADPARAMETER,
 NULL, HB_ERR_FUNCNAME );
  return;
   }
   pOrderInfo.itmResult = hb_itemNew( NULL );
   errCode = SELF_ORDLSTADD( pArea, pOrderInfo );
   if( !pOrderInfo.itmResult ||
 HB_IS_NIL( pOrderInfo.itmResult ) )
  hb_retl( errCode == HB_SUCCESS );
   else
  hb_itemReturn( pOrderInfo.itmResult );
   hb_itemRelease( pOrderInfo.itmResult );
}
else
   hb_errRT_DBCMD( EG_NOTABLE, EDBCMD_NOTABLE, NULL,
 HB_ERR_FUNCNAME );
 }
  #PRAGMA ENDDUMP
   #ELSE
  #PRAGMA BEGINDUMP
 #include hbapi.h
 #include hbapirdd.h
 #include hbapierr.h
 #include hbapiitm.h
 #include hbvm.h
 #include hbset.h
 HB_FUNC( ORDLISTADDBIS )
 {
HB_THREAD_STUB
AREAP pArea = ( AREAP ) hb_rddGetCurrentWorkAreaPointer();
if( pArea )
{
   DBORDERINFO pOrderInfo;
   ERRCODE errCode;
   /* Clipper clears NETERR flag when index is open */
   hb_rddSetNetErr( FALSE );
   memset( pOrderInfo, 0, sizeof( DBORDERINFO ) );
   pOrderInfo.atomBagName = hb_param( 1, HB_IT_STRING );
   pOrderInfo.itmOrder= hb_param( 2, HB_IT_STRING );
   if( !pOrderInfo.atomBagName )
   {
  if( !ISNIL( 1 ) )
 hb_errRT_DBCMD( EG_ARG, EDBCMD_ORDLSTADD_BADPARAMETER,
 NULL, ORDLISTADD );
  return;
   }
   pOrderInfo.itmResult = hb_itemNew( NULL );
   errCode = SELF_ORDLSTADD( pArea, pOrderInfo );
   if( !pOrderInfo.itmResult ||
 HB_IS_NIL( pOrderInfo.itmResult ) )
  hb_retl( errCode == SUCCESS );
   else
  hb_itemReturn( pOrderInfo.itmResult );
   hb_itemRelease( pOrderInfo.itmResult );
}
else
   hb_errRT_DBCMD( EG_NOTABLE, EDBCMD_NOTABLE, NULL,
 ORDLISTADD );
 }
  #PRAGMA ENDDUMP
   #ENDIF
 #ENDIF
 
 END CODE 
 
 
 
 ___
 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:[14143] trunk/harbour

2010-03-12 Thread vouchcac

Revision: 14143
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14143view=rev
Author:   vouchcac
Date: 2010-03-12 09:08:06 + (Fri, 12 Mar 2010)

Log Message:
---
2010-03-12 01:03 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * contrib/hbqt/hbqt_hbqplaintextedit.cpp
  * contrib/hbqt/hbqt_hbqplaintextedit.h
! Fixed behavior of book-marks. Now color representation 
  on bookmarked lines is persistent and consistent with 
  corresponding buttons in the statusbar.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.cpp
trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.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] Re: hbIDE - Let's review

2010-03-12 Thread Massimo Belgrano

2010/3/11 Pritpal Bedi bediprit...@hotmail.com

Massimo Belgrano wrote:

Unfinished the sub project/multi project implementation

Did you tried ?
IMO whatever is defined in .hbp is presented to hbMK2,
which has the capability of building sub-projects,
Viktor, update me on this issue.

I remember
http://www.mail-archive.com/harbour@harbour-project.org/msg21625.html
http://www.mail-archive.com/harbour@harbour-project.org/msg21625.html

visual define harbour/hbmk flag

Visual design is easy, but what should go inside,
I am not sure. Are you saying that all those flags,
placable in .hbp and forwarded on command-line be
fetched visually ? If yes, then I need someone to
provide me the list of all those flags, and the syntax
which must be verified.

I have proposted an array structure for collect
Dynamic defined wizard for visual define Flag like follow screenshot
starting from array/xml easy to define for hbide,harbour
{/a,automatic memvar}
{/w,warning level,{ {0,warning level0},{1,warning level1
default},{0,warning level0} } }
{/b,include debug info}
i can finish this array if in your opinion is good way
If contain 3 dimension need a combobox and third dimension is used for
validate
easy extend to other language

http://old.nabble.com/Re:-SF.net-SVN:-harbour-project:-14049--trunk-harbour-p27767006.html

User defined keyboard mapping and user menu

Yep, but it will be the last action. All other
publick actions needs to be known beforehand before
initiating this process. A must have... is on my TODO list.
Project tree require too many click
I have tried to simplify it and based on
folders, what other methodology you suggest ?

Having only opened project with his source (like xmate)
Open recent file under request /button

when i select a souce of project automatically select this project as
current

Understand that in hbIDE source editing and project management
are two separate actions. BTW what purpose will it solve ?

Be clear
what project be compiled

Made possible add documentation to harbour using hbide

I was waiting for Vailton's or Bacco's applications.
Ok, I will provide it here in hbIDE soon. Are anybody willing
to have embedded documentation in sources ? And for that
matter, such documentation will be pulled as prototypes are
pulled and presented in same way as Harbour help does.

Good

Simple keystroke for open harbour help (f1) and go to selected function

How do you want F1 to work ? Either of the two actions can be
carried out, open the help dialog and if current cursor is on some
Harbour function name, that is brought to focus. Right ?

mark breakpoint visual debug

I have least knowledge of debugger feature in Harbour.
Someone has to help me in this direction.
*
*

The capability are present in hbdebug.lib ,execute steep by
step, breakpoint,whatch point,Inspect variables,Inspect workarea (dbf) but
integrated in hbide to be more productive

i suggest see intresting
The xailer debugger
http://www.ciber-tec.com/xdebugeng.htm
http://www.ciber-tec.com/xdebugeng.htmThe xharbour.com debugger
http://www.xharbour.com/index.asp?page=products_addon_xdebugger
The visual studio debugger
http://www.startvbdotnet.com/forms/debug1.aspx

column mode in editor

This is the toughest part in hbIDE. In the past I have
failed on few tries. Still I do not know how to. Infact it needs
extended lines which I have no clues, how to in Qt.

extend intellisense capabillty

Please jot down all what should be there.
Prototype tooltip and functions completion is what I know
of, what others.

Follow are requested from other user that i have received via mail
is Possible use with xharbour or xbase++?

Yes, this is next logical step to make hbIDE more useful.
Anybody to help in this direction ?

will be xmate be a basic with clipper.env,xbase.env?

is possible use via command line for edit a project or a prg or rc?

I do not understand what you mean by command-line.
Once hbIDE is on, bring any source you want to edit, what is the issue.

Opening via command line as hbide test.hbp .or hbide test.prg
so hbide will be also registred to open hbp/prg

Is possible define the structure of file like fromfoxpro modi stru
command?
Integrate Dot prompt dbase functionaly

I need detailed analysis what you are asking here?
Dot prompt ( hbRUN.exe ) can be implemented though, I will try.

Good
Imo immediate windows is also usefull for debugging scope as in visual
studio
http://z.about.com/d/visualbasic/1/0/W/2/ecvbai0305-4.gif

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

Re: [Harbour] libgpm ?

In this case I am not using hbmk2 to compile

I am Using Marinas-ide

but I didn't find libgpm anymore in my path

Bruno

2010/3/12 marco bra marcobra.ubu...@gmail.com



 2010/3/10 Bruno Luciani bruno.luci...@gmail.com

 when I have installes libgpm-devel in linux UBUNTU

 Harbour detect it , and generates gttrm with GPM support , but generates a
 lib named libgpm.a  ??

 I saw it in any moment , but i don' t see anymore , and have problems
 compiling programs using gttrm

 But desinstaling libgpm-devel  now works ok but without GPM support


 this the error:

 /usr/local/lib/harbour/libgttrm.a(gttrm.o): In function
 `hb_gt_trm_mouse_Hide':

 gttrm.c:(.text+0x16e): undefined reference to `gpm_visiblepointer'

 /usr/local/lib/harbour/libgttrm.a(gttrm.o): In function
 `hb_gt_trm_mouse_Show':



 Have you already tried to add the  -lgpm

 hbmk2 -lgpm ...

 Hth

 ___
 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] libgpm ?

2010-03-12 Thread Massimo Belgrano

Hi Bruno
can you describe feature of marinas-ide and post (or wave me)  same
screen-shoot?
http://sourceforge.net/projects/marinas-ide/
http://sourceforge.net/projects/marinas-ide/

2010/3/12 Bruno Luciani bruno.luci...@gmail.com

 In this case I am not using hbmk2 to compile

 I am Using Marinas-ide

 but I didn't find libgpm anymore in my path

 Bruno



-- 
Massimo Belgrano

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

Re: [Harbour] GC Pointers - Anyway to detatch them ?

On Thu, 11 Mar 2010, Pritpal Bedi wrote:

Hi,

 I am looking for a solution where is GC pointer is
 detatched from freeing it, all other operations remaining 
 the same. 

You have to implement it.
Add to GC structure 'detached' member which will inform you destructor
code executed by our GC that it should not release the QT object.
QT Object should be 'detached' when they are attached to some other
objects and will be freed together with them.
I do not know the HBQT details but if possible I suggest to also clean
references to such object from GC pointer item so it will not be
longer accessible as stand alone object (it's enough to set NULL/0
to object pointer in GC block).

 It is possible that I am not been able to explain what I need properly.
 
 In hbQT we are been unable to know, at certain points, when 
 Qt releases the pointer. As per inherent nature of pointers
 C or C++ does not set the value of pointer variable to NULL.

???
Sorry but this suggests that some code is broken or wrongly casted
and has to be fixed. You have to isolate such places to check where
exactly the problem appears to eliminate similar situations in the
future and of course fix them.
I do not understand current HBQT code so I cannot help in details.
Looks that you are using 'QPointer pq' only as some type of dummy
pointer which protects against multiple call to 'delete' operator
in GC pointer item destructor but it's not used at all to resolve
the main problem and blocking access to freed object for all other
code.
I also do not see any protection against wrong object casting and
raw pointer items are accepted what effectively blocks any serious
cleanups. Few months ago I sent code example which adds such protection
to this list.
You cannot make code which is only partially safe. It will never work
correctly. It has to be fully safe or it is extremely hard to locate
real sources of problems. I.e. due to unprotected ph member of
QGC_POINTER you can encapsulate pointer to some freed object in
hb_gcAlloc() block and return it to PRG code as GC pointer item.
From the beginning it's wrong pointer so it will has to fail inside
GC release operation so you are looking for workarounds inside GC
pointer item destructors when in fact they do not create any problems.
The code is growing up and the number of potential problems is also
increased and it's harder to fully follow all internal dependencies.
Finally it's fighting with the ghosts. As long as the base things are
not really safe then resolving upper level problems seems to be waste
of time because no one can say what is the real source of problem.

 And hence when it is subject to freeing, GC does not 
 know if it has already been freed and hence GPF's.

Yes of course. Such situations are unacceptable and definitely
have to be fixed. Our GC have to be informed that some objects
were released. QPointer calls should make it.

 I have a mechanism in place where all delete operations 
 can be carried on as per Qt specs, I just want that the 
 pointer is not freeed in GC. It will only detatch GC from it 
 and will clear its stack.

Maybe I'm missing sth but seems that It will only hides the real bugs.
The easiest method is redirecting FREE message to dummy method which
does nothing. Functionally you will reach the same results. Memory leak
which eliminates the problem of accessing freed memory.

If you want to create really working solution then you have to start
from the beginning and fix the code using GC pointer items. If you need
sth like:

void * hbqt_gcpointer( int iParam )
{
   QGC_POINTER * p = ( QGC_POINTER * ) hb_parptrGC( hbqt_gcFuncs(), iParam );

   if( p  p-ph )
  return p-ph;
   else if( HB_ISPOINTER( iParam ) )
  return hb_parptr( iParam ); /* TOFIX: In what cases is this needed? 
Reference counting to avoid referring to freed pointers? */
   else
  return NULL; /* TODO: Still better if RTE. */
}

then it means that your code is wrong.
p-ph is not cleared when QT freese the object and:
   else if( HB_ISPOINTER( iParam ) )
  return hb_parptr( iParam );
means that you still have some completely unsafe pointer items
which can make memory corruptions and any create problems in any
other 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:[14144] trunk/harbour

Revision: 14144
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14144view=rev
Author:   vszakats
Date: 2010-03-12 10:42:29 + (Fri, 12 Mar 2010)

Log Message:
---
2010-03-12 11:39 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
  * utils/hbmk2/hbmk2.prg
+ Readded -pipe option for gcc (except djgpp) and icc/linux family
  compilers in a more sophisticated way. Now -pipe option is only
  used when hbmk2 controls the output filename, and in such case
  the output filename will always be deleted by hbmk2 if the
  C compiler returned error. This way -pipe can never leave
  faulty or dummy object files on disk, confusing incremental builds
  or just leaving trash behind. BTW, it'd be interesting to
  know why such seemingly buggy behavior hasn't been fixed in gcc
  in the last 6-7 years... (making -pipe option useless for Harbour 
  build process f.e.)

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] libgpm ?

Do you know QAC ?

it is a porting of it to HBQTCOMMAND

Bruno

2010/3/12 Massimo Belgrano mbelgr...@deltain.it

 Hi Bruno
 can you describe feature of marinas-ide and post (or wave me)  same
 screen-shoot?
 http://sourceforge.net/projects/marinas-ide/
 http://sourceforge.net/projects/marinas-ide/

 2010/3/12 Bruno Luciani bruno.luci...@gmail.com

 In this case I am not using hbmk2 to compile

 I am Using Marinas-ide

 but I didn't find libgpm anymore in my path

 Bruno



 --
 Massimo Belgrano

 e

 ___
 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] libgpm ?

On Fri, 12 Mar 2010, Bruno Luciani wrote:

Hi,

 In this case I am not using hbmk2 to compile
 I am Using Marinas-ide

So please always send such information so we can safely ignore
your messages instead of looking for not existing bugs in Harbour
code. I already verified GPM library settings in Harbour build
process and hbmk/hbmk2 settings.
Completely lost time :-(

 but I didn't find libgpm anymore in my path

so you haven't installed it in your system.
Please look at your system documentation/packages and install it.
It's not Harbour problem.

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

Re: [Harbour] libgpm ?

I have installed Libgpm-devel and I had to deinstall it
because , I don 't find libgpm  and this produce an error

Only answer my question

Exist a library named libgpm.a in harbour or not ?

because I don't find it

and , Marinas-ide use inside it Hbmk2

but what I try to say is that I am no using directly

Sorry about that

Bruno

2010/3/12 Przemysław Czerpak dru...@acn.waw.pl

 On Fri, 12 Mar 2010, Bruno Luciani wrote:

 Hi,

  In this case I am not using hbmk2 to compile
  I am Using Marinas-ide

 So please always send such information so we can safely ignore
 your messages instead of looking for not existing bugs in Harbour
 code. I already verified GPM library settings in Harbour build
 process and hbmk/hbmk2 settings.
 Completely lost time :-(

  but I didn't find libgpm anymore in my path

 so you haven't installed it in your system.
 Please look at your system documentation/packages and install it.
 It's not Harbour problem.

 best regards,
 Przemek
 ___
 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] libgpm ?

On Fri, 12 Mar 2010, Bruno Luciani wrote:
 I have installed Libgpm-devel and I had to deinstall it
 because , I don 't find libgpm  and this produce an error

But you haven't installed libgpm.

 Only answer my question
 Exist a library named libgpm.a in harbour or not ?
 because I don't find it

You will not find libgpm.{a,so} in Harbour.
It's system library. Again:
   Please look at your system documentation/packages and install it.

 and , Marinas-ide use inside it Hbmk2
 but what I try to say is that I am no using directly
 Sorry about that

You installed only devel package without base package breaking dependencies
and created above problem.

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

Re: [Harbour] libgpm ?

 I have installed Libgpm-devel and I had to deinstall it 
 because , I don 't find libgpm  and this produce an error
 
 Only answer my question
 
 Exist a library named libgpm.a in harbour or not ?
 
 because I don't find it
 
 and , Marinas-ide use inside it Hbmk2

This is not true. It's only used to build 
the IDE itself.

The IDE uses its own make engine.

Brgds,
Viktor

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

[Harbour] FT_FWRITELN or FT_FWRITEL ??

2010-03-12 Thread Jacek Kubica

Hi,

There is a difference in the name of function
betwen hbnf and original nanfor.lib (as far xharbour version)

This function is defined in w file /contrib/hbnf/fttext.c
 * $Id: fttext.c 13880 2010-02-15 14:12:56Z druzus $

 described as FT_FWRITELN
 
 * FT_FWRITELN()
 *  $CATEGORY$
 * File I/O
 *  $ONELINER$
 * Write a line to the currently selected text file
 *  $SYNTAX$
 *
 * FT_FWRITELN(  cData , [  lInsert  ] ) - lSuccess

 but defined as FT_FWRITEL  (without 'N' on the end)
  
 HB_FUNC( FT_FWRITEL )
 {
   const char * theData  = hb_parc( 1 );
   int  iDataLen = hb_parclen( 1 );
   int  lInsert  = hb_parl( 2 );
   int  err;

Is this intentional or  should be corrected ??

-- 
Best regards,
 Jacek Kubica


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

Re: [Harbour] libgpm ?

yes your are wright , my mystake

I am not the Marinas-Ide developer only a helper


Bruno


2010/3/12 Viktor Szakáts harbour...@syenar.hu

  I have installed Libgpm-devel and I had to deinstall it
  because , I don 't find libgpm  and this produce an error
 
  Only answer my question
 
  Exist a library named libgpm.a in harbour or not ?
 
  because I don't find it
 
  and , Marinas-ide use inside it Hbmk2

 This is not true. It's only used to build
 the IDE itself.

 The IDE uses its own make engine.

 Brgds,
 Viktor

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

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

Re: [Harbour] recommended C compiler for Win

Hi,

 Results in 64-bit mode using MSVC 2008 (same as 32-bit) 
 and mingw 4.4.4 20100129 (prerelease):
 mingw  msvc
 C++ 11.63
 C11.08
 mingw seems to be the winner here in default 
 Harbour builds, even though msvc had the advantage 
 of C++ mode.
 
 Finally I installed for tests GCC 4.5 (devel version)
 and in C++ mode with -flto it gives also better results
 then in C mode so it's potentially the fastest code.
 I have to say that I vary like how the meta code is
 implemented. Unlike other compilers GCC can be used
 with LTO without any complicated settings and programmer
 can easy control if he wants or not link time optimization
 using one link time switch.

Sounds good, I will try 4.5.0 a bit later.

 Plus, 64-bit mode has a clear advantage over 32-bit.
 
 I have similar results in Linux.
 64bit Harbour programs are faster then 32bit ones.
 
 I will make more tests, but it seems it's 
 worth switching to mingw also for 64-bit mode.
 
 The very strong thing in GCC is really good performance
 for different hardware. The optimization logic is not
 hardcoded to one processor family so it can be easy adopt
 to completely different CPUs. Anyhow I do not know what
 it the quality of Win64 GCC ports so here you will have
 to took the decision yourself. It's quite new port anyhow
 I think that in short time it should be very stable and
 efficient. 64big GCC ports for different *nixes have been
 existing for _very_ long time.

With some time investment I could build everything 
required for my local application using mingw64. 
In fact mingw support is starting to overtake the 
MSVC level for 3rd party libs, though there are still 
bugs in mingw Windows headers which have to be dealt 
with.

The only so far known problem is ignored -mwindows 
option when using mingw64 4.4.4, so app doesn't 
pop with GTWVT, with GTWIN it runs beautifully. 
I'm not sure if the problem is with Harbour or 
mingw64.

Binary size is just a bit larger than mingw 32-bit 
build (and still larger than msvc64).

Brgds,
Viktor

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

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

Revision: 14145
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14145view=rev
Author:   vszakats
Date: 2010-03-12 13:08:29 + (Fri, 12 Mar 2010)

Log Message:
---
2010-03-12 14:07 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
  * contrib/hbnf/fttext.c
+ Added FT_FWRITELN().
* Converted FT_FWRITEL() to be a wrapper for FT_FWRITELN().

  * contrib/hbxpp/thfuncx.prg
* Formatting.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbnf/fttext.c
trunk/harbour/contrib/hbxpp/thfuncx.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] recommended C compiler for Win

On Fri, 12 Mar 2010, Szak�ts Viktor wrote:

Hi,

 The only so far known problem is ignored -mwindows 
 option when using mingw64 4.4.4, so app doesn't 
 pop with GTWVT, with GTWIN it runs beautifully. 
 I'm not sure if the problem is with Harbour or 
 mingw64.

It sounds like an old issue.
If main() function is found in linked object files or
libraries then console application is created with main()
as startup entry. Otherwise windows application is created
with WinMain() startup entry. It's the reason why we created
separated libraries hbmainstd and hbmainwin with console and
GUI startup entries. It should be enough to chose the valid
one. I thought that hbmk2 does it.

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

Re: [Harbour] recommended C compiler for Win

Hi,

 The only so far known problem is ignored -mwindows 
 option when using mingw64 4.4.4, so app doesn't 
 pop with GTWVT, with GTWIN it runs beautifully. 
 I'm not sure if the problem is with Harbour or 
 mingw64.
 
 It sounds like an old issue.
 If main() function is found in linked object files or
 libraries then console application is created with main()
 as startup entry. Otherwise windows application is created
 with WinMain() startup entry. It's the reason why we created
 separated libraries hbmainstd and hbmainwin with console and
 GUI startup entries. It should be enough to chose the valid
 one. I thought that hbmk2 does it.

It does it for shared builds.

hbmk2 behaves the exact same for mingw and mingw64, 
yet it doesn't work for mingw64 and does for mingw.

So either it's just a coincidence that mingw works, 
and there is hbmk2 bug, or there is a difference 
in either in Harbour mingw64 builds or mingw64 
itself.

.c stub rightly issues hb_forceLinkMainWin() in 
both cases, which should be enough to pull WinMain().

If I try 'hbmk2 a.prg -shared', it works, but 
if I try 'hbmk2 a.prg -shared -gtwvt', it tells: 
  'Can't locate the starting procedure: 'MAIN''

Then just 'hbmk2 a.prg -gtwvt':
  'It's not a GUI program'

a.prg is:
---
FUNCTION MAIN()
ALERT( hello )
RETURN 0
---

Brgds,
Viktor

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

Re: [Harbour] recommended C compiler for Win

On Fri, 12 Mar 2010, Szak�ts Viktor wrote:

Hi,

 hbmk2 behaves the exact same for mingw and mingw64, 
 yet it doesn't work for mingw64 and does for mingw.

This problem was exploited in different MINGW version.
Not in all ones.
Seems that now HBMK2 is tuned only for some chosen MinGW
versions.

 So either it's just a coincidence that mingw works, 
 and there is hbmk2 bug, or there is a difference 
 in either in Harbour mingw64 builds or mingw64 
 itself.

I noticed differences between different mi...@32
releases so it's nothing amazing that they may
exist also between 32 and 64 bit MinGW versions.

 .c stub rightly issues hb_forceLinkMainWin() in 
 both cases, which should be enough to pull WinMain().

It not a problem of linking WinMain() but giving the
highest priority to main().

 If I try 'hbmk2 a.prg -shared', it works, but 
 if I try 'hbmk2 a.prg -shared -gtwvt', it tells: 
   'Can't locate the starting procedure: 'MAIN''

It means that using -gtwvt hbmk2 switch activates sth
what forces using MAIN() as startup entry. We only have
to locate what it is and fix it. For sure you cannot
pass hbmainstd as one of linked libraries because in such
case console application will be created.

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

Re: [Harbour] recommended C compiler for Win

2010-03-12 Thread Maurilio Longo

Przemyslaw,

could this issue explain some of my troubles the other day?

Maurilio.



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


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

Re: [Harbour] recommended C compiler for Win

Hi,

 hbmk2 behaves the exact same for mingw and mingw64, 
 yet it doesn't work for mingw64 and does for mingw.
 
 This problem was exploited in different MINGW version.
 Not in all ones.
 Seems that now HBMK2 is tuned only for some chosen MinGW
 versions.

There is nothing special done for mingw in hbmk2, 
it uses the .c stub along the same lines as hbmk 
script.

Command line is clean from tricks. The only 
special thing done is '-mwindows' option.

Here is the link command:
   x86_64-w64-mingw32-gcc.exe C:\Users\vszakats\AppData\Local\Temp\a.o 
C:\Users\vszakats\AppData\Local\Temp\hbmk_oiiufu.o-mwindows 
-Wl,--start-group -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage 
-lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd 
-lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro -lhbcplr 
-lhbpp -lhbcommon -lkernel32 -luser32 -lgdi32 -ladvapi32 -lws2_32 -lwinspool 
-lcomctl32 -lcomdlg32 -lshell32 -luuid -lole32 -loleaut32 -lmpr -lwinmm 
-lmapi32 -limm32 -lmsimg32 -lwininet -lhbpcre -lhbzlib  -Wl,--end-group -oa.exe 
-LF:/devl/hb20/lib/win/mingw64

 So either it's just a coincidence that mingw works, 
 and there is hbmk2 bug, or there is a difference 
 in either in Harbour mingw64 builds or mingw64 
 itself.
 
 I noticed differences between different mi...@32
 releases so it's nothing amazing that they may
 exist also between 32 and 64 bit MinGW versions.

Yes, it seems there is something here to deal with.

 .c stub rightly issues hb_forceLinkMainWin() in 
 both cases, which should be enough to pull WinMain().
 
 It not a problem of linking WinMain() but giving the
 highest priority to main().
 
 If I try 'hbmk2 a.prg -shared', it works, but 
 if I try 'hbmk2 a.prg -shared -gtwvt', it tells: 
  'Can't locate the starting procedure: 'MAIN''
 
 It means that using -gtwvt hbmk2 switch activates sth
 what forces using MAIN() as startup entry. We only have
 to locate what it is and fix it. For sure you cannot
 pass hbmainstd as one of linked libraries because in such
 case console application will be created.

The only difference is in .c stub content, here it is in 
diff form:
---

 HB_FUNC_EXTERN( MAIN );
+HB_FUNC_EXTERN( HB_GT_WVT );
+
+HB_EXTERN_BEGIN
+void hb_forceLinkMainWin( void );
+HB_EXTERN_END

 void _hb_lnk_ForceLink_hbmk2( void )
 {
HB_FUNC_EXEC( MAIN );
+   HB_FUNC_EXEC( HB_GT_WVT );
+
+   hb_forceLinkMainWin();
 }

 #include hbinit.h

 HB_CALL_ON_STARTUP_BEGIN( _hb_hbmk_setdef_ )
+   hb_vmSetDefaultGT( WVT );
hb_vmSetLinkedMain( MAIN );
 HB_CALL_ON_STARTUP_END( _hb_hbmk_setdef_ )
---

Does it show anything to you?

Brgds,
Viktor

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

[Harbour] Error with 14142

2010-03-12 Thread Rossine


Hello,

I see this errors with this release:

[ERROR]
Error E2451 ../../../filesys.c 331: Undefined symbol 'ulSize' in function
fs_win
_get_drive
*** 1 errors in Compile ***
mingw32-make[3]: *** [filesys.obj] Error 1
mingw32-make[2]: *** [descend] Error 2
mingw32-make[1]: *** [rtl.inst] Error 2
mingw32-make: *** [src.inst] Error 2
[ENDERROR]

Best Regards,

Rossine.

-- 
View this message in context: 
http://old.nabble.com/Error-with-14142-tp27875079p27875079.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

Re: [Harbour] Error with 14142

Hi,

 I see this errors with this release:
 
 [ERROR]
 Error E2451 ../../../filesys.c 331: Undefined symbol 'ulSize' in function
 fs_win
 _get_drive
 *** 1 errors in Compile ***
 mingw32-make[3]: *** [filesys.obj] Error 1
 mingw32-make[2]: *** [descend] Error 2
 mingw32-make[1]: *** [rtl.inst] Error 2
 mingw32-make: *** [src.inst] Error 2
 [ENDERROR]

Thanks, I'll commit the fix. Anyhow I'd suggest 
to try use default UNICODE build with UNICOWS 
solution.

1) Download static lib for your compiler from here:
  http://libunicows.sourceforge.net/
2) Add '-l{mingw|bcc|watcom}unicows' to your hbmk2 
   build script or command-line.
3) Download unicows.dll from here:
  http://go.microsoft.com/fwlink/?LinkId=14851

Brgds,
Viktor

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

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

Revision: 14146
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14146view=rev
Author:   vszakats
Date: 2010-03-12 15:00:19 + (Fri, 12 Mar 2010)

Log Message:
---
2010-03-12 15:59 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
  * src/rtl/filesys.c
! Fixed non-UNICODE code after recent get/set drive changes.
% Minor opt.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/src/rtl/filesys.c


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

[Harbour] Re: To modify behavior a function

2010-03-12 Thread Antonio Martinez

Vikthor,

It's never a safe or good practice to create wrapper with
original name but different behavior in real applications.
Ok !


[ Moreover, you have to carefully check the licensing
issues and requirements when including modified Harbour
source code in your closed-source application. ]
Ok !


THX. Regards



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

Re: [Harbour] Error with 14142

2010-03-12 Thread Rossine


Hi,

 I see this errors with this release:
 
 [ERROR]
 Error E2451 ../../../filesys.c 331: Undefined symbol 'ulSize' in function
 fs_win
 _get_drive
 *** 1 errors in Compile ***
 mingw32-make[3]: *** [filesys.obj] Error 1
 mingw32-make[2]: *** [descend] Error 2
 mingw32-make[1]: *** [rtl.inst] Error 2
 mingw32-make: *** [src.inst] Error 2
 [ENDERROR]

OK, work´s fine now :)

Thanks, I'll commit the fix. Anyhow I'd suggest 
to try use default UNICODE build with UNICOWS 
solution.

1) Download static lib for your compiler from here:
  http://libunicows.sourceforge.net/
2) Add '-l{mingw|bcc|watcom}unicows' to your hbmk2 
   build script or command-line.
3) Download unicows.dll from here:
  http://go.microsoft.com/fwlink/?LinkId=14851

Excuse my ignorance, but did not work :(

See how I did:

I downloaded and unicows.lib Unicows.dll and did so

- Unicows.lib include in my file .Hbc as:
  libs=c:\unicows\unicows.lib

- Unicows.dll I copied to the folders of windows 98:
 c:\windows, c:\windows\system, c:\windows\systrem32

I generated the harbour again the libs and includes in my file .BAT the
line:

set HB_BUILD_UNICODE=yes

Works well with: set HB_BUILD_UNICODE=no

What can be wrong ?

Best Regards,

Rossine.

-- 
View this message in context: 
http://old.nabble.com/Error-with-14142-tp27875079p27880529.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

Re: [Harbour] Error with 14142

Hi,

 1) Download static lib for your compiler from here:
 http://libunicows.sourceforge.net/
 2) Add '-l{mingw|bcc|watcom}unicows' to your hbmk2 
  build script or command-line.
 3) Download unicows.dll from here:
 http://go.microsoft.com/fwlink/?LinkId=14851
 
 Excuse my ignorance, but did not work :(
 
 See how I did:
 
 I downloaded and unicows.lib Unicows.dll and did so
 
 - Unicows.lib include in my file .Hbc as:
  libs=c:\unicows\unicows.lib

In case of .hbc file, I suggest to use:
   {mingw|bcc|watcom}libs=unicows
   libpaths=dir of unicows lib

Second setting is not needed if you copy the lib file 
to Harbour lib dir (hb/lib/win/bcc in your case pbly)

Make sure to use Harbour 2.1.0dev r14108 or newer.

 - Unicows.dll I copied to the folders of windows 98:
 c:\windows, c:\windows\system, c:\windows\systrem32

OK

 I generated the harbour again the libs and includes in my file .BAT the
 line:
 
 set HB_BUILD_UNICODE=yes

Just drop it, the default is 'yes', so no need to 
use above setting.

 Works well with: set HB_BUILD_UNICODE=no

UNICOWS just doesn't do anything in this case.

 What can be wrong ?

What is the error?

Brgds,
Viktor

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

[Harbour] QAplication and TRACE

2010-03-12 Thread CarozoDeQuilmes

Hi Pritpal, can you remove or suspend the followed traces from HBQT ??

QApplication.cpp:115: HB_TR_ALWAYS hbqt_exit 0 00D5835C

QApplication.cpp:120: HB_TR_ALWAYS hbqt_exit 1 





Thanks in advance

CdQ


Note: because in my project, these traces are put into my sysout build
process.  Look:


.

QApplication.cpp:120: HB_TR_ALWAYS hbqt_exit 1 

D:\SILVER~1\mingw\bin\gcc.exe -ID:\SILVER~1\mingw\include
-ID:\SILVER~1\qt\include -ID:\SILVER~1\harbour\include
-ID:\SILVER~1\HBQTCO~1\include -ID:\SILVER~1\MARINA~2\samples\_SAMPL~1
-ID:\SILVER~1\MARINA~2\samples\_SAMPL~1 -mno-cygwin -Wall -c
D:\SILVER~1\MARINA~2\samples\_SAMPL~1\__sgi_obj_m2gh\sample2.c
-oD:\SILVER~1\MARINA~2\samples\_SAMPL~1\__sgi_obj_m2gh\sample2.o

QApplication.cpp:115: HB_TR_ALWAYS hbqt_exit 0 00D7CA04

QApplication.cpp:120: HB_TR_ALWAYS hbqt_exit 1 

QApplication.cpp:115: HB_TR_ALWAYS hbqt_exit 0 00D7CA04

QApplication.cpp:120: HB_TR_ALWAYS hbqt_exit 1 

== Processing
D:\SilverGui\marinas-ide\samples\_sample_project_for_test_ide\sample3.prg
...

QApplication.cpp:115: HB_TR_ALWAYS hbqt_exit 0 00D5835C

QApplication.cpp:120: HB_TR_ALWAYS hbqt_exit 1 

QApplication.cpp:115: HB_TR_ALWAYS hbqt_exit 0 00D7CA04

QApplication.cpp:120: HB_TR_ALWAYS hbqt_exit 1 

QApplication.cpp:115: HB_TR_ALWAYS hbqt_exit 0 00D7CA04

QApplication.cpp:120: HB_TR_ALWAYS hbqt_exit 1 

D:\SILVER~1\harbour\bin\harbour.exe /n
/iD:\SILVER~1\harbour\include;D:\SILVER~1\HBQTCO~1\include;D:\SILVER~1\MARINA~2\samples\_SAMPL~1;D:\SILVER~1\MARINA~2\samples\_SAMPL~1
/pD:\SILVER~1\MARINA~2\samples\_SAMPL~1\__sgi_obj_m2gh\sample3
D:\SILVER~1\MARINA~2\samples\_SAMPL~1\sample3.prg
-oD:\SILVER~1\MARINA~2\samples\_SAMPL~1\__sgi_obj_m2gh\sample3.c

Harbour 2.1.0dev (Rev. 14147)

Copyright (c) 1999-2010, http://www.harbour-project.org/

Compiling 'D:\SILVER~1\MARINA~2\samples\_SAMPL~1\sample3.prg' and generating
preprocessed output to
'D:\SILVER~1\MARINA~2\samples\_SAMPL~1\__sgi_obj_m2gh\sample3'...

100

100

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

[Harbour] hbMK2 - Error

2010-03-12 Thread Pritpal Bedi


Hello Viktor

E:\harbour\contrib\hbidem
hbmk2: Processing environment options: -compiler=mingw
hbmk2: Processing configuration: e:\harbour\bin\hbmk.cfg

Unrecoverable error 6005: Exception error:

Exception Code:C005
Exception Address:0055C060
EAX:0063005C  EBX:0022FC60  ECX:  EDX:0022FC60
ESI:0063005C  EDI:0050  EBP:00B7ABA0
CS:EIP:001B:0055C060  SS:ESP:0023:0022FBD0
DS:0023  ES:0023  FS:003B  GS:
Flags:00010206
CS:EIP: 8B 70 1C 8B 53 08 89 44 24 04 89 1C 24 FF 52 0C
SS:ESP: 0022FC60 0001 00B4EDC8 0055CC5C 003B 0058EEF3 003F
00B7AB58 0022FC60

C stack:
EIP: EBP:   Frame: OldEBP, RetAddr, Params...


Modules:
0x0040 0x001CD000 e:\harbour\bin\hbmk2.exe
0x7C90 0x000B2000 C:\WINDOWS\system32\ntdll.dll
0x7C80 0x000F5000 C:\WINDOWS\system32\kernel32.dll
0x77C1 0x00058000 C:\WINDOWS\system32\msvcrt.dll
0x7E41 0x0009 C:\WINDOWS\system32\USER32.dll
0x77F1 0x00048000 C:\WINDOWS\system32\GDI32.dll
0x7639 0x0001D000 C:\WINDOWS\system32\IMM32.DLL
0x77DD 0x0009B000 C:\WINDOWS\system32\ADVAPI32.dll
0x77E7 0x00092000 C:\WINDOWS\system32\RPCRT4.dll
0x77FE 0x00011000 C:\WINDOWS\system32\Secur32.dll

Called from ARCHCOMPFILTER(0) in ../../../hbmk2.prg
Called from HBMK2(0) in ../../../hbmk2.prg
Called from MAIN(0) in ../../../hbmk2.prg

It is a quick impression after 
/*
 * $Id: ChangeLog 14147 2010-03-12 19:31:06Z vszakats $
 */

Investigating...

-
 enjoy hbIDEing...
Pritpal Bedi 
_a_student_of_software_analysis__design_
-- 
View this message in context: 
http://n2.nabble.com/hbMK2-Error-tp4724810p4724810.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: GC Pointers - Anyway to detatch them ?

2010-03-12 Thread Pritpal Bedi


Hello Przemek

I think I could not present properly what I mean.

Preparing a flow-chart to demonstrate whole hbQT process 
at a glance and trying to pinpoint what is needed at what point.
I am looking into some of your advices and hopefully will 
cover one or two pitfalls.

Will return to this message later...


-
 enjoy hbIDEing...
Pritpal Bedi 
_a_student_of_software_analysis__design_
-- 
View this message in context: 
http://n2.nabble.com/GC-Pointers-Anyway-to-detatch-them-tp4717974p4724826.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: GC Pointers - Anyway to detatch them ?

2010-03-12 Thread francesco perillo

 Preparing a flow-chart to demonstrate whole hbQT process

It would be great for us beginners in order to catch-up Qt development...
___
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:[14148] trunk/harbour

2010-03-12 Thread vouchcac

Revision: 14148
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14148view=rev
Author:   vouchcac
Date: 2010-03-12 22:30:10 + (Fri, 12 Mar 2010)

Log Message:
---
2010-03-12 14:32 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * contrib/hbqt/doc/en/class_qapplication.txt
  * contrib/hbqt/qtgui/QApplication.cpp
  * contrib/hbqt/qth/QApplication.qth
- Removed tracelog calls.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbqt/doc/en/class_qapplication.txt
trunk/harbour/contrib/hbqt/qtgui/QApplication.cpp
trunk/harbour/contrib/hbqt/qth/QApplication.qth


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] hbMK2 - Error

Hi Pritpal,

hbmk2 is pure .prg code, so if there is such 
error, it can only be lower level problem.

ARCHCOMPFILTER() uses macro evaluation, so 
given recent changes, first pls try to rebuild 
everything from fresh sources and retry.

If it still happens pls post full hbmk2 
configuration, maybe it helps locating it.
(or it that's not possible, you can enable 
line numbers and put a trace call before line 
'bFilter := ( {| hbmk | + cFilterHarb + } )', 
to see what gets executed.

Brgds,
Viktor

On 2010 Mar 12, at 23:23, Pritpal Bedi wrote:

 
 Hello Viktor
 
 E:\harbour\contrib\hbidem
 hbmk2: Processing environment options: -compiler=mingw
 hbmk2: Processing configuration: e:\harbour\bin\hbmk.cfg
 
 Unrecoverable error 6005: Exception error:
 
Exception Code:C005
Exception Address:0055C060
EAX:0063005C  EBX:0022FC60  ECX:  EDX:0022FC60
ESI:0063005C  EDI:0050  EBP:00B7ABA0
CS:EIP:001B:0055C060  SS:ESP:0023:0022FBD0
DS:0023  ES:0023  FS:003B  GS:
Flags:00010206
CS:EIP: 8B 70 1C 8B 53 08 89 44 24 04 89 1C 24 FF 52 0C
SS:ESP: 0022FC60 0001 00B4EDC8 0055CC5C 003B 0058EEF3 003F
 00B7AB58 0022FC60
 
C stack:
EIP: EBP:   Frame: OldEBP, RetAddr, Params...
 
 
 Modules:
 0x0040 0x001CD000 e:\harbour\bin\hbmk2.exe
 0x7C90 0x000B2000 C:\WINDOWS\system32\ntdll.dll
 0x7C80 0x000F5000 C:\WINDOWS\system32\kernel32.dll
 0x77C1 0x00058000 C:\WINDOWS\system32\msvcrt.dll
 0x7E41 0x0009 C:\WINDOWS\system32\USER32.dll
 0x77F1 0x00048000 C:\WINDOWS\system32\GDI32.dll
 0x7639 0x0001D000 C:\WINDOWS\system32\IMM32.DLL
 0x77DD 0x0009B000 C:\WINDOWS\system32\ADVAPI32.dll
 0x77E7 0x00092000 C:\WINDOWS\system32\RPCRT4.dll
 0x77FE 0x00011000 C:\WINDOWS\system32\Secur32.dll
 
 Called from ARCHCOMPFILTER(0) in ../../../hbmk2.prg
 Called from HBMK2(0) in ../../../hbmk2.prg
 Called from MAIN(0) in ../../../hbmk2.prg
 
 It is a quick impression after 
 /*
 * $Id: ChangeLog 14147 2010-03-12 19:31:06Z vszakats $
 */
 
 Investigating...
 
 -
 enjoy hbIDEing...
Pritpal Bedi 
 _a_student_of_software_analysis__design_
 -- 
 View this message in context: 
 http://n2.nabble.com/hbMK2-Error-tp4724810p4724810.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

[Harbour] Re: hbMK2 - Error

2010-03-12 Thread Pritpal Bedi



Viktor Szakáts wrote:
 
 ARCHCOMPFILTER() uses macro evaluation, so 
 given recent changes, first pls try to rebuild 
 everything from fresh sources and retry.
 

Yep, executes fine after clean build.




-
 enjoy hbIDEing...
Pritpal Bedi 
_a_student_of_software_analysis__design_
-- 
View this message in context: 
http://n2.nabble.com/hbMK2-Error-tp4724810p4724980.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] SF.net SVN: harbour-project:[14149] trunk/harbour

2010-03-12 Thread druzus

Revision: 14149
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14149view=rev
Author:   druzus
Date: 2010-03-13 00:26:30 + (Sat, 13 Mar 2010)

Log Message:
---
2010-03-13 01:25 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/include/hbstack.h
  * harbour/src/vm/estack.c
% declare hb_stack TLS pointer in MT HVM as static when HVM is compiled
  with HB_HVM_ALL=yes

  * harbour/src/compiler/hbcomp.c
! added protection against multiple freeing the same expression on
  some errors in compiled code. It's necessary after removing reference
  counters which made such protection indirectly. It fixed bug reported
  by Teo.

  * harbour/include/hbsetup.h
! check GCC version for hot and cold function attribute macros

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/include/hbsetup.h
trunk/harbour/include/hbstack.h
trunk/harbour/src/compiler/hbcomp.c
trunk/harbour/src/vm/estack.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] SF.net SVN: harbour-project:[14099] trunk/harbour/ChangeLog

On Sun, 07 Mar 2010, vszak...@users.sourceforge.net wrote:

Hi Viktor,

 2010-03-08 00:48 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
   * ChangeLog
 ! Added missing change from prev entry:
   * src/rtl/gtwvt/gtwvt.c
 * Changed RegisterClass() call to RegisterClassEx().
   Same availability, more features, recommended call.

This modification broke WinCE builds:
   ../../../../../../src/rtl/gtwvt/obj/wce/mingwarm/gtwvt.o:gtwvt.c:
   undefined reference to `RegisterClassExW'
   collect2: ld returned 1 exit status
   make[4]: *** [harbourmt-21-wce-arm.dll] Błąd 1

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

2010-03-12 Thread vouchcac

Revision: 14150
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14150view=rev
Author:   vouchcac
Date: 2010-03-13 01:28:47 + (Sat, 13 Mar 2010)

Log Message:
---
2010-03-12 17:20 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * contrib/hbqt/generator/hbqtgen.prg

  * contrib/hbqt/qth/QList.qth
  * contrib/hbqt/qth/QObject.qth
 
  * Re0generated: contrib/hbqt/qtgui/?.cpp 
  * Re-generated: contrib/hbqt/qtcore/?.cpp

+ Eliminated any occurance of hb_retptr(*) calls.
  Now all objects which are created with new or are
  returned as a method call are encapsulated in GC 
  pointer. This is a step closer to find-out the potential
  GPFs.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbqt/doc/en/class_qapplication.txt
trunk/harbour/contrib/hbqt/doc/en/class_qlist.txt
trunk/harbour/contrib/hbqt/doc/en/class_qobject.txt
trunk/harbour/contrib/hbqt/doc/en/class_qpaintdevice.txt
trunk/harbour/contrib/hbqt/generator/hbqtgen.prg
trunk/harbour/contrib/hbqt/qtcore/QAbstractItemModel.cpp
trunk/harbour/contrib/hbqt/qtcore/QAbstractListModel.cpp
trunk/harbour/contrib/hbqt/qtcore/QAbstractTableModel.cpp
trunk/harbour/contrib/hbqt/qtcore/QChar.cpp
trunk/harbour/contrib/hbqt/qtcore/QCoreApplication.cpp
trunk/harbour/contrib/hbqt/qtcore/QFile.cpp
trunk/harbour/contrib/hbqt/qtcore/QIODevice.cpp
trunk/harbour/contrib/hbqt/qtcore/QList.cpp
trunk/harbour/contrib/hbqt/qtcore/QModelIndex.cpp
trunk/harbour/contrib/hbqt/qtcore/QObject.cpp
trunk/harbour/contrib/hbqt/qtcore/QResource.cpp
trunk/harbour/contrib/hbqt/qtcore/QTextCodec.cpp
trunk/harbour/contrib/hbqt/qtcore/TQChar.prg
trunk/harbour/contrib/hbqt/qtcore/TQList.prg
trunk/harbour/contrib/hbqt/qtcore/TQObject.prg
trunk/harbour/contrib/hbqt/qtgui/QAbstractButton.cpp
trunk/harbour/contrib/hbqt/qtgui/QAbstractItemDelegate.cpp
trunk/harbour/contrib/hbqt/qtgui/QAbstractItemView.cpp
trunk/harbour/contrib/hbqt/qtgui/QAbstractPrintDialog.cpp
trunk/harbour/contrib/hbqt/qtgui/QAbstractProxyModel.cpp
trunk/harbour/contrib/hbqt/qtgui/QAbstractScrollArea.cpp
trunk/harbour/contrib/hbqt/qtgui/QAbstractSlider.cpp
trunk/harbour/contrib/hbqt/qtgui/QAbstractSpinBox.cpp
trunk/harbour/contrib/hbqt/qtgui/QAbstractTextDocumentLayout.cpp
trunk/harbour/contrib/hbqt/qtgui/QClipboard.cpp
trunk/harbour/contrib/hbqt/qtgui/QComboBox.cpp
trunk/harbour/contrib/hbqt/qtgui/QDragEnterEvent.cpp
trunk/harbour/contrib/hbqt/qtgui/QDragLeaveEvent.cpp
trunk/harbour/contrib/hbqt/qtgui/QDragMoveEvent.cpp
trunk/harbour/contrib/hbqt/qtgui/QDropEvent.cpp
trunk/harbour/contrib/hbqt/qtgui/QFocusEvent.cpp
trunk/harbour/contrib/hbqt/qtgui/QGradient.cpp
trunk/harbour/contrib/hbqt/qtgui/QHelpEvent.cpp
trunk/harbour/contrib/hbqt/qtgui/QImage.cpp
trunk/harbour/contrib/hbqt/qtgui/QItemSelectionModel.cpp
trunk/harbour/contrib/hbqt/qtgui/QKeyEvent.cpp
trunk/harbour/contrib/hbqt/qtgui/QLayout.cpp
trunk/harbour/contrib/hbqt/qtgui/QLayoutItem.cpp
trunk/harbour/contrib/hbqt/qtgui/QLineEdit.cpp
trunk/harbour/contrib/hbqt/qtgui/QMoveEvent.cpp
trunk/harbour/contrib/hbqt/qtgui/QPaintDevice.cpp
trunk/harbour/contrib/hbqt/qtgui/QPaintEngine.cpp
trunk/harbour/contrib/hbqt/qtgui/QPrintEngine.cpp
trunk/harbour/contrib/hbqt/qtgui/QResizeEvent.cpp
trunk/harbour/contrib/hbqt/qtgui/QSessionManager.cpp
trunk/harbour/contrib/hbqt/qtgui/QStyle.cpp
trunk/harbour/contrib/hbqt/qtgui/QStyleHintReturn.cpp
trunk/harbour/contrib/hbqt/qtgui/QStyleHintReturnMask.cpp
trunk/harbour/contrib/hbqt/qtgui/QStyleHintReturnVariant.cpp
trunk/harbour/contrib/hbqt/qtgui/QSyntaxHighlighter.cpp
trunk/harbour/contrib/hbqt/qtgui/QTextBlock.cpp
trunk/harbour/contrib/hbqt/qtgui/QTextBlockGroup.cpp
trunk/harbour/contrib/hbqt/qtgui/QTextInlineObject.cpp
trunk/harbour/contrib/hbqt/qtgui/QTextList.cpp
trunk/harbour/contrib/hbqt/qtgui/QTextObject.cpp
trunk/harbour/contrib/hbqt/qtgui/QValidator.cpp
trunk/harbour/contrib/hbqt/qtgui/QWheelEvent.cpp
trunk/harbour/contrib/hbqt/qth/QList.qth
trunk/harbour/contrib/hbqt/qth/QObject.qth
trunk/harbour/contrib/hbqt/qtnetwork/QHttpHeader.cpp


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

Revision: 14151
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14151view=rev
Author:   vszakats
Date: 2010-03-13 02:07:35 + (Sat, 13 Mar 2010)

Log Message:
---
2010-03-13 03:03 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
  * src/rtl/gtwvt/gtwvt.c
! Reverted RegisterClassEx() to RegisterClass() for WinCE.
  Thanks for the information.

  * src/rtl/gtdos/gtdos.c
  * src/rtl/gtwvt/gtwvt.c
  * src/rtl/filesys.c
  * src/rdd/dbcmd.c
  * src/rdd/dbcmd53.c
  * src/rdd/wafunc.c
  * src/rdd/workarea.c
  * src/rdd/dbfcdx/dbfcdx1.c
  * src/rdd/dbffpt/dbffpt1.c
  * src/rdd/ordwldsk.c
  * src/rdd/hbsix/sxord.c
  * src/rdd/hbsix/sxsem.c
  * src/rdd/ordcount.c
  * contrib/hbtpathy/tpwin.c
  * contrib/rddbmcdx/bmdbfcdx.c
  * contrib/gtwvg/gtwvg.c
  * contrib/gtwvg/wvggui.c
  * contrib/gtwvg/wvgwing.c
  * contrib/rddads/adsfunc.c
  * contrib/hbwin/axcore.c
  * contrib/hbwin/mapi.c
  * contrib/hbwin/win_dlg.c
* 'memset( obj, 0, sizeof( TYPE_OF_OBJ ) )'
  changed to:
  'memset( obj, 0, sizeof( obj ) )'
  (same meaning but less room for mistake)
* Variable scope cleanups in few places.

  * bin/hb-mkimp.bat
  * src/vm/itemapi.c
* Formatting.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/bin/hb-mkimp.bat
trunk/harbour/contrib/gtwvg/gtwvg.c
trunk/harbour/contrib/gtwvg/wvggui.c
trunk/harbour/contrib/gtwvg/wvgwing.c
trunk/harbour/contrib/hbtpathy/tpwin.c
trunk/harbour/contrib/hbwin/axcore.c
trunk/harbour/contrib/hbwin/mapi.c
trunk/harbour/contrib/hbwin/win_dlg.c
trunk/harbour/contrib/rddads/adsfunc.c
trunk/harbour/contrib/rddbmcdx/bmdbfcdx.c
trunk/harbour/src/rdd/dbcmd.c
trunk/harbour/src/rdd/dbcmd53.c
trunk/harbour/src/rdd/dbfcdx/dbfcdx1.c
trunk/harbour/src/rdd/dbffpt/dbffpt1.c
trunk/harbour/src/rdd/hbsix/sxord.c
trunk/harbour/src/rdd/hbsix/sxsem.c
trunk/harbour/src/rdd/ordcount.c
trunk/harbour/src/rdd/ordwldsk.c
trunk/harbour/src/rdd/wafunc.c
trunk/harbour/src/rdd/workarea.c
trunk/harbour/src/rtl/filesys.c
trunk/harbour/src/rtl/gtdos/gtdos.c
trunk/harbour/src/rtl/gtwvt/gtwvt.c
trunk/harbour/src/vm/itemapi.c


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

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

Revision: 14152
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14152view=rev
Author:   vszakats
Date: 2010-03-13 02:19:10 + (Sat, 13 Mar 2010)

Log Message:
---
2010-03-13 03:18 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
  * src/vm/Makefile
  * src/vm/vmmt/Makefile
! Fixed GUI mode not working for mingw64 targets.
  [TOMERGE 2.0]

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/src/vm/Makefile
trunk/harbour/src/vm/vmmt/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] recommended C compiler for Win