Re: [Harbour] Harbour 2.0.0 stats after one month
Hi Martin are you welcome You have also good Xbase++ experiences Can you help us in refiniing hbxbp/hbide? Xbase+ Part compatible and more http://docs.google.com/View?id=dhmtv9fs_240zntnvdc7 hbide is visual version of harbour based on hbxbp http://docs.google.com/View?id=dhmtv9fs_235db6hz754 Can i request what do using [x]harbour for? 2010/1/26 Viktor Szakáts harbour...@syenar.hu: Besides actively participating on Harbour dev list in the early times, Martin developed the first significant chunks of Harbour's hbct lib. He also contributed to complete and finalize math handling subsystem in hbrtl (most of math.c). Most of his contributions are still there and working fine. Brgds, Viktor -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] CDX RDD question (live usage/compatibility)
On Mon, 25 Jan 2010, Maurizio la Cecilia wrote:
Hi,
Sorry for reopening a very old and OT thread, but my needs are quite the same
as Viktor's one and i think something changed after 2005.
I ported successfully a large clipper 5.2e application, working on many
networks, to Harbour 2.0.
Now, before to swap the installation to Harbour version, i would to test the
effectiveness of the job using one or few Harbour workstation concurrently
with old Clipper ones on the same network.
Thus, i changed the Clipper app to use the DBFCDX driver and compiled
Harbour using the same driver and setting the locking scheme to CLIP (not
CLIP53). The adopted code is:
CL52 DBFCDX/SIX3 SIXCDX drivers are broken and can corrupt index files.
so I cannot give you any guaranties that it will work. Anyhow if
you want to use it and access the same index files by Harbour then
you should use in Harbour SIXCDX RDD which tries to replicate some
low level SIXCDX behavior. It creates less efficient indexes in some
cases but it's a workaround for some CL52/SIXCDX bugs.
CL53 DBFCDX/COMIX seems to be much better choice for Clipper.
Additionally you have to chose _EXACTLY_ the same locking schemes in
both compilers.
CL52 DBFCDX/SIXCDX uses FP locking. CL53 DBFCDX/COMIX use CL53 locking
but it can be changed to FP locking if you link with your application
cdxlock.obj
REQUEST DBFCDX
RDDSetDefault(DBFCDX)
RddInfo( RDDI_LOCKSCHEME, DB_DBFLOCK_CLIP )
None of Clipper CDX drivers uses such locking scheme so it's wrong.
REQUEST HB_LANG_IT
REQUEST HB_CODEPAGE_IT850
hb_cdpSelect('IT850')
hb_LangSelect('IT')
If you are using HB_CODEPAGE_IT850 in Harbour then you have to link your
Clipper application with ntxita.obj. Otherwise index files will be corrupted
because Clipper and Harbour will use different collation orders.
Apart of a dirty Clipper problem about the compound indexes (i posted
yesterday a message on the google clipper group) solved using the INDEX
command in place of the OrdCondSet()/OrdCreate() pair, the program crashes
Harbour and CL53 DBFCDX/COMIX do not support none compound IDX indexes
so I guess you are using CL52 DBFCDX or SIXCDX driver.
only in one function, giving a lock required error after a successfully
lock of the same record. The strange thing is that the flow is apparently
the same of other parts of the application working fine.
In Clipper and Harbour 1022 Lock required RT error is logical error.
It means that programmer didn't successfully locked the record. The
physical record lock is not checked when this error is generated.
It means that it's a problem with application code. Check why it's
exploited when you compile it using Harbour. It's possible that setting
valid locks scheme will hide the problem but for sure it will not fix
the code. Such error should not appear in code which always checks
results of RLOCK/FLOCK operations and never tries to write to not locked
record so it's something what you should try to locate and fix in your code.
Thus, i'm thinking that i gone wrong in some configuration option or i'm
ignoring some bug of the adopted implementation.
Ther'is any hint about the DBFCDX driver coexistence? Ther'is another better
path to try (not SQL based, as i need to mantain DBF approach before
quitting old Clipper world).
See above. You have to use exactly the same locking scheme and national
sorting order inb both applications. If you are using CL52 DBFCDX or SIXCDX
then use in Harbour SIXCDX too. If you are using CL53 DBFCDX or COMIX them
use in Harbour DBFCDX.
CL52 DBFCDX and SIXCDX have serious bugs and for me should never be used
in production environment. Anyhow it's possible that your code does not
exploit them very often so you can live with it.
HTH,
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] INIT/EXIT Procedures - Thread Wise
On Mon, 25 Jan 2010, Pritpal Bedi wrote:
Hi,
Anyhow we can think about adding dynamically initialized thread static
variables were initialization code is executed when variable is accesed
1-st time, i.e.:
thread static s_var init {code}
{code} is evaluated when thread access s_var the 1-st time and its
result is assigned to s_var. Such implementation does not cause any
overhead in code which never access s_var.
Exactly this is what I want. Please commit.
It's not such trivial. It's necessary to modify compiler, generated
PCODE and HVM. It will be also good to ask group if such syntax
extension is acceptable:
thread static s_var init { || hb_datetime() }
or maybe we should add to sth.ch:
#command thread static !var! init initcode = ;
thread static var initblock {initcode}
and then to compiler support for:
thread static var initblock block
so programmer can simply make:
thread static s_var init hb_datetime()
2. Do we have some provison in Class framework to get
the chain of inheritance. This is required for Xbase++ object
method :isDerivedFrom( cClassOrObject ).
__clsParent( nClassHandle, cClassName ) - lDerived
i.e.:
? __clsParent( obj:classH, MYCLS )
CLASS Abc INHERIT MyCls
ENDCLASS
CLASS Bcd INHERITS Abc
ENDCLASS
oBcd := Bcd():new()
? __clsParent( oBcd:classH, MYCLS ) // what will be the result ?
.T.
Better if encapsulated as :
if( oBcd:isDerivedFrom( MyCls ) )
// program logic...
endif
METHOD isDerivedFrom( cClassName )
RETURN __clsParent( Self:classH, cClassName )
We have also commented code for :isDerivedFrom() method in
src/vm/classes.c
which we can enable if we decide it's usable as general OOP functionality
like :CLASSNAME or :CLASSH
:isDerivedFrom() must be in the core as it is Xbase++ implementation.
I would prefer to call it directly instead of __clsParent( obj:classH,
MYCLS ).
Looking forward that it is enabled by default.
There is much more default methods in different OOP implementations
in xbase world. I do not think that it's good idea to adding separately
some of them because some of us wants to use it in some project without
bigger vission about final code.
I do not know which system methods use xbase++ and which of them are part
of object and which ones belongs to class object only.
best regards,
Przemek
___
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:[13704] trunk/harbour
Hi Przemek, Log Message: --- 2010-01-25 12:35 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/hbwin/win_misc.c ! fixed buffer overflow in WIN_WIDETOANSI() caused by wrongly calculated buffer size * harbour/utils/hbmk2/hbmk2.prg * updated names of xHarbour libraries - now it works in static mode TOFIX: -xhb shared mode uses 'harbour' instead of 'xharbour' library and 'hbmainstd' instead of 'mainstd' TOFIX2: -gui switch in -xhb mode cause compile time error: /tmp/hbmk_auhl2d.c:8: error: syntax error before void Thank you. For me the problem with TOFIX and TOFIX2, is that I have no idea what names are used for dynlibs in xhb. If you can tell me about it, I can apply the fixes. Also, what is the equivalent of hbmainwin in xhb? Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] INIT/EXIT Procedures - Thread Wise
Hello
Przemysław Czerpak wrote:
It's not such trivial. It's necessary to modify compiler, generated
PCODE and HVM. It will be also good to ask group if such syntax
extension is acceptable:
thread static s_var init { || hb_datetime() }
or maybe we should add to sth.ch:
#command thread static !var! init initcode = ;
thread static var initblock {initcode}
and then to compiler support for:
thread static var initblock block
so programmer can simply make:
thread static s_var init hb_datetime()
This issue essentially resolvs around _performance_.
So if the PP method described as above places no overhead
then that's it! But if it checked everytime the variable is
accessed then there are other ways also to simulate it.
? __clsParent( oBcd:classH, MYCLS ) // what will be the result ?
.T.
METHOD isDerivedFrom( cClassName )
RETURN __clsParent( Self:classH, cClassName )
I am delighted to hear this.
Will implement in hbXBP code shortly.
There is much more default methods in different OOP implementations
in xbase world. I do not think that it's good idea to adding separately
some of them because some of us wants to use it in some project without
bigger vission about final code.
I do not know which system methods use xbase++ and which of them are part
of object and which ones belongs to class object only.
I understand this concern.
Because I have a solution as above, I do not need it by default anymore.
Thanks for clarifications.
Regards
Pritpal Bedi
--
View this message in context:
http://old.nabble.com/INIT-EXIT-Procedures---Thread-Wise-tp27302415p27320680.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] SF.net SVN: harbour-project:[13711] trunk/harbour
You're right, now I see it. Brgds, Viktor On 2010 Jan 26, at 05:11, Pritpal Bedi wrote: Viktor Szakáts wrote: I think you missed the ' ' (space) after hb_getenv( SHELL ) and the actual file. cC := iif( hbide_getOS() == nix, , /C ) = cC := iif( hbide_getOS() == nix, , /C ) No, not needed. I am not issueing hb_processRun() but Qt's process management and the parameters are handled differently under QStringList. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13711--trunk-harbour-tp27317153p27317736.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] qt slots/events
Hi Pritpal,
I see this code in hbxbp:
---
METHOD HbpQtUI:destroy()
LOCAL a_
FOR EACH a_ IN ::aSignals
Qt_Slots_disConnect( ::pSlots, a_[ 1 ], a_[ 2 ] )
NEXT
FOR EACH a_ IN ::aEvents
Qt_Events_disConnect( ::pEvents, a_[ 1 ], a_[ 2 ] )
NEXT
...
RETURN NIL
METHOD HbpQtUI:event( cWidget, nEvent, bBlock )
IF hb_hHasKey( ::qObj, cWidget )
IF Qt_Events_Connect( ::pEvents, ::qObj[ cWidget ], nEvent, bBlock )
aadd( ::aEvents, { ::qObj[ cWidget ], nEvent } )
ENDIF
ENDIF
RETURN Self
---
Which is redundant, because we're keeping track
of events/slots in both ::pSlots/::pEvents, and
also maintaining a .prg level copy of the list in
::aSlots/::aEvents. It's also prone to leak/GPF, as
it's up to .prg level code to make sure all slots/events
are disconnected.
By using GC facility, would it be possible to rework
hbqt low-levels, to allow for this code, solving both
problems:
---
METHOD HbpQtUI:destroy()
LOCAL a_
::pSlots := NIL
::pEvents := NIL
...
RETURN NIL
METHOD HbpQtUI:event( cWidget, nEvent, bBlock )
IF cWidget $ ::qObj
Qt_Events_Connect( ::pEvents, ::qObj[ cWidget ], nEvent, bBlock )
ENDIF
RETURN Self
---
What do you think?
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13704] trunk/harbour
On Tue, 26 Jan 2010, Szak�ts Viktor wrote:
Hi Viktor,
TOFIX: -xhb shared mode uses 'harbour' instead of 'xharbour' library
and 'hbmainstd' instead of 'mainstd'
TOFIX2: -gui switch in -xhb mode cause compile time error:
For me the problem with TOFIX and TOFIX2, is that
I have no idea what names are used for dynlibs in xhb.
If you can tell me about it, I can apply the fixes.
Thank you very much.
I've just look closer at current xHarbour CVS and it will not be easy
to make sth with it.
In current xHarbour CVS code MinGW build uses 'xharbour[mt]-1.2.1'
and in the earlier versions it was without version number 'xharbour[mt]'.
But non GNU make windows builds create 'harbour.dll' !!! instead of
'xharbour.dll'. Looks that first xHarbour developers should clean it
and we should not touch it now.
Also, what is the equivalent of hbmainwin in xhb?
xHarbour does not have such library at all. It only has 'mainstd' in
MinGW builds.
Current xHarbour versions seems to have also some additional libraries
for dynmaic code but I do not know what is their exact job. They try to
overload some of HVM public symbols and such operation is illegal for
most of linkers so I guess it's a hack only for some chosen windows
compilers. I cannot say more without investing more time in checking
the xHarbour code and I have serious doubts that it's possible to find
xHarbour developer who can explain what exactly this feature should do
and can clean it to work with all linkers so I think we should not touch
it too.
BTW I have also some questions about filters in hbmk2 script files.
Does -help output describe all condition variables?
Is it possible to use or add conditional switch like {shared} in .hbc files?
How exactly the conditions are processed? Can they be located anywhere in
the line and when evaluate to false they disable whole line?
What will happen if I use more then one condition in single line,
i.e. -o{win}win{bcc}bcc ?
Maybe it's be possible to create .hbc file which will allow to use
different xHarbour versions without touch hbmk2 code.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbwin.lib error
On Tue, 26 Jan 2010, Szak�ts Viktor wrote: Hi, Either use hbwin.hbc to link in hbwin module. Or add libpng lib to the liblist manually. (first option strong preferred, to avoid any similar problems in the future) Also see: contrib\hbwin\hbwin.hbc I think this should be modified to use REQUEST mechanism, i.e. REQUEST HB_PNG Now everyone who use WIN_PRN class has to link his code with PNG library even if it's unnecessary. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbwin.lib error
On Tue, 26 Jan 2010, Szak�ts Viktor wrote: Hi, Removing 'lib' will cause various additional problems to deal with depending on platform and compiler, so current name is best option. In *nixes thius library is called 'png' so it's necessary to use -lpng hbmk2 switch. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Harbour 2.0.0 binaries for OS/2-eCS
Third report Harbour 2.0.0 binaries files for OS/2-eComStation are available since 26 Dec 2009, exactly one month ago Harbour 2.0.0 contrib libs file for OS/2-eComStation are available since 11 Jan 2010, 15 days ago Total of downloads reach 353 as current value, which 245 are for binaries Current 353 downloads are distributed as: harbour-2.0.0.bin-os2.watcom.zip8334 % harbour-2.0.0.bin-os2.gcc433.zip5924 % harbour-2.0.0.bin-os2.gcc335omf.zip 4418 % harbour-2.0.0.bin-os2.gcc335aout.zip5924 % and harbour-2.0.0.contrib-os2.zip 108 and we have a new winner: for now Harbour 2.0.0 binaries is the champion in number of downloads in Harbour for OS/2 history Harbour beta3 have 239 downloads since 15 Jun, 2007 (many months) and was previous champion So in one month Harbour 2.0.0 have 245*100/239=102 % of Harbour beta3 We have interesting results: ( pattern is very close to first report ) a) Surprisely most wanted choice is OpenWatcom with 34 % b) os2gcc433 is second choice with 24 %, now paired with traditional os2gcc335 c) gcc OMF type are ahead of a.out type (24 %), with 24 % (433)+ 18 % (335omf) = 42 % Considering OpenWatcom too, OMF type have 42%+34% = 76% d) Old os2gcc335 in a.out type have 24 % of current preference Results confirm that we took the right decisions: 1) Keep support of OS/2-OpenWatcom 2) Inclusion of OMF type support in gcc4xx and gcc335 3) Inclusion of newer os2gcc4xx support As numbers show, binaries raised a good interest in Harbour for OS/2, and contribs, delivered later, confirmed firmly that interest ( A great miss was hbqt ) Thanks to everyone David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] CDX RDD question (live usage/compatibility)
CL52 DBFCDX/SIX3 SIXCDX drivers are broken and can corrupt index files. so I cannot give you any guaranties that it will work. Anyhow if you want to use it and access the same index files by Harbour then you should use in Harbour SIXCDX RDD which tries to replicate some low level SIXCDX behavior. It creates less efficient indexes in some cases but it's a workaround for some CL52/SIXCDX bugs. CL53 DBFCDX/COMIX seems to be much better choice for Clipper. Ok. I realize. No chance to recompile in Cl53, however, as i don't own it. Additionally you have to chose _EXACTLY_ the same locking schemes in both compilers. CL52 DBFCDX/SIXCDX uses FP locking. CL53 DBFCDX/COMIX use CL53 locking but it can be changed to FP locking if you link with your application cdxlock.obj REQUEST DBFCDX RDDSetDefault(DBFCDX) RddInfo( RDDI_LOCKSCHEME, DB_DBFLOCK_CLIP ) None of Clipper CDX drivers uses such locking scheme so it's wrong. Ok. My mistake. I based my choice on xHarbour manual saying: Setting the locking scheme to 1 will lock the database files like CA-Clipper 5.2 does. To use CA-Clipper 5.3's locking scheme, set DBFLOCKSCHEME to 2. This will emulate shared locks using exclusive locks. Visual FoxPro's locking scheme is selected with DBFLOCKSCHEME set to 3. If you are using HB_CODEPAGE_IT850 in Harbour then you have to link your Clipper application with ntxita.obj. Otherwise index files will be corrupted because Clipper and Harbour will use different collation orders. I ever link ntxita.obj, also in DBFNTX build. Harbour and CL53 DBFCDX/COMIX do not support none compound IDX indexes so I guess you are using CL52 DBFCDX or SIXCDX driver. Sorry, i was meaning production .CDX multitag indexes... In Clipper and Harbour 1022 Lock required RT error is logical error. It means that programmer didn't successfully locked the record. The physical record lock is not checked when this error is generated. It means that it's a problem with application code. Check why it's exploited when you compile it using Harbour. It's possible that setting valid locks scheme will hide the problem but for sure it will not fix the code. Such error should not appear in code which always checks results of RLOCK/FLOCK operations and never tries to write to not locked record so it's something what you should try to locate and fix in your code. The problem is ONLY in Cl52+DBFCDX. With app built with Harbour or Cl52+DBFNTX all works fine. The Rlock() returns .t. in all the builded app, BUT ONLY in Cl52+DBFCDX exits a Lock required error at subsequent field replace. This happens also if the Cl52+DBFCDX is the ONLY program running on the network... So, i think that the problem is not deriving from my code... Same code works fine in all other points of app updating a record. See above. You have to use exactly the same locking scheme and national sorting order inb both applications. If you are using CL52 DBFCDX or SIXCDX then use in Harbour SIXCDX too. If you are using CL53 DBFCDX or COMIX them use in Harbour DBFCDX. CL52 DBFCDX and SIXCDX have serious bugs and for me should never be used in production environment. Anyhow it's possible that your code does not exploit them very often so you can live with it. The feel i receive from your message is that i'm going in a puzzled challenge, so i think i'll have two options: A) To leave the Cl52+DBFNTX app, working well from twenty year ago, and to change the driver of Harbour to DBFNTX B) To take the courage of replace with Harbour+DBFCDX all the install I don't know the effectiveness of the DBFNTX in Harbour, so i ask you if also the A) choice is dangerous and the pure Harbour path is the only affordable. My great thanks for your support and precious feedback. Best regards. Maurizio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbwin.lib error
Removing 'lib' will cause various additional problems to deal with depending on platform and compiler, so current name is best option. In *nixes thius library is called 'png' so it's necessary to use -lpng hbmk2 switch. For me it works on all platforms by using 'libpng', probably because I use the (default case) embedded version. Maybe we should call it hbpng, like we do with zlib and pcre, but I won't be able to dedicate a few days now just to retest this whole matter from ground up :( Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbwin.lib error
Hi, Either use hbwin.hbc to link in hbwin module. Or add libpng lib to the liblist manually. (first option strong preferred, to avoid any similar problems in the future) Also see: contrib\hbwin\hbwin.hbc I think this should be modified to use REQUEST mechanism, i.e. REQUEST HB_PNG Now everyone who use WIN_PRN class has to link his code with PNG library even if it's unnecessary. I can't oversee this solution, but if it helps us to loosen this dependency, you're probably right. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13704] trunk/harbour
Hi Przemek, * harbour/utils/hbmk2/hbmk2.prg * updated names of xHarbour libraries - now it works in static mode TOFIX2: -gui switch in -xhb mode cause compile time error: /tmp/hbmk_auhl2d.c:8: error: syntax error before void Can you post me -debugstub output for this case? 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:[13714] trunk/harbour
Revision: 13714 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13714view=rev Author: vszakats Date: 2010-01-26 13:42:56 + (Tue, 26 Jan 2010) Log Message: --- 2010-01-26 14:40 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * utils/hbmk2/hbmk2.hu_HU.po * utils/hbmk2/hbmk2.pt_BR.po * utils/hbmk2/hbmk2.prg ! Fixed rare problem where options containing .hbp/.hbm/.clp extesions have been mistaken as file recursions instead of being processes as options. F.e. -runflag=test.hbp ! Updated help text about possible filter keywords. ! Fixed to use xharbour[mt] for dynlib name for mingw targets. Added NOTE that in newer xhb version this is not true anymore. Support for other targets also doesn't work, because of non-existent or not consistent dynlib naming scheme in xhb. ! Fixed to use 'mainstd' instead of 'hbmainstd', and not to use 'hbmainwin' at all in -xhb mode for mingw targets. For rest of targets the xhb solution is inconsistent, so it's not currently possible give them any meaningful support in hbmk2. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/utils/hbmk2/hbmk2.hu_HU.po trunk/harbour/utils/hbmk2/hbmk2.prg trunk/harbour/utils/hbmk2/hbmk2.pt_BR.po 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] hbwin.lib error
On Tue, 26 Jan 2010, Szak�ts Viktor wrote: Hi, I think this should be modified to use REQUEST mechanism, i.e. REQUEST HB_PNG Now everyone who use WIN_PRN class has to link his code with PNG library even if it's unnecessary. I can't oversee this solution, but if it helps us to loosen this dependency, you're probably right. We can make it just like for PCRE library by registering the function in init code. I can implement 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] SF.net SVN: harbour-project:[13704] trunk/harbour
On Tue, 26 Jan 2010, Szak�ts Viktor wrote: Hi, * harbour/utils/hbmk2/hbmk2.prg * updated names of xHarbour libraries - now it works in static mode TOFIX2: -gui switch in -xhb mode cause compile time error: /tmp/hbmk_auhl2d.c:8: error: syntax error before void Can you post me -debugstub output for this case? I've already fixed it but forgot to commit. Sorry. I'll commit in a while. The problem was caused by HB_EXTERN_C macro which is not defined by xHarbour in pure C mode. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbwin.lib error
I think this should be modified to use REQUEST mechanism, i.e. REQUEST HB_PNG Now everyone who use WIN_PRN class has to link his code with PNG library even if it's unnecessary. I can't oversee this solution, but if it helps us to loosen this dependency, you're probably right. We can make it just like for PCRE library by registering the function in init code. I can implement it. It would be very nice. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13714] trunk/harbour
On Tue, 26 Jan 2010, vszak...@users.sourceforge.net wrote: Hi, Log Message: --- 2010-01-26 14:40 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * utils/hbmk2/hbmk2.hu_HU.po * utils/hbmk2/hbmk2.pt_BR.po * utils/hbmk2/hbmk2.prg ! Fixed rare problem where options containing .hbp/.hbm/.clp extesions have been mistaken as file recursions instead of being processes as options. F.e. -runflag=test.hbp ! Updated help text about possible filter keywords. ! Fixed to use xharbour[mt] for dynlib name for mingw targets. Added NOTE that in newer xhb version this is not true anymore. Support for other targets also doesn't work, because of non-existent or not consistent dynlib naming scheme in xhb. ! Fixed to use 'mainstd' instead of 'hbmainstd', and not to use 'hbmainwin' at all in -xhb mode for mingw targets. For rest of targets the xhb solution is inconsistent, so it's not currently possible give them any meaningful support in hbmk2. Thank you very much. I'll test it ASAP. 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:[13715] trunk/harbour
Revision: 13715 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13715view=rev Author: druzus Date: 2010-01-26 14:21:50 + (Tue, 26 Jan 2010) Log Message: --- 2010-01-26 15:21 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/utils/hbmk2/hbmk2.prg * use HB_EXTERN_BEGIN / HB_EXTERN_END macros instead of HB_EXTERN_C in -xhb mode. It fixes the problem with -gui switch. 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] SF.net SVN: harbour-project:[13715] trunk/harbour
Thanks a lot. Is there anything against using the BEGIN/END method in all cases? If there isn't, it'd simplify logic. Brgds, Viktor On 2010 Jan 26, at 15:21, dru...@users.sourceforge.net wrote: Revision: 13715 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13715view=rev Author: druzus Date: 2010-01-26 14:21:50 + (Tue, 26 Jan 2010) Log Message: --- 2010-01-26 15:21 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/utils/hbmk2/hbmk2.prg * use HB_EXTERN_BEGIN / HB_EXTERN_END macros instead of HB_EXTERN_C in -xhb mode. It fixes the problem with -gui switch. 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 mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13716] trunk/harbour
Revision: 13716 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13716view=rev Author: vszakats Date: 2010-01-26 14:48:53 + (Tue, 26 Jan 2010) Log Message: --- 2010-01-26 15:47 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * utils/hbmk2/hbmk2.prg + Added -hbexe option. This is the default, but it may help hbide and other tools to clear doubts about target type. (or to override some previous -hbdyn/-hblib options for whatever reasons) * contrib/hbide/ideprojmanager.prg * hbMK2.exe - hbmk2 Executable .exe extension is Win/OS2/DOS specific. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/ideprojmanager.prg trunk/harbour/utils/hbmk2/hbmk2.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbwin.lib error
Hi,
Now everyone who use WIN_PRN class has to link his code
with PNG library even if it's unnecessary.
PNG library is used in win_BitMapDimensions, now is not used in WIN_PRN class
to print win_BMPs class.
Note that now it's a RAW implementation driver dependent and some drivers don't
need the original dimensions to work.
Unfortunately the PNG support is few used in win drivers.
win_BitMapDimensions works fine and can be nice changed win_BMP class with
attache sample prg.
Perhaps in future, we can change it to not RAW driver dependent and convert these formats into DIB plane but now, I don't know
how do it and if this is correct.
What do you think about?
Best regards,
Xavi
CREATE CLASS WIN_BMP
EXPORTED:
METHOD New()
METHOD LoadFile( cFileName, aDimXY )
METHOD Create()
METHOD Destroy()
METHOD IsSupported( oPrn, nError )
METHOD Draw( oPrn, aRectangle, nError )
VAR Type INIT 0 // Type BitMap: 1 == BM, 2 == JPEG, 3
== PNG
VAR DimXYINIT { 0, 0 } // Image Dimensions X Y pixels
VAR Rect INIT { 0, 0, 0, 0 } // Coordinates to print BitMap
// XDest,//
x-coord of destination upper-left corner
// YDest,//
y-coord of destination upper-left corner
// nDestWidth, // width
of destination rectangle
// nDestHeight, //
height of destination rectangle
// See WinApi StretchDIBits()
VAR BitMap INIT
VAR FileName INIT
ENDCLASS
METHOD New() CLASS WIN_BMP
RETURN Self
METHOD LoadFile( cFileName, aDimXY ) CLASS WIN_BMP
::FileName := cFileName
::Bitmap := win_LoadBitMapFile( ::FileName )
IF Empty( ::Bitmap )
::Type := 0
::DimXY := { 0, 0 }
ELSE
::Type := win_bitmapType( ::Bitmap )
IF ISARRAY( aDimXY )
::DimXY := aDimXY
ELSEIF ! win_BitMapDimensions( ::Bitmap, @::DimXY[1], @::DimXY[2] )
::DimXY := { 1, 1 } // Driver may use the original dimensions
ENDIF
ENDIF
RETURN ::Type != HB_WIN_BITMAP_UNKNOWN
METHOD Create() CLASS WIN_BMP // Compatibility function for Alaska Xbase++
RETURN Self
METHOD Destroy() CLASS WIN_BMP // Compatibility function for Alaska Xbase++
RETURN NIL
METHOD IsSupported( oPrn, nError ) CLASS WIN_BMP
RETURN ( nError := win_BitmapIsSupported( oPrn:hPrinterDc, ::Bitmap ) ) == 0
METHOD Draw( oPrn, aRectangle, nError ) CLASS WIN_BMP // Pass a WIN_PRN object
reference Rectangle array
IF ISARRAY( aRectangle )
::Rect := aRectangle
ENDIF
RETURN IIF( ::IsSupported( oPrn, @nError ), oPrn:DrawBitMap( Self ), .F. )
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbwin.lib error
On Tue, 26 Jan 2010, Xavi wrote: Hi, Now everyone who use WIN_PRN class has to link his code with PNG library even if it's unnecessary. PNG library is used in win_BitMapDimensions, now is not used in WIN_PRN class to print win_BMPs class. It is because it's in the same file as other functions used by WIN_BMP class and WIN_BMP class is used by WIN_PRN. Just simply try to link this code without png library: proc main() win_prn() return Anyhow moving WIN_BITMAPDIMENSIONS() to separate file is also good idea. It would resolve current dependency problem. Anyhow if you want to use above function in WIN_BMP class then we still need some type of startup initialization controlled by REQUEST mechanism. Note that now it's a RAW implementation driver dependent and some drivers don't need the original dimensions to work. Unfortunately the PNG support is few used in win drivers. win_BitMapDimensions works fine and can be nice changed win_BMP class with attache sample prg. Perhaps in future, we can change it to not RAW driver dependent and convert these formats into DIB plane but now, I don't know how do it and if this is correct. What do you think about? It's good idea but it would be very nice to keep it modular. We can try to use startup initialization or we can define separate classes with common interface i.e. HB_PNG which can be accepted by WIN_PRN just like WIN_BMP. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbwin.lib error
Hi Xavi (and also Przemek), On 2010 Jan 26, at 16:32, Xavi wrote: Now everyone who use WIN_PRN class has to link his code with PNG library even if it's unnecessary. PNG library is used in win_BitMapDimensions, now is not used in WIN_PRN class to print win_BMPs class. Note that now it's a RAW implementation driver dependent and some drivers don't need the original dimensions to work. Unfortunately the PNG support is few used in win drivers. win_BitMapDimensions works fine and can be nice changed win_BMP class with attache sample prg. Perhaps in future, we can change it to not RAW driver dependent and convert these formats into DIB plane but now, I don't know how do it and if this is correct. What do you think about? The BMP class modifications are all good, but the WIN_BMP() separation would not by itself solve the libpng dependency, since WIN_DRAWBITMAP() is still used from WIN_PRN(), and this function resides in the same file where PNG dependent stuff is. Plus even we separate those two, the libpng dependency stays to be a problem for everyone using WIN_BMP(), and since everyone likes to print logos, I'd guess many (if not most) users would end up needed libpng anyway. For me BTW, libpng dependency isn't such a huge problem, and creating such dependencies is sooner or later inevitable, which means on the longer term it cannot be avoided with tricks anyway. What is important IMO is to solve such dependency so that it works on all supported platforms and environments, and in this case I think the problem part could cross-builds. I hope someone can test it. For pure Windows users it's as easy as adding libpng to the liblist or using hbwin.hbc as I told previously. We're in trunk so such changes are acceptable, and users following development should adapt now, final users can adapt on next release. After all .png printing is quite an important feature these days. As for converting PNG/JPEG to DIB, I absolutely agree. It just have to be written. For JPEG support we will need to include it in /external, and if there is no objection I can do it even now, I have it ready locally since quite some time now, just upgraded to v8 days ago. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbwin.lib error
I'll commit the separation ASAP, to clear that part up. Brgds, Viktor On 2010 Jan 26, at 16:53, Przemysław Czerpak wrote: On Tue, 26 Jan 2010, Xavi wrote: Hi, Now everyone who use WIN_PRN class has to link his code with PNG library even if it's unnecessary. PNG library is used in win_BitMapDimensions, now is not used in WIN_PRN class to print win_BMPs class. It is because it's in the same file as other functions used by WIN_BMP class and WIN_BMP class is used by WIN_PRN. Just simply try to link this code without png library: proc main() win_prn() return Anyhow moving WIN_BITMAPDIMENSIONS() to separate file is also good idea. It would resolve current dependency problem. Anyhow if you want to use above function in WIN_BMP class then we still need some type of startup initialization controlled by REQUEST mechanism. Note that now it's a RAW implementation driver dependent and some drivers don't need the original dimensions to work. Unfortunately the PNG support is few used in win drivers. win_BitMapDimensions works fine and can be nice changed win_BMP class with attache sample prg. Perhaps in future, we can change it to not RAW driver dependent and convert these formats into DIB plane but now, I don't know how do it and if this is correct. What do you think about? It's good idea but it would be very nice to keep it modular. We can try to use startup initialization or we can define separate classes with common interface i.e. HB_PNG which can be accepted by WIN_PRN just like WIN_BMP. 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
[Harbour] jpeg lib to /external
Hi All, Any objection to commit it? Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbIDE[ 15 ] import also from harbour makefile
15 each library in harbour have a makefile that allow compile with win-make all modules How hbide Will be used for easy editing harbour itself? Two way may be used: open as way:hbdir use same makefile information for editing project Import project way: from one makefile to hbc like for xmate My idea is to give any hbIDE request a number reply to __THIS THREAD_ but with new topic heading containing first words as hbIDE[ 14 ] Any feature you want and in message body explain it. One reply per request. And remember to reply to _THIS THREAD_ whenever a new number is assigned. Above compilation assigns 13 numbers, next starts at 14. Again I request to follow this methodology. Regards Pritpal Bedi -- -- Massimo Belgrano ne ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbIDE[ 15 ] import also from harbour makefile
15 each library in harbour have a makefile that allow compile with win-make all modules How hbide Will be used for easy editing harbour itself? Two way may be used: open as way:hbdir use same makefile information for editing project Import project way: from one makefile to hbc like for xmate IMO HBIDE has nothing to do with our GNU Makefiles. Now Harbour examples already have an .hbp file each, and on the longer run I plan to add .hbp files to each contrib also, as soon as we make the switch from GNU Make to hbmk2 build system for them. At this point each contrib will be just a normal 3rd party lib hosted in Harbour SVN, and HBIDE can be used to open them as is. I'd think this direction is a better investment that making HBIDE suited to read all the makefiles in the world. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbIDE[ 15 ] import also from harbour makefile
Yes agree wit you but i think that with this feature hbide will be usefull also for xharbour or other project with that use gnu makefiles. IMO HBIDE has nothing to do with our GNU Makefiles. Now Harbour examples already have an .hbp file each, and on the longer run I plan to add .hbp files to each contrib also, as soon as we make the switch from GNU Make to hbmk2 build system for them. At this point each contrib will be just a normal 3rd party lib hosted in Harbour SVN, and HBIDE can be used to open them as is. I'd think this direction is a better investment that making HBIDE suited to read all the makefiles in the world. -- Massimo Belgrano ___ 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:[13717] trunk/harbour
Revision: 13717 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13717view=rev Author: vszakats Date: 2010-01-26 16:27:27 + (Tue, 26 Jan 2010) Log Message: --- 2010-01-26 17:26 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/Makefile * contrib/hbwin/hbwin.h * contrib/hbwin/win_bmp.c + contrib/hbwin/win_bmpd.c * contrib/hbwin/win_tprn.prg + contrib/hbwin/win_tbmp.prg + Moved WIN_BMP() class to separate source file. + Moved WIN_BITMAPDIMENSIONS() and its low-level support functions to separate source file, to avoid creating unwanted dependency to libpng. + Applied Xavi's patches to WIN_BMP(). * Restored nError parameter for ::IsSupported() * ::LoadFile() now fills dimensions automatically. * ::Draw() 3rd dim array parameter replaced with nError. * contrib/hbwin/hbwapi.h + Added 'extern' keyword. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/Makefile trunk/harbour/contrib/hbwin/hbwapi.h trunk/harbour/contrib/hbwin/hbwin.h trunk/harbour/contrib/hbwin/win_bmp.c trunk/harbour/contrib/hbwin/win_tprn.prg Added Paths: --- trunk/harbour/contrib/hbwin/win_bmpd.c trunk/harbour/contrib/hbwin/win_tbmp.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] hbIDE[ 15 ] import also from harbour makefile
Yes agree wit you but i think that with this feature hbide will be usefull also for xharbour or other project with that use gnu makefiles. Please note that 'makefile' is not a standard file format, it's rather a language. There cannot be a generic reader written for it, unless HBIDE will contain a full blown GNU Make script parser, which is IMO not our goal. Even Harbour 'Makefile' content is not trivial to parse, and doesn't contain enough information to create a build from it. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbIDE[ 15 ] import also from harbour makefile
Massimo Where did you follow it ? My idea is to give any hbIDE request a number reply to __THIS THREAD_ but with new topic heading containing first words as You have _NOT_REPLIED_ to the original thread instead has sent a new post. Pritpal Bedi Massimo Belgrano-3 wrote: 15 each library in harbour have a makefile that allow compile with win-make all modules How hbide Will be used for easy editing harbour itself? Two way may be used: open as way:hbdir use same makefile information for editing project Import project way: from one makefile to hbc like for xmate My idea is to give any hbIDE request a number reply to __THIS THREAD_ but with new topic heading containing first words as hbIDE[ 14 ] Any feature you want and in message body explain it. One reply per request. And remember to reply to _THIS THREAD_ whenever a new number is assigned. Above compilation assigns 13 numbers, next starts at 14. Again I request to follow this methodology. Regards Pritpal Bedi -- -- View this message in context: http://old.nabble.com/hbIDE--15---import-also-from-harbour-makefile-tp27325237p27325629.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbIDE[ 15 ] import also from harbour makefile
15 each library in harbour have a makefile that allow compile with win-make all modules How hbide Will be used for easy editing harbour itself? Two way may be used: open as way:hbdir use same makefile information for editing project Import project way: from one makefile to hbc like for xmate IMO HBIDE has nothing to do with our GNU Makefiles. Now Harbour examples already have an .hbp file each, and on the longer run I plan to add .hbp files to each contrib also, as soon as we make the switch from GNU Make to hbmk2 build system for them. At this point each contrib will be just a normal 3rd party lib hosted in Harbour SVN, and HBIDE can be used to open them as is. I'd think this direction is a better investment that making HBIDE suited to read all the makefiles in the world. Yes agree wit you but i think that with this feature hbide will be usefull also for xharbour or other project with that use gnu makefiles. Please note that 'makefile' is not a standard file format, it's rather a language. There cannot be a generic reader written for it, unless HBIDE will contain a full blown GNU Make script parser, which is IMO not our goal. Even Harbour 'Makefile' content is not trivial to parse, and doesn't contain enough information to create a build from it. -- View this message in context: http://old.nabble.com/hbIDE---Requested-Thought-of-Features-Tracking-tp27313368p27325735.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] SF.net SVN: harbour-project:[13716] trunk/harbour
Hi Viktor Szakáts wrote: To decide whether the target is Executable (-hbexe), Dynamic lib (-hbdyn) or Static lib (-hblib) Ok, I got it. It means it is approptiate to change the label Dll to Dynamic Library in Projects tree. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13716--trunk-harbour-tp27323795p27325856.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Hash docs
Hi, documentation of the 3rd numeric parameter of HB_HMERGE() in doc/en-EN/hashes.txt is for sure not correct. Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13716] trunk/harbour
Hi, Viktor Szakáts wrote: To decide whether the target is Executable (-hbexe), Dynamic lib (-hbdyn) or Static lib (-hblib) Ok, I got it. It means it is approptiate to change the label Dll to Dynamic Library in Projects tree. Yes. Pls make sure to fall back to Executable if none of these options are found in .hbp. Brdgs, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Compiling Postgres Lib in Windows
I don' t have postgres includes in my instalation Which package i need to install to get this files ? Postgres Standard Binary instalation do not have it Bruno ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbIDE[ 16 ] xMate Project Load - How to handle .lib(s)
Hello Viktor How should I handle .lib extensions while converting from a .xhp file? One way I think is: c:\myfolder\mylib.lib Strip the paths from all .libs Club common paths in link properties = -Lc:\myfolder Put only file name without extension = -lmylib Or there is a better way ? Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/hbIDE---Requested-Thought-of-Features-Tracking-tp27313368p27325973.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] hbIDE[ 15 ] import also from harbour makefile
No i have reply from my gmai but i have deleted part of messages 2010/1/26 Pritpal Bedi bediprit...@hotmail.com: Massimo Where did you follow it ? My idea is to give any hbIDE request a number reply to __THIS THREAD_ but with new topic heading containing first words as You have _NOT_REPLIED_ to the original thread instead has sent a new post. Pritpal Bedi Massimo Belgrano-3 wrote: 15 each library in harbour have a makefile that allow compile with win-make all modules How hbide Will be used for easy editing harbour itself? Two way may be used: open as way:hbdir use same makefile information for editing project Import project way: from one makefile to hbc like for xmate My idea is to give any hbIDE request a number reply to __THIS THREAD_ but with new topic heading containing first words as hbIDE[ 14 ] Any feature you want and in message body explain it. One reply per request. And remember to reply to _THIS THREAD_ whenever a new number is assigned. Above compilation assigns 13 numbers, next starts at 14. Again I request to follow this methodology. Regards Pritpal Bedi -- -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbIDE[ 16 -17 ]
Hi Pripal, How about a feature to insert with a press of a key the missing 'close code construct' like endif , next , endcase. a beautifier. Now this needs a lot of user customization options. Great work anyhow! keep it up! Thanks, Abe -- View this message in context: http://old.nabble.com/hbIDE---Requested-Thought-of-Features-Tracking-tp27313368p27326007.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] hbIDE[ 16 ] xMate Project Load - How to handle .lib(s)
Hi Pritpal, On 2010 Jan 26, at 17:55, Pritpal Bedi wrote: Hello Viktor How should I handle .lib extensions while converting from a .xhp file? One way I think is: c:\myfolder\mylib.lib Strip the paths from all .libs Club common paths in link properties = -Lc:\myfolder Put only file name without extension = -lmylib Yes, this is the proper way. Or there is a better way ? hbmk2 already has an xMate to .hbp conversion option, I'd suggest to use this in HBIDE: hbmk2 -xhp=file.xhp Pls hold on a little, I have to commit some fix to it. In the meantime could you send me a sample .xhp file? hbmk2 doesn't currently support parsing lib files, as I probably didn't have such example. 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:[13718] trunk/harbour
Revision: 13718 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13718view=rev Author: vszakats Date: 2010-01-26 17:30:09 + (Tue, 26 Jan 2010) Log Message: --- 2010-01-26 18:29 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * utils/hbmk2/hbmk2.prg ! Fixed -xhp option which didn't save the result due to copy/paste typo. [TOMERGE 2.0] 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] hbIDE[ 16 ] xMate Project Load - How to handle .lib(s)
Or there is a better way ? hbmk2 already has an xMate to .hbp conversion option, I'd suggest to use this in HBIDE: hbmk2 -xhp=file.xhp Pls hold on a little, I have to commit some fix to it. In the meantime could you send me a sample .xhp file? hbmk2 doesn't currently support parsing lib files, as I probably didn't have such example. Nevermind I've found some samples. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbIDE[ 16 -17 ]
a Beautifier will go thru code and indent/Outdent the lines properly. number of spaces before/after operators like == := delete double spaced lines. capitalize keywords properly etc. -- View this message in context: http://n2.nabble.com/hbIDE-Requested-Thought-of-Features-Tracking-tp4456648p4462194.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] hbwin.lib error
On Tue, 26 Jan 2010, Szak�ts Viktor wrote: Hi, I'll commit the separation ASAP, to clear that part up. Thank you. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] jpeg lib to /external
On Tue, 26 Jan 2010, Szak�ts Viktor wrote: Hi, Any objection to commit it? No, it's good idea. Thank you. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Hash docs
On Tue, 26 Jan 2010, Mindaugas Kavaliauskas wrote: Hi, documentation of the 3rd numeric parameter of HB_HMERGE() in doc/en-EN/hashes.txt is for sure not correct. Yes, it is wrong. HB_HMERGRE( h1, h2 [, nMethod | bCode ] ) if 3-rd parameter is codeblock then it is evaluated against each item pair (key=value) in source (h2) hash array. It receives 3 parameters: key, value, position. Then if it returns true the given item pair (key=value) is added to the destination hash array. if 3-rd parameter is numeric value then it defines method of sets merging. It can be: #define HB_HASH_UNION 0 /* logical OR on items in two hash tables */ #define HB_HASH_INTERSECT 1 /* logical AND on items in two hash tables */ #define HB_HASH_DIFFERENCE 2 /* logical XOR on items in two hash tables */ #define HB_HASH_REMOVE 3 /* h1 ( h1 ^ h2 ) */ by default HB_HASH_UNION is used. best regards, Przemek ___ 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:[13704] trunk/harbour
On Tue, 26 Jan 2010, Szak�ts Viktor wrote: [...] Hi, Thank you very much for the explanation. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: R: [Harbour] CDX RDD question (live usage/compatibility)
On Tue, 26 Jan 2010, Maurizio la Cecilia wrote: Ok. My mistake. I based my choice on xHarbour manual saying: Setting the locking scheme to 1 will lock the database files like CA-Clipper 5.2 does. To use CA-Clipper 5.3's locking scheme, set DBFLOCKSCHEME to 2. This will emulate shared locks using exclusive locks. Visual FoxPro's locking scheme is selected with DBFLOCKSCHEME set to 3. 1 works like CL52/CL53 DBFNTX if you do not link ntxlock.obj with your code. If you are using HB_CODEPAGE_IT850 in Harbour then you have to link your Clipper application with ntxita.obj. Otherwise index files will be corrupted because Clipper and Harbour will use different collation orders. I ever link ntxita.obj, also in DBFNTX build. The name is confusion. These .obj files change collation order in Clipper VM and all index formats not omnly NTX. Harbour and CL53 DBFCDX/COMIX do not support none compound IDX indexes so I guess you are using CL52 DBFCDX or SIXCDX driver. Sorry, i was meaning production .CDX multitag indexes... And what was your problem? The problem is ONLY in Cl52+DBFCDX. With app built with Harbour or Cl52+DBFNTX all works fine. The Rlock() returns .t. in all the builded app, BUT ONLY in Cl52+DBFCDX exits a Lock required error at subsequent field replace. This happens also if the Cl52+DBFCDX is the ONLY program running on the network... So, i think that the problem is not deriving from my code... Same code works fine in all other points of app updating a record. The DBFCDX driver from CL5.2 has few very serious bugs which can cause memory corruption which can cause any other bad side effects so everything is possible. The feel i receive from your message is that i'm going in a puzzled challenge, so i think i'll have two options: A) To leave the Cl52+DBFNTX app, working well from twenty year ago, and to change the driver of Harbour to DBFNTX It's possible. B) To take the courage of replace with Harbour+DBFCDX all the install It's probably safer method. Anyhow as long as some network transport layer does not cause some separate buffering which can cause problems when DOS and Windows applications access files concurrently then it should be safe to share database files and indexes between Clipper and Harbour. It's enough to set compatible national sorting and locking schemes. I don't know the effectiveness of the DBFNTX in Harbour, so i ask you if also the A) choice is dangerous and the pure Harbour path is the only affordable. In Harbour DBFNTX is probably much faster then in Clipper and for sure they can be used to index realy big tables (I know that some people use Harbour only to reindex files for Clipper due to huge speed differnce and the fact that over some size limits Clipper begins to GPF during indexing). Harbour DBFNTX implementation also supports all CDX extensions and few others but you will not be able to enable all of them if you want to share data with Clipper. Compound index, large NTX file support up to 4TB or using RECNO as hidden part of index key to eliminate linear scan during record updating in indexes uses keys with big number of repeated values are extensions which change index formats and I implemented them only in Harbour and xHarbour so only in these languages can operate on such NTX indexes. Technically NTX format is much faster then CDX. In the ideal environment where you have a lot of RAM and you can keep index files in memory CDX is many times slower then NTX. But we are not leaving in ideal world and in most of cases indexes are accessed using slow network connections. It means that the size of index files will determinate the speed. CDX files store keys in leaf nodes in compressed form what greatly reduces the total index size and it's the reason of better overall performance when the cost of reading/writing from/to index file is very big, i.e. files are stored on file server. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbIDE[ 16 -17 ]
AbeB wrote: a Beautifier will go thru code and indent/Outdent the lines properly. number of spaces before/after operators like == := delete double spaced lines. capitalize keywords properly etc. Some formatting constructs are there in EditFormat option. But I agree a full blown formatter is a must applied in full source or a fragmanet thereof. We will think about it later as to what tool to use, hbformat or xMate's. Pritpal Bedi -- View this message in context: http://n2.nabble.com/hbIDE-Requested-Thought-of-Features-Tracking-tp4456648p4462664.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] Clipper vs Harbour: exclusive access
On Tue, 26 Jan 2010, Saulius Zrelskis wrote: Hi, I want to share my observations how differs Clipper and Harbour IO activity on exclusive opened dbf file. Clipper 5.2 and 5.3 module dbf1.c, function dbfRead on shared database reads only selected record with _fsRead, but for exclusive database reads in 1024 bytes chunks as many records, as possible with _xpage_read. The same with writing: shared with _fsWrite and exclusive with _xpage_update. Yes. Clipper seems to use the same caches with 1024 bytes page size for indexes and exclusive mode DBF tables. Harbour reads and writes records one-by-one not depending on access mode. Harbour does not use any caches so far with the exception to index tree paths but it's only few pages so it can be ignored. Prepared simple wrappers to Clipper low-level APIs _fs*, and Harbour APIs hb_fs* from module filesys.c registers calls to these APIs. [...] From logs we can see, that Clipper uses for this sample 12 calls (4 read and 8 write). Harbour uses 302 calls (102 read and 180 write)! Log file attached. Clipper uses buffering data on IO requests. Buffering can speed up IO quite a bit. Rather than reading one record at a time from the network or disk, Clipper reads a larger block at a time. This is typically much faster, big amount of IO requests detrimental to performance in network environment. Is there plans to introduce buffered IO for dbf files? In current RDD code all IO API is redirected to replaceable IO functions so anyone can write such caching system for all core RDDs without touching their code. It's enough to write simple HB_FILE IO driver like NETIO or MEMIO. I can try to write it in some spare time but maybe someone else can do it too. As I can see you wrote some wrappers to Clipper functions so I guess you have enough knowledge to create new HB_FILE IO driver adding buffering for all files open in exclusive mode with name starting with buf:. What do you think about it? 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:[13719] trunk/harbour
Revision: 13719 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13719view=rev Author: vszakats Date: 2010-01-26 19:38:16 + (Tue, 26 Jan 2010) Log Message: --- 2010-01-26 20:33 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * harbour.spec * INSTALL * external/Makefile + external/jpeg + external/jpeg/README + external/jpeg/link.txt + external/jpeg/Makefile + external/jpeg/cderror.h + external/jpeg/cdjpeg.h + external/jpeg/jaricom.c + external/jpeg/jcapimin.c + external/jpeg/jcapistd.c + external/jpeg/jcarith.c + external/jpeg/jccoefct.c + external/jpeg/jccolor.c + external/jpeg/jcdctmgr.c + external/jpeg/jchuff.c + external/jpeg/jcinit.c + external/jpeg/jcmainct.c + external/jpeg/jcmarker.c + external/jpeg/jcmaster.c + external/jpeg/jcomapi.c + external/jpeg/jconfig.h + external/jpeg/jcparam.c + external/jpeg/jcprepct.c + external/jpeg/jctrans.c + external/jpeg/jcsample.c + external/jpeg/jdapimin.c + external/jpeg/jdapistd.c + external/jpeg/jdarith.c + external/jpeg/jdatadst.c + external/jpeg/jdatasrc.c + external/jpeg/jdcoefct.c + external/jpeg/jdcolor.c + external/jpeg/jdct.h + external/jpeg/jddctmgr.c + external/jpeg/jdhuff.c + external/jpeg/jdinput.c + external/jpeg/jdmainct.c + external/jpeg/jdmarker.c + external/jpeg/jdmaster.c + external/jpeg/jdmerge.c + external/jpeg/jdpostct.c + external/jpeg/jdsample.c + external/jpeg/jdtrans.c + external/jpeg/jerror.c + external/jpeg/jerror.h + external/jpeg/jfdctflt.c + external/jpeg/jfdctfst.c + external/jpeg/jfdctint.c + external/jpeg/jidctflt.c + external/jpeg/jidctfst.c + external/jpeg/jidctint.c + external/jpeg/jinclude.h + external/jpeg/jmemansi.c + external/jpeg/jmemdos.c + external/jpeg/jmemmac.c + external/jpeg/jmemmgr.c + external/jpeg/jmemname.c + external/jpeg/jmemnobs.c + external/jpeg/jmemsys.h + external/jpeg/jmorecfg.h + external/jpeg/jpegint.h + external/jpeg/jpeglib.h + external/jpeg/jquant1.c + external/jpeg/jquant2.c + external/jpeg/jutils.c + external/jpeg/jversion.h + external/jpeg/rdbmp.c + external/jpeg/rdcolmap.c + external/jpeg/rdgif.c + external/jpeg/rdppm.c + external/jpeg/rdrle.c + external/jpeg/rdswitch.c + external/jpeg/rdtarga.c + external/jpeg/transupp.c + external/jpeg/transupp.h + external/jpeg/wrbmp.c + external/jpeg/wrgif.c + external/jpeg/wrjpgcom.c + external/jpeg/wrppm.c + external/jpeg/wrrle.c + external/jpeg/wrtarga.c + Added JPEG lib v8. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL trunk/harbour/external/Makefile trunk/harbour/harbour.spec Added Paths: --- trunk/harbour/external/jpeg/ trunk/harbour/external/jpeg/Makefile trunk/harbour/external/jpeg/README trunk/harbour/external/jpeg/cderror.h trunk/harbour/external/jpeg/cdjpeg.h trunk/harbour/external/jpeg/jaricom.c trunk/harbour/external/jpeg/jcapimin.c trunk/harbour/external/jpeg/jcapistd.c trunk/harbour/external/jpeg/jcarith.c trunk/harbour/external/jpeg/jccoefct.c trunk/harbour/external/jpeg/jccolor.c trunk/harbour/external/jpeg/jcdctmgr.c trunk/harbour/external/jpeg/jchuff.c trunk/harbour/external/jpeg/jcinit.c trunk/harbour/external/jpeg/jcmainct.c trunk/harbour/external/jpeg/jcmarker.c trunk/harbour/external/jpeg/jcmaster.c trunk/harbour/external/jpeg/jcomapi.c trunk/harbour/external/jpeg/jconfig.h trunk/harbour/external/jpeg/jcparam.c trunk/harbour/external/jpeg/jcprepct.c trunk/harbour/external/jpeg/jcsample.c trunk/harbour/external/jpeg/jctrans.c trunk/harbour/external/jpeg/jdapimin.c trunk/harbour/external/jpeg/jdapistd.c trunk/harbour/external/jpeg/jdarith.c trunk/harbour/external/jpeg/jdatadst.c trunk/harbour/external/jpeg/jdatasrc.c trunk/harbour/external/jpeg/jdcoefct.c trunk/harbour/external/jpeg/jdcolor.c trunk/harbour/external/jpeg/jdct.h trunk/harbour/external/jpeg/jddctmgr.c trunk/harbour/external/jpeg/jdhuff.c trunk/harbour/external/jpeg/jdinput.c trunk/harbour/external/jpeg/jdmainct.c trunk/harbour/external/jpeg/jdmarker.c trunk/harbour/external/jpeg/jdmaster.c trunk/harbour/external/jpeg/jdmerge.c trunk/harbour/external/jpeg/jdpostct.c trunk/harbour/external/jpeg/jdsample.c trunk/harbour/external/jpeg/jdtrans.c trunk/harbour/external/jpeg/jerror.c trunk/harbour/external/jpeg/jerror.h trunk/harbour/external/jpeg/jfdctflt.c trunk/harbour/external/jpeg/jfdctfst.c trunk/harbour/external/jpeg/jfdctint.c trunk/harbour/external/jpeg/jidctflt.c trunk/harbour/external/jpeg/jidctfst.c trunk/harbour/external/jpeg/jidctint.c trunk/harbour/external/jpeg/jinclude.h trunk/harbour/external/jpeg/jmemansi.c trunk/harbour/external/jpeg/jmemdos.c trunk/harbour/external/jpeg/jmemmac.c
[Harbour] SF.net SVN: harbour-project:[13720] trunk/harbour
Revision: 13720 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13720view=rev Author: vszakats Date: 2010-01-26 19:41:36 + (Tue, 26 Jan 2010) Log Message: --- 2010-01-26 20:40 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * utils/hbmk2/hbmk2.prg + -xhp= converter switch now recognizes some more types of file. (lib, object and libpaths) * contrib/hbnetio/utils/netiosrv.prg * contrib/hbnetio/utils/netiocmd.prg - Deleted call protection. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbnetio/utils/netiocmd.prg trunk/harbour/contrib/hbnetio/utils/netiosrv.prg trunk/harbour/utils/hbmk2/hbmk2.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13721] trunk/harbour
Revision: 13721 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13721view=rev Author: vszakats Date: 2010-01-26 19:44:16 + (Tue, 26 Jan 2010) Log Message: --- 2010-01-26 20:43 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * utils/hbmk2/hbmk2.prg ! Deleted one debug line left in previous commit. 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] Can be Harbour have tool like Glade working with it...?
Just curious of your answers... I'm looking for some cross platform tool to quickly design user interface and then refine event methods and then compile it with harbour Something similar to this http://glade.gnome.org/ ( Glade + Python ) http://www.linuxjournal.com/article/7421 Can be a hbide future extension...? Thank you and best regards. ___ 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:[13719] trunk/harbour
Hi Viktor, Thank you very much. It's wonderful include! Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compiling Postgres Lib in Windows
Bruno, Which package i need to install to get this files ? Download the sources .- http://www.postgresql.org/ftp/source Also, I think that zip archive has the includes .- http://www.postgresql.org/download/windows Advanced users can also download a _zip archive_ of the binaries, without the installer. -- Xavi El 26/01/2010 17:55, Bruno Luciani escribió: I don' t have postgres includes in my instalation Which package i need to install to get this files ? Postgres Standard Binary instalation do not have it Bruno ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Warnings
Warning W8004 ../../../win_bmpd.c 142: 'nPos' is assigned a value that is never used in function hb_jpeg_get_param Warning W8004 ../../../win_bmpd.c 84: 'bpc' is assigned a value that is never used in function hb_jpeg_get_param Warning W8004 ../../../win_bmpd.c 83: 'colorspace' is assigned a value that is never used in function hb_jpeg_get_param Warning W8004 ../../../win_bmpd.c 82: 'width' is assigned a value that is never used in function hb_jpeg_get_param Warning W8004 ../../../win_bmpd.c 81: 'height' is assigned a value that is never used in function hb_jpeg_get_param Warning W8001 ../../../win_bmpd.c 248: Superfluous with function in function hb_png_get_param EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Can be Harbour have tool like Glade working with it...?
marco bra wrote: I'm looking for some cross platform tool to quickly design user interface and then refine event methods and then compile it with harbour Something similar to this http://glade.gnome.org/ ( Glade + Python ) http://www.linuxjournal.com/article/7421 Can be a hbide future extension...? Why should we concentrate on GTK when all our future goals are planned for Qt ? I have on my TODO list, integration of Qt Creator through Hbp*() classes. Qt Creator generates a .ui file and hbIDE is already taking advantage of .ui files. We just need to polish this HbpQtUI() class to embed events, though practically you can do it right now. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Can-be-Harbour-have-tool-like-Glade-working-with-it-tp4463143p4463319.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] What's wrong with this define?
Abeb wrote: #define xlCenter (0xEFF4) i know that it's 4294963188, but why does it work in other languages and not in Harbour? I think that Harbour use type HB_LONG defined as LONGLONG, and LONGLONG is 64bit type Adam -- View this message in context: http://old.nabble.com/What%27s-wrong-with-this-define--tp27312947p27329881.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13722] trunk/harbour
Revision: 13722 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13722view=rev Author: vszakats Date: 2010-01-26 21:20:24 + (Tue, 26 Jan 2010) Log Message: --- 2010-01-26 22:19 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_bmpd.c ! Pacified BCC warnings. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/win_bmpd.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:[13722] trunk/harbour
-Messaggio Originale- Da: vszak...@users.sourceforge.net A: harbour@harbour-project.org Data invio: martedì 26 gennaio 2010 22.20 Oggetto: [Harbour] SF.net SVN: harbour-project:[13722] trunk/harbour 2010-01-26 22:19 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_bmpd.c ! Pacified BCC warnings. Thank you. EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: R: [Harbour] CDX RDD question (live usage/compatibility)
-Messaggio originale- Da: Przemyslaw Czerpak [mailto:dru...@acn.waw.pl] Inviato: martedì 26 gennaio 2010 20.05 A: Harbour Project Main Developer List. Oggetto: Re: R: [Harbour] CDX RDD question (live usage/compatibility) 1 works like CL52/CL53 DBFNTX if you do not link ntxlock.obj with your code. Now it's clear. The name is confusion. These .obj files change collation order in Clipper VM and all index formats not omnly NTX. Yes. I know that. The feel i receive from your message is that i'm going in a puzzled challenge, so i think i'll have two options: A) To leave the Cl52+DBFNTX app, working well from twenty year ago, and to change the driver of Harbour to DBFNTX It's possible. B) To take the courage of replace with Harbour+DBFCDX all the install It's probably safer method. Anyhow as long as some network transport layer does not cause some separate buffering which can cause problems when DOS and Windows applications access files concurrently then it should be safe to share database files and indexes between Clipper and Harbour. It's enough to set compatible national sorting and locking schemes. I don't know the effectiveness of the DBFNTX in Harbour, so i ask you if also the A) choice is dangerous and the pure Harbour path is the only affordable. In Harbour DBFNTX is probably much faster then in Clipper and for sure they can be used to index realy big tables (I know that some people use Harbour only to reindex files for Clipper due to huge speed differnce and the fact that over some size limits Clipper begins to GPF during indexing). Harbour DBFNTX implementation also supports all CDX extensions and few others but you will not be able to enable all of them if you want to share data with Clipper. Compound index, large NTX file support up to 4TB or using RECNO as hidden part of index key to eliminate linear scan during record updating in indexes uses keys with big number of repeated values are extensions which change index formats and I implemented them only in Harbour and xHarbour so only in these languages can operate on such NTX indexes. Technically NTX format is much faster then CDX. In the ideal environment where you have a lot of RAM and you can keep index files in memory CDX is many times slower then NTX. But we are not leaving in ideal world and in most of cases indexes are accessed using slow network connections. It means that the size of index files will determinate the speed. CDX files store keys in leaf nodes in compressed form what greatly reduces the total index size and it's the reason of better overall performance when the cost of reading/writing from/to index file is very big, i.e. files are stored on file server. Your technical analysis is very useful and only now i realize that the NTX rdd is expanded in Harbour. A quick view on whatsnew.txt told me that was present yet in version 0.46. Anyway, the Harbour CDX install on all clients could be the safer choice, as you say. Again my great thanks for your support and kindness. Best regards. Maurizio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbIDE[ 16 -17 ]
Hi, Sorry for dropping in. hbformat could come in handy for this. Cheers Jerry - Original Message - From: Pritpal Bedi bediprit...@hotmail.com To: harbour@harbour-project.org Subject: Re: [Harbour] hbIDE[ 16 -17 ] Date: Tue, 26 Jan 2010 11:08:23 -0800 (PST) AbeB wrote: a Beautifier will go thru code and indent/Outdent the lines properly. number of spaces before/after operators like == := delete double spaced lines. capitalize keywords properly etc. Some formatting constructs are there in EditFormat option. But I agree a full blown formatter is a must applied in full source or a fragmanet thereof. We will think about it later as to what tool to use, hbformat or xMate's. Pritpal Bedi -- View this message in context: http://n2.nabble.com/hbIDE-Requested-Thought-of-Features-Tracking-tp4456648p4462664.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 -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Can be Harbour have tool like Glade working with it...?
Hi, If its not asking too much. Can you provide a small demo with tutorial to do this? Even a video will do. Thanks, Jerry - Original Message - From: Pritpal Bedi bediprit...@hotmail.com To: harbour@harbour-project.org Subject: [Harbour] Re: Can be Harbour have tool like Glade working with it...? Date: Tue, 26 Jan 2010 13:10:50 -0800 (PST) marco bra wrote: I'm looking for some cross platform tool to quickly design user interface and then refine event methods and then compile it with harbour Something similar to this http://glade.gnome.org/ ( Glade + Python ) http://www.linuxjournal.com/article/7421 Can be a hbide future extension...? Why should we concentrate on GTK when all our future goals are planned for Qt ? I have on my TODO list, integration of Qt Creator through Hbp*() classes. Qt Creator generates a .ui file and hbIDE is already taking advantage of .ui files. We just need to polish this HbpQtUI() class to embed events, though practically you can do it right now. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Can-be-Harbour-have-tool-like-Glade-working-with-it-tp4463143p4463319.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 -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbpqtui class
Hi Pritpal, hbpqtui is a QT specific class, and while I understand the feature is useful, such class should reside in HBQT, not HBXBP, since it's not, or not easily portable functionality. Just think about the case if we'd like to create an HBXBP compatible library, but based on a different GUI subsystem (GTK, WX, whatever). Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Can be Harbour have tool like Glade working with it...?
Jerry Finuliar wrote: If its not asking too much. Can you provide a small demo with tutorial to do this? Even a video will do. hbIDE itself is a working tutorial. Simply look into the sources, mainly ideprojmanager.prg and search for HbpQtUI(). The underlying dialog is generated by Qt Creator and relevant .ui is placed in harbour/conrib/hbide/resources/*.ui. Hope you will understand. I will write a descent help manual once I am done with hbIDE. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Can-be-Harbour-have-tool-like-Glade-working-with-it-tp4463143p4464777.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: Can be Harbour have tool like Glade working with it...?
Hi, Ok. Ill take a look. Hope I will get it. Thanks a lot for this tool. - Original Message - From: Pritpal Bedi bediprit...@hotmail.com To: harbour@harbour-project.org Subject: [Harbour] Re: Can be Harbour have tool like Glade working with it...? Date: Tue, 26 Jan 2010 17:58:43 -0800 (PST) Jerry Finuliar wrote: If its not asking too much. Can you provide a small demo with tutorial to do this? Even a video will do. hbIDE itself is a working tutorial. Simply look into the sources, mainly ideprojmanager.prg and search for HbpQtUI(). The underlying dialog is generated by Qt Creator and relevant .ui is placed in harbour/conrib/hbide/resources/*.ui. Hope you will understand. I will write a descent help manual once I am done with hbIDE. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Can-be-Harbour-have-tool-like-Glade-working-with-it-tp4463143p4464777.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 -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: hbpqtui class
Viktor Szakáts wrote: hbpqtui is a QT specific class, and while I understand the feature is useful, such class should reside in HBQT, not HBXBP, since it's not, or not easily portable functionality. Just think about the case if we'd like to create an HBXBP compatible library, but based on a different GUI subsystem (GTK, WX, whatever). It is scheduled to be compatible with Xbp framework. That is why I put it there. As I am only concerned with Qt at this moment I have decided it to be put under there only. Many more clsses are under pipeline as discussed earlier and I do not care what sub-sytems come in the future. So far nobody has even thought of them. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/hbpqtui-class-tp4464679p4464787.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: hbpqtui class
hbpqtui is a QT specific class, and while I understand the feature is useful, such class should reside in HBQT, not HBXBP, since it's not, or not easily portable functionality. Just think about the case if we'd like to create an HBXBP compatible library, but based on a different GUI subsystem (GTK, WX, whatever). It is scheduled to be compatible with Xbp framework. That is why I put it there. As I am only concerned with Qt at this moment I have decided it to be put under there only. Many more clsses are under pipeline as discussed earlier and I do not care what sub-sytems come in the future. So far nobody has even thought of them. I don't care? Great answer, so I don't care about HBQT + HBXBP + HBIDE either. That will free a lot of valuable time to spend on better things. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: hbpqtui class
Viktor Szakáts wrote: I don't care? Great answer, so I don't care about HBQT + HBXBP + HBIDE either. That will free a lot of valuable time to spend on better things. Upto you Viktor. You can delete these contributions from the SVN. Regards Pritpal Bedi - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/hbpqtui-class-tp4464679p4464822.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:[13723] trunk/harbour
Revision: 13723 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13723view=rev Author: vouchcac Date: 2010-01-27 02:22:27 + (Wed, 27 Jan 2010) Log Message: --- 2010-01-26 18:21 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/idemisc.prg * contrib/hbide/ideprojmanager.prg * contrib/hbxbp/hbpprocess.prg ! xMate project file .xhp loading more normalized. I could build almost all of my projects created from it. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/idemisc.prg trunk/harbour/contrib/hbide/ideprojmanager.prg trunk/harbour/contrib/hbxbp/hbpprocess.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] Re: hbpqtui class
Hi Pritpal, I don't care? Great answer, so I don't care about HBQT + HBXBP + HBIDE either. That will free a lot of valuable time to spend on better things. Upto you Viktor. You can delete these contributions from the SVN. Yes, it probably is a good idea to move them to separate project(s). The reason is that they grow in unbelievable rate, but even root problems are not solved and not even being dealt with (= ignored), and this I believe will take an unnecessarily huge amount of fixing work in a lot of existing code on all levels. In my view we should concentrate on the basics first and then build the upper levels on the this base. Plus it's also good if basic things agreed upon in the past are more or adhered to, or at least remembered. IMO we're at the point when moving HBQT, HBXBP and HBIDE to their own repositories would be of a benefit for all projects, without losing too much. Anyway I don't care is pretty much the opposite of how things are supposed to be done here in Harbour, particularly when it comes to basic system design methods. If you ignore these, the quality of these components will hardly be equal to that of Harbour. And if we want to keep quality image of Harbour intact (which is the result of 10 years of development in this spirit), all components should adhere to this. Please consider these, even if the heat of quick development is stronger these days. It's much harder to fix design problems afterwards. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0 stats after one month
Martin wrote: You guys may want to update Harbour's entry on freshmeat, on the FSF software list etc I wrote a few times in the past about this: http://lists.harbour-project.org/pipermail/harbour/2009-March/016556.html But no one had step in to update all these feeds. Chen. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Clipper vs Harbour: exclusive access
Hi Przemek, [...] so I guess you have enough knowledge to create new HB_FILE IO driver adding buffering for all files open in exclusive mode with name starting with buf:. What do you think about it? Sorry, still not enough ;( But I think if file starts with buf: prefix, file access mode can't influence buffering, this must be added for all prefixed files. Like in Novell client there are settings: 'file caching' (all files) and 'file caching on exclusively opened files'. It is user decision. Best regards, Saulius ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour-users] Re: how to ?
Itamar,
do you like a workaround ?
{|| MyFunc(oOwB, oObj) }
FUNCTION MyFun(oOwB, oObj)
RETURN MyFunc2(oOwB, oObj)
Regards
Itamar Lins escribió en mensaje ...
Hi!
how to resolve this is question?
{||MyFunc(oOwB , oObj)}
Error E0047 Code block contains both macro and declared symbol
references.
Best regards,
Itamar M. Lins Jr.
___
Harbour-users mailing list (attachment size limit: 40KB)
Harbour-users@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour-users
[Harbour-users] Re: how to ?
Itamar,
The trick is detached locals: A function returns a codeblock for each n
FOR n:= 1 TO 100
@ x, y . ON CLICK FunDetached(oOwB, oHora, n)
NEXT
*
FUNCTION FunDetached(oOwB, oHora, n)
RETURN {|| MyFunc(oOwB, oHora, n) }
*
*
FUNCTION MyFunc(oOwB, oHora, n)
RETURN Mesa(oOwB, oHora, n)
Regards
Itamar Lins escribió en mensaje ...
No, because oOwB change N times and Myfunc2 will return only the last.
For example
For n = 1 to 100
...
@ x,y OwnerButton oMesa of oDlgMesas Text cAtende+'
'+strzero(nCount,3) Coordinates 00,45,20,15 Size 60,60 ;
ON CLICK {||mesa(oOwB , oHora)} FLAT BITMAP cMesa TRANSPARENT
COORDINATES 0,0,41,41
...
{||mesa(oOwB)} //so it works well
{||mesa(oOwB,oHora)} //so it not works
Next
it should be changed at runtime!
Regards,
Itamar M. Lins Jr.
Antonio Martinez alcis...@arrakis.es
escreveu na mensagem news:hjm87k$bh...@ger.gmane.org...
Itamar,
do you like a workaround ?
{|| MyFunc(oOwB, oObj) }
FUNCTION MyFun(oOwB, oObj)
RETURN MyFunc2(oOwB, oObj)
Regards
Itamar Lins escribió en mensaje ...
Hi!
how to resolve this is question?
{||MyFunc(oOwB , oObj)}
Error E0047 Code block contains both macro and declared symbol
references.
Best regards,
Itamar M. Lins Jr.
___
Harbour-users mailing list (attachment size limit: 40KB)
Harbour-users@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour-users
