[Harbour] Re: Documentation storm on user's list
στις 29/05/2010 10:40, O/H Przemysław Czerpak έγραψε: This is my last massage in this thread. I strongly suggest to invest resources necessary to create such long messages about how to create harbour documentation in creating some real documentation. It will be really productive. best regards, Przemek To (Przemek, Viktor and co-developers) I understand that you, the leaders of Harbour, along with a bunch of very capable and helpfully dedicated developers, have undertaken an abandoned-on-the-shelf project and have made it such an outstanding programming language with an unparalleled quality, similar to which is not easy to find in the FOSS arena. We the standalone HB_users, mostly ex-clipper programmers, feel very happy, lucky and blessed to have you in the head of this great-great project: - happy because we were here to see it happen, - lucky because we have (someone more, someone lesser) _benefited_ by your generously offered product, product of your hard work - blessed because (well, i 'm not such a religious man to speak about it, let say that..) we just feel it so! I guess that some of us, being motivated by such thoughts, we're seeking ways to give back whatever we think could help the project, give back not as a payment but rather as a moral obligation . Sadly i see that till now the results is a mixture of plenty of good intentions along with much disturbing noise. It really doesn't help! To mumbling, in the event, our apologies does not help either. Maybe the best thing we could do is to follow your suggestion, that is, to try to invest resources necessary to create such long messages about how to create harbour documentation in creating some real documentation. [The only problem here is the very real case where some user (for many reasons, eg. lack of time, lack of knowledge, inefficiency in writing etc) is unable to create some real documentation but still he wants to contribute. That was the aim to create a Harbour-Foundation but since you consider that it'd produce more problems than it'd solve, we can let the proposition peacefully rest into recycle bin of the never-said]. Once again, we[*] feel the need to express ours warm thanks and sincere appreciation to your great work. Many-many thanks for your patient too! --- Pete [*] and before any fellow reader comes and question me: who have made me the spoke-person of Harbour users, i must clarify that i 'm not pretend that i represent anyone, nor i am doing it intentionally! it's only because i find it humanly normal to express an opinion, it's only because we sometimes have to speak about things that touch our common interests, but also because this _dumbness by the users side_ is unfitting to thinking people, and certainly discouraging and disheartening for the developers! [forgive me if you find my words are wrong and/or upsetting, but Please let's take, from time to time, the chance to reply to them just to say 'thanks'. eventually, it seems that still it counts more than we guess...] ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Documentation storm on user's list
στις 29/05/2010 00:42, O/H Pritpal Bedi έγραψε: Ok, I commit to write documentation, how much you will pay ? Certainly not less than the current market price[*] for similar products. (and of course, I'd prefer it to be an under-official-leadership initiative.) Users of Harbour can pledge how much one is willing to pay, pledge only on this list, do not pay now, and if the total figure will match my expectations, I will start writing. You will pay when I will at certain stage. For sure, your suggested terms are fairly reasonable, however.. Accepted ? ..I'd prefer to we follow a Harbour-Fund financing model. That is, we start making donations to a common-treasure and let project leaders decide and make hiring agreements for manual creation, or whatever would help project's improvement. But, of course, let's hear other harbour followers opinions. [*] Okay! plus the beers, at the release-day feasts. ( 12 bottles maximum and no more.. ;) ) ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Documentation storm on user's list
στις 27/05/2010 23:33, O/H smu johnson έγραψε: Some thoughts, On Thu, May 27, 2010 at 12:18 PM, pete_westg pete_we...@yahoo.gr mailto:pete_we...@yahoo.gr wrote: are you sure you have understood my words? I 'm afraid you don't! What I am not sure for, is the reason for this misunderstanding. Perhaps, is it due to my bad English or what? - Stating that Harbour's lack of documention is straightly against to the spirit of open source initiative can be considered offensive by many. Who made you the spokesperson of the Open Source movement? It could be interpreted that your statement means their years of work were done improperly. Please don't put words in my mouth that i never said. Or please show me even one instance of the word Harbour into my first post to which you are referring. There is not one! You have just tailored a phrase, by mixing your assumptions with cut-n-past parts of my lines, to base your claim that this (the tailored) statement can be considered offensive by many. I wonder what is the purpose of this conversation. Is it to accuse me, for my comments being offensive, strange, insulting, bugging or whatever? I can't say to someone do or don't feel offended. All I can do is to explain my point, and wish that through understanding, the reasons that make someone to feel offended would vanish. So, i must make it clear, that when i wrote documentation is (or must be) on upper top, in the scale of open source priorities, since documents, or better the lack of documents, is straightly against to the spirit of open source initiative (this is my unaltered phrase) i was not referring specifically to Harbour but rather i was expressing a general point, regarding the whole opensource case. and I believe, you don't need to be a spokesperson of the OS movement to speak up your thoughts about it. I have a sentiment that the problem in present days is not just the open source code. you don't need to be a specialist to see it. Trillions lines of very good code have been written and quadrillions will be written in the close future. It is really amazing and all the respect belongs to the great developers. On the other hand we can't ignore the fact that we already have an infinite ocean of source code inside which we (the community/society) could sink or we could sail. I vote to sail! and the ship to sail and not sink, you guess it, is the documents. To put it an other way, the crucial subject today, is not any more the open source code. It is (and always was) the open knowledge. And knowledge without documentations is simply impossible. Documentation is the vehicle of knowledge. documenting is to securing the ability to be able to use the brilliant machines that brilliant developers-brains have created. Now, Viktor will come and accuse me: Empty words, again. Yes, I see it. I see the emptiness in the absence of manual. I see the emptiness in my inability to be useful in the subject. And the question is still here, as you Viktor, say. Why we have no documentation? Why we have such a brilliant and huge amount of excellent code, like Harbour has become thanks to your (and all of developers) tremendous efforts and not an analogous documentation? We said, it is difficult to create documentation. but if we think it better, difficulty is not the main reason. The main reason is that nobody wants documentation so much, nobody is burned to create it. and the deeper cause of this, is the lack of belief to the great value of a documentation, is the lack of belief to the vital significance of a manual, it is because we are much eager for source code and we are not interested for documentation, perhaps because is not so glorious to write documents compared to code-writing. obviously we lack a documenting culture( similar to coding culture), and for this to happen, perhaps we need empty words, even to just have something to filling up, even to just have something to keep the spark alive. as i see it there two directions. to get rid off of this documentation blah-blah, which means that we'll immediately stop bugging you the developers, or to keep searching ways how the goal of documentation will become true. Honestly, Viktor, i 'm not interest to bugging you, (i don't know what exactly the bugging is, or means, but if it is related to the activity of a bug, then i think it's my time to start feeling offended. However, feeling offended or not, doesn't cure my real displeasure to feel almost guilty because i can't find a practical way to effectively contribute documentation. ___ P.S. Strangely enough, i see no reaction to the challenging idea of harbour-xhb merging. Does the harbour community think it was a joke or this deafening silence express their glacial indifference about the future of Harbour? --- Pete ___ Harbour mailing list
[Harbour] Re: Documentation storm on user's list
στις 28/05/2010 15:23, O/H Viktor Szakáts έγραψε: Pls remember that even such _quite well documented_, _fully open_ and long time known systems as Linux, have several companies _earning_ large sums of money by supporting them (f.e. Red Hat), (I don't know if this has been proposed before but) why don't you create some kind of Harbour Fund? It could be used to accept donations, contributions and, why not, for hired services (be it on-line help or code-writing or support etc.) --- Pete ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Documentation storm on user's list
στις 27/05/2010 13:02, O/H Viktor Szakáts έγραψε: To Pete, [ Sorry to reply here, but I'm readonly user of users-list. ] Strange and insulting thoughts towards anyone who have dedicated huge amount (many years) of (maybe even full time) to take this project where it is now. Maybe you could elaborate on what you mean by documentation friendly code... If coding means nothing to you, pls delete all the Harbour sources and try to use it after... Viktor, [I finally managed to discover that my post in users-forum had been replied here. so, here it is my humble yet belated answer] are you sure you have understood my words? I 'm afraid you don't! What I am not sure for, is the reason for this misunderstanding. Perhaps, is it due to my bad English or what? And how did you find insulting thoughts, there where it doesn't exist? When I am saying documentation is more valuable than coding, in no way mean that coding is nothing. It just means that without documentation, many parts of code is almost unusable, for many people (users). We all agree with you that if every individual harbour user would be willing to write some (small) part of documentation, the Harbour manual would perhaps be already here. But life has shown that it is not that simple. Months ago we have had the very same discussion. many people had then declared their interest to contribute, some of them had shown their valuable ideas and had made specific proposals. Unfortunately after a while the interest had faded out, and the only real remained/result was an documenting extension into hbide, which supposedly would help to write documentation. I have tried to use it. It didn't work (not in operational meaning of the term). Beyond this, i 've had spent hours digging into sources, trying to format some pieces of documentation. the results were not significant. why? because writing documentation is indeed difficult, actually is more difficult than somebody can imagine and for sure more difficult than coding. that's why, i suppose, for every thousands good coders correspond few -very few or even none- good documenters. Regarding your definition of idealism, i couldn't put it better. thinking, learning, contributing and/or paying is the only realistic approach. Starting from the later, please don't have any doubt that I (and I believe many other Harbour users) would be more than willing to _pay_ for a manual if anything did exist. Contributing is another crucial story. Nobody's _demanding_ anything from developers. And how one could do that? But asking for documentation should not considered as a demand. Is a very normal and absolutely expected query for any newcomer to Harbour. The do it yourself is a pushing away answer. What insulting do you find in this paragraph? By documentation friendly code i mean two simple and very well known things. a. Short introductory description on top of source code (in place of this long and more or less useless copyright reminding replica ) b. in-line comments. c. sample program. [OK, they are three, but any combination of two will perfectly do the job ;)] P.S.: merging harbour-xhb? (wow! this question could be a real philosophical dilemma). although this is a core-developers decision, you better don't have doubts that the great majority of the users, in case they'd been asked for, would loudly vote No! --- Pete ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: NETIO Questions
στις 22/04/2010 21:49, O/H Winston Garcia έγραψε: Have you a sample of Netio server what received many conections ? The samples en contrib/netio only accept one conection at time ? Greeting Winston Garcia Venezuela Take a look there: http://f1.grp.yahoofs.com/v1/sJzQSwQCQIw6Af3naxConxutoY73t1E0_89GDgni_uAcXdcW2NxwfaeOJflYf70ReA1pJdu_mVYYmlkv4st3C-jZREL9OxKf/CONTRIB/NETIO.7z It is a simple NETIO applet that i wrote (win platform) utilizing Server client connection(s). Install the prog. (just copy the executable) into directory where are your .dbfs and start it in server mode. Then install in *each* client-machine a copy of the (same) executable, enter server's IP and try to connect. It should work.. rgrds, --- Pete ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: field-(name) in a macro
στις 21/03/2010 20:31, O/H Przemysław Czerpak έγραψε:
On Sun, 21 Mar 2010, Alexandr Okhotnikov wrote:
Hi
Example!
FUNC MAIN()
DBCREATE( aa.dbf, { { DACC, C, 10, 0 } } )
use aa.dbf alias aa new
DBAPPEND()
aa-DACC := hello
? aa-DACC :, aa-DACC
? 'aa-(DACC) :', aa-(DACC)
RETURN 0
Have you tested it?
druzus:/tmp# hbrun tst.prg
aa-DACC : hello
aa-(DACC) : hello
druzus:/tmp#
druzus:/tmp# harbour -n -gh tst.prg
Harbour 2.1.0dev (Rev. 14184)
Copyright (c) 1999-2010, http://www.harbour-project.org/
Compiling 'tst.prg'...
Lines 11, Functions/Procedures 1
Generating Harbour Portable Object source output to 'tst.hrb'... Done.
druzus:/tmp# hbrun tst.hrb
aa-DACC : hello
aa-(DACC) : hello
druzus:/tmp#
So it _confirms_ that you information about different in compiler when
HRB files are generated was completely wrong !!!
BTW technically such difference is impossible because compiler internally
generates _ONLY_ .HRB files which is native raw format for Harbour and
when -gc[N] switch is used then generated code is translated to .c code
as PCODE encapsulated in C functions (-gc[0-2]) or as C code directly
calling HVM functions (-gc3)
best regards,
Przemek
Hbrun tst.prg does work.
Compiled version does NOT!
(please see below tests)
WORKING -
C:\DEV\Harbour\Mytestshbrun tst.prg
aa-DACC : hello
aa-(DACC) : hello
Press any key to continue...
C:\DEV\Harbour\Mytests
NOT WORKING -
C:\DEV\Harbour\Mytestshbmk2 tst.prg
hbmk2: Processing configuration: C:\Harbour\bin\hbmk.cfg
Harbour 2.1.0dev (Rev. 14220)
Copyright (c) 1999-2010, http://www.harbour-project.org/
Compiling 'tst.prg'...
Lines 13, Functions/Procedures 1
Generating C source output to 'E:\WIN_TEMP\tst.c'... Done.
C:\DEV\Harbour\Myteststst
aa-DACC : hello
Error BASE/1449 Syntax error:
Called from MAIN(9)
C:\DEV\Harbour\Mytests
--
Exactly the same error generates the line:
Public mVar. := Len(_HMG_SYSDATA [ 66 ]) + 1
regards,
---
Pete
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: field-(name) in a macro
στις 24/03/2010 12:01, O/H Viktor Szakáts έγραψε:
WORKING -
C:\DEV\Harbour\Mytestshbrun tst.prg
aa-DACC : hello
aa-(DACC) : hello
Press any key to continue...
C:\DEV\Harbour\Mytests
NOT WORKING -
C:\DEV\Harbour\Mytestshbmk2 tst.prg
hbmk2: Processing configuration: C:\Harbour\bin\hbmk.cfg
Harbour 2.1.0dev (Rev. 14220)
Copyright (c) 1999-2010, http://www.harbour-project.org/
Compiling 'tst.prg'...
Lines 13, Functions/Procedures 1
Generating C source output to 'E:\WIN_TEMP\tst.c'... Done.
C:\DEV\Harbour\Myteststst
aa-DACC : hello
Error BASE/1449 Syntax error:
Called from MAIN(9)
C:\DEV\Harbour\Mytests
--
Exactly the same error generates the line:
PublicmVar. := Len(_HMG_SYSDATA [ 66 ]) + 1
Very interesting. Here they both compile cleanly
(and first one also works) alright even with latest SVN.
Here is tested code (unaltered):
---
DBCREATE( aa.dbf, { { DACC, C, 10, 0 } } )
use aa.dbf alias aa new
DBAPPEND()
aa-DACC := hello
? aa-DACC :, aa-DACC
? 'aa-(DACC) :', aa-(DACC)
---
---
LOCAL _HMG_SYSDATA
PublicmVar. := Len(_HMG_SYSDATA [ 66 ]) + 1
---
Double check your environment and test .prg,
because it's almost sure there is something
wrong with it.
Brgds,
Viktor
Ok, I will try to check my env. (although i'm not sure what exactly
should I look for, since everything looks simple clean. -I am just
setting paths and let the hbmk2 do the rest.)
BTW, is there any possibility to be the problem O/S related?
I 'm getting the error(s) on my every-day-use WIN2K box. On a WinXPPRO
machine (where I make clean harbour's builds) everything works w/o prob.
However binaries (exes and libs) on WIN2K box are copy/pasted from WinXPPRO.
regards,
---
Pete
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour-users] Re: Mangled Posts
στις 18/03/2010 21:35, O/H do...@people.net.au έγραψε: Hi all For some reason my posts are getting mangled in the daily digests and I'm not sure why. Hi xProgrammer, I'm not sure what you mean by getting mangled. I do read harbour.user mailing list through my e-mail client (thunderbird). I'm also receiving a daily-digest in my yahoo.mail account. In both, all posts (yours included) seem to be ok. The only problem i have noticed so far, in the digest version, is that in your posts show up in some places odd characters which, i suppose, are tab characters (perhaps not correctly decoded?) but this little-to-none effect has to your text regarding readability. (By the way, I (and it's not only me, i think) find much interesting your posts about your client-server implementation.) regards, --- Pete ___ Harbour-users mailing list (attachment size limit: 40KB) Harbour-users@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour-users
[Harbour] What about hard-coded make directives?
Hi, I don't know if it is technically easy or even possible to implemented, but i think it might be very handy to have inside main .prg one (or more) make-time directive(s) instructing hbmk2, about desired compiler options and/or libraries inclusion. Something like: #makeoption /switch1, /switch2, ... /switchN and #libinclude libhb1, libhb2, ... libhbN or #using /switch1, /switch2, libhb1, libhb2, ... libhbN It could save us (the commandliners particularly) some time and stress-full typing of hard to remember switches and lib names. Just a thought.. --- Pete ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: What about hard-coded make directives?
στις 17/03/2010 18:18, O/H Viktor Szakáts έγραψε: The rest would need hbmk2 to parse all source files for make options, which would in turn have a rather huge speed penalty. Plus it'd need a 3rd kind of option syntax to maintain (above existing .hbp and .hbc). No, in no way I did mean to parse all source files. And i fully agree that that should be a very good chance of troubles like those you are describe. My thought was of a very few or even one line *on top of main.prg only* in the form : #using this lib list, /and that switch list. I can think some good reasons for implementing this feature (readability, flexibility, testability, security, etc.) but if it's so much and complex work to be done then we can forget it. -no doubt, you are the chief-programmer here! ;-) regards, --- Pete ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: About ADEL()
στις 13/03/2010 12:52, O/H Viktor Szakáts έγραψε:
And here you answered the question. ADEL() is a Clipper
compatibility function, so it's expected to behave exactly
the same way as in Clipper, regardless of what we think
about some of that behavior.
Hi Viktor,
Thanks you for your reply. I don't like to be pedantic but,
as I understand it, the term compatibility is the case where the
compatible object keeps the same *documented* behavior and produce the
same *expected* results like the original. Preserving or rather
cloning undocumented questionable/problematic features, just for the
sake of compatibility, is a bit surrealistic, which is ok on a
philosophical/aesthetic level but from a pure programming view,
perhaps needs more consideration.
I agree that adel() does some kind of delete in the meaning that deletes
the contents of an element but not the element itself, however, let me
just to point out that in the case of a multidimensional array this
delete translates to make it broken.
Anyway, enough with ADEL(). The question is if we can do something with
HB_ADEL(). I don't know if it is proper to propose now modifications but
here it is:
---
HB_ADEL(aArray, [wrong type value]) -- mismatch argument RTE
HB_ADEL(aArray, [nPosition out of index]) -- boundary RTE
HB_ADEL(aArray) -- {} // an empty array, equal to aArray := {}
--
Of course all of the above could be easily implemented locally,
in prg or preprocessor level, but since i have faced the problem
in a real code situation, I thought that it might be useful
to notify my experience here.
Please, (and i hope i don't peculate your time) consider the code:
-
// IF nFile := ascan(a, {|x| UPPER(x[F_NAME]) == HBDIR.EXE}) 0
IF ( nFile := HB_ASCAN( a, {|x| UPPER(x[F_NAME]) == HBDIR.EXE},,,.T. )
) 0
HB_Adel(a, nFile, .t. )
ENDIF
-
It took me some time to realize what was wrong (in the now commented
line above). The problem, as you can easily see, was the (unforgivable)
lack of parentheses that had as result nFile var to take a boolean value
(.T. in the particular case), which subsequently was giving to HB_ADEL()
the freedom to do its magic by deleting the first array element
instead of HBDIR.EXE element. Of course I would have saved my time
(and my nerves) if HB_ADEL() had, from the very first run, warned me
about the erroneous type value of nFile.
best regards,
---
Pete
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour-users] Re: GUI programming.
στις 15/03/2010 17:10, O/H Paola Bruccoleri έγραψε: Hello Pete.. do you know ooHG? it is a pure OOP GUI and the licence is the same that harbour bye Hi Paola, Yes, I am aware of ooHG. Interesting project and good product also. But to be honest I am not an eager supporter of the OOP model. Actually I keep many doubts about object programming paradigm, since I don't believe is better than other models like procedural programming for example. I know, OOP is established as main stream programming style but I don't think that they're proved all the benefits that it is supposed that it has. regards, --- Pete ___ Harbour-users mailing list (attachment size limit: 40KB) Harbour-users@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour-users
[Harbour] About ADEL()
According documentation a proper use of the Adel() function, is:
ADEL(aTarget, nPosition) -- aTarget
where nPosition is the aTarget array element being deleted.
However, function ADEL() does interesting, -yet unexpected at least for
me, things when it's invoked with a slightly fuzzy way shown in the
sample below:
8-
#define CRLF HB_OSNewLine()
PROCEDURE MAIN()
LOCAL aArray := {one, two, three, four, five}
? TestProg: + HB_ARGV()+ [testing adel() function]
?
?
? --- Our array before adel()'s touch.. --
AEVAL( aArray, {|ele| QQOUT(HB_ValToExp(ele) + )} )
?
? CASE_1 : ADEL(aArray, .T. .OR. .F.) --
ADEL(aArray, .T. .OR. .F.) // to adel() or to not adel()?
AEVAL( aArray, {|ele| QQOUT(HB_ValToExp(ele) + )} )
?
? CASE_2 : ADEL(aArray, 'Guess what element you'll nullify* now?') --
ADEL(aArray, Guess what element you'll nullify now?) // RTFM
AEVAL( aArray, {|ele| QQOUT(HB_ValToExp(ele) + )} )
?
? CASE_3 : ADEL(aArray, 2^66) --
ADEL(aArray, 2^66) // can arrays grow up so much ??
AEVAL( aArray, {|ele| QQOUT(HB_ValToExp(ele) + )} )
?
? CASE_4 : ADEL(aArray) --
ADEL(aArray) // do you mean, delete entire array?
AEVAL( aArray, {|ele| QQOUT(HB_ValToExp(ele) + )} )
?
? CASE_4b : ADEL(ADEL(aArray)) --
?? ADEL(ADEL(aArray)) // now that you've learned the art of adeleting...
?
AEVAL( aArray, {|ele| QQOUT(HB_ValToExp(ele) + )} )
?
Wait
RETURN
-8
In cases 1 2 one would expect the runtime mechanism to throw an error
because of the erroneous value types passed.
In case 3 a boundary error might be more appropriate/alarming.
And in Case 4 either:
- an entire array deletion could be more connotative expected or
- a runtime error due to lack of the 2nd mandatory arg.
Having the Adel() in all the above case to delete the first array
element is quite unreasonable, primarily because such an action is
undocumented. To be fair this is not a Harbour only feature. Clipper
behaves exactly the same here!
And while talking about adel() i think the name ADEL is rather
misleading, since the function does NOT actually delete elements,
but rather nullifies them, and you have to use asize()[*] to achieve
what you probably wanted to do. Perhaps ANUL() would be a more precise name
but i think it's a little late now to rename it g.
__
[*] I am aware of HB_ADEL() function, that accepts a 3rd parameter
(boolean) by which you can eventually adjust the array size without
the need of calling asize(). This is a good thing. The bad things are
that HB_adel() stands in the shade of adel() (due to lack of
documentation) while the above remarks about ADEL() apply also for
HB_ADEL too.
---
Pete
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: About Harbour Documentation
στις 18/02/2010 17:27, O/H Viktor Szakáts έγραψε: Hi All, So, I'd like to ask prospective contributors to _ignore these_ and concentrate on our path. It has been said many times: There will only be a documentation (in any format, or medium), if someone actually writes them. There is no other way. Ok, let's (try to) write some documentation. But before we start we have to know, what format should adopt. I mean, is Nanforum format mandatory or we could follow a more human form? For example, I am going to start documenting the functions HB_DirExists(), HB_FileExists(), HB_FNameExists() found into src\rtl\hbfile.c I choose to reproduce the structure of, say, doc\en-EN\dir.txt, hence i have to write something like: /* * The following parts are Copyright of the individual authors. * www - http://www.harbour-project.org * * Copyright 2010 documentor's_name m...@myoffice.gr *Documentation for: HB_DirExists(), HB_FileExists(), HB_FNameExists() * * See COPYING for licensing terms. * */ /* $DOC$ * $TEMPLATE$ * Function * $NAME$ * HB_DirExists() * $CATEGORY$ * API * $SUBCATEGORY$ * FileSys * $ONELINER$ * Determine if a directory exists * $SYNTAX$ * HB_DirExists( [cDirName] ) -- lExists * $ARGUMENTS$ * cDirName Directory name you want to check if exist. * Can contain a path and Drive letter. * Wildcards are NOT supported. * If no path specified then the current path is used. * SET DEFAULT are not evaluated. * $RETURNS$ * HB_DirExists returns a logical TRUE if cDirName exists, otherwise FALSE * $DESCRIPTION$ *Here goes a detailed and very time consuming 'bla-bla' about the function *for which bla-bla is better to been left for the second documantation wave *and why not as an imagination exercise for the potential reader) * * $EXAMPLES$ * #include 'common.ch' * Function Main( cDir ) *Default cDir to lib *QOUT(Current directory:CurDir() ) *QOUT(--) *QOUT( Directory:cDirdoes IIF( HB_DirExists(cDir), , NOT ) exist! ) *cDir := C:\ *QOUT( Directory:cDirdoes IIF( HB_DirExists(cDir), , NOT ) exist! ) *QOUT() *WAIT *RETURN Nil * * $STATUS$ * R * $COMPLIANCE$ * C * $PLATFORMS$ * All(LFN) * $FILES$ * Library is rtl * $SEEALSO$ * HB_FileExists(), HB_FNameExists() * $END$ */ Now i have one/two more questions: Are all those eye-bothering '$' '*' necesary? Also, are _all_ the above statements mandatory or we could leave out some of them like $SUBCATEGORY$ $STATUS$ $COMPLIANCE$ etc. to make the txt more compact and 'quick-readable' Supposing the answers are 'yes' let see how the above document could be written: -- /* $DOC$ FUNCNAME : HB_DirExists( cDirName ) -- lExists SHORTDESC : Determine if a directory exists ARGUMENTS : cDirName Directory name you want to check if exist. Can contain a path and Drive letter. Wildcards are NOT supported. If no path specified then the current path is used. SET DEFAULT are not evaluated. RETURNS : HB_DirExists returns a logical TRUE if cDirName exists, otherwise FALSE DESCRIPTION: [Here goes a detailed and very time consuming 'bla-bla' about the function for which bla-bla is better to left for the second documantation wave (and why not as an imagination exersize for the potential reader) ... ...] EXAMPLES: #include 'common.ch' Function Main( cDir ) Default cDir to lib QOUT(Current directory:CurDir() ) QOUT(--) QOUT( Directory:cDirdoes IIF( HB_DirExists( cDir ), , NOT ) exist! ) cDir := C:\ QOUT( Directory:cDirdoes IIF( HB_DirExists( cDir ), , NOT ) exist! ) QOUT() WAIT RETURN Nil PLATFORMS: All(LFN) FILES: Library is rtl SEE ALSO: HB_FileExists(), HB_FNameExists() $END$ */ An other critical question is how do i decide to document what? That is, how do I know if the above documentation is not already written by someone else? Obviously, somebody has to monitor the whole process, keeping an eye on 'who is documenting what' to avoid overlapping writing. And of course, there are other things/questions that must be cleared up, but can't been discussed all at once.. regards, --- Pete ___ Harbour
[Harbour] WCenter() malfunction.
Hi, WCenter() does not seem to work properly, at least in my installation. The problem arises when I pass the parameter [.t.], in order to obtain a real centering, that is, in the center of 'physical screen' (or terminal window). Although the wrow() wcol() coordinates seems to been updated correctly, the window's region does not move to the center of screen. The result is corrupted / mispositioned text, leaking out of the viewable margins of the window. The interesting thing, which (maybe) could help to isolate the problem, is that if you call alert() and then close it, immediately after the previously unsuccessfully 'centered' window, moves to the correct place in the center and everything looks ok. The other collateral damage is that (portion of) the alert() is not displayed on the topmost screen layer, but overlapped beneath the 'non-centered' window. However, after the alert() trick the overlap problem vanish. Below is a small prog, showing the problem. (Tested with both MingW and BCC, using Pritpal Bedi's latest distro.) /*--- code -*/ PROC Main() SetColor(W+/B) Scroll(); DevPos(0,0) ? Hello Harbour.. ? It was a long time. @ Row()+2, 0 Say Ok! now let's open a win. (press a key..) Inkey(0) SetColor(W/BG) wopen( 0,0,10,40 ) wbox(ÚÄ¿³ÙÄÀ³) WinMess(This is a window. Press a key to center it, please.) Inkey( 0 ) wcenter(.T.) Alert( Hmmm! wcenter() doesn't seem to work properly..; ..not to mention that alert() is being overlapped!) winMess(The very same window again. It must be centered now. (or not?)) Inkey(0) Alert(How about alert position?) return PROC WinMess(cMess) *** Scroll() DevPos((MaxRow()/2)-1, 0) ? cMess RETURN /*--- End code -*/ --- Pete ___ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://login.yahoo.com/config/mail?.intl=gr ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
