Re: [Harbour] bug: GTXWC and HB_GTI_WINTITLE
On Wed, 28 Oct 2009, Viktor Szakáts wrote: > hb_gtInfo( HB_GTI_WINTITLE, "string with accented chars" ) > > doesn't seem to respect app CP (like now f.e. GTWVT does) > with GTXWC, accented chars don't appear correctly in title > bar. > > I tried to fix it by converting to UTF8 in gtxwc.c, but I > may be missing something as it's still not right. this is a shot in the dark, but anyway. try adding XChangeProperty( wnd->dpy, wnd->window, XInternAtom( wnd->dpy, "_NET_WM_NAME", False ), XInternAtom( wnd->dpy, "UTF8_STRING", False ), 8, PropModeReplace, wnd->szTitle, strlen( wnd->szTitle )); right after calling XStoreName() in gtxwc.c (line 2965). it could be that it is needed after line 3358, but i couldn't quickly figure out what that block really is for (adding this there as well probably won't hurt anyway). -- [-] mkdir /nonexistent ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] bug: GTXWC and HB_GTI_WINTITLE
Hi All, hb_gtInfo( HB_GTI_WINTITLE, "string with accented chars" ) doesn't seem to respect app CP (like now f.e. GTWVT does) with GTXWC, accented chars don't appear correctly in title bar. I tried to fix it by converting to UTF8 in gtxwc.c, but I may be missing something as it's still not right. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12776] trunk/harbour
Hello Przemek Przemysław Czerpak wrote: > > I'm attaching it to the message sent to your private email address. > Received and reviewing. Please do not make any changes to your copy as I have formatted it a little. Gramatical review follows next. I must say that it is one of the finest analysis of a compiler internals I ever read. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/SF.net-SVN%3A-harbour-project%3A-12776--trunk-harbour-tp26075637p26086674.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12776] trunk/harbour
On Tue, 27 Oct 2009, Pritpal Bedi wrote: Hi Pritpal, > > BTW I created text which describes most important differences between > > Harbour and xHarbour. But it will be good if someone who know English > > fix me before I'll public it. > You can send it to me to look-at, if you decides so. Thank you very much. I'm attaching it to the message sent to your private email address. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
Hi sali, Should be solved after recent commit, you may give it a try in your environment. Brgds, Viktor On 2009 Oct 27, at 17:07, sali wrote: - Original Message - From: "Viktor Szakáts" > To: "Harbour Project Main Developer List." > Sent: Tuesday, October 27, 2009 3:56 PM Subject: Re: [Harbour] hbmk2 suggestion Okay I understand it this way. This is expected behavior as it detected your own C compiler installation (msvc), so it didn't idea is, if one select at install time no-msvc than to prepare config for hbmk2 not-to-set-msvc-as-default-even-if-there-is-msvc without user's knowledge), it's expected from user to choose MSVC libs. ha, except that is known that is hard to know what is "expectable" from the user's point-of-view [or to have readme.txt telling what is the search order algorythm for installed compilers] but ok ok, i don't want to waste your time on this ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12778] trunk/harbour
Revision: 12778 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12778&view=rev Author: druzus Date: 2009-10-27 18:49:44 + (Tue, 27 Oct 2009) Log Message: --- 2009-10-27 19:49 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/codepage/cpru866.c * harbour/src/codepage/cpruiso.c * harbour/src/codepage/cprukoi.c * harbour/src/codepage/cpruwin.c * harbour/src/codepage/cpua1125.c * harbour/src/codepage/cpua866.c * harbour/src/codepage/cpuakoi.c * harbour/src/codepage/cpuawin.c * use macros in codepage definition instead of direct constant values Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/src/codepage/cpru866.c trunk/harbour/src/codepage/cpruiso.c trunk/harbour/src/codepage/cprukoi.c trunk/harbour/src/codepage/cpruwin.c trunk/harbour/src/codepage/cpua1125.c trunk/harbour/src/codepage/cpua866.c trunk/harbour/src/codepage/cpuakoi.c trunk/harbour/src/codepage/cpuawin.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12776] trunk/harbour
Hi Przemysław Czerpak wrote: > > BTW I created text which describes most important differences between > Harbour and xHarbour. But it will be good if someone who know English > fix me before I'll public it. > You can send it to me to look-at, if you decides so. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/SF.net-SVN%3A-harbour-project%3A-12776--trunk-harbour-tp26075637p26082044.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12776] trunk/harbour
Hi Przemek, + added XHB_AINS(), XHB_ADEL() functions which accept negative indexes. Warning I haven't replicated xHarbour bugs in AINS() so it's not exactly the same. Sooner or later someone will fix AINS() code in xHarbour CVS. Such changelog entries always makes me smile. But I always have a question, how many xHarbour developers read this mailing list?.. :) At least Phil Krylov is reading it and ports some of bug fixes to xHarbour anyhow it's a serious question if it's worth to invest time in keeping xHarbour compatibility. I think we can stop all sort of syncing for now, as we have good enough support for majority of users wishing to switch to from xhb to Harbour. xhb core development looks essentially halted anyway, so there isn't too much new features to sync in the last few years. [ Only background processes comes to mind which is still missing from Harbour and may be used by app developers. ] BTW I created text which describes most important differences between Harbour and xHarbour. But it will be good if someone who know English fix me before I'll public it. Please publish it, otherwise it will be difficult for anyone to make fixes :) Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12777] trunk/harbour
Revision: 12777 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12777&view=rev Author: vszakats Date: 2009-10-27 16:39:24 + (Tue, 27 Oct 2009) Log Message: --- 2009-10-27 17:36 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/axcore.c * Replaced duplicated constant with HB_SIZEOFARRAY() macro. * utils/hbmk2/hbmk2.prg + C compiler autodetection will now make sure to skip compilers where required Harbour core libraries aren't installed. This autodetection is disabled when HB_LIB_INSTALL is set manually and also when lib/ dir is missing altogether, assuming there is a single-compiler installation used in this case (where such autodetection cannot work reliably). When using -info option, a screen message is shown if autodetected C compiler is skipped for above reason. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/axcore.c trunk/harbour/utils/hbmk2/hbmk2.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12776] trunk/harbour
On Tue, 27 Oct 2009, Mindaugas Kavaliauskas wrote: Hi, > >+ added XHB_AINS(), XHB_ADEL() functions which accept negative indexes. > > Warning I haven't replicated xHarbour bugs in AINS() so it's not > > exactly the same. Sooner or later someone will fix AINS() code in > > xHarbour CVS. > Such changelog entries always makes me smile. But I always have a > question, how many xHarbour developers read this mailing list?.. :) At least Phil Krylov is reading it and ports some of bug fixes to xHarbour anyhow it's a serious question if it's worth to invest time in keeping xHarbour compatibility. BTW I created text which describes most important differences between Harbour and xHarbour. But it will be good if someone who know English fix me before I'll public it. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
- Original Message - From: "Viktor Szakáts" To: "Harbour Project Main Developer List." Sent: Tuesday, October 27, 2009 3:56 PM Subject: Re: [Harbour] hbmk2 suggestion Okay I understand it this way. This is expected behavior as it detected your own C compiler installation (msvc), so it didn't idea is, if one select at install time no-msvc than to prepare config for hbmk2 not-to-set-msvc-as-default-even-if-there-is-msvc without user's knowledge), it's expected from user to choose MSVC libs. ha, except that is known that is hard to know what is "expectable" from the user's point-of-view [or to have readme.txt telling what is the search order algorythm for installed compilers] but ok ok, i don't want to waste your time on this ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
Okay I understand it this way. This is expected behavior as it detected your own C compiler installation (msvc), so it didn't use the embedded one. We can change priorities if this isn't no need, "compiler" switch to force compiler is ok, i just wanted to inform that there is "broken-link" betwen installation/setup where i selected during installation/setup not-to-expand msvc binaries [i wanted just embedded mingw] and run time hbmk2 which detected existing msvc compiler and defaulted to it although there were no previously expanded binaries for it, that's all. idea is, if one select at install time no-msvc than to prepare config for hbmk2 not-to-set-msvc-as-default-even-if-there-is-msvc I'm thinking the other way round: If someone has MSVC installed (and I believe MSVC doesn't get installed without user's knowledge), it's expected from user to choose MSVC libs. Maybe later someone else or I will add a feature to toggle each target platform compiler to add such extra level of configuration, but to me this seems to make it too much complicated and creates another factor to consider in every scenario (f.e. what if someone just copies/installs MSVC libs afterwards? What if MSVC libs are distributed separately) Next level could be that hbmk2 verifies if libs are actually available for a given detected target, and if not, it skips it. Probably that's the solution which need to be implemented, but not now. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
- Original Message - From: "Viktor Szakáts" To: "Harbour Project Main Developer List." Sent: Tuesday, October 27, 2009 2:56 PM Subject: Re: [Harbour] hbmk2 suggestion it happened with your integrated install, syenar.hu harbour-project, download from the end of september Okay I understand it this way. This is expected behavior as it detected your own C compiler installation (msvc), so it didn't use the embedded one. We can change priorities if this isn't no need, "compiler" switch to force compiler is ok, i just wanted to inform that there is "broken-link" betwen installation/setup where i selected during installation/setup not-to-expand msvc binaries [i wanted just embedded mingw] and run time hbmk2 which detected existing msvc compiler and defaulted to it although there were no previously expanded binaries for it, that's all. idea is, if one select at install time no-msvc than to prepare config for hbmk2 not-to-set-msvc-as-default-even-if-there-is-msvc ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
just to say that some additional docs about .hmb .hbc .hbp would be helpfull, since --help is to short to be sufficant i used examples also had problems with platform discovery, although msvc was not Did this happen with latest Harbour? Autodetection for MSVC should As for the docs, I won't have time for it (plus writing docs is it happened with your integrated install, syenar.hu harbour-project, download from the end of september Okay I understand it this way. This is expected behavior as it detected your own C compiler installation (msvc), so it didn't use the embedded one. We can change priorities if this isn't good, but the idea is that C compiler choice is of the user's and mingw should only play a role if nothing else is found. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12776] trunk/harbour
Hi, + added XHB_AINS(), XHB_ADEL() functions which accept negative indexes. Warning I haven't replicated xHarbour bugs in AINS() so it's not exactly the same. Sooner or later someone will fix AINS() code in xHarbour CVS. Such changelog entries always makes me smile. But I always have a question, how many xHarbour developers read this mailing list?.. :) Regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
- Original Message -
From: "Viktor Szakáts"
To: "Harbour Project Main Developer List."
Sent: Tuesday, October 27, 2009 1:39 PM
Subject: Re: [Harbour] hbmk2 suggestion
just to say that some additional docs about .hmb .hbc .hbp would be
helpfull, since --help is to short to be sufficant i used examples
also had problems with platform discovery, although msvc was not
Did this happen with latest Harbour? Autodetection for MSVC should
As for the docs, I won't have time for it (plus writing docs is
it happened with your integrated install, syenar.hu harbour-project,
download from the end of september
at the first moment, it was strange behaviour because the same downloaded
install on one computer produced app builds, on another broke.
later i found that hbmk2 [or some part of it] discovered msvc instance on
another computer, and used it as default compiler, but missed libs
[particularly ${hb_lib}\libhbct.a] which was not expanded at install time
but, since i became familiar with hbmk2, it is no more problem for me
and for docs, it is ok, everybody needs to put them together for himself,
just it takes little time and effort in digging and experimenting
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
just to say that some additional docs about .hmb .hbc .hbp would be helpfull, since --help is to short to be sufficant i used examples for simple building, but for advanced and full usage, need something more than --help also had problems with platform discovery, although msvc was not selected at instalation time, at run time hbmk discovered an existing msvc instance and used that as default compiler, of course, the build proces broke since there were no msvc related libs expanded at instalation time. after i succeded to find a problem source, i added hardcoded "compiler" switch to force mingw compiler. Did this happen with latest Harbour? Autodetection for MSVC should now be about the same in Harbour build and hbmk2, but it was developed much later to the bulid phase. If it's with recent Harbour, and you can post your PATH I can give it a check. As for the docs, I won't have time for it (plus writing docs is not my strong point), so besides the hundred small examples, numerous examples on this list and quick samples in INSTALL, don't expect it from me. I hope someone else will make one. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How harbour will be better?
Very Thanks for clarification to hbmk I have a different experiences, that allow ne see only one side of problem now try explain my point of view A percentage of Harbour user in first steep are not able to compile sample, particular contrib because not know parameter of hbmk If true this would be quite sad as all our samples can be compiled by either hbmk2 or hbmk2 . Of course it's left to users exercise to decide which of these two, plus it's also users job to put hbmk2 to PATH or point to hbmk2 by hand. Probably it could be made even more simple, but however sad to this sounds, but Harbour is a programming language and some degree of programming (or general computer skills, cmdline) experience is inevitable to make use of it. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
hi, just to say that some additional docs about .hmb .hbc .hbp would be helpfull, since --help is to short to be sufficant i used examples for simple building, but for advanced and full usage, need something more than --help also had problems with platform discovery, although msvc was not selected at instalation time, at run time hbmk discovered an existing msvc instance and used that as default compiler, of course, the build proces broke since there were no msvc related libs expanded at instalation time. after i succeded to find a problem source, i added hardcoded "compiler" switch to force mingw compiler. except these mentioned problem [as for newbs] hbmk2 works great thnx! - Original Message - From: "Viktor Szakáts" To: "Harbour Project Main Developer List." Sent: Tuesday, October 27, 2009 10:34 AM Subject: Re: [Harbour] hbmk2 suggestion Much easier to read 'hbmk2 --help' output, or just take ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] hbmk2 suggestion
>-Original Message-
>From: Massimo Belgrano [mailto:mbelgr...@deltain.it]
>Sent: Tuesday, October 27, 2009 11:20 AM
>To: Harbour Project Main Developer List.
>Subject: Re: [Harbour] hbmk2 suggestion
[...]
>xbase++ for same final result use
>#pragma library("xppui3.lib")
>as you read in ainet sample
>http://news.alaska-software.com/readmessage?id=%3C1xwdedeqtb373
>$.1kbal6arq2jed@40tude.net%3e&group=public.soapbox
This may look like a records to strong typed in C or anther language
(using, include etc) in prg body :
#declare LibNameToUsing.LIB
Or
#declare funcName from LibName
Or
#libraries ...
Regards,
Marek Horodyski
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] How harbour will be better?
Very Thanks for clarification to hbmk
I have a different experiences, that allow ne see only one side of problem
now try explain my point of view
A percentage of Harbour user in first steep are not able to compile
sample, particular contrib because not know parameter of hbmk
I invite also Other Guru like roberto lopez,rathinagiri reply here if
think that problem exist or share his experiences
2009/10/27 Viktor Szakáts :
>>> hbmk2 test.prg hbmemio.hbc
>>> why cannot you copy '-lhbmemio' ('hbmemio.hbc') to your compile/link
>>> command?
>>> I do not see any functional difference. In both cases you have to copy
>>> sth from reference code but in the second case you are using unknown
>>> for Clipper users syntax which does not have clear for all behavior.
>>
>> No the problem is that is not possible hbmk2 info is allways migging
>> many user require here "How compile sample from qt or other" because
>> thie information is not jouned to prg
>
> Since such #pragma can be left out as well (not obligatory),
> in this respect it's not much better than adding a simple
> comment to source.
>
xbase++ for same final result use
#pragma library("xppui3.lib")
as you read in ainet sample
http://news.alaska-software.com/readmessage?id=%3c1xwdedeqtb373$.1kbal6arq2jed@40tude.net%3e&group=public.soapbox
>>>
>>> This is completely different feature because it works at link time so can
>>> be used in binary libraries.
>>> Unfortunately due to portability such feature cannot be added to Harbour
>>> because it may work only with some subset of supported by Harbour C
>>> compilers and practice shows that such non portable features create
>>> much more troubles then resolve problems.
>>> The proposed:
>>> #pragma option:hbmk2 ...
>>> is compile time feature and it does not work with binary libraries.
>>> Looks that using above example you only confirmed that this #pragma
>>> command can confuse users who may just like you expect different
>>> behavior then the real one ;-)
>>> So my current conclusion is that it will only create new problems
>>> instead of help newbie users.
>>
>> afaik i can add lib in hbc
>> i am afraid i dont undestand you about what is binary library
>> to lack in my knowdlege
>> Here i hope that viktor explain
>> Why in compile time feature can't add binary library?
>> I don't want absolutely create new problems
>
> Pulling .hbc files (or .lib files) cannot be done from
> binary files (as object and libs) since it relies on source
> code parsing and hbmk2 logic, instead of being a linker
> feature. We can't change that unless we drop some compilers
> from the mix, but even then nothing guarantees that it can
> be kept in the future for new compilers.
>
> To put it short:
>
> Everyone posting examples requiring external libs or needing
> special options should include the hbmk2 command line in their
> posted examples. Easy, simple, straighforward and it works _now_.
>
> Brgds,
> Viktor
>
> ___
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
Massimo Belgrano
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12775] trunk/harbour
dru...@users.sourceforge.net wrote: * harbour/contrib/hbwin/hbwinole.h * harbour/contrib/hbwin/olecore.c + added hb_oleItemGetCallBack() and hb_oleItemSetCallBack() functions and support for user defined items bound with OLE GC pointer item * harbour/contrib/hbwin/axcore.c * bound callback function with OLE item so it will be automatically released with OLE object * harbour/contrib/hbwin/tests/testax.prg ! destroy window * enabled destructor So far MS-Windows users haven't defined expected behavior for OLE code so I took my own arbitrary decision and bound callback with OLE GC item. When last copy of this item is cleared then callback is unregistered and freed. It means that it can happen before AX window is closed. If you prefer different behavior then please clearly define what you need and I can try to change existing code. Now testax.prg should cleanly execute without any GPF traps and resource leaks. I guess you mean me :). I have only got online now, so I had not seen your other post. What you have done looks perfectly logical. I guess there may be other ways of instantiating ActiveX objects without using ATL, and perhaps the window handle would not be available. So it's not the job of this code to destroy windows etc. Thank you very much and I will test soon. Regards Alex ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
hbmk2 test.prg hbmemio.hbc
why cannot you copy '-lhbmemio' ('hbmemio.hbc') to your compile/link
command?
I do not see any functional difference. In both cases you have to
copy
sth from reference code but in the second case you are using unknown
for Clipper users syntax which does not have clear for all behavior.
No the problem is that is not possible hbmk2 info is allways migging
many user require here "How compile sample from qt or other" because
thie information is not jouned to prg
Since such #pragma can be left out as well (not obligatory),
in this respect it's not much better than adding a simple
comment to source.
xbase++ for same final result use
#pragma library("xppui3.lib")
as you read in ainet sample
http://news.alaska-software.com/readmessage?id=%3c1xwdedeqtb373$.1kbal6arq2jed@40tude.net%3e&group=public.soapbox
This is completely different feature because it works at link time
so can
be used in binary libraries.
Unfortunately due to portability such feature cannot be added to
Harbour
because it may work only with some subset of supported by Harbour C
compilers and practice shows that such non portable features create
much more troubles then resolve problems.
The proposed:
#pragma option:hbmk2 ...
is compile time feature and it does not work with binary libraries.
Looks that using above example you only confirmed that this #pragma
command can confuse users who may just like you expect different
behavior then the real one ;-)
So my current conclusion is that it will only create new problems
instead of help newbie users.
afaik i can add lib in hbc
i am afraid i dont undestand you about what is binary library
to lack in my knowdlege
Here i hope that viktor explain
Why in compile time feature can't add binary library?
I don't want absolutely create new problems
Pulling .hbc files (or .lib files) cannot be done from
binary files (as object and libs) since it relies on source
code parsing and hbmk2 logic, instead of being a linker
feature. We can't change that unless we drop some compilers
from the mix, but even then nothing guarantees that it can
be kept in the future for new compilers.
To put it short:
Everyone posting examples requiring external libs or needing
special options should include the hbmk2 command line in their
posted examples. Easy, simple, straighforward and it works _now_.
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
>
> If you can copy and past part of .prg code why you cannot copy part
> of .hbp file?
> Or if you see in source code:
> compile and link using:
> hbmk2 test.prg -lhbmemio
> or:
> hbmk2 test.prg hbmemio.hbc
> why cannot you copy '-lhbmemio' ('hbmemio.hbc') to your compile/link
> command?
> I do not see any functional difference. In both cases you have to copy
> sth from reference code but in the second case you are using unknown
> for Clipper users syntax which does not have clear for all behavior.
No the problem is that is not possible hbmk2 info is allways migging
many user require here "How compile sample from qt or other" because
thie information is not jouned to prg
>
>> xbase++ for same final result use
>> #pragma library("xppui3.lib")
>> as you read in ainet sample
>> http://news.alaska-software.com/readmessage?id=%3c1xwdedeqtb373$.1kbal6arq2jed@40tude.net%3e&group=public.soapbox
>
> This is completely different feature because it works at link time so can
> be used in binary libraries.
> Unfortunately due to portability such feature cannot be added to Harbour
> because it may work only with some subset of supported by Harbour C
> compilers and practice shows that such non portable features create
> much more troubles then resolve problems.
> The proposed:
> #pragma option:hbmk2 ...
> is compile time feature and it does not work with binary libraries.
> Looks that using above example you only confirmed that this #pragma
> command can confuse users who may just like you expect different
> behavior then the real one ;-)
> So my current conclusion is that it will only create new problems
> instead of help newbie users.
afaik i can add lib in hbc
i am afraid i dont undestand you about what is binary library
to lack in my knowdlege
Here i hope that viktor explain
Why in compile time feature can't add binary library?
I don't want absolutely create new problems
Thanks and sorry
Best regards
>
> best regards,
> Przemek
> ___
--
Massimo Belgrano
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12776] trunk/harbour
Revision: 12776
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12776&view=rev
Author: druzus
Date: 2009-10-27 10:51:37 + (Tue, 27 Oct 2009)
Log Message:
---
2009-10-27 11:51 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/contrib/xhb/xhbarr.c
+ added XHB_AINS(), XHB_ADEL() functions which accept negative indexes.
Warning I haven't replicated xHarbour bugs in AINS() so it's not
exactly the same. Sooner or later someone will fix AINS() code in
xHarbour CVS. This code illustrates the problem and also
incompatibilities with Clipper:
#ifdef __HARBOUR__
#ifndef __XHARBOUR__
#xtranslate adel() => xhb_adel()
#xtranslate ains() => xhb_ains()
#endif
#endif
proc main()
local a := { 100, 200, 300 }
? ; aeval( a, { |x| qout( x ) } )
adel( a, -1, .t. )
? ; aeval( a, { |x| qout( x ) } )
ains( a, -1, 400, .t. )
? ; aeval( a, { |x| qout( x ) } )
ains( a )
? ; aeval( a, { |x| qout( x ) } )
return
Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/xhb/xhbarr.c
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
On Tue, 27 Oct 2009, Massimo Belgrano wrote:
Hi,
> Because typically it start coping a sample that contain it
> if harbour user get a sample contain:
> #pragma option:hbmk2 mylib.hbc
> request MYLIB
> it will be easy to compile and if it get another sample that include
> #pragma option:hbmk2 hbmemio.hbc
> REQUEST HB_MEMIO
> Follow is a typical sequence
> in the first step compile as sample but in second step lost right way
> note that in second steep the info HB_MEMIO not help discover hbmemio.lib
If you can copy and past part of .prg code why you cannot copy part
of .hbp file?
Or if you see in source code:
compile and link using:
hbmk2 test.prg -lhbmemio
or:
hbmk2 test.prg hbmemio.hbc
why cannot you copy '-lhbmemio' ('hbmemio.hbc') to your compile/link
command?
I do not see any functional difference. In both cases you have to copy
sth from reference code but in the second case you are using unknown
for Clipper users syntax which does not have clear for all behavior.
> xbase++ for same final result use
> #pragma library("xppui3.lib")
> as you read in ainet sample
> http://news.alaska-software.com/readmessage?id=%3c1xwdedeqtb373$.1kbal6arq2jed@40tude.net%3e&group=public.soapbox
This is completely different feature because it works at link time so can
be used in binary libraries.
Unfortunately due to portability such feature cannot be added to Harbour
because it may work only with some subset of supported by Harbour C
compilers and practice shows that such non portable features create
much more troubles then resolve problems.
The proposed:
#pragma option:hbmk2 ...
is compile time feature and it does not work with binary libraries.
Looks that using above example you only confirmed that this #pragma
command can confuse users who may just like you expect different
behavior then the real one ;-)
So my current conclusion is that it will only create new problems
instead of help newbie users.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
Hi Przemek
Because typically it start coping a sample that contain it
if harbour user get a sample contain:
#pragma option:hbmk2 mylib.hbc
request MYLIB
it will be easy to compile and if it get another sample that include
#pragma option:hbmk2 hbmemio.hbc
REQUEST HB_MEMIO
Follow is a typical sequence
in the first step compile as sample but in second step lost right way
note that in second steep the info HB_MEMIO not help discover hbmemio.lib
xbase++ for same final result use
#pragma library("xppui3.lib")
as you read in ainet sample
http://news.alaska-software.com/readmessage?id=%3c1xwdedeqtb373$.1kbal6arq2jed@40tude.net%3e&group=public.soapbox
Best regard
2009/10/27 Przemysław Czerpak :
> On Tue, 27 Oct 2009, Szak�ts Viktor wrote:
>
> I know this. But I'm interesting how it can help newbie users in
> their own code. They still have to add valid library name so why
> it's better then using REQUEST and -l hbmk2 switch.
> Maybe I'm missing sth but it's a feature which can work only with
> source code so it's not even an option for binary libraries. For
> me it may help only in compilation of some example files from Harbour
> SVN if they do not have their own .hbp files and does not contain any
> information about compile/link commands in their headers.
>
> best regards,
> Przemek
> ___
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
Massimo Belgrano
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12775] trunk/harbour
Revision: 12775 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12775&view=rev Author: druzus Date: 2009-10-27 09:34:35 + (Tue, 27 Oct 2009) Log Message: --- 2009-10-27 10:34 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbapi.h * harbour/src/vm/garbage.c * added emulation for hb_gcAlloc() function covered by HB_LEGACY_LEVEL2 It will be removed in the future but now it gives a time for 3-rd party code developers to updated existing code and switch to hb_gcAllocate() * harbour/contrib/hbwin/hbwinole.h * harbour/contrib/hbwin/olecore.c + added hb_oleItemGetCallBack() and hb_oleItemSetCallBack() functions and support for user defined items bound with OLE GC pointer item * harbour/contrib/hbwin/axcore.c * bound callback function with OLE item so it will be automatically released with OLE object * harbour/contrib/hbwin/tests/testax.prg ! destroy window * enabled destructor So far MS-Windows users haven't defined expected behavior for OLE code so I took my own arbitrary decision and bound callback with OLE GC item. When last copy of this item is cleared then callback is unregistered and freed. It means that it can happen before AX window is closed. If you prefer different behavior then please clearly define what you need and I can try to change existing code. Now testax.prg should cleanly execute without any GPF traps and resource leaks. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/axcore.c trunk/harbour/contrib/hbwin/hbwinole.h trunk/harbour/contrib/hbwin/olecore.c trunk/harbour/contrib/hbwin/tests/testax.prg trunk/harbour/include/hbapi.h trunk/harbour/src/vm/garbage.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
For you is not complicated, but for other user will be each operation increase difficult, and capability to made error also here we can find user that miss how compile sample, me included having "#pragma option:hbmk2 mylib.hbc" in source code cover complexity made possible copy and past from internet to a new project All that needs to be done is to supply an .hbp file for projects published on the internet. Since you will never be able to control the whole build process of apps from .prg source code, such .hbp file should be distributed anyway. Include .hbc files in these project files is IMO a no brainer. Project files are common in most (non-interpreted) programming languages. I find this #pragma option much less intuitive in its current form. It needs some more brainstorming to make it like using/import in other languages. We need to cover headers, REQUESTs and give it sleeker syntax. Przemysław #pragma option:hbmk2 mylib.hbc allow compile with hbmk2 without know how request MYLIB is different because instruct only that is need a library/symbol In my source i have already included REQUEST HB_MEMIO but when compile with hbmk2 i must adding hbmemio.lib or #pragma option:hbmk2 hbmemio.hbc First off, I don't think newbies will start with hbmemio, but anyway, any "newbie" should be used to the fact that each functionality is made available through libs. This has been so since Clipper '85. And these libs needs to be linked to app. This doesn't seem very complicated or unusual to me. The last thing a newbie will think of is using #pragma (which is new syntax), and using it with a relatively obscure and not well documented option as 'hbmk2:option'. Much easier to read 'hbmk2 --help' output, or just take a glance on almost any of our projects inside the repository. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
On Tue, 27 Oct 2009, Massimo Belgrano wrote: Hi, > #pragma option:hbmk2 mylib.hbc allow compile with hbmk2 without know how > request MYLIB is different because instruct only that is need a library/symbol Yes but someone has to add this #pragma command to source code so he has to know library name. It means that it's only an option for example files in Harbour SVN which do not have their own .hbp files. > In my source i have already included > REQUEST HB_MEMIO > but when compile with hbmk2 i must adding hbmemio.lib > or > #pragma option:hbmk2 hbmemio.hbc > I pray either made a solution for made harbour easy for newbies You still haven't explained why it's easier to add to source code: #pragma option:hbmk2 hbmemio.hbc instead of using: hbmemio.hbc as hbmk2 parameter and how it may help newbie users. In both cases they have to make similar job and they need similar knowledge. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
On Tue, 27 Oct 2009, Szak�ts Viktor wrote: > >Massimo probably I do not understand sth but can you explain how > >using: > > #pragma option:hbmk2 mylib.hbc > >is better then: > > request MYLIB > The idea of the #pragma is to automatically pull > required libs, include paths and whatnot (all > contained in the .hbc file) right from the source > files. > It doesn't replace REQUEST at all, though. I know this. But I'm interesting how it can help newbie users in their own code. They still have to add valid library name so why it's better then using REQUEST and -l hbmk2 switch. Maybe I'm missing sth but it's a feature which can work only with source code so it's not even an option for binary libraries. For me it may help only in compilation of some example files from Harbour SVN if they do not have their own .hbp files and does not contain any information about compile/link commands in their headers. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
Viktor For you is not complicated, but for other user will be each operation increase difficult, and capability to made error also here we can find user that miss how compile sample, me included having "#pragma option:hbmk2 mylib.hbc" in source code cover complexity made possible copy and past from internet to a new project Przemysław #pragma option:hbmk2 mylib.hbc allow compile with hbmk2 without know how request MYLIB is different because instruct only that is need a library/symbol In my source i have already included REQUEST HB_MEMIO but when compile with hbmk2 i must adding hbmemio.lib or #pragma option:hbmk2 hbmemio.hbc I pray either made a solution for made harbour easy for newbies 2009/10/27 Przemysław Czerpak : > On Tue, 27 Oct 2009, Massimo Belgrano wrote: >> i hope that you implement in hbnk2 before 2.0 something like: >> #pragma option:hbmk2 mylib.hbc >> becasue allow newbbies easy compiling script > > Massimo probably I do not understand sth but can you explain how using: > #pragma option:hbmk2 mylib.hbc > is better then: > request MYLIB > > best regards, > Przemek > ___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- Massimo Belgrano ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
Massimo probably I do not understand sth but can you explain how using: #pragma option:hbmk2 mylib.hbc is better then: request MYLIB The idea of the #pragma is to automatically pull required libs, include paths and whatnot (all contained in the .hbc file) right from the source files. It doesn't replace REQUEST at all, though. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
On Tue, 27 Oct 2009, Massimo Belgrano wrote: > i hope that you implement in hbnk2 before 2.0 something like: > #pragma option:hbmk2 mylib.hbc > becasue allow newbbies easy compiling script Massimo probably I do not understand sth but can you explain how using: #pragma option:hbmk2 mylib.hbc is better then: request MYLIB best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
i hope that you implement in hbnk2 before 2.0 something like: #pragma option:hbmk2 mylib.hbc becasue allow newbbies easy compiling script This needs support from Harbour compiler. Moreover I don't want to rush it and I currently have not enough time to spend on it anyway. Let's plan it a little more and see what can be done, until then I don't think it's such complicated to add the few .hbc files to an app's project (.hbp) file. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
i hope that you implement in hbnk2 before 2.0 something like: #pragma option:hbmk2 mylib.hbc becasue allow newbbies easy compiling script 2009/10/26 Viktor Szakáts : >> Sorry if i not understand right >> >> Can i use multiple hbc? >> hbmk2 hello.prg hmg.hbc rddads.hbc hbmemio.hbc > > Yes, of course. > > [ you may even refer to another .hbc from an .hbc file. ] > > Brgds, > Viktor > > ___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- Massimo Belgrano ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12774] trunk/harbour
Revision: 12774 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12774&view=rev Author: vszakats Date: 2009-10-27 08:33:31 + (Tue, 27 Oct 2009) Log Message: --- 2009-10-27 09:33 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/tests/testdll.prg * Minor. * contrib/hbwin/win_dll.c % Deleted cDLL structure member. - Deleted __XHARBOUR__ guarded parts (related to C structure handling, probably never tested, plus it didn't look something mature anyway) ; TOFIX: win64 .dll support, strangely testdll gives slightly different results for BCC and MSVC builds (and MINGW builds where it GPFs), also UNICODE isn't supported at all. So I guess Harbour .dll handling would better be rewritten. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/tests/testdll.prg trunk/harbour/contrib/hbwin/win_dll.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
