The future of Harbour

4,809 views
Skip to first unread message

Eric Lendvai

unread,
Dec 5, 2019, 1:14:50 PM12/5/19
to Harbour Users

I just noticed some deep conversion in the post "Harbour 3.2 Updated and available for download" https://groups.google.com/forum/#!topic/harbour-users/xA2kwORukTw and https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/harbour-users/xA2kwORukTw/W0xL6sbVBQAJ

But this new post, to match the subject.


I am fairly new to Harbour, only a little over 2 years. For more than 25 years I was developing desktop and web apps in VFP (Visual FoxPro) and Python mainly.


I saw the same problems of lack of direction and support for the Harbour language, but also came to appreciate its power, cross platform support and to be a true 4GL for C.


I created the web site https://harbour.wiki with the hope to create a foundation, similar to the Python Software Foundation, to help keep the language alive.


The only person that seriously responded to the proposal for a foundation was Antonio Linares. But he became very busy with mod_harbour, a solution to bring Harbour to the web.


He is not a maintainer of the project and can not merge commits. He had the great vision of the Harbour language, but also brought a commercial solution to the GUI problem.

He now fully embraces open-source solutions and was the main force behind mod_harbour.


As was mentioned before, the main core developers left the project, and it is almost impossible to bring in new developers.


I am donating my time to maintain harbour.wiki with the hope to turn it over to a foundation. I was also able to purchase the domain name "harbour.dev" with the hope to also donate it to the foundation.

This new domain name could become the core branch for the language?


Tutorial, reference material, requests for enhancement proposals, central package indexes are some of the main issues a Harbour foundation should deal with.


I created a source code scrapper in harbour.wiki to help create a core synced documentation, and slowly I am bringing Pete's and others documentation in it. I would really like to rely on some other developers to help with that project.

Antonio also proposed to create a documentation of the compiler itself, but again we don't have real access to core developers to help.

Ideally we should have something that looks like the one made for python: https://realpython.com/cpython-source-code-guide/


But in regards to the GUI issue, in my opinion, most future projects are web apps or could be implemented with html/css technologies like electron has, but having Harbour as the core language.


Also harbour is missing local SQL support, similar to what VFP had.


I just posted a repo about creating FastCGI apps in Harbour, and will soon have a detailed article about web development in Harbour . Hopefully the mod_harbour community can also embrace it.


Again, whatever my opinions are about web vs desktop, SQL, GUI platforms are, a foundation should be created to provide support and leadership for Harbour.

We need enough members in the foundation to ensure no single point of view steers the language, but instead provides support.

We don't want another fork, like xharbour, Viktor 3.4 ...


Other solutions like X#, xbase++ are just mainly commercial enterprises and still have the same issues of lack of developers base.

X# is basically a clone of Harbour in .Net, but with the restriction of the C# language.

xbase++ is Windows 32 bit only and closed source code.


Any ideas ?

Jnf Nascimento

unread,
Dec 5, 2019, 4:56:08 PM12/5/19
to Harbour Users
ja tentou enviar um email para o Victor e o Prmezek?, e deveria ter um link para doações aos principais desenvolvedores

Maurizio la Cecilia

unread,
Dec 5, 2019, 5:43:05 PM12/5/19
to harbou...@googlegroups.com
Hi Eric,
I really appreciate your wiki, one of few tries I saw that have an organic support for Harbour developers.
The foundation idea is smart, your preference for open-source development is same as mine.
I'm hoping that your proposal will be accepted by the most active developers.
I'm available for any contribution, if in my possibilities.
Best regards.
--
Maurizio
--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/harbour-users/e5c55a41-a3ba-4d77-bc43-cbfdfc78bd00%40googlegroups.com.


Eric Lendvai

unread,
Dec 5, 2019, 5:49:29 PM12/5/19
to harbou...@googlegroups.com
Yes I sent emails to both.  Only Viktor communicate back with me. He is open to provide minor help, but his private life is keeping him very busy. 
I use his hbmk2 contrib all the time!

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.

Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/harbour-users/360ee644-19cf-42d7-9603-b7e9f30144d6%40googlegroups.com.

Eric Lendvai

unread,
Dec 5, 2019, 5:51:31 PM12/5/19
to harbou...@googlegroups.com
Thank you. I saw you signed up on the wiki. Will send you my private email address. Later today. 


Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-users+unsubscribe@googlegroups.com.

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.

Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/harbour-users/db9f2af9-cbda-05ce-eb1e-fee4847de84a%40gmail.com.

DanCa

unread,
Dec 6, 2019, 4:13:55 AM12/6/19
to Harbour Users
For some reasons my Thunderbird seems not to send mails to the newsgroup right now. .-(
here is the message I tried to send yesterday, using Google groups for the first time in my life...

To Eric and Maurizio,

Eric, thank you for the time you are devoting to Harbour.

Harbour has absorbed a tremendous amount of time and effort from all people that have been involved in the project. I tried a couple of years ago to create a kind of community, and I registered the domain xdevelopers.com (now available I think), aimed at grouping all the xbase developers, where i put a CGI program developed with the embrional Harbour library that I am developing (dBaseWeb, it has a bit improved since). Some programmers answered to the call, they are still in the database. The domain has been moved then to a subdirectory of my web site, you can find it at:

http://developers/appliserver.com

My larval project is frozen, if not dead (but still working: you can register if you want, provided not to use a google mail address because TIP library for some reasons was failing to send to Gmail addresses).

The idea however is right IMO: we should create a community and decide all together. We don't need anymore a decider that keeps control under obscure circumstances. We need a crowfunding, a democratic process to state what to do and a serious plan to go ahead. If five thousand developers give a 100 buck each, we'll have a lot of money to carry on whatever future we want for Harbour.

I don't think people here is not willing to pour a little part of what they are earning with Harbour+their work to fund such a grand project. Maybe I'm wrong, but not that much, I believe.

To Maurizio:
I too like open-source projects, but I am a programmer, I think in terms of logic. We are programmers. We are (almost) all professionals and use Harbour to make and sell programs and make a living of it. Right?
Harbour is for most of us a convenient way to develop, being free from the strategies of Big Bosses
that decide what we should learn, study and use on the basis of their profits and their "vision", whatever it is.

.NET is a nightmare, so large that it is impossible to know all the functions and master it completely. We are talking of thousands of functions, involving a deep knowledge of Windows internals, etc.
And they just invented C# not because there was a real need of it, just to steer people from Java. They are the ones that took a beautiful product like Visual Foxpro and decided to let it die because it was not in their plans: not because programmers did not like it.

So why not to put some money on Harbour to keep it well and alive and keep alive the very idea of freedom? When the main developer of Minigui Extended asked for economic support, many have answered. IMO it's a bargain to pay a little money to have Harbour still alive.

The case of Viktor should make us think. He was alone at the command, for no money. He has done a terrific work, and at the end of the tale, probably forced by his real life, had to decide: should Harbour grant him some money, ok. If not, abandon the project. He had to left.
So we lost a talented programmer. Well done.

Let's imagine another scenario, in which the community rules what should be done, and there is a debate on what to carry on and which are the priorities. And Viktor makes some money from it.
Shouldn't it be a better way to proceed?

I'm just talking freely, I don't know if that is possible at all. But people work for money, and are happy in doing the job they love. So ask Viktor (or Przemek) to continue developing Harbour and give them some money, and I think they will be happy to say yes.

Just my personal opinion, I repeat.

you say:

About crowfunding I'm not convinced. We have the sample of xHarbour Guide: a work leaved in a suspended state and abandoned probably because the profit wasn't interesting for the author.

The author said that he poured a lot of money in the making of the docs, and never recovered the full amount. Can we blame him for being forced not to continue losing money?

again you say:

My aim isn't to make Harbour similar to commercial products, but to make it fully compliant with most recent technologies, all in a open source environment.

Nice, but you are expecting that someone carries on the hard work for free. I don't.
And you ends up with:

You're proposing to use it basically as a core compiler and to leave to third part commercial products the task to accomplish the lacking features.
I think that most of the interest on Harbour is also due in his open source spirit, not depending on the times and policies of development of business software houses.
I for one would be developing with xBase++/Microsoft Visual Studio/RAD Studio or other commercial tools if something should be payed.

I don't consider "lacking features" the supplemental parts of Harbour that can be sold by third parties. First of all, they would have interest in keeping the project alive and could contribute with software contributions to the core compiler or money, at choice.
Look at OpenSUSE, just to say. The Linux model works quite well, isn't it?

And I'm not sure that the only reason to use Harbour should be its gratuity: Harbour is a valid product and I use it, and I'll continue to use it even if I'll be requested to pay something. Of course for 1000 euros or so, I would look at other languages/compilers, but my idea is to ask programmers little money and keep it as free as possible, just paying a couple of talented core developers, and leaving the volunteers to contribute the best they can to the rest.

I am curious to hear what people think about it, however. Maybe I'm just babbling and should shut up. If so, sorry for having bothered you all.

Dan 

Eric Lendvai

unread,
Dec 6, 2019, 4:52:56 AM12/6/19
to Harbour Users
Thanks for signing up to harbour.wiki. Just sent you a direct email about it. 

Appliserver

unread,
Dec 6, 2019, 4:53:03 AM12/6/19
to harbou...@googlegroups.com

Eric, thank you for the time you are devoting to Harbour.

Harbour has absorbed a tremendous amount of time and effort from all people that have been involved in the project. I tried a couple of years ago to create a kind of community, and I registered the domain xdevelopers.com (now available I think), aimed at grouping all the xbase developers, where i put a CGI program developed with the embrional dBaseWeb library that I am developing (it has a bit improved since). Some programmers answered to the call, they are still in the database. The domain has been moved then to a subdirectory of my web site, you can find it at:

http://developers/appliserver.com

My larval project is frozen, if not dead (but still working: you can register if you want, provided not to use a google mail address because TIP library for some reason was failing to send to Gmail addresses). The idea however is right IMO: we must create a community and decide all together. We don't need anymore a decider that keeps control under obscure circumstances. We need a crowfunding, a democratic process to state what to do and a serious plan to go ahead. If five thousand developers give a 100 buck each, we'll have a lot of money to carry on whatever future we want for Harbour.


I don't think people here is not willing to pour a little part of what they are earning with Harbour+their work to fund such a grand project. Maybe I'm wrong, but not that much, I believe.

BTW I personally would suggest the following lines:
1) Android port
2) decide once for all a standard, solid GUI among the standard, solid available
2) focus on web development
3) Harbour documentation project STARTING FROM SCRATCH, that's to say a guide to design RDBM programs, not only a reference to the available functions/commands
4) a CASE would be the cherry on the cake.

Dan
--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.

Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.

Appliserver

unread,
Dec 6, 2019, 4:53:03 AM12/6/19
to harbou...@googlegroups.com
To Eric and Maurizio,

Eric, thank you for the time you are devoting to Harbour.

Harbour has absorbed a tremendous amount of time and effort from all
people that have been involved in the project. I tried a couple of years
ago to create a kind of community, and I registered the domain
xdevelopers.com (now available I think), aimed at grouping all the xbase
developers, where i put a CGI program developed with the embrional
Harbour library that I am developing (dBaseWeb, it has a bit improved
since). Some programmers answered to the call, they are still in the
database. The domain has been moved then to a subdirectory of my web
site, you can find it at:

http://developers/appliserver.com

My larval project is frozen, if not dead (but still working: you can
register if you want, provided not to use a google mail address because
TIP library for some reasons was failing to send to Gmail addresses).

The idea however is right IMO: we should create a community and decide
all together. We don't need anymore a decider that keeps control under
obscure circumstances. We need a crowfunding, a democratic process to
state what to do and a serious plan to go ahead. If five thousand
developers give a 100 buck each, we'll have a lot of money to carry on
whatever future we want for Harbour.

I don't think people here is not willing to pour a little part of what
they are earning with Harbour+their work to fund such a grand project.
Maybe I'm wrong, but not that much, I believe.

Appliserver

unread,
Dec 6, 2019, 4:53:03 AM12/6/19
to harbou...@googlegroups.com

Maurizio la Cecilia

unread,
Dec 6, 2019, 7:26:03 AM12/6/19
to harbou...@googlegroups.com
Hi Dan,
I agree.
>
> .NET is a nightmare, so large that it is impossible to know all the
> functions and master it completely. We are talking of thousands of
> functions, involving a deep knowledge of Windows internals, etc.
> And they just invented C# not because there was a real need of it,
> just to steer people from Java. They are the ones that took a
> beautiful product like Visual Foxpro and decided to let it die because
> it was not in their plans: not because programmers did not like it.
>
> So why not to put some money on Harbour to keep it well and alive and
> keep alive the very idea of freedom? When the main developer of
> Minigui Extended asked for economic support, many have answered. IMO
> it's a bargain to pay a little money to have Harbour still alive.
"Money, get away..." (Pink Floyd)
I am not a dreamer fond of the utopia of the world without money, but I
fear that compensating someone with money means leaving to him the
management of the project. This would bring me back to the times when I
had to beg the necessary fixes to carry on my work to Microsoft or
Borland, with the result of seeing them published only when it suited
them, or even never.
I hope I'm wrong, but I feel this.
>
> The case of Viktor should make us think. He was alone at the command,
> for no money. He has done a terrific work, and at the end of the tale,
> probably forced by his real life, had to decide: should Harbour grant
> him some money, ok. If not, abandon the project. He had to left.
> So we lost a talented programmer. Well done.

The case of Viktor it's just the case in which the community delegated
to one the job. We leaved, for our commodity, Viktor to act and to take
decision (most of them right) without collaborate and mediate. Perhaps
the fork could been avoided, if other people was participating at the
changes.  We, me the first one, have watched him working, limiting
ourselves to thank without influencing the decisions and without helping
in any way.

Do you remember the debate about to leave qtcontribs in addons folder or
transfer it in another repository?
It was one of the rare cases in which the community talked about the
question and now, also if someone wasn't in agreement with the final
result, nobody can tell that was a unilateral Viktor's decision.

>
>
> Let's imagine another scenario, in which the community rules what
> should be done, and there is a debate on what to carry on and which
> are the priorities. And Viktor makes some money from it.
> Shouldn't it be a better way to proceed?
>
> I'm just talking freely, I don't know if that is possible at all. But
> people work for money, and are happy in doing the job they love. So
> ask Viktor (or Przemek) to continue developing Harbour and give them
> some money, and I think they will be happy to say yes.
>
> Just my personal opinion, I repeat.
Perhaps, the Foundation idea of Eric is the better path.
Perhaps, this way take sense to pay someone to apply the directives, I
admit.
>
> you say:
>
> About crowfunding I'm not convinced. We have the sample of xHarbour
> Guide: a work leaved in a suspended state and abandoned probably
> because the profit wasn't interesting for the author.
>
> The author said that he poured a lot of money in the making of the
> docs, and never recovered the full amount. Can we blame him for being
> forced not to continue losing money?
Again my poor English could be misunderstood...
I was saying that often crowfunding doesn't cover the right fee for the
work.
I wasn't blaming the poor author.
>
> again you say:
>
> My aim isn't to make Harbour similar to commercial products, but to
> make it fully compliant with most recent technologies, all in a open
> source environment.
>
> Nice, but you are expecting that someone carries on the hard work for
> free. I don't.
Why not? If we collaborate all, no hurt.
Obviously, if we want a Viktor 2.0 there's no future without money.
> And you ends up with:
>
> You're proposing to use it basically as a core compiler and to leave
> to third part commercial products the task to accomplish the lacking
> features.
> I think that most of the interest on Harbour is also due in his open
> source spirit, not depending on the times and policies of development
> of business software houses.
> I for one would be developing with xBase++/Microsoft Visual Studio/RAD
> Studio or other commercial tools if something should be payed.
>
> I don't consider "lacking features" the supplemental parts of Harbour
> that can be sold by third parties. First of all, they would have
> interest in keeping the project alive and could contribute with
> software contributions to the core compiler or money, at choice.
> Look at OpenSUSE, just to say. The Linux model works quite well, isn't
> it?
>
> And I'm not sure that the only reason to use Harbour should be its
> gratuity: Harbour is a valid product and I use it, and I'll continue
> to use it even if I'll be requested to pay something. Of course for
> 1000 euros or so, I would look at other languages/compilers, but my
> idea is to ask programmers little money and keep it as free as
> possible, just paying a couple of talented core developers, and
> leaving the volunteers to contribute the best they can to the rest.

With respect, but your concept of open-source isn't the mine.

For what I think open-source isn't equal to free of charge, almost when
is applied to development software.

Open-source, IMHO, is to participate to a project in active way, gaining
the knowledge of the sources and having the surety that you could
continue to develop on it without the risk that Nantucket or CA will
abandon Clipper, or Microsoft abandon VFP or after you invested in
VisualBasic M$ decide to break compatibility, etc, etc.

About the gratuity I've another concept: how much I'd spent in time to
study and (when in my humble possibilities) work on sources, deepening
Harbour and quite all the contribs and third part libraries I was needing?
How much I'd spent in time collaborating on Harbour, HWGui, etc.?
How much I'd spent to retrieve the needed documentation finding it in
changelog.txt, in the threads of the group or studying the source of the
functions?

Well, I bought xBase++, then I studied the manual and in less than a
month I'd learned the language, then I'd developed my first application
in the next two weeks (before to find that RDD was buggy...), paying
about 600€ to have a (hopefully) working development tool.
I think that, dividing 600€ by the hours I spent on Harbour & C., my
hourly fee would be of about 1€ * 10^-5 or minus.

So about money, I think open-source is a loser when related to
development. I'm an happy user of a lot of open-source applications and
I never paid, only contributed to the project when possible.

I could agree with you on an aspect: if I had paid for Harbor (but
complete with preparatory manual, user guide, language reference,
examples, etc.) 1500€, I would have made a deal.
On this we can reason.

A Foundation that grants the future to the project and charge of fee
only the users not collaborating could be a solution, IMHO.

>
> I am curious to hear what people think about it, however. Maybe I'm
> just babbling and should shut up. If so, sorry for having bothered you
> all.
>
> Dan
>
Of course, I'm also waiting for other guys opinions. And your
argumentation are all valid, or both us are just babbling...

--
Maurizio

Mel Smith

unread,
Dec 6, 2019, 5:56:03 PM12/6/19
to Harbour Users

Hi Maurizio:

   I say:  Let's leave money out of Harbour. If one wishes to make a living from Harbour, then build a great app for your users and charge *them* for it.

   If you love the thought of Harbour and its development, then contribute freely until you become fatigued with it, or 'fall out of love'. If you then decide to leave, then leave gracefully and leave a product of work you are proud of.

   The xHarbour group is facing the same problems as this group:  Patrick Mast and Ron Pinkas split off from this group many years ago. They had gradually become disinterested, and departed. Patrick Mast always had an eye for the money-making aspects of Harbour, but could not make much headway in xHarbour, and is now pursuing / marketing his WinFakt package. He also sells support for his GUI screen for xHarbour. 

   The users over at xHarbour have now lost most of the original developers, and are now dependent upon Enrico Maria Giordano (with 'some' help from Luiz Culik some times) for simpler changes in .prgs and .c , and David Smith offers help to users with problems that need an expert's understanding of error messages. The users there generally use Borland/Embarcadero compilers (from Borland 5.5.1 up through Embarcadero's Borland 7.4). Whereas, in *this* group, the MinGW set of compilers are favoured.

   So, please don't forget about the *many* harbour language users in the xHarbour fork. Probably many would like to join you but feel frightened  to make the transition. Fright: .o instead of .obj,  .a instead of .lib, etc, etc. Surely, only format changes, but still scary for them

   Myself:  I have apps made in both Harbour and xHarbour, and at least weekly and I transit back-and-forth.

   
-Mel Smith

 
   It is a pity that the experts here ignore their brethren over at xHarbour

Maurizio la Cecilia

unread,
Dec 6, 2019, 6:37:51 PM12/6/19
to harbou...@googlegroups.com
Hi Mel,

Il 06/12/2019 23:56, Mel Smith ha scritto:

Hi Maurizio:

   I say:  Let's leave money out of Harbour. If one wishes to make a living from Harbour, then build a great app for your users and charge *them* for it.
It's just what I'm doing since I landed to [x]Harbour


   If you love the thought of Harbour and its development, then contribute freely until you become fatigued with it, or 'fall out of love'. If you then decide to leave, then leave gracefully and leave a product of work you are proud of.
I don't figure how I could 'fall out of love'. I like Harbour and I don't plan to change my development environment.


   The xHarbour group is facing the same problems as this group:  Patrick Mast and Ron Pinkas split off from this group many years ago. They had gradually become disinterested, and departed. Patrick Mast always had an eye for the money-making aspects of Harbour, but could not make much headway in xHarbour, and is now pursuing / marketing his WinFakt package. He also sells support for his GUI screen for xHarbour. 

   The users over at xHarbour have now lost most of the original developers, and are now dependent upon Enrico Maria Giordano (with 'some' help from Luiz Culik some times) for simpler changes in .prgs and .c , and David Smith offers help to users with problems that need an expert's understanding of error messages. The users there generally use Borland/Embarcadero compilers (from Borland 5.5.1 up through Embarcadero's Borland 7.4). Whereas, in *this* group, the MinGW set of compilers are favoured.

   So, please don't forget about the *many* harbour language users in the xHarbour fork. Probably many would like to join you but feel frightened  to make the transition. Fright: .o instead of .obj,  .a instead of .lib, etc, etc. Surely, only format changes, but still scary for them

   Myself:  I have apps made in both Harbour and xHarbour, and at least weekly and I transit back-and-forth.
I migrated from Clipper many years ago and I adopted xHarbour at beginnings.
As soon I discovered the commercial plot that was behind it and I read the xhb-diff.txt doc of Harbour distro, I decided to use Harbour and still I'm fully convicted that I did the right thing.
Porting from xHarbour to Harbour went a joke, thus I don't understand the reluctance to definitely transit to Harbour. I repeat, the reading of xhb-diff.txt and a speed test should be enough to decide.

Anyway, the developer is a wild animal and thus he's free to live in the scape he prefer...


   
-Mel Smith

 
   It is a pity that the experts here ignore their brethren over at xHarbour
I agree, but the choice is on charge of the xHarbourians.

Thanks for your abstract of the history and of the state of art of xHarbour.

--

Maurizio

--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.

do...@people.net.au

unread,
Dec 12, 2019, 11:51:37 PM12/12/19
to harbou...@googlegroups.com
Hi all

Really interested in this discussion about the future of Harbour.

I think that the fundamental problem is that it isn't a solution "fresh
out of the box". By that I mean that you can download and build Harbour
(or depending upon your platform etc download it pre-built). But then
in most instances you have to decide what GUI you are going to use and
what database. Also decide what editor and maybe what integrated
development environment. Also whilst there is a fair amount of
documentation about the many functions, commands, directives etc a
comprehensive general guide to the language (like a text book) doesn't
exist which is OK if you have a background of xBase but can be a bit
daunting otherwise.

If you can get over all of that you will probably fall in love with
Harbour but if you aren't already aware of the beauty of the xBase
languauge you will most likely give up before you get to that point.

I know that Harbour comes with built in support for xBase data files in
my experience if you are doing anything substantial in the way of multi
user data access, especially over multiple sites, then traditional xBase
data file access is too inefficient.

When faced with these issues when I first started with Harbour on a
Linux platform I started out using Antonio Linares' FiveLinux for GUI
support. I then wrote my own interface to GTK+. The trouble with GTK+
is that it isn't sufficiently cross platform (Qt wasn't quite there when
I started). Also its latest version does not fully support fixed
rendering despite the fact that it is more efficient so they can preach
about translating your software to support multiple languages (which I
don't want to do) with dynamic placement. Probably default support for
Qt or some other cross platform GUI library should be included in
Harbour.

The moment I had to support multiple sites I ran into performance issues
with data access. I solved that by writing a client server database in
Harbour that used xBase tables. I found that to be efficient and
robust. It was almost a no brainer to support transaction logging and
triggers. The only extrra feature that I would have liked was the
ability to have variable length fields.

My days of using Harbour for business are gone but I may be able to work
on some of these issues if there is an agreed direction and a master
plan.

Regards
Doug

Francesco Perillo

unread,
Dec 13, 2019, 9:11:39 AM12/13/19
to harbou...@googlegroups.com
Hi Doug,
may I ask why you wrote a lot of delicate code (a gui and a database server) instead of moving to another language? I imagine that you had to adapt your code anyway to use the new gui and the databases server....

I'm interested in the database server: I want to get rid of the dbf file sharing (in a time of cryptolocker...) and use the cpu power of the server instead of moving data across the lan... since you say that you are no more in the harbour business, can you think about open sourcing your code?


Francesco

Francesco Perillo

unread,
Dec 13, 2019, 9:32:55 AM12/13/19
to harbou...@googlegroups.com

Not related to Harbour but I feel the same feeling...

Maurizio la Cecilia

unread,
Dec 13, 2019, 9:52:56 AM12/13/19
to Harbour User Group
Hi Doug,
very interesting history.
I'm asking you if your client-server implementation is netio based or is created from scratch.
Sharing your work or just your approach could be much useful for thinking to smart alternatives. The persistence of a dbf database could be a plus.
Best regards.

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.

do...@people.net.au

unread,
Dec 13, 2019, 4:59:41 PM12/13/19
to harbou...@googlegroups.com
Hi

My client-server database server was created from scratch using the TIP
classes.

Data was sent in the form of an array that had been serialized using
HBSerialize(). This can be put straight into a local object using a
standard Harbour function although I made a modified version to avoid
going to an error condition if the array contained data that was not
present in the receiving object. That was helpful if you added fields
in later releases.

Queries were all set up on the server via config files read in at server
start up. They were in XML format although you could use any
appropriate format such as json if you didn't like XML. They were
stored in an array so requesting client only had to send the query
number and the required parameters.

Data logging was easy as you only needed to store the serialized array
in a memo field.

Implementing triggers was straight forward as you could use the
HBCompileFrom functions.

I didn't need ad hoc queries but that shouldn't be too hard either
sending the same config that the server uses at startup or using a
modification of the trigger concept if you want to do it in xBase code.

I started up a separate server program instance for each end user
(although they could be shared) as I only needed about 8 and it meant
that iut was easy to monitor what each user was doing if there was any
issue. That approach had several other advantages as different users
could use different versions of both the database server backend and /
or the frontend. For a much larger number of users you would probably
run with threads.

My code used the TIP timeout to determine the end of transmission but I
did show (but only in testing) that you could send a length as part of
the transmission which would be more efficient although in practice
there was no need in my case for increased efficiency as it was very
fast as first implemented.

The only other real limitation in my code was that whilst you could do
as many "normal" joins as you liked you could only do 1 join to many - I
have forgotten what you call it in SQL maybe left outer join? I am sure
that that could be solved if needs be.

I hadn't implemented roll forward from a backup but if you data log that
would be relatively trivial.Roll back would require more storage I guess
but could be done.

So what wouldn't you get that you might get in some other system?

Variable length fields (Other than memo fields) - limitation of xBase
format files

Transaction control

Data server redundancy - I reckon that that might be quite doable.

When my server returned a query it included a standardized error code
(mostly 0) so that the front end could deal with error situations as
best it could.

I am happy to share my code. I did so once in the past but it didn't
seem to be of interest.

My front end was generated from a series of format files so that all
screens behaved in the same way. The generator, pretty much embodied my
style and so wouldn't suit most people but the approach is ideal but
would need configurable templates to be generally useful.

At startup my frontend programs load an initial config file (stored
locally) which tells it where its current config file is (stored on the
server). The latter file includes the version number which is checked
against the version number of the frontend program. If the two differ
the user is given the option to upgrade (or downgrade) to the specified
version. It then copies the new version and alters the user's menu so
that in future it will run the newly downloaded version. That means
that you can very easily change the version that any user is using
remotely. Great for testing and progressively introducing upgraeded
versions of your software.

Regards
Doug
> https://groups.google.com/d/msgid/harbour-users/CAGDVDAitfUKutVOToq7OgyrR2fDLAYp5G569iYvNZpJUTGsS9A%40mail.gmail.com
> [1].
>
>
> Links:
> ------
> [1]
> https://groups.google.com/d/msgid/harbour-users/CAGDVDAitfUKutVOToq7OgyrR2fDLAYp5G569iYvNZpJUTGsS9A%40mail.gmail.com?utm_medium=email&utm_source=footer

Appliserver

unread,
Dec 14, 2019, 10:23:23 AM12/14/19
to harbou...@googlegroups.com
On 12/13/2019 05:51 AM, do...@people.net.au wrote:
> Hi all
>
> Really interested in this discussion about the future of Harbour.
>
> I think that the fundamental problem is that it isn't a solution
> "fresh out of the box". By that I mean that you can download and
> build Harbour (or depending upon your platform etc download it
> pre-built). But then in most instances you have to decide what GUI
> you are going to use and what database. Also decide what editor and
> maybe what integrated development environment. Also whilst there is a
> fair amount of documentation about the many functions, commands,
> directives etc a comprehensive general guide to the language (like a
> text book) doesn't exist which is OK if you have a background of xBase
> but can be a bit daunting otherwise.
>
Doug,
JFTR, I followed a different path.
When faced to the GUI issues, I decided that the way to go was to use
Harbour (or xHarbour) as a terrific way to produce CGI programs.
The current state of CGI programs is "disregarded, inefficient,
deprecated"? Bullshit.

Of course if you try to use .NET apps or whatever with the CGI
technology you'll probably end up with very inefficient stuff. Try to
use Harbour as it is without any GUI overhead.
You'll have something like *pure c executables run by a web server*,
something that is highly efficient and causes no overhead at all. A
monster, a killer app.

My larger executable is a mere 2-3 Mb sized program (yes, it's a pure
text-mode Harbour executable) either under Linux or Windows. Apache (or
IIS, or whatever) will execute it in milliseconds. The rendering and all
the UI issues are managed by the browser, and Harbour in pure text mode
achieves a troughput simply "alien classifiable" under current ratings. :-)

Just to test it, I installed a Harbour CGI in a puny laptop running a
squalid Windows XP Home, with a pure C highly efficient web server (Jana
server) and the user WAS NOT ABLE TO NOTICE that the technology used was
that client-server stuff with a web server and all the overhead
involved. It was faster than other "native" programs . No jokes.
Put such a execzilla monster on a modern server. Use it. Say "Oh!"
Stop with all that stuff about dBase compatibility. Harbour is a
superset of C, highly efficient, multi-platform, t is in fact pure C
made easier. It would be better than Java, if not for the GUI problem.

> If you can get over all of that you will probably fall in love with
> Harbour but if you aren't already aware of the beauty of the xBase
> languauge you will most likely give up before you get to that point.
>
You are near to hitting the point IMO
> I know that Harbour comes with built in support for xBase data files
> in my experience if you are doing anything substantial in the way of
> multi user data access, especially over multiple sites, then
> traditional xBase data file access is too inefficient.
>
I don't know the dimensions you are talking about. I can figure out
that: a million users accessing the databases is over the possibilities
of Harbour. You must use SQL. Ok. World has changed etc. I manage, on
the other side, private sites that can have a hundred of less users.
Here dbf behaves quite good... more or less. So we are back to the
point: not to publicize Harbour as a compatibility tool to the
(venerable) Clipper. It is a SoPCL (Superset of Pure C Language) and
that should be the way to refer to it. Who knows about Clipper? A scarce
and old subset of old programmers ("Clipperheads", eh...). What the
hell? Do we really think that the actual Harbour has more to do with
Clipper than providing the loyal compatibility, than at the same time
being something COMPLETELY DIFFERENT?
Stop thinking of Harbour as the new Clipper - it is, but it is a new
thing, also.

> When faced with these issues when I first started with Harbour on a
> Linux platform I started out using Antonio Linares' FiveLinux for GUI
> support.
I too, more or less, trying HWGUI, but landing to MINIGUI then.

> I then wrote my own interface to GTK+. The trouble with GTK+ is that
> it isn't sufficiently cross platform (Qt wasn't quite there when I
> started). Also its latest version does not fully support fixed
> rendering despite the fact that it is more efficient so they can
> preach about translating your software to support multiple languages
> (which I don't want to do) with dynamic placement. Probably default
> support for Qt or some other cross platform GUI library should be
> included in Harbour.
>
Ugh. You made a huge work. I made a similar (=huge) work on CGI side
(dBaseWeb).
> The moment I had to support multiple sites I ran into performance
> issues with data access. I solved that by writing a client server
> database in Harbour that used xBase tables. I found that to be
> efficient and robust. It was almost a no brainer to support
> transaction logging and triggers. The only extrra feature that I
> would have liked was the ability to have variable length fields.
>
> My days of using Harbour for business are gone but I may be able to
> work on some of these issues if there is an agreed direction and a
> master plan.
>
> Regards
> Doug
>
Dan

Gerald Drouillard

unread,
Dec 14, 2019, 11:07:43 AM12/14/19
to harbou...@googlegroups.com
On Sat, Dec 14, 2019 at 10:23 AM Appliserver <webm...@appliserver.com> wrote:
Doug,
JFTR, I followed a different path.
When faced to the GUI issues, I decided that the way to go was to use
Harbour (or xHarbour) as a terrific way to produce CGI programs.
The current state of CGI programs is "disregarded, inefficient,
deprecated"? Bullshit.
+1
 

Of course if you try to use .NET apps or whatever with the CGI
technology you'll probably end up with very inefficient stuff. Try to
use Harbour as it is without any GUI overhead.
You'll have something like *pure c executables run by a web server*,
something that is highly efficient and causes no overhead at all. A
monster, a killer app.

My larger executable is a mere 2-3 Mb sized program (yes, it's a pure
text-mode Harbour executable) either under Linux or Windows. Apache (or
IIS, or whatever) will execute it in milliseconds. The rendering and all
the UI issues are managed by the browser, and Harbour in pure text mode
achieves a troughput simply "alien classifiable" under current ratings. :-)
+1 

Just to test it, I installed a Harbour CGI in a puny laptop running a
squalid Windows XP Home, with a pure C highly efficient web server (Jana
server) and the user WAS NOT ABLE TO NOTICE that the technology used was
that client-server stuff with a web server and all the overhead
involved. It was faster than other "native" programs . No jokes.
Put such a execzilla monster on a modern server. Use it. Say "Oh!"
Stop with all that stuff about dBase compatibility. Harbour is a
superset of C, highly efficient, multi-platform, t is in fact pure C
made easier. It would be better than Java, if not for the GUI problem.
+1 
 
I don't know the dimensions you are talking about. I can figure out
that: a million users accessing the databases is over the possibilities
of Harbour. You must use SQL. Ok. World has changed etc. I manage, on
the other side, private sites that can have a hundred of less users.
Here dbf behaves quite good... more or less. So we are back to the
point: not to publicize Harbour as a compatibility tool to the
(venerable) Clipper. It is a SoPCL (Superset of Pure C Language) and
that should be the way to refer to it. Who knows about Clipper? A scarce
and old subset of old programmers ("Clipperheads", eh...). What the
hell? Do we really think that the actual Harbour has more to do with
Clipper than providing the loyal compatibility, than at the same time
being something COMPLETELY DIFFERENT?
Stop thinking of Harbour as the new Clipper - it is, but it is a new
thing, also.
+1
Clipper was good at CGI back in the day also.  But harbour is so much more. 

Mel Smith

unread,
Dec 14, 2019, 11:25:18 AM12/14/19
to Harbour Users


On Saturday, December 14, 2019 at 9:07:43 AM UTC-7, Gerald Drouillard wrote:


On Sat, Dec 14, 2019 at 10:23 AM Appliserver <webm...@appliserver.com> wrote:
Doug,
JFTR, I followed a different path.
When faced to the GUI issues, I decided that the way to go was to use
Harbour (or xHarbour) as a terrific way to produce CGI programs.
The current state of CGI programs is "disregarded, inefficient,
deprecated"? Bullshit.
+1
    + 1
 Agree totally with Dan.

    (I've used Harbour as a CGI app under the  free Apache Web Server since 2009. With no operational problems whatsoever. My only difficulty was switching back and forth between Javascript and Harbour when coding Front-end and Back-end simultaneously. The similarity (and differences) between the languages was brain-busting for awhile. Then, add-in HTML and CSS, and you have to dance very carefully while coding.)

-Mel Smith

 

Mel Smith

unread,
Dec 14, 2019, 11:33:05 AM12/14/19
to Harbour Users

    (I've used Harbour as a CGI app under the  free Apache Web Server since 2009. With no operational problems whatsoever. My only difficulty was switching back and forth between Javascript and Harbour when coding Front-end and Back-end simultaneously. The similarity (and differences) between the languages was brain-busting for awhile. Then, add-in HTML and CSS, and you have to dance very carefully while coding.)
 
Addendum:
   But I simplified my coding task a bit by making a small library of Javascript functions that emulated Harbour functions. This helped .
-Mel


Appliserver

unread,
Dec 14, 2019, 11:50:23 AM12/14/19
to harbou...@googlegroups.com
function tostring(para)
    local retVal
    do case
    case para==NIL
        retval="NIL"
    case valtype(para)="N"
        retVal=ltrim(str(para))
    case valtype(para)="D"
        retVal=dtoc(para)
    case valtype(para)="L"
        retval=if(para,"true","false")
    otherwise
        retVal=para
    endcase
return retVal

:-)
Just to use something similar to the Javascript "toString" method

Dan
--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.

Eric Lendvai

unread,
Dec 14, 2019, 3:38:58 PM12/14/19
to Harbour Users
I also agree with many of the replies in this message post that Harbour is more than just a Clipper compatible language, it is a 4 GL language on top of C.

Also agree that Harbour can is very well suited to create web apps.

I recently added a repo to create FastCGI Harbour apps: https://github.com/EricLendvai/Harbour_FastCGI

I should have by next week a detail article about how to create FastCGI apps on https://harbour.wiki

It should be fairly easy to port over any CGI apps to it. This would allow you to keep your tables or SQL connections open between calls, and not have to restart your EXE at every web page request!
I hope this can help many of the current CGI Harbour developers out there and also bring some more developers to the web.

The article will also explain how to debug and deal with program updates as well.

Eric

do...@people.net.au

unread,
Dec 14, 2019, 4:51:45 PM12/14/19
to harbou...@googlegroups.com
Hi all

I agree with everyone that Harbour is a 4GL (well actually I regard it
as a 5GL)

As far as web programming is concerned rather than use a CGI interface I
wrote a very simple web server in Harbour using the TIP classes. Not
sure how scalable but very fast and yes you could leave tables open etc.
Basic technique pretty much like client-server database. Fast but in
my case that wasn't important. Meant I could keep Linux back end and
send to Windoze front end. I may try the fast CGI approach out of
interest. Writing my own mini web server in Harbour meant that I didn't
have to spend time learning about someone else's program - all I had to
learn was the HTTP protocol which is very easy especially as I didn't
need to send images.

Using web browser as front end is a good approach and one that I used
years ago generating web pages on the fly from templates (but not from
Harbour). It certainly supports multiple devices BUT even on any given
device type there are issues with different browsers which can be very
frustrating. Because of the proposed client I had to code in VB (which
I hadn't used before) rather than C, with SQLServer (which I hadn't used
before) and embed HTML and Javascript (both of which were pretty new to
me) so I do understand the multiple languages at once issue. My lap
wasn't big enough for all those manuals! That was back when Microsoft
had IE for the Apple BUT it was so very incompatible with IE for the PC.
Writing a generator that would write HTML that would work on both wqas
quite a challenge.

Regards
Doug
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> Unsubscribe: harbour-user...@googlegroups.com
> Web: http://groups.google.com/group/harbour-users
>
> ---
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to harbour-user...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/harbour-users/c4dabe8c-263c-4986-84b1-6d22619de10b%40googlegroups.com
> [1].
>
>
> Links:
> ------
> [1]
> https://groups.google.com/d/msgid/harbour-users/c4dabe8c-263c-4986-84b1-6d22619de10b%40googlegroups.com?utm_medium=email&utm_source=footer

Appliserver

unread,
Dec 15, 2019, 8:07:16 AM12/15/19
to harbou...@googlegroups.com
On 12/14/2019 10:51 PM, do...@people.net.au wrote:
> Hi all
>
...
> Using web browser as front end is a good approach and one that I used
> years ago generating web pages on the fly from templates (but not from
> Harbour). It certainly supports multiple devices BUT even on any
> given device type there are issues with different browsers which can
> be very frustrating.
That is related to the good techniques to adopt in writing
cross-platform javascript code.
Provided the situation at present is WAY better than it was some years
ago, still differences exist among the ECMAScript (the "real name" of
Javascript) implementations.

I participated in endless discussions (mainly as a lurker...) in the
group comp.lang.javascript, where some of the more experienced
programmers are involved, and learned a lot. Javascript SEEMS quite
simple, but it is not - if you want really to master it.

I included in my dBaseWeb library many scripts ready to use. I wrote
them at my best, still I feel I am a kind of amateur with regard to
Javascript. Some of the scripts are 8-years old but they still run in
every browser I tested, so I am quite proud of the results.
Unfortunately there are around in Internet a lot of scripts "ready to
use" that are really ill-made, or specific to one browser, and fail
miserably on another.

Just to make an example: I have a script that changes the dimensions of
a <div> element to adapt it to the current window/frame dimensions (the
script refers to the div with ID "container", that is a standard element
of the pages created with other automated functions, or the div ID can
be passed as a parameter). The desired size is 980 pixel or less.
//10/2015
function sizeDiv(i){
if(arguments.length==0) i='container'
var d=document.getElementById(i)
if (typeof d != 'undefined'){
if (d.offsetParent) {
var theW=d.offsetParent.clientWidth||d.offsetParent.offsetWidth}
else {
var
theW=(window.innerWidth||document.documentElement.clientWidth||document.body.clientWidth)}
if (theW>0) d.style.width=Math.min(theW,980)+'px'}}

The point is that the script uses the property offsetParent, and them
tries the syntax offsetParent.clientWidth, or has a fallback to
offsetParent.offsetWidth.
Or it tries window.innerWidth, or document.documentElement.clientWidth,
or document.body.clientWidth.

If no element with the specified ID, or the default one, is found
nothing happens, and also nothing happens if none of the tried
properties is supported.

The goal is to have robust multi-platform scripts, and this requires to
deepen not only ECMAcript "per se" but also the different
implementations on different browsers! *that* is really frustrating! I
think that no other language is so loosely-conceived to impose to the
developers to learn 3 or 4 dialects!
In the past things were even worst: a really robust script had to sniff
the browser in which it was executed or, better, feature-test the
environment (with some complicated trick to avoid an exception error on
some tests...).
In writing dBaseWeb the time I spent on Javascript is by far larger than
the time spent on Harbour code...

> Because of the proposed client I had to code in VB (which I hadn't
> used before) rather than C, with SQLServer (which I hadn't used
> before) and embed HTML and Javascript (both of which were pretty new
> to me) so I do understand the multiple languages at once issue. My
> lap wasn't big enough for all those manuals! That was back when
> Microsoft had IE for the Apple BUT it was so very incompatible with IE
> for the PC. Writing a generator that would write HTML that would work
> on both wqas quite a challenge.
>
Exactly
> Regards
> Doug
>
Dan

fdaniele

unread,
Dec 16, 2019, 6:13:21 AM12/16/19
to Harbour Users
Thanks mr. Eric, you are our future !!

Eric Lendvai

unread,
Dec 17, 2019, 6:08:53 AM12/17/19
to Harbour Users
Thanks, but this is all going to be a team effort.

What about if we create a SurveyMonkey survey to find out what we should focus our efforts on?

We first need to setup the list of questions we would ask Harbour developers.

For example. 
 Grade from 1 to 10 (less to most important) 
     -Supporting most C compilers, or just the ones the Harbour 3.4 is targeting ?
     -Creating an interactive package index system (like Python, Node, .Net have)
     -Training material about the Harbour Core, to help create new core developers
     -Training material for new Harbour developers
     -Web development tools
     -Desktop Apps, and maybe list the main tools?
     -Electron like for Harbour?
     -Centralized Harbour Job Postings?
     -A full Harbour Foundation
     -Method to bring over xHarbour and Xbase++ developers
     -Method to bring over Foxpro and Visual FoxPro developers
     -Funding source or sponsors?

Please add more questions here .

Francesco Perillo

unread,
Dec 17, 2019, 6:48:04 AM12/17/19
to harbou...@googlegroups.com
Hi Eric,
go to the last line for a shorter and quick read... :-)

In this period I need a way to hide dbf files from shared disks.

NETIO, letodf or letodbf are first choices, a home-made server like Dougs' is also ok (if he wants to share the code it can be a foundation to evolve...)
(Since I have a linux server where I want to host the dbf, I think it would be a problem to access dbf files from linux and from windows clients via a samba share concurrently... I mean record and file locking...)

About GUI... electron ????? wow...  html/web based ? there are users here that don't want to compile their own copy of harbour compiler and you think they will install a internet-facing server with all the security implications? The idea is really interesting but how many people will embrace it?

And I want to add one more item to the discussion: I'm no more involved in creating end-user software, I just help a company of a friend with a big program I developed since 1987. I spent endless and sleepless nights several years ago working on hwgui internals (I have several forks on one old harddisk) then on hbQt then on hmg4 (built on hbQt) then, with the help and main contribution of Luigi, several iterations of a private library based on hbQt. I use version 3, Luigi iterated to version 5.
I used version 2 to create a software that is a frontend to several scripts I used. I developed on windows and in a few hours I ported to linux and mac (thanks to Qt).
I used version 3 to port one module of the big program to a GUI frontend since the textmode was very limiting and the UI frustrating. I decided to go to a full UI rewrite and refactored most of the code to OOP. The result is pretty good and works ok.

This happened about 3 years ago. Since then they never felt the need to port other modules to GUI!

One accounting lady still uses a text-mode accounting software written in Clipper 87 for day-by-day use and then export and import the data in the brand-new, shiny GUI-mode version that is a nightmare to use...

So, are we sure that *all* clients need a GUI?



So, shortly: please add a "hide-the-dbf" and a "GUI" question... :-)

do...@people.net.au

unread,
Dec 17, 2019, 7:25:46 AM12/17/19
to harbou...@googlegroups.com
Hi all

I think that we need to have a default GUI interface and hopefully one
that can cover most if not all of the platforms that Harbour runs on
but at a minimum Windows, Mac, the various Unix derivatives especially
Linux (including RaspberryPi) and hopefully Android. And maybe also an
"out of the box" web front end solution as well.

Possibly more than 1 question:
1. Should there be a default GUI interface?
2. If so what GUI(s) should that be?

Just had an idea, possibly crazy but I'll put it out there anyway. What
if we could incorporate an existing, hopefully open source, web page
rendering engine into harbour run time and use that as our GUI then
maybe we could have compatibility between code delivered across the web
and delivered locally? Does that even make sense?

I note that years ago I wrote a real time code generator that generated
web pages from templates stored in SQL files that could be extended
using javascript. The generated pages could be cached for performance.
Lots of other niceties which I wont bore you with now.

Later I wrote a static code generator that generated Harbour classes
(data classes and GUI classes) from a series of XML files the
functionality of which could be extended by including Harbour code.

In terms of what they generated either could have been modoified to
generate the other but not the necessary extensions - I wouldn't like to
have to write a converter between Harbour code and javascript. Is it
possible / practical to have Harbour code compiled real time and run on
a web type front end?

Regards
Doug


On 2019-12-17 22:08, Eric Lendvai wrote:?
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> Unsubscribe: harbour-user...@googlegroups.com
> Web: http://groups.google.com/group/harbour-users
>
> ---
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to harbour-user...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/harbour-users/2881e15e-ad8e-4fa2-a3ab-35b94d560345%40googlegroups.com
> [1].
>
>
> Links:
> ------
> [1]
> https://groups.google.com/d/msgid/harbour-users/2881e15e-ad8e-4fa2-a3ab-35b94d560345%40googlegroups.com?utm_medium=email&utm_source=footer

do...@people.net.au

unread,
Dec 17, 2019, 7:43:52 AM12/17/19
to harbou...@googlegroups.com
Hi all

With regard to hiding the dbf files from shared drive. With my database
server the files are stored on the server and not on a shared folder
(although, of course they could be stored on a shared folder if one so
wished - its entirely up to whoever sets the system up). Access is via
queries sent as IP requests using its own simple protocol. So you need
access to the server to access the data files. You could take further
steps to hide them and / or encrypt them but in my case that wasn't
necessary.

The query is a serialized array containing the query number, a sequence
number, the user ID and an array of parameters. For an insert or update
that parameter array is a two dimensional array of field names and
values, The end user PC has no connection to the data files. Backup
requires access to the dat server - but could obviously be automated if
desired.

Regards
Doug
> This happened about 3 years ago. SINCE THEN THEY NEVER FELT THE NEED
> TO PORT OTHER MODULES TO GUI!
>
> One accounting lady still uses a text-mode accounting software written
> in Clipper 87 for day-by-day use and then export and import the data
> in the brand-new, shiny GUI-mode version that is a nightmare to use...
>
> So, are we sure that *all* clients need a GUI?
>
> So, shortly: please add a "hide-the-dbf" and a "GUI" question... :-)
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> Unsubscribe: harbour-user...@googlegroups.com
> Web: http://groups.google.com/group/harbour-users
>
> ---
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to harbour-user...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/harbour-users/CADPHLr--U%2BuW051kJ7N4hYMEXwf470p5hpRvgAxzN2Peium82g%40mail.gmail.com
> [1].
>
>
> Links:
> ------
> [1]
> https://groups.google.com/d/msgid/harbour-users/CADPHLr--U%2BuW051kJ7N4hYMEXwf470p5hpRvgAxzN2Peium82g%40mail.gmail.com?utm_medium=email&utm_source=footer
Message has been deleted

Ernad Husremovic

unread,
Dec 17, 2019, 11:32:22 AM12/17/19
to Harbour Users
Hello community,

I am sharing my thoughts through this README 


Regards,
Ernad

Carlitus

unread,
Dec 17, 2019, 11:33:05 AM12/17/19
to Harbour Users
My humble reflection

Harbour needs Web...

Harbour is a great language that covers many features in the desktop world, but now Harbour to make the leap to the Web

Many expert programmers have worked during these years very effectively with Harbour in Win applications but now the future goes through the Web

Harbour needs Web

This is now possible, for me the question is: What price are programmers willing to pay to learn and add the web to our lives?

The road and direction for Harbour to continue evolving is easy: Web.
The cost for all programmers to make the change is difficult: How?

We have reached the moment Blade Runner: 2019. We don't stay behind. The future has arrived

Harbour needs Web.

Carles.

Francesco Perillo

unread,
Dec 17, 2019, 4:48:11 PM12/17/19
to harbou...@googlegroups.com
Doug,
are you willing to share your library?


do...@people.net.au

unread,
Dec 17, 2019, 9:24:30 PM12/17/19
to harbou...@googlegroups.com
Hi Francesco

Yes more than happy.

I did start neatening up the code but more making it compliant with the
accepted way of writing Harbour code plus it does need some decent
documentation.

So give me a bit of time.

I can also indicate the directions I was thinking of taking it and where
I thought it could be improved. Others may like to make suggestions
too.

I did add triggers (it only took a few lines of code - Harbour is
wonderful like that) and tested it but have not used it in production.

I also implemented on a test basis including the length of a given
message in the message so that one didn't have to rely on timeouts.
Again I tested this but not in a production setting. Should be more
efficient but in my live scenarios using timeouts (which were settable
via config file) was more than adequate.

Not sure where that cose is (not too hard to rewrite if necesaary) as it
was never part of production code.

Some features would be easy to add given its architecture. Examples
include:

Ad hoc queries: not currently supported but as queries are read in from
XML files at startup and processed the same basic code could be used for
an ad hoc query.

Data logging / roll forward from a backup: all queries/inserts/updates
are sent as a serialised array so can simply be stored in a single table
and could be applied in the same way as for live except you would be
cycling through a table rather than reading from an IP socket. Reads
need not be tored as they don't change the data base. And there would
be no need to send output back to any client.

A possible enhancement to the above would be to store any error against
such a log for possible troubleshooting.

I will get things rolling with code largely as is and we can determine
if there is any interest and if so discuss the possible road ahead.

I would love to decide if the majority can decide on a default GUI.

Regards
Doug

On 2019-12-18 08:47, Francesco Perillo wrote:
> Doug,
> are you willing to share your library?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> Unsubscribe: harbour-user...@googlegroups.com
> Web: http://groups.google.com/group/harbour-users
>
> ---
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to harbour-user...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/harbour-users/CADPHLr9DPVhR99Hgu%2BpZboQF0LGc8y6yijhvDT7qn%2BDCA0yxhg%40mail.gmail.com
> [1].
>
>
> Links:
> ------
> [1]
> https://groups.google.com/d/msgid/harbour-users/CADPHLr9DPVhR99Hgu%2BpZboQF0LGc8y6yijhvDT7qn%2BDCA0yxhg%40mail.gmail.com?utm_medium=email&utm_source=footer

do...@people.net.au

unread,
Dec 17, 2019, 10:07:22 PM12/17/19
to harbou...@googlegroups.com
Hi all

I am going to present a client-server database server written entirely
in Harbour. I have found it to be robust and efficient even across
relatively slow links between multiple sites. Whilst it suits my
purposes well I make no claim about its suitability in your situation.
However I am presenting it as I believe it may be helpful to others. If
there is a degree of interest I may well make enhancements to the
existing code. Anyone is free to use or modify it as they see fit. But
if you think any such modification may be of benefit to others it would
be nice if you would post about it in this forum.

I will give here a brief description of the code as it currently exists.

The server code at startup looks for a configuration file that tells it:
1. what IP port to attach to,
2. what data files to open in what work areas and with what indexes,
and
3. what the available queries are and where to find the relevant
configuration files.

I note that I have used .ntx files but it would be better, no doubt, to
use cdx files

Queries are of several types, the important ones being:
1. List
2. Read
3. Write (Insert oe Update)

Writes automatically re read the written data and transmit it back to
the client.

Queries have two parts:
1. A field list (which includes links to other tables), and
2. A selection criterion (the index that will be used and the parameters
that will be passed and used against it)

Each query is stored as an object5 held in a master array

Queries that return a list and have what I think is a left outer join
also have a secondary field list

Queries may have a pre post and or after post trigger

The server opens the specified files, sets up the query objects and then
listens on the specified port for incoming requests.

The clients communicate with the server via IP and do not need any
direct access to the files that the database server is accessing. Only
the data specifically requested by the client or that the client
specifically sends to the server are transmitted over the network. All
the traversal of data and index files as well as file locking and lock
retrying is done on the server. The server also allocates primary keys
for inserts which is sent back to the client - which certainly used to
be a failing with SQL Server when I last used it a long time ago.
Whilst the real driver for utilising such an architecture is when there
are multiple users across a network and even more so when there are
multiple sites involved it is also suitable for a single user with both
the server and the front end application running on the one computer.

Regards
Doug

David Allen

unread,
Dec 17, 2019, 10:12:25 PM12/17/19
to harbou...@googlegroups.com
That sounds awesome Doug.  This would be perfect for newbies like me just beginning Harbour.

Thank you for sharing.

David

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.

fdaniele

unread,
Dec 18, 2019, 2:57:25 AM12/18/19
to Harbour Users
If I can say one thing ...
I am a small programmer, and I am convinced that harborur must conquer the web in order to continue living .

Clipper we only know that we are old, new programmers do not know what a wonderful system it is.

now, I see that there are several of us (the best ones) who have already created solutions with CGI or something like my friend Campagna, the wonderful Eric, the fantastic Doug, the great Linares, the magic Rathinagiri.

I would like to ask everyone to join forces, we can create a system for young people, we make everyone understand that the clipper is old but not useless!

come on guys, let's have fun like we were young!

Semper fidelis
Daniele


Francesco Perillo

unread,
Dec 18, 2019, 3:51:02 AM12/18/19
to harbou...@googlegroups.com
Thank you Doug for your decision, I'm looking forward to your code.

For GUI, I believe the solution is a Qt based library, multiplatform, already working in production...

A web based solution can be ok, but there are a lot more variables to handle, like which js/html libraries to use (plain query+bootstrap, try to integrate vue, react?) or create a framework solution like laravel?

do...@people.net.au

unread,
Dec 18, 2019, 4:10:44 AM12/18/19
to harbou...@googlegroups.com
Hi Francesco

I agree but we really need others to join in the discussion and put
forward their points of view.

I presume if I were starting out now I would go with a Qt based GUI
interface but having said that the only alternative I know is GTK+
because that was the best / easiest solution out there for me and my
environment at the time I started out. I don't know if there are any
other contenders out there. I think someone suggested something called
wxWidgets or something like that. My only other thought are calls into
a browser renderer.

Experience with FiveWin and its offshoot FiveLinux suggests to me that
its hard to write a consistent, bug free single dialect interface to two
GUIs that have differing underlying constructs. Not having used Qt in
any environment, let alone multiple environments,means I don't know how
well the Qt team have managed it. But if the world is trending towards
web interfaces that may help. Although, as you rightly point out the
web is one of the most inconsistent, vendor dependant environments out
there as it currently exists despite efforts towards standardisation.

Regards
Doug
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> Unsubscribe: harbour-user...@googlegroups.com
> Web: http://groups.google.com/group/harbour-users
>
> ---
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to harbour-user...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/harbour-users/CADPHLr9-dhvSv8jk-hsvYyCZZ36Kx%3Dw65bWPyUH1pkFu2Sfzqw%40mail.gmail.com
> [1].
>
>
> Links:
> ------
> [1]
> https://groups.google.com/d/msgid/harbour-users/CADPHLr9-dhvSv8jk-hsvYyCZZ36Kx%3Dw65bWPyUH1pkFu2Sfzqw%40mail.gmail.com?utm_medium=email&utm_source=footer

Adam Berent

unread,
Dec 18, 2019, 7:00:10 AM12/18/19
to Harbour Users

They have repeatedly been attempts to build a GUI
but in the interest of the Harbour is not construction own GUI, It is not in the interest:
Fivewin, Xailer, xHarbour e.t.c.
and this harbor library will never be created it's a waste of time and discussion.
Many programming languages offer a free user interface with open source code

Already tried to do it to no avail:
1.

2.

3.

e.t.c.

Best regards
Adam B.


alkresin

unread,
Dec 18, 2019, 7:31:47 AM12/18/19
to Harbour Users
>  Grade from 1 to 10 (less to most important)
>  ...

  I think that we should set more real tasks), and a primary one, IMO, is to make an official release of 3.2 and to update the web site respectively.
  What about an "official" (or "native", or "unique") GUI, SQL, DBMS, etc. ... There are many popular languages, which hasn't them and this fact doesn't prevent them to be at a top.
  We should calmly accept the fact that Harbour never be in the first 100 languages list. This doesn't prevent us from using it in development. The core is stable, the language itself is complete enough and all other, any newest technologies can be realized as external libraries, written on C or other languages.

Regards, Alexander.

Angel Pais

unread,
Dec 18, 2019, 9:53:30 AM12/18/19
to harbou...@googlegroups.com
A Laravel compatible (mvc ) framework is being tested by the mod-harbour.org group.
Currently performance testings are being made.
More news in the near future...



--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.

Don Lowenstein

unread,
Dec 18, 2019, 10:05:33 AM12/18/19
to harbou...@googlegroups.com

I agree with Carles.

 

Harbour needs Web … as a full featured tool for development, including coding, debugging, testing and QA processes.

 

Many of us (me included) have built web applications using Harbour as a backend solution.

We’ve also built dynamic Harbour generated HTML pages to send back to the browser.

Personally, I’ve used the CGI process exclusively. 

Which works great, since it’s been around for decades.

 

But, debugging Harbour backend processes was neither intuitive or easy.

 

Through awkward workarounds, I’ve have achieved debugging capability.  However, real-time web debugging is critical.

 

My 2 cents.

 

Don.

--

--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.

xamm-inf

unread,
Dec 18, 2019, 11:06:54 AM12/18/19
to Harbour Users
Mr. Lendvai,

We need a poll with his questions:


 Grade from 1 to 10 (less to most important) 

Maurício Faria

unread,
Dec 18, 2019, 12:26:58 PM12/18/19
to harbou...@googlegroups.com
I had an insight that I want to share.
I seems a little bit out of the reality, but I will share it anyway.
ADS is a well known client server solution in the (X)Harbour community
but its not free nor open source.
But after changing hands a few times it seems almost dead.
Its even hard to find info about licensing.
There is a remote possibility that SAP is not interested in it anymore
or that its not financially viable anymore and they are only waiting the
right time to kill it for good.
And they say that they embraces the Open Source effort...
So, does anybody reading this have any contact with SAP people that
could ask for an "opening" ?
If ADS becomes free of licencing or, even better, open source, this
could be a huge impulse to the (X)Harbour community.
And ADS could become an alive niche project.
And also the Delphi guys will love this.
Ok, just crazy thoughts in my mind...

[[]] Maurício Faria

Gerald Drouillard

unread,
Dec 18, 2019, 1:25:52 PM12/18/19
to harbou...@googlegroups.com

If ADS becomes free of licencing or, even better, open source, this
could be a huge impulse to the (X)Harbour community.
And ADS could become an alive niche project.
And also the Delphi guys will love this.
Ok, just crazy thoughts in my mind...

To me what seems even more powerful than ADS is NETIO.  Not only do you get the remote database but the remote filesystem.  But if you are doing all web development then those layers aren't really needed.

Gilbert Karweru

unread,
Dec 18, 2019, 3:21:49 PM12/18/19
to Gerald Drouillard
In all my years of using harbour, the most powerful feature I found was NETIO...it gives you all you require for a client-server ‎architecture. I have implemented solutions that can access a database (even sql), over an Internet connection at very good speeds, only requiring a public IP and a port forward.  

There is a need for a default multi-platform GUI..(rjopek's hbUI looks very promising if he can get everyone's help)

The Web is obviously the next best thing. A.Linaries has done some good work in mod_harbour.

I would vote for dropping all pretences of supporting clipper and adopt a more aggressive development path that would appeal to younger and upcoming developers.

It would be great to have a foundation to which those willing can channel contributions.

All in all, please, let us not let this project die.

Rgds,
Gilbert

From: Gerald Drouillard
Sent: Wednesday, 18 December 2019 21:25
Subject: Re: [harbour-users] The future of Harbour

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.

Mario H. Sabado

unread,
Dec 18, 2019, 5:06:17 PM12/18/19
to 'elch' via Harbour Users
Hi,

I just want to post a test case done by a Harbour dev (Ron?) using LetoDBf (LetoDB fork).  I have to admit that I already used it also in my productions with 100+ concurrent sessions per site.  As I have never used ADS but came from Clipper to (x)Harbour migration, I really can't tell about the comparison.  So about the subject of a DB Server utilizing DBF file format, maybe LetoDB/LetoDBf can be looked upon and considered by the core developers as viable option?

Just sharing my opinion.

Best regards,
Mario

**************************************************************************************************************************
First of all, I apologize for being so slow to reply. Life intervened, and when I got back to the computer I found I'd wiped out my ADS dev/test environment. However it's all fixed now.

You may be suprised at the results I got.

I have a country club management package that is running at a number of clubs (golf and country, ski hills, yacht clubs, etc.) and I set up one of my client's data sets to test the comparison. Part of the country club application is a query engine that the end user can use to create broadcast emails, bulk invoices and reports, among other things. I set up the server is running both ADS and LetoDBF simultaneously and I set up both server engines to serve data from the same physical data set so the only change is which driver the client is invoked with.

I then deliberately set up an expensive query that would take a fair bit of time to complete. The query code uses do while... / dbskip()  / enddo code to work through the controlling database with seeks / do while / dbskip() / enddo constructs in child databases to execute the filter functions.

So, the results:

Using the ADS driver, I get the query completing on average in 2 minutes and a second or two - sometimes as low as 1:55, sometimes as high as 2:05
Using LetoDBF, the same query completes on average in just under 30 seconds - sometimes as low as 24 seconds, sometimes as high as 32 seconds.

Of course, the server is doing other work including providing my internet radio feed (bluesradio.gr, by the way - great station) and some other stuff. The server is running CentOS 6.8 on an I3 core machine with 4GB RAM, gigabit ethernet. Pretty standard stuff.

The client is a Windows 7 notebook - Lenovo T420s with 4GB RAM i5-2520m running all sorts of stuff.

Anyhow, I thought you'd be interested to know that LetoDBF wipes the floor with ADS in a real-world application. That said, of course it could be that tweaking the code to optimize for ADS might give closer results, but personally, I doubt that ADS would be faster in the real world.
********************************************************************************************************

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.

Eric Lendvai

unread,
Dec 18, 2019, 8:04:37 PM12/18/19
to Harbour Users
Hello Alexander,

I saw you requesting an account on harbour.wiki. But the email address you used is not allowing messages from the domain "harbour.wiki" or even my own personal domain "elsoftware.com".
Your account is approved, so you can always login with whatever account name and password you used / requested.
Could you contact me on Skype. Search for "eric lendvai" and I can add you as a contact. Then you could send me another email address to link your account to. 

Thanks, Eric

Charles M

unread,
Dec 19, 2019, 12:22:54 AM12/19/19
to Harbour Users
Hi Adam.

Have you tried QtContribs (https://groups.google.com/forum/#!forum/qtcontribs) by Pritpal Bedi?

I've developed many applications using this framework, its robust, simple, production ready, and almost* complete.

Also, you can use QtDesigner or QtCreator with your projects. The beauty of Qt + the power of Harbour is amazing!

Domenico D'Oria

unread,
Dec 19, 2019, 5:58:32 AM12/19/19
to Harbour Users
Hi to all, my two cents in the discussion.

i'm domenico from italy

an old ( born in 1960 ) programmer

Born with dBase II passed to dBase III and after to Clipper and now to Harbour 3.4

i develop programs for my self, because my job is different ( ict technician )

when i have decided which gui to use with Harbour, i choose Marinas-gui, in that time it works under windows and under linux and rapidly i go to linux a strong Operative system.

Operative systems  are continuosly updated and so Marinas under new linux versions could not be installed, and probably Carozo de Quilmes does have no time to update his software.

So i convert my sw toys to HWgui step by step. The job of Alexander is amazing so now i prefer use his Gui.

I wrote a software under Harbour + netio for the server side ( Ubuntu 18.04.03 lts ) and a client under Windows ( now with oohg, but i'm transform it step by step to Hwgui )

When i think which gui have to be used with Harbour, probably i suggest HWgui, Marinas could be ok if it would be mainteined.

But if you take a look how much Hardware resources take the first,  well under Windows it takes less resources of every other Windows Gui ( Minigui, HMG, oohg, Qt, Marinas ), and the same less resources under Linux.

It's important to understand that Qt is a proprietary software and even if there is a free version, you can distribuite it only if your software have to be free, whithout of charge.

On the contrary Winapi for windows is integrated in the operative system, and GTK+ is opensource so you have not to paid nothing to anyone.

But we know Information technology is going on, and now all software is going to a new paradigm, Software As a Service ( SaS ) and with cloud all software houses are going with :

1) Remote Desktop Connection ( almost Windows Clients  with Windows Servers, with Microsft Sql  )

2) Web Server Connection ( using Browsers as Client Side ) and Servers on the other side, with some others Sql Servers ( Mysql, PostgreS, MariaDb, ecc )

3) desktop applications that receive data form Sql Servers.

Which is the best ?

I'm not a Guru, even not an influencer so i do not know, probably the best solution is 2, becouse the software is running on the server, mostly a Linux server, ( we write once and deploy only one  ) and can be accessed from any  device, PC, NB, PAD, SMARTPHONES, INTERNET OF THINGS

So undoubtly Web is the future.

I take a look on Linares mod_harbour, and the new Job of Eric and these are the ways we have to go.

For desktop application the only suggestion is : only a standard istruction for calling a Gui OBject, the underlining could be the Gui of your choice.

best regards

Domenico























Francesco Perillo

unread,
Dec 19, 2019, 6:05:01 AM12/19/19
to harbou...@googlegroups.com
just to say that this statement is not correct.
you may charge for your program but qt must not be linked statically (short and probably not complete)

Alain Aupeix

unread,
Dec 19, 2019, 7:06:34 AM12/19/19
to harbou...@googlegroups.com
Le 19/12/2019 à 11:58, Domenico D'Oria a écrit :
> Born with dBase II passed to dBase III and after to Clipper and now to
> Harbour 3.4

Same except 3.2
>
> i develop programs for my self, because my job is different ( ict
> technician )

Me too
>
> when i have decided which gui to use with Harbour, i choose
> Marinas-gui, in that time it works under windows and under linux and
> rapidly i go to linux a strong Operative system.

Never be able to make it works

> When i think which gui have to be used with Harbour, probably i
> suggest HWgui,
>
> But if you take a look how much Hardware resources take the first,
> well under Windows it takes less resources of every other Windows Gui
> ( Minigui, HMG, oohg, Qt, Marinas ), and the same less resources under
> Linux.
>
> It's important to understand that Qt is a proprietary software and
> even if there is a free version, you can distribuite it only if your
> software have to be free, whithout of charge.
>
> On the contrary Winapi for windows is integrated in the operative
> system, and GTK+ is opensource so you have not to paid nothing to anyone.
+1 for HwGUI

A+
--
------------------------------------------------------------------------
Alain Aupeix
http://jujuland.pagesperso-orange.fr/
http://pissobi-lacassagne.pagesperso-orange.fr/
------------------------------------------------------------------------
U.buntu 12.04 & Xu.buntu 16.04 | G.ramps 3.4.9-1 | H.arbour 3.2.0dev
(2019-03-12 10:42) | Hw.Gui (2797)
------------------------------------------------------------------------

Domenico D'Oria

unread,
Dec 19, 2019, 11:45:17 AM12/19/19
to Harbour Users
Hi Francesco sorry for the incorrect statement

Don Lowenstein

unread,
Dec 19, 2019, 12:16:21 PM12/19/19
to harbou...@googlegroups.com
Same for me.

Except I use Antonio Linares FiveTech libraries for GUI and many other useful tasks. I've never had any issue migrating through the various versions of Windows since Windows 3.1



-----Original Message-----
From: harbou...@googlegroups.com <harbou...@googlegroups.com> On Behalf Of Alain Aupeix
Sent: Thursday, December 19, 2019 6:07 AM
To: harbou...@googlegroups.com
Subject: Re: [harbour-users] Re: The future of Harbour

Le 19/12/2019 11:58, Domenico D'Oria a crit :
--
--
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/harbour-users/9ac4be5a-ccc0-f607-9b02-f327bee7f8a6%40wanadoo.fr.

Luigi Ferraris

unread,
Dec 20, 2019, 8:06:26 AM12/20/19
to Harbour Users
Hi friends,
I'm the last wheel of a car, I'm 55 old, I'm a fun of Harbour Open Source Project, I'm a fun of Qt.

First of all, I think Harbour must follow Open Source spirit so, while take in account exist Microsoft Visual Studio or other payed tools, they can't be the target. The target is, and must be, Open Source tool[s].

Basically, I think Harbour was borned to replace (for free, so Open source direction) different XBase compilers, adding (in many years, hard job for few people) evolutions (obviously solving bugs) to the ability and power of Xbase language (simplified reasoning for space).

Hi hope, speaking about web, that none of us intends to relegate the Xbase language, and therefore the Harbour project, to do (or to be used only for) things like:
FUNCTION exists( xxx, area ) ; RETURN ( (area)->(DBSEEK( xxx )) )
FOPEN( ... ); FWRITE( "<!doctype html>" ); FWRITE( "<html lang='en'>" );... FCLOSE()
with only one target: preserve current DBF data base because...

and this is the next argument, DISPOUT can't be used (today) for (G)UI.
IOW, missing a GUI library is, and was been, the main problem and, from my pov, Harbour project lost (for some unexpected reasons) the Qt train, a very cross system GUI library (see QtContribs death).
A little note: when Microsoft put his feet in Qt, Visual Studio was adopted as preferred tool; for some minutes the original Open Source spirit was been in bilic.

At the end, I think Harbour need a very and most robust C/C++ interoperability, thinking to OOP (class, object) breaking (perhaps) with the past.
Need a separated library to access DBF/NTX (today very powerful and simple) totally C/C++ written and independent.
In this way:
a) C/C++ programmer or project like LibreOffice, Qt and other, can use/adopt Harbour project DBF files and indirectly promoting the power of Harbour project.
b) giving to XBase language the ability to cooperate with C/C++, IOW using external libraries (obvioulsy with API), preserving DISPOUT but giving us more options.

I have simplified a lot a complex argument to avoid take more space so, don't shoot me.
I'm sorry if my English is not very well.

Regards,
Luigi

Riztan Gutierrez

unread,
Dec 20, 2019, 2:14:35 PM12/20/19
to harbou...@googlegroups.com
Hi all. First, give thanks for the initiative of this thread. Then apologize for the translation;)

My name is Riztan Gutierrez (44 years old) Greetings from Venezuela.

I have read and tried to understand the messages and then my humble contribution.

A foundation for the project.
I think this point is the main one, the project needs an institution that assumes the necessary policies to keep our beloved tool afloat.

We must define how to make this foundation generate income, perhaps through: support, preparation of educational material, memberships, project management.

Create with Harbor and the community the necessary applications for the total management of the foundation, both internal and public management.

Secondary points (to treat from the foundation)

- Divide the project into different parts according to one objective: GUI, web, security, core, etc.

In my opinion, something very harmful is that there are several projects with the same function. We see it a lot in the different GUI libraries. Several libraries for QT, GTK, etc. It should be a team working on providing a harbor tool to use the QT, another for the GTK, and all the many useful tools that exist.

The foundation is the way to unify efforts.


Although I do not consider myself a star programmer, I am willing to collaborate in all that I can.

Several years ago I collaborated with Rafa (thefull) in the t-gtk and I have been developing my TPuy work tool, also a while ago I started a job of an API and TPV / POS client for prestashop, using httpd and NetIO. All totally free, available at: https://sourceforge.net/projects/hbtools/




Web World
Harbor on the web? I think you can, but on the server side. Harbor doesn't have much to envy of node.js. However, on the browser side the king is javascript and I think it would be a wasted effort to do transpiler, etc. And the advances suggest that browsers are going to look like harbor hehehe (they will incorporate a virtual machine and compile javascript code).

Additionally, there is a whole standardization in process that I think is better to evaluate and enter it with Harbor. That way, gradually making harbor more compatible with the javascript code, dart, typescript. Obviously this is my personal opinion, maybe I am wrong, it would be best to address each topic in its corresponding thread.

Now, you could use tools designed for the web. With a little effort, perhaps you can harbour incorporate the chrome V8 engine and thus display javascript content in our windows (as does the libwebkitgtk in GNU / Linux)

GTK4 promises very interesting things about the web world ...

Multiplatform generic syntax.
This a bit related to the topic of GUI's. Perhaps the problem is not if the guide is QT or GTK, perhaps what we need is to create a layer with a more universal syntax (there will be limitations). That this syntax works with any of the libraries to use, even in an android environment.

Without more to say for the moment, a hug to all!

Cheers
Riztan

_______________________________________________

Hola a todos. Lo primero, dar gracias por la iniciativa de este hilo.

Mi nombre es Riztan Gutierrez (44 años) Saludos desde Venezuela.

He leído y tratado de comprender los mensajes y a continuación mi humilde aporte. 

Una fundación para el proyecto. 
Creo este punto es el principal, el proyecto necesita una institución que asuma las políticas necesarias para mantener a flote nuestra amada herramienta.

Hay que definir como hacer que esta fundación pueda generar ingresos, quizás a través de: soporte, elaboración de material educativo, membresías, dirección de proyectos.

Crear con Harbour y la comunidad las aplicaciones necesarias para la gestión total de la fundación, tanto gestión interna como pública.

Puntos secundarios (para tratar desde la fundación)

- Dividir el proyecto en las diferentes partes según un objetivo:  GUI, web, seguridad, core, etc.

A mi criterio, algo muy dañino es que existan varios proyectos con la misma función. Lo vemos bastante en las diferentes librerias GUI.  Varias bibliotecas para QT, GTK, etc.  Debería ser un equipo trabajando en proporcionar una herramienta en harbour para utilizar las QT, otro para la GTK, y todas las muchisimas herramientas muy utiles que existen.

La fundación es la via para unificar esfuerzos.


Aunque no me considero un programador estrella, estoy dispuesto a colaborar en todo lo que pueda. 

Hace varios años colaboré con Rafa (thefull) en la t-gtk y he estado desarrollando mi herramienta de trabajo TPuy, igualmente hace un tiempo inicié un trabajo de un API y cliente TPV/POS para prestashop, usando httpd y NetIO. Todo totalmente libre, disponible en: https://sourceforge.net/projects/hbtools/




Mundo Web.
Harbour en el web? Creo que se puede, pero del lado del servidor. Harbour no tiene mucho que envidiar de node.js.  Sin embargo, del lado del navegador el rey es javascript y creo sería un esfuerzo perdido hacer transpilador, etc. Y los avances apuntan a que los navegadores se van a parecer a harbour jejeje (van a incorporar una maquina virtual y compilarán codigo javascript).  

Adicionalmente, hay toda una estandarización en proceso que creo es mejor evaluar y entrar en ella con Harbour. De esa forma ir haciendo paulatinamente a harbour más compatible con el codigo de javascript, dart, typescript. Obviamente esta es mi opinión personal, quizás estoy equivocado, lo mejor sería tratar cada tema en su hilo correspondiente.

Ahora, se podría hacer uso de herramientas pensadas para el web. Con un poco de esfuerzo, quizás se puede incorporar el motor V8 de chrome en harbour y de esa forma desplegar contenido de javascript en nuestras ventanas (como lo hace la libwebkitgtk en GNU/Linux)

GTK4 promete cosas muy interesantes respecto al mundo web...

Sintaxis generica multiplataforma.
Esto un poco relacionado con el tema de las GUI's. Quizás el problema no es si la gui es QT o GTK, quizás lo que necesitamos es crear una capa con una sintaxis más universal (habrá sus limitaciones). Que esta sintaxis funcione con cualquiera de las librerias a utilizar, incluso en un entorno android. 

Sin más que decir por el momento, un abrazo a todos!

Saludos
Riztan

do...@people.net.au

unread,
Dec 20, 2019, 5:14:38 PM12/20/19
to harbou...@googlegroups.com
Hi all

This post is mainly to start a separate thread for discussion about what
GUI libraries should be directly supported in any forthcoming "standard
Harbour" if there is to be such a thing.

Some of the issues that need to be determined (in my opinion) are:

What GUI library (or possibly libraries) should be supported?
[Supporting only 1 as standard would be ideal but it may not be
practical. If multiple can they have the same syntax kind of like
replaceable GUI interfaces mimmicing replaceable database drivers. I
note that this decision presumably ties in somewhat with the range of
operating systems to be supported.]

Does such a library need to support as best it can absolute positioning
which is more compatible with the way that traditional xBase programmers
grew up with?
[This may impact on choice of GUI library.]

I think it is fair to assume that any such library would be OO. Do we
need to hide that behind a set of commands for some users so rather than
something like:
oMyWindow := MainWindow():New( nTop, nLeft, nHeight, nWidth)
they can do something like:
CREATE MAINWINDOW oMyWindow @ nTop, nLeft SIZXE nHeight, nWidth ?

Should we base such a library / libraries off existing efforts or design
from scratch using existing efforts as a resource only? If refactoring
existing efforts how do we choose which ones to base code on?
Regardless, how do we decide on a maintainer / maintainers for such
work? How does the user group / possible foundation suggest / set
guidelines for any such work?

A question that also arises and impacts on this issue but is far more
general in nature is what coding standards would we ideally like in such
code?

Regards
Doug




José M. C. Quintas

unread,
Dec 20, 2019, 7:26:47 PM12/20/19
to harbou...@googlegroups.com
OOP, multithread, Windows API, create own controls

This is contrib/gtwvg

It is ready for enhancement.

José M. C. Quintas

do...@people.net.au

unread,
Dec 21, 2019, 2:50:09 AM12/21/19
to harbou...@googlegroups.com
Hi José

I am sure many will agree with you.

The downside I see (and I am no doubt biassed because of my choice of
OS) is that this would cut out anyone not using Windows and make any
code non transportable without a substantial rewrite.

Having said that it may well be that a majority only want to target
Windows and Windows is probably the background of most newbies to
Harbour.

My first wish is to see Harbour continuing to prosper as a viable
language into the future and if that's what turns out to be the best way
forward then so be it. But I am very much in the Linux camp.

The original Harbour concept was to write once and compile for different
operating systems. That was achieved for utilities and text based
programs and may be for qtcontrib based GUI programs (don't know as I
never tried that). Whether that is still the concept I don't know -
perhaps that is a fundamental question that we need to decide. Do we
build different flavors of Harbour for different OSes with different
default GUI interfaces?

I'm now 64 and don't need to use Harbour to earn a living so I'm not too
fussed about what I would have classed as my "needs". I do want to see
Harbour survive and prosper as a viable 5GL. I was using Harbour
yesterday as the DICOM data file from a brain perfusion scan contained
some Philips private data tags that I had never encountered previously
so I had to make a small modification to some code I wrote some 5 years
ago. I just love the language!

I have bush fires raging near me but not directly threatening, at least
not yet, Been living in smoke for weeks now. If you want some idea
maybe check out:

https://www.smh.com.au/national/nsw/nsw-fires-live-updates-rfs-prepares-for-day-of-catastrophic-bushfire-conditions-20191221-p53m1p.html

Don't know how long that link will be good but I am sure if you search
on something like NSW bush fires you'll get an idea.

Regards
Doug
> --

Luigi Ferraris

unread,
Dec 21, 2019, 1:46:33 PM12/21/19
to Harbour Users
Hi guys,

the problem is not what/how many GUI, Harbour can support: this is the Harbour's GUI "never ending story".
The same question can translated to what/how many RDBMS Harbour can support, isn't it?

Perhaps, I'm reducing too much a complex argument, but

C/C++ is (seems to be) the preferred language to write cross platform libraries.
Harbour is a compiler for XBase language translated to C.

If XBase, through Harbour, can cooperate with C/C++ in agile and profitable way, our programs will use
LOCAL object := something()
where something() can be an object of: Qt, Gtk, Haru, Cairo, MySql, etc.
Most likely, through additional layer, API
   program <-> Harbour_C <-> Harbour_API_Qt <-> Qt
   program <-> Harbour_C <-> Harbour_API_Gtk <-> Gtk
AFAIK, more or less what happen today.

If there isn't anyone to be able to (or want to) write Harbour_API_xxx we (XBase) will never have xxx.
But, problems seems arise at this level: program <-> Harbour_C <-> ... related with OOP, Garbage Collection, pointers, etc., etc.
I'm not a C programmer: I inferred it by reading post on Harbour, trying to understand Guru's pov and fighting with Qt concepts.

So, I think is better to have a good cooperation, hopely to find people of goodwill, who wish to give their time and work for the realization of these APIs.
(a little digression: QtContribs, Pritpal where are you?)

On the other hand, every GUI has its point of view; always they have similar basic concepts but with different approach, backend, etc.
As example compare
   https://developer.gnome.org/gtk3/stable/GtkLabel.html
   https://doc.qt.io/qt-5/qlabel.html
so, OOP is a must.

But all of these problems are secondary.
For me the big one is: how many people (Harbour's Guru) are there today?
I'm speaking what happens behind the scenes of Harbour compiler fundamentals.
I fear, we are talking about to remake the house, without or with few (as you prefer) engineers and/or bricklayers.
So, for me this is the great alarm for everyone.

Regards
Luigi
  
@Josè with a great, very great respect to who written hb_gtwvg (I will never be able to do) do you really want compare with MFC, Gtk, Qt, etc.?
In my opinion it is unfair. Their purpose was/is: open the doors to the transition from CUI to GUI, while preserving code compatibility as much as possible.
For me, a widely achieved and very valid goal.


Pritpal Bedi

unread,
Dec 22, 2019, 12:49:28 AM12/22/19
to Harbour Users
Hi Luigi
 

(a little digression: QtContribs, Pritpal where are you?)


Very much here, in the middle of all of you. 

It just happened to realize the power of Harbour and HbQt in many commercial applications, with an extremely high degree of success. More, Qt has diverted its stance towards QML oriented approach more than Widgets, and also changed the licensing model, and I stopped further development on it. HbQt until Qt 5.8 is robust and rewarding and there seems no need to dig into QML part of Qt as my engine has not been able to resolve new concepts introduced by Qt. BTW, by any standards, HbQt in its current state is a robust development environment, not only for desktop applications but also for Android and iOS apps.  

If you are not aware ( as I read in this post ), just to let you know that GTWVG was developed by me and is in use for my all commercial applications. Yes, it is not multi-platform, only Windows, but has prooved to be robust.

Pritpal Bedi
a student of software analysis & concepts

Luigi Ferraris

unread,
Dec 22, 2019, 12:10:05 PM12/22/19
to Harbour Users
Hi Pritpal, I'm very happy to know about you :-)

 
If you are not aware ( as I read in this post ), just to let you know that GTWVG was developed by me and is in use for my all commercial applications. Yes, it is not multi-platform, only Windows, but has prooved to be robust.

Pritpal Bedi


I hope, my English was not so bad and you (and any other Harbour developer) understood my words.
My intent was precisely to enhance this great work (I remember GTWVG is by you, was been a bad language usage for generalize), which allows many applications, including commercial ones, to work and be appreciated, using the XBase language and the Harbour compiler, giving a new life while preserving knowledge and code.

Best regards
Luigi

Eric Lendvai

unread,
Dec 23, 2019, 2:05:21 AM12/23/19
to Harbour Users
Hello Luigi,

I share your concern about the lack of core developers.

I made a tool to code scrape the Harbour compiler and its contribs. The result of this is on https://harbour.wiki/index.asp?page=PublicLanguageReferenceHarbourSourceCodeExplorer
Trying to bring in all of Pete's documentation in it and any other source I can find.
Then hope to find some developers that have core knowledge and build https://harbour.wiki/index.asp?page=PublicLanguageReferenceDocumentationExplorer
Hopefully to more we can understand the compiler the higher chance we can get to get some contributors again.

My two cents (meaning opinion) ...

Gilbert Karweru

unread,
Dec 23, 2019, 2:41:36 AM12/23/19
to Harbour Users
'Replaceable GUI drivers' might be a great cure for this never ending debate. The GUI logic for various platforms can be supported through DLLS or HRBs ‎with prg level code containing classes which in turn call code in the DLL or HRB.

Just like harbour itself, one would only need to write code once, and compile with the GUI appropriate to the environment one is working in.

Just my two cents.

Rgds,
gk
From: Eric Lendvai
Sent: Monday, 23 December 2019 10:05
To: Harbour Users
Subject: Re: [harbour-users] Future of Harbour - GUI Library Support

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.

Maurizio la Cecilia

unread,
Dec 23, 2019, 3:23:12 AM12/23/19
to Harbour User Group
I agree.
My own development tool is just based on that.
I've a set of metaobjects (menu, forms, database, reports, etc.) described by unary syntax and I can build CUI (gtwvt based) and GUI (HwGUI based or, thanks to a contribution of Luigi Ferraris and Francesco Perillo, QTcontrib based) just changing a single setting in hbp file.
This behaviour could be expanded to other GUI libraries, if the descriptors of the front end interface are the same.
A resource container of shared entities, applicable to all supported GUI libraries.
Some restriction is mandatory, but the advantages could be greater than the loss of power in single GUI approach.
JM2C
--
Maurizio

do...@people.net.au

unread,
Dec 23, 2019, 4:31:00 AM12/23/19
to harbou...@googlegroups.com
Hi all

And if we do head that way (replaceable GUI drivers) it needn't stop a
particular GUI driver from supporting a feature that other drivers can't
support (which is true of RDD's) but that would have to be made clear
(in documentation at least and maybe in compiler warnings) so that a
programmer can choose to limit his code to one particular GUI or to
write code that should work across all platforms.

I guess a first step would be to map out what each GUI offers in the way
of classes and how they might map to each other.

I do note that GTK+ version 3 does not guarantee to honor absolute
positioning requests.

Regards
Doug

PS Fire threat has eased somewhat for the time being but remains a very
real threat.
>> FROM: Eric Lendvai
>> SENT: Monday, 23 December 2019 10:05
>> TO: Harbour Users
>> REPLY TO: harbou...@googlegroups.com
>> SUBJECT: Re: [harbour-users] Future of Harbour - GUI Library Support
>>
>> Hello Luigi,
>>
>> I share your concern about the lack of core developers.
>>
>> I made a tool to code scrape the Harbour compiler and its contribs.
>> The result of this is on
>>
> https://harbour.wiki/index.asp?page=PublicLanguageReferenceHarbourSourceCodeExplorer
>> Trying to bring in all of Pete's documentation in it and any other
>> source I can find.
>> Then hope to find some developers that have core knowledge and build
>>
> https://harbour.wiki/index.asp?page=PublicLanguageReferenceDocumentationExplorer
>> Hopefully to more we can understand the compiler the higher chance
>> we can get to get some contributors again.
>>
>> My two cents (meaning opinion) ...
>>
>> On Saturday, December 21, 2019 at 10:46:33 AM UTC-8, Luigi Ferraris
>> wrote:
>>
>>> Hi guys,
>>>
>>> the problem is not what/how many GUI, Harbour can support: this is
>>> the Harbour's GUI "never ending story".The same question can
>>> translated to what/how many RDBMS Harbour can support, isn't it?
>>>
>>> Perhaps, I'm reducing too much a complex argument, but
>>>
>>> C/C++ is (seems to be) the preferred language to write cross
>>> platform libraries.
>>> Harbour is a compiler for XBase language translated to C.
>>>
>>> If XBase, through Harbour, can cooperate with C/C++ in agile and
>>> profitable way, our programs will use
>>> LOCAL object := something()
>>> where something() can be an object of: Qt, Gtk, Haru, Cairo,
>>> MySql, etc.
>>> Most likely, through additional layer, API
>>> program <-> Harbour_C <-> Harbour_API_Qt <-> Qt
>>> program <-> Harbour_C <-> Harbour_API_Gtk <-> Gtk
>>> AFAIK, more or less what happen today.
>>>
>>> If there isn't anyone to be able to (or want to) write
>>> Harbour_API_xxx we (XBase) will never have xxx.
>>> But, problems seems arise at this level: program <-> Harbour_C <->
>>> ... related with OOP, Garbage Collection, pointers, etc., etc.
>>> I'm not a C programmer: I inferred it by reading post on Harbour,
>>> trying to understand Guru's pov and fighting with Qt concepts.
>>>
>>> So, I think is better to have a good cooperation, hopely to find
>>> people of goodwill, who wish to give their time and work for the
>>> realization of these APIs.
>>> (_a little digression: QtContribs, Pritpal where are you?_)
>> [1].
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Harbour Users" group.
>> Unsubscribe: harbour-user...@googlegroups.com
>> Web: http://groups.google.com/group/harbour-users
>>
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "Harbour Users" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to harbour-user...@googlegroups.com.
>> To view this discussion on the web visit
>>
> https://groups.google.com/d/msgid/harbour-users/20191223074130.5156946.58618.5961%40gmail.com
>> [2].
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> Unsubscribe: harbour-user...@googlegroups.com
> Web: http://groups.google.com/group/harbour-users
>
> ---
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to harbour-user...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/harbour-users/CAGDVDAggfkMzO68ErzkP5%3DX3Pejf9kdyDR%2BAc94tRx%2BneJ7Yxw%40mail.gmail.com
> [3].
>
>
> Links:
> ------
> [1]
> https://groups.google.com/d/msgid/harbour-users/dec6b467-3798-465a-b034-0043e6baaa80%40googlegroups.com?utm_medium=email&amp;utm_source=footer
> [2]
> https://groups.google.com/d/msgid/harbour-users/20191223074130.5156946.58618.5961%40gmail.com?utm_medium=email&amp;utm_source=footer
> [3]
> https://groups.google.com/d/msgid/harbour-users/CAGDVDAggfkMzO68ErzkP5%3DX3Pejf9kdyDR%2BAc94tRx%2BneJ7Yxw%40mail.gmail.com?utm_medium=email&utm_source=footer

Maurício Faria

unread,
Dec 23, 2019, 7:46:15 AM12/23/19
to harbou...@googlegroups.com

Francesco Perillo

unread,
Dec 23, 2019, 8:54:25 PM12/23/19
to harbou...@googlegroups.com
It seems to me that instead on narrowing our goals, we are widening them, adding good ideas but very difficult to put in practice.

Theoretically is a great idea but I'd like to ask this question: how many of you are available to modify your programs to accommodate the new syntax/library?

If you coded like Maurizio did, the port is easier. Not easy, easier than the way I coded my software.

Gilbert Karweru

unread,
Dec 25, 2019, 4:00:23 AM12/25/19
to harbou...@googlegroups.com
I honestly think harbour is at crossroads. It is either we are willing to change or die out since we don't seem to be attracting new users/developers and soon enough, we will be too old. 

We shouldn't be held back by individuals who believe you can move forward by not changing.

Harbour must embrace new techonologies (especially GUI and web), and honour its promise of 'write once compile on many'. The approach to GUI must then be generic and replaceable GUI architecture seems a very good way to go.

What I must ask, probably from experienced developers like Priptal,Kresin,Robez,Grigory etc, is whether the GUIs they have developed so far, can be condensed into a single library, such that one would only need to include such during compile?

Gilbert.


--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
To view this discussion on the web visit

Carlitus

unread,
Dec 26, 2019, 6:18:57 AM12/26/19
to Harbour Users
Hola a todos,

En este dia de fiesta quiero compartir unas pequeñas reflexiones con vosotros.

Creo que Harbour es un producto muy estable y que te permite realizar practicamente cualquier diseño de programa y lo que no puede siempre podras añadirlo con bibliotecas de terceros. Pienso que es un sistema duro, fuerte y robusto.


Una de las respuestas mas realistas para mi que se han escrito en este hilo es la de Alexander el pasado 18.12.2019 y qu me hizo recapacitar:


 There are many popular languages, which hasn't them and this fact doesn't prevent them to be at a top.

We should calmly accept the fact that Harbour never be in the first 100 languages list. This doesn't prevent us from using it in development. The core is stable, the language itself is complete enough and all other, any newest technologies can be realized as external libraries, written on C or other languages.

 

Es cierto, completamente !!!


Creo que actualmente Harbour es una bestia en sistemas desktop y mi deseo es verlo en la web, no para mi especialmente porque por motivos de trabajo uso otros lenguajes consolidados y que funcionan muy bien. Pero me gustaria ver como nuestro querido Harbour da este gran salto y cierra el circulo como gran compilador, pero mi pobre experiencia dice que va a ser muy dificil. Por que ? Porque en general todos los programadores de Harbour somos una generación mayor, lejos de toda esta jueventud que se come y devora  todo muy facilmente. El coste de aprender nuevos lenguajes (html, javascript, css, jquery, bootstrap, materialize,…) junto con el soporte de harbour va a ser el gran pretexto para no dar el salto. Demasiado coste.


Recientemente  he tenido la suerte de vivir el nacimiento de mod harbour para la web. Realmente la semilla estaba puesta gracias a Antonio Linares, funciona, va bien y va a mejorar cada dia mas. Independientemente de que otras tecnologias o maneras de funcionar como fastcgi u otro, puedan ser otras soluciones, el problema q veo en si no el el core o nucleo sino la asimilación de la metodologia para programar en este entorno, porque un “Hello World” lo hace todo el mundo pero un programa no: Programar es facil, hacer programas es dificil…”.


Señores: Programar en la web es dificil, muy dificil


Hace unos meses cree un framework hecho con Harbour basado en “Laravel”, uno de los frameworks mas populares usados hoy en dia, para poder probar la potencia del mod. La misma filosofia y mismo patron de arquitectura de software, no he inventado nada, simplemente emular lo que tiene éxito entre cientos de miles de programadores. El sistema funciona realmente y de hecho el proyecto que hemos iniciado con Antonio Linares, Genesis (http://genesis.mod-harbour.org/) demuestra que podemos hacer programas en la web con Harbour. Ah !!! junto (html,css,js,…)  y es que va todo junto, cogidos de la mano.


Entonces que ha pasado con el framework Mercury. Veo que los colegas no quieren usarlo, pero la gran pregunta es: ¿Por qué?  Porque creo que entrar y dar el salto a la web es dificil como hemos dicho antes y el precio de estudiar todos estos lenguajes de complemento, patrones de diseño de aplicaciones, nuevos sistemas,… es muy alto.

 

Entonces que podemos hacer para crear aplicaciones en la web con nuestro Harbour ? Tiene sentido habiendo otros lenguajes potentes y preparados para ello ? Independientemente de que muchos Harbourianos quieren seguir en desktop, los que quieran dar el salto a la web, podrán hacerlo con Harbour ? Si como dice Alexander, somos una minoria que no estamos ni entre los 100 mejores,… tiene sentido estas inquietudes  y sobretodo esfuerzos ?


Felices fiestas.

C.


-----------------------------------------------------------------------------------------------------


Traducido con Google Translator:


Hi everyone,


On this holiday I want to share some small reflections with you.


I believe that Harbor is a very stable product and that allows you to make practically any program design and what you cannot always add it with third-party libraries. I think it is a hard, strong and robust system.


One of the most realistic answers for me that have been written in this thread is that of Alexander last 18.12.2019 and what made me reconsider:


 There are many popular languages, which hasn't them and this fact doesn't prevent them to be at a top.

We should calmly accept the fact that Harbour never be in the first 100 languages list. This doesn't prevent us from using it in development. The core is stable, the language itself is complete enough and all other, any newest technologies can be realized as external libraries, written on C or other languages.


It is true, completely !!!


I think Harbor is currently a beast on desktop systems and my desire is to see it on the web, not for me especially because for work reasons I use other consolidated languages ​​that work very well. But I would like to see how our beloved Harbor makes this great leap and closes the circle as a great compiler, but my poor experience says that it will be very difficult. Why ? Because in general all the Harbor programmers are an older generation, far from all this youth that eats and devours everything very easily. The cost of learning new languages ​​(html, javascript, css, jquery, bootstrap, materialize, ...) together with the harbor support is going to be the great excuse for not making the leap. Too much cost.


Recently I have been fortunate to live the birth of mod harbor for the web. The seed was really laid thanks to Antonio Linares, it works, it goes well and it will improve every day more. Regardless of whether other technologies or ways of functioning as fastcgi or another, may be other solutions, the problem I see in itself is not the core or core but the assimilation of the methodology to program in this environment, because a "Hello World" everyone does but one program does not: Programming is easy, making programs is difficult… ”.


Gentlemen: Programming on the web is difficult, very difficult


A few months ago I created a framework made with Harbor based on “Laravel”, one of the most popular frameworks used today, to test the power of the mod. The same philosophy and same pattern of software architecture, I have not invented anything, just emulate what is successful among hundreds of thousands of programmers. The system really works and in fact the project that we have started with Antonio Linares, Genesis (http://genesis.mod-harbour.org/) shows that we can do programs on the web with Harbor. Ah !!! together (html, css, js, ...) and that is that everything goes together, holding hands.


So what happened with the Mercury framework. I see that colleagues do not want to use it, but the big question is: Why? Because I think that entering and making the leap to the web is difficult as we have said before and the price of studying all these complement languages, application design patterns, new systems, ... is very high. 


So what can we do to create applications on the web with our Harbor? Does it make sense having other powerful languages ​​prepared for it? Regardless of how many Harborborns want to stay on desktop, those who want to make the leap to the web, can they do it with Harbor? If, as Alexander says, we are a minority that we are not even in the top 100, ... does this concern make sense and especially efforts?



Happy Holidays.


Carles.






 

Ash

unread,
Dec 26, 2019, 2:06:09 PM12/26/19
to Harbour Users
Hello Everyone,

Here is the standard "Hello, World!" program written in 3 languages. These three programs accomplish the same result - Hello, World! is displayed on the screen. 

Assembler 

    org  0x100        

    mov  dx, msg      
    mov  ah, 9       
    int  0x21         

    mov  ah, 0x4c     
    int  0x21
         
    msg  db 'Hello, World!', 0x0d, 0x0a, '$'
   


#include <stdio.h>
int main() {

   printf("Hello, World!");

   return 0;
}


dBase III  

PROCEDURE Main

   ? "Hello, world!"

   RETURN

Trivial examples, I know, but they highlight the complexity of methods used. I chose dBase III back in 1984 to solve business issues because the scripting language was the easiest to work with. I was able to translate business requirements into business applications quickly and easily. At 70, I am still writing programs in the same way except that now I am using Harbour. I dread the idea of programming in assembler or C.

Please consider the use case of converting an old Clipper program to GUI:

I only have a few options - WVW, WVT,WVG or QT libraries. As the resulting xBase program looks more like a C program, I no longer feel comfortable and start looking for alternatives. 

What we need is Harbour GUI that is part of Harbour core and provides for the following to begin with:

Form/Dialogue
@...SAY
@...GET
@...GET CHECKBOX/LISTBOX/PUSHBUTTON/RADIOGROUP/BROWSE/CALENDAR

Many efficient business applications can be built using these controls. Once we have the required/agreed framework in place, more controls can be added to Harbour core easily. 

Wayne Ratliff: The spirit of Vulcan/dBase is alive and well in Harbourland.

Regards.
Ash
 

Don Lowenstein

unread,
Dec 26, 2019, 4:50:28 PM12/26/19
to harbou...@googlegroups.com

For me, FiveTechSoft / FiveWin is a very acceptable and straightforward GUI solution.

 

 

 

From: 'Gilbert Karweru' via Harbour Users <harbou...@googlegroups.com>
Sent: Wednesday, December 25, 2019 3:00 AM
To: harbou...@googlegroups.com
Subject: Re: [harbour-users] Future of Harbour - GUI Library Support

 

I honestly think harbour is at crossroads. It is either we are willing to change or die out since we don't seem to be attracting new users/developers and soon enough, we will be too old. 

Ernad Husremovic

unread,
Dec 28, 2019, 5:00:43 AM12/28/19
to Harbour Users
Hello community,
I think that there are to main problems with this project:

1. There is no prominent open-source software built around project

There are numerous examples, where language projects are ceasing not because the are by the engineering point bad, but they have no applications around it.
For example look at Dart language. Millions of dollars have spent to the language by the google, but it didn't succeed  ... until  Flutter (https://flutter.dev/) have published.
Ruby has RoR, python has numpy and billion of other projects, golang has docker and numerous other. Harbour have not single one prominent project!

2. The community is rigid

The community is not ready to accept, even discuss that It should embrace as goals to adopt and learn other tools as must-have 
(for example SQL management), reporting (for example: make good bridge with Java/JasperReports) .
Along with adopting "new worlds", the community is not ready to mark some parts as pure legacy which has no future.
For example i think that main putting efforts into GUI library and/or WEB GUI is path with small benefits. Why? 
Because there are good matured solutions with other languages. 
I suppose that community is putting efforts to desktop GUI because they ignore the fact: people should avoid build MONOLIT
applications. They should build client frontend as one subproject, backend as another. 
Harbour HAS already good enough frontend for an accountant's data entry  - yes it is CUI interface. 
But for another uses, harbour developers should adopt new technologies. Example>

You can see on my github page https://github.com/hernad/
three projects:
- eShell  - it is mainly Visual studio code project used as host of our new desktop application
- vscode-f18  - it is extension which downloads our CUI F18-client harbour application and shows it in eShell web window
- vscode-postgresql - used to setup postgresql connection (F18-client is launched with parameters get from this extension)
- vscode-pdf - view of pdf document in another tab of eShell

With this approach I have connected my "old-school" harbour project with new worlds.
 
In another thread, one honored colleague sad that I am disruptor. I suppose he is right.
That is the way I work in this community either in my personal projects. 

If there is something useful to others - it is available as open-source software. If it is not, I will continue to disrupt only myself.  
 

On Thursday, 5 December 2019 19:14:50 UTC+1, Eric Lendvai wrote:

I just noticed some deep conversion in the post "Harbour 3.2 Updated and available for download" https://groups.google.com/forum/#!topic/harbour-users/xA2kwORukTw and https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/harbour-users/xA2kwORukTw/W0xL6sbVBQAJ

But this new post, to match the subject.


I am fairly new to Harbour, only a little over 2 years. For more than 25 years I was developing desktop and web apps in VFP (Visual FoxPro) and Python mainly.


I saw the same problems of lack of direction and support for the Harbour language, but also came to appreciate its power, cross platform support and to be a true 4GL for C.


I created the web site https://harbour.wiki with the hope to create a foundation, similar to the Python Software Foundation, to help keep the language alive.


The only person that seriously responded to the proposal for a foundation was Antonio Linares. But he became very busy with mod_harbour, a solution to bring Harbour to the web.


He is not a maintainer of the project and can not merge commits. He had the great vision of the Harbour language, but also brought a commercial solution to the GUI problem.

He now fully embraces open-source solutions and was the main force behind mod_harbour.


As was mentioned before, the main core developers left the project, and it is almost impossible to bring in new developers.


I am donating my time to maintain harbour.wiki with the hope to turn it over to a foundation. I was also able to purchase the domain name "harbour.dev" with the hope to also donate it to the foundation.

This new domain name could become the core branch for the language?


Tutorial, reference material, requests for enhancement proposals, central package indexes are some of the main issues a Harbour foundation should deal with.


I created a source code scrapper in harbour.wiki to help create a core synced documentation, and slowly I am bringing Pete's and others documentation in it. I would really like to rely on some other developers to help with that project.

Antonio also proposed to create a documentation of the compiler itself, but again we don't have real access to core developers to help.

Ideally we should have something that looks like the one made for python: https://realpython.com/cpython-source-code-guide/


But in regards to the GUI issue, in my opinion, most future projects are web apps or could be implemented with html/css technologies like electron has, but having Harbour as the core language.


Also harbour is missing local SQL support, similar to what VFP had.


I just posted a repo about creating FastCGI apps in Harbour, and will soon have a detailed article about web development in Harbour . Hopefully the mod_harbour community can also embrace it.


Again, whatever my opinions are about web vs desktop, SQL, GUI platforms are, a foundation should be created to provide support and leadership for Harbour.

We need enough members in the foundation to ensure no single point of view steers the language, but instead provides support.

We don't want another fork, like xharbour, Viktor 3.4 ...


Other solutions like X#, xbase++ are just mainly commercial enterprises and still have the same issues of lack of developers base.

X# is basically a clone of Harbour in .Net, but with the restriction of the C# language.

xbase++ is Windows 32 bit only and closed source code.


Any ideas ?

Ash

unread,
Dec 28, 2019, 7:26:17 PM12/28/19
to Harbour Users
Hello Everone,

I feels as if my ship, Harbour, has lost its captain!


To jog our memories, please refer to Wikipedia article to understand why Clipper compiler for xbase became so popular.


https://en.wikipedia.org/wiki/Clipper_(programming_language)


Antonio Linares initiated the Harbour Project to deliver an open source alternative to Clipper. Therefore, we must never forget Clipper. Harbour is Clipper on steroroids.


As I have articulated before, we must regroup and release Harbour Core V3.2 for Windows and Linux, and possibly for MacOS platforms. Including other OSes will slow down Harbour development.


Harbour is, as Clipper was, an invaluable tool for me and I am sure many others. It allows programmers like me build reliable business applications quickly without having to resort to C.


Regards.

Ash


On Thursday, December 26, 2019 at 4:50:28 PM UTC-5, Don wrote:

For me, FiveTechSoft / FiveWin is a very acceptable and straightforward GUI solution.

 

 

 

From: 'Gilbert Karweru' via Harbour Users <harbou...@googlegroups.com>
Sent: Wednesday, December 25, 2019 3:00 AM
To: harbou...@googlegroups.com
Subject: Re: [harbour-users] Future of Harbour - GUI Library Support

 

I honestly think harbour is at crossroads. It is either we are willing to change or die out since we don't seem to be attracting new users/developers and soon enough, we will be too old. 

 

We shouldn't be held back by individuals who believe you can move forward by not changing.

 

Harbour must embrace new techonologies (especially GUI and web), and honour its promise of 'write once compile on many'. The approach to GUI must then be generic and replaceable GUI architecture seems a very good way to go.

 

What I must ask, probably from experienced developers like Priptal,Kresin,Robez,Grigory etc, is whether the GUIs they have developed so far, can be condensed into a single library, such that one would only need to include such during compile?

 

Gilbert.

 

 

On Tuesday, December 24, 2019, 04:54:26 AM GMT+3, Francesco Perillo <fper...@gmail.com> wrote:

 

 

It seems to me that instead on narrowing our goals, we are widening them, adding good ideas but very difficult to put in practice.

Theoretically is a great idea but I'd like to ask this question: how many of you are available to modify your programs to accommodate the new syntax/library?

If you coded like Maurizio did, the port is easier. Not easy, easier than the way I coded my software.

 

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.


Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to harbou...@googlegroups.com.


To view this discussion on the web visit

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.


Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to harbou...@googlegroups.com.

Angel Pais

unread,
Dec 28, 2019, 7:34:06 PM12/28/19
to harbou...@googlegroups.com
Who's the Admin of harbour's 3.2 github repository ?


Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/harbour-users/2bb0fd7b-eda1-4029-9b2c-e4a7ccb11782%40googlegroups.com.

Maurizio la Cecilia

unread,
Dec 30, 2019, 4:32:30 AM12/30/19
to Harbour User Group
AFAIK, is Viktor Szakats.
Best regards.
--
Maurizio

Angel Pais

unread,
Dec 30, 2019, 10:06:06 AM12/30/19
to harbou...@googlegroups.com
So the project is locked down.
We need a new admin and Viktor willingness to give it over to someone else, in orden to make it move on

mstuff kstuff

unread,
Dec 31, 2019, 10:25:36 PM12/31/19
to Harbour Users
As a laymen and, reading all these ideas as to what should be done next, I don't care. I am pretty much happy with Harbour as it has progressed, except for a couple of basic thing that seem to no longer work and the lack of response/help.
Setting that aside, I think that if you want to attract new users you should consider a new front end. Something like:

Harbour's strong point is data manipulation, (database) business and personal
but, it can do so much more. It is not good for graphic gaming, other than
that, your imagination is the limit. Harbour is Clipper compatible (which is dbIII
compatible). It can produce a stand alone executable x32 or x64 file. Scope it out, it is free.

then add
+gui
+ sql
+ zip
+whatever

or something like that.
You need be very positive. It is just marketing. Sell Harbour!
Respectfully submitted, Mike Knowles


mstuff kstuff

unread,
Dec 31, 2019, 10:42:44 PM12/31/19
to Harbour Users

mstuff kstuff

unread,
Dec 31, 2019, 10:59:14 PM12/31/19
to Harbour Users
One other thing.
I hate to say,  I thought Harbour as open source and was done by people who just wanted to produce free software or the challenge of producing better software. If they are now looking for money, kill Harbour and join xHarbour.
Not so respectfully submitted, Mike Knowles

mstuff kstuff

unread,
Jan 1, 2020, 7:30:20 PM1/1/20
to Harbour Users
I had no I idea that one person developed GTWVG.
Thanks, I really like it and use it all the time.

Indirectly you put me to shame. I had begun posting some of my programs on
Sourceforge as PD with for non-commercial use. When I found out that one
person did GTWVG and was so unselfish as to give it away. It made me feel
guilty. I had to go back and remove the restrictions.

Regarding your newer GT. Could a wvt_tone() be included? I'm not sure if tone
is a proper GT thing or not. The only reason I am asking is because I can't seem
to get Harbour's version to work or even a ? chr(7) and it would be nice to have
an alternative if possible.

Sincerely, Mike

José M. C. Quintas

unread,
Jan 1, 2020, 10:17:54 PM1/1/20
to harbou...@googlegroups.com

wapi_MessageBeep()

José M. C. Quintas

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.

tarpauwatratar

unread,
Jan 28, 2020, 5:37:34 AM1/28/20
to Harbour Users
I met Harbour for the first time two years ago. It was my first job in IT and first conntact with self-employment :) IMHO it was terrible experience. I've written about it here http://discuss.spoj.com/t/jak-nie-programowac/27080 (sorry but in polish; title is: how to not program). 

After a time I understood that it's not problem with Harbour but with people which works with me. They traits Harbour like Clipper or even dBese and it's terrible. 

I developed some GUI apps in Harbour and HMG but I wasn't sattisfied. Comparing them to my works in NetBeans it took more time and effects were worse. 

IMO Harbour has one great feature. It is the best language for command line apps. It's much better than ncurses. DBF's are easy to create and maintain not only for IT-people but also for other. Modifications can be easily done using LibreOffice or Excel. I think Harbour should focus on this feature.

For example @ GET, @ LISTBOX etc. doesn't allow me to pass containter like aoMySpecialGetList - only GETLIST is allowed. TBrowse doesn't suppor changing size of columns. I dream about possibility of using RGB colors in GETSYSTEM.

After these improvement Harbour will be great however probably not used be lot of programmers. My old Harbour-team stucked with Harbour 2.0 and commercial and/or forsaken solutions like siergiej or mediator. They will rewrite all programs in C# because .Net is more powerful, better supported and easier to use in business work. The can't upgrade to Harbour 3.x because of compability reasons.

Francesco Perillo

unread,
Jan 28, 2020, 6:35:14 AM1/28/20
to harbou...@googlegroups.com
I used google translator to read your article and I had the same feeling: the problem is in the people who wrote the code. They are abusing the language, not using it.

Can you please write more on these points:

I developed some GUI apps in Harbour and HMG but I wasn't sattisfied. Comparing them to my works in NetBeans it took more time and effects were worse.

Which problems did you find? 
 
After these improvement Harbour will be great however probably not used be lot of programmers. My old Harbour-team stucked with Harbour 2.0 and commercial and/or forsaken solutions like siergiej or mediator. They will rewrite all programs in C# because .Net is more powerful, better supported and easier to use in business work. The can't upgrade to Harbour 3.x because of compability reasons.

Which are the blocking problems that don't allow to move to a more recent version of Harbour? Are you using some external libs not available for Harbour 3?
Are you really sure that developing a new solution in C# is doable in a finite timeframe?

tarpauwatratar

unread,
Jan 28, 2020, 8:05:01 AM1/28/20
to Harbour Users
Can you please write more on these points:
I developed some GUI apps in Harbour and HMG but I wasn't sattisfied. Comparing them to my works in NetBeans it took more time and effects were worse.

One of the best thing in Harbour which is inherited from Clipper is its simplicity. How to get an input with validation, correct colors etc? Just use the following code:

   #command @ <row>, <col> GET <v> [PICTURE <pic>] ;
                           
[VALID <valid>] [WHEN <when>] [SEND <snd>] ;
                           
[CAPTION <cap>] [MESSAGE <msg>];



I don't like TBrowse because it doesn't fully highlight a selected row - all TBColumns are highlighted but the space between them is not. Its why I have written my own open source solution. How to use it? It's also easy to do:

#command @ <top>, <left>, <bottom>, <right> ROWBROWSE <obj> ID <id> [COLOR <color>] ;
           
[BORDER <border>] [TITLE <title>] [ALIGN <align>] [TITLECOLOR <titlecolor>] ;
           
[ROW <row>] [ACTION <action>] [COLORBLOCK <colorblock>] ;
           
[HEADERCOLOR <headercolor>] [KEYMAP <keymap>] [CARGO <cargo>];
           
[AUTOHIGHLIGHT <autohighlight>] [SKIP <skip>] [GOBOTTOM <gobottom>] [GOTOP <gotop>];


In my opinion this approach doesn't work great with modern GUI. There are too many options and powerful enought GUI handling makes syntax complex. Using NetBeans I had multiple tutorials, good IDE, help on StackOverflow and language which was designed for this task. Nothing of these can be found in case of Harbour. Close to none tutorials, no great IDE and HMG isn't easy to use in object oriented programming. 

For example compare documentation and code in the Qt documentation (https://doc.qt.io/qt-5/qlabel.html) with this http://hmgextended.com/files/manual/index.html.

Harbour can't beat Java or C#. Without backward compability with Clipper it is not attractive for old developers who are looking for this kind of solutions. Young developers have multiple modern languages to choose - for them backward compability is a con of Harbour. Also support is much worse than in case of popular languages.

It is why I like Harbour for cmd-taks but I prefer other languages for GUI.

Which are the blocking problems that don't allow to move to a more recent version of Harbour? Are you using some external libs not available for Harbour 3?
Are you really sure that developing a new solution in C# is doable in a finite timeframe?

I am not working in this company any longer. The last thing I've heard is that 'Harbour 3 changed multiple of headers and it's not possible to compile program without time consuming changes in all .bat and .prg files'. I don't know is it true or just my old acquaintances are lazy ;) Maybe they have problem with Mediator (http://www.otc.pl/index.asp?s=35)? I am not sure.

Luigi Ferraris

unread,
Jan 28, 2020, 1:33:06 PM1/28/20
to harbou...@googlegroups.com
Hi tarpauwatratar,

Basically I'm in agreement with you when you write

"In my opinion this approach doesn't work great with modern GUI. There are too many options and powerful enought GUI handling makes syntax complex."

But I think we can't compare XBase (Harbour) framework with other (many times payed) framework.
At the same time and related to IDE, documentation, etc. you must think to the diffusion of the product or backend / underlayer.

Behind the scene
@ <row>, <col> GET <v> [PICTURE <pic>] ....
   AADD( GetList, _GET_ ....

there is an array (getlist) and (yes!) an object (get) because of XBase framework.

If I want switch to another framework I need to rewrite previous code, probably losing some/many framework benefits (as you pointed out) but more probably I need to add something (as you pointed out)
A basic example referring to Qt
@ <row>, <col> GET <v> PARENT <p> [PICTURE <pic>] ....
without adding to GetList because Qt has it's own logic to navigate through widgets and where <v> probably is a reference to an object and <p> the required parent (again an object) else a new window is open (give me a cent for brief description, explanation, example probably not very cool).
With other framework, maybe you need different changes, again: losing, adding.

A foundamental problem: positioning; if I code
@ 10, 10
First of all, I lose the ability about dynamic positioning so you need another different code.
Anyway, I think will be very different if the work space (think about framework unit measurement) is 0, 0, 25, 79 rather than 0, 0, 1024, 769
Conversions (good) are required before sending arguments to the framework.
At the end, your .ch can be
#if CUI
   @ <row>, <col> GET <v> [PARENT <p>] [PICTURE <pic>] ....
   row := convToClp( row ), col := convToClp( col )
    AADD( GetList, _GET_ ....

#elseif GUI(a)
 @ <row>, <col> GET <v> [PARENT <p>] [PICTURE <pic>] ....
   row := convToQt( row ), col := convToQt( col )
   .............

#elseif GUI(b)
 @ <row>, <col> GET <v> [PARENT <p>] [PICTURE <pic>] ....
   row := convToGtk( row ), col := convToGtk( col )
   .............

changing std.ch or creating your (but only your) alterntive .ch (ROWBROWSE)?

IMHO, switching from CUI to GUI is not so simple and thinking to use (at the same time) different GUIs with high results can be a nightmare, despite commands definition.

But, perhaps I'm limited.

Regards
Luigi Ferraris

tarpauwatratar

unread,
Jan 28, 2020, 1:52:56 PM1/28/20
to Harbour Users
Basically I'm in agreement with you when you write
 
:)

But I think we can't compare XBase (Harbour) framework with other (many times payed) framework.

You're right. Usualy I don't compare xBase with other technologies. I've done it only to explain my point of view. For me Harbour is great but only for CUI. In case of GUI I choose other options like C# and .Net in case of Windows or C++ + Qt otehrwise. It's why I think that Harbour development should be focused on CUI solutions.

 changing std.ch or creating your (but only your) alterntive .ch (ROWBROWSE)?

It is what I have done (https://github.com/e-Lama/libgui). My own rowbrowse.ch in the project which is developed independently of discusions about Harbour. Every Harbour user can download it and use. It is really helpful for CUI development but If sb doesn't like it - no problem.

Pritpal Bedi

unread,
Jan 28, 2020, 3:50:26 PM1/28/20
to Harbour Users
Hi

 C++ + Qt otehrwise. It's why I think that Harbour development should be focused on CUI solutions.



Did you "ever" looked into HbQt before floating above statement?

Probably your viewpoint might get a big boost.

A rock solid bindings for Qt, even with @nn, nn SAY / GET implementation.
Have a look and you may find it more productive than any other language.

The only attached darwback to this library is that Viktor threw it away from Harbour's main stream.


Pritpal Bedi
a student of software analysis & concepts

tarpauwatratar

unread,
Jan 28, 2020, 7:12:22 PM1/28/20
to Harbour Users
Hm.. it looks interesting. Thank you for information.

I've heard about this project but I've never looked at it.

xamm-inf

unread,
Jan 29, 2020, 4:25:52 AM1/29/20
to Harbour Users
Please, try Xailer, IDE like Delphi, Harbour based.
www.xailer.info Personal version is free.

Heraldo Filho

unread,
Jan 29, 2020, 7:33:46 AM1/29/20
to Harbour Users
After more than 40 years working with computers, languages (15 years with clipper), database and others, I believe that there will always be simple and complex things, each one with its advantages and disadvantages.
harbor is simple, practical and objective.
long live the harbor.
Eric congratulates https://harbour.wiki/.
in relation to the foundation I am following the comments.

Johan Nel

unread,
Feb 20, 2020, 7:52:56 AM2/20/20
to Harbour Users
Sorry for so late responding.

My believe is that for Harbour to survive it needs to embrace new technology.  Currently that is .NET and with MS, Xamarin and Mono working on a OS independent version Core 5, it seems to be moving in the right direction.

We all sharing one common trait, we love XBase.  In that context X# is probably the only real solution for the XBase language to keep existing.  Just a shot in the dark:  How about joining the X# bandwagon and throw your efforts behind it?  It already has lots of XBase and Harbour support included in the current version and with the focus to implement VFP, it should see growth towards the end of the year at the X# Conference and SWFOX where the DevTeam will be present.

Just my 2c worth.

Johan Nel
Friend of XSharp
George, South Africa.

Ernad Husremovic

unread,
Feb 20, 2020, 2:21:57 PM2/20/20
to Harbour Users
Hi.

1. Product you are promoting is closed sourced project.

2. There open source parts published on github.
These project are maintained by 3 developers.

3. Xsharp has only similar syntax to harbour.

4. It seems that MS SQL  is main target, regarding data access layer
 
I would never choose migration path harbour -> XSharp:

1) Migration would be slow and expensive journey

2) If I want use .NET platform, C# or F# are program languages to go. 

I strongly believe that harbour is by far better developer tool than XSharp. 

Regards,
Ernad

Anand K Gupta

unread,
Feb 21, 2020, 3:43:09 AM2/21/20
to harbou...@googlegroups.com
I Agree.
HMG and HMG MiniGUI is the best can happen to Clipper programmers.
XSharp is a commercial try, which is not wrong per se, to earn some by giving customer support (as per their website).

The free support and development we get in HMG MiniGUI is unprecedented to say the least.
We are not only thankful but grateful to Grigory and other members.

Regards,

Anand



--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.

Johan Nel

unread,
Feb 21, 2020, 4:03:53 AM2/21/20
to Harbour Users
Hi Ernad,


On Thursday, February 20, 2020 at 9:21:57 PM UTC+2, Ernad Husremovic wrote:

1. Product you are promoting is closed sourced project.
No since beginning of this year the compiler is also opensource and can be found on GitHub: https://github.com/X-Sharp/XSharpDev


2. There open source parts published on github.
These project are maintained by 3 developers.
Correct 4 actually, but we as users do also contribute.

3. Xsharp has only similar syntax to harbour.
Not 100% true, it contains the #command etc that is found in all Clipper forks.  Work has also been done on XBase++ syntax and most of the other XBase dialects.

4. It seems that MS SQL  is main target, regarding data access layer
No, DBF also supported and Data Access via ADO.NET so any RDBMS is supported.
 
I would never choose migration path harbour -> XSharp:
Fair enough we all have our preferences.

1) Migration would be slow and expensive journey
There is already a VO->X# exporter which need minimal changes to code to compile.  VFP Transporter also in the making.  There will be Transporters for other dialects as the language matures.

2) If I want use .NET platform, C# or F# are program languages to go. 
Fair enough, your choice.  Beauty is that .NET is language agnostic so we can mix and match code written in any .NET language.

I strongly believe that harbour is by far better developer tool than XSharp. 
I cannot comment since I have tried harbour and it was a show stopper to me.  The migration from Clipper->VO->Vulcan.NET->X# was more of a joy ride for me. And put on top of X# the .NET framework is huge and very seldom I have not found a component that did not include the dirty work I required.  X# brings DBF support, macro-compilation, codeblocks, LAMBDA/Linq and an XBase script engine to .NET.  A win win situation for me.

Johan.

Johan Nel

unread,
Feb 21, 2020, 4:06:58 AM2/21/20
to Harbour Users
Hi Anand,


On Friday, February 21, 2020 at 10:43:09 AM UTC+2, Anand K Gupta wrote:
I Agree.
HMG and HMG MiniGUI is the best can happen to Clipper programmers.
XSharp is a commercial try, which is not wrong per se, to earn some by giving customer support (as per their website).
Two options free open source with 4 releases per year on average.  FOX (Friend of XSharp) paid monthly releases and direct support from the DevTeam.

The free support and development we get in HMG MiniGUI is unprecedented to say the least.
We are not only thankful but grateful to Grigory and other members.
Yes I believe in general we XBase developers are spoiled with the level of support we do get.  It is not so common in other languages.

Johan.

Regards,

Anand




Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbou...@googlegroups.com.

Massimo Belgrano

unread,
Feb 21, 2020, 6:05:22 AM2/21/20
to harbou...@googlegroups.com
hbide is very interesting editor and show the power of hbqt
https://sourceforge.net/projects/qtcontribs/files/HbIDE/ 
 

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.

Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/harbour-users/e5c55a41-a3ba-4d77-bc43-cbfdfc78bd00%40googlegroups.com.


--
Massimo Belgrano
Delta Informatica S.r.l. (Cliccami per scoprire 
It is loading more messages.
0 new messages