HMGforum.com

Hi.

Ricci wrote:How do I download the svn?

Since this can be a pain to a first time SVNer I will try to introduce some guidance...
If you never download code via SVN, first install TortoiseSVN from http://tortoisesvn.net/downloads.html
After that, in Windows Explorer right-click in your C:\ ( or any other drive you want ) and select SVN Checkout.
In URL of repository type https://hmg.svn.sourceforge.net/svnroot/hmg
The Checkout directory will be automatically filled with C:\hmg which is where SVN will download the code. You can change this if you want.
In Checkout Depth choose Fully recursive.
In Revison choose HEAD revision.
Click OK.
That's it, after download process ends you have the source code in C:\hmg.
Open a console at C:\hmg and run buildlib.bat to build the lib.
Open a console at C:\hmg\samples and type build build_all to build the samples.

Only to have an idea, you can look to this viewtopic.php?f=15&t=1252&p=9074&hilit=printing#p9074.
I will start to use this idea, rewrite it for HMG4 and publish again.

Cheers

I love the idea of independence from Microsoft Windows
android platform is a very interesting platform Imo we can get advantage & money with clipper business app rewritten for GoogleAndroid,Iphone,windows mobile

Imo HMG3 compatibility must be better as possible
Use in same project minigui syntax & hbqt will be very right way

mrduck wrote:I and Luigi are trying to get HMG4 in better shape. I don't know if we will succeed but we are trying hard and got some results.

I was thinking about some problems:

1) HMG3 compatibility.
2) HMG4 compatibility with itself
3) Using Qt directly
4) is anyone really interested in HMG4 or have some software in production using HMG4 ?

Francesco

I just committed to hmg4 repository changes needed to compile rathinagiri interst(ing) calculator under hmg4.

There are a couple of changes needed in rathinagiri code:
- rem begin/end ini blocks (not implemented in hmg4 yet, any volunteer ??? hmg3 code is not good since it uses window registry and so is not portable)

- remove nomaximize from window definition (bug in hmg4)

- rename variable "interest" used as a temporary store in calculations: a variable with the same name is used to store the main window...

- for images, there are various solutions. I put them in a images subfolder to unclutter the work directory and create a qrc from the rc file

begin/end ini blocks (not implemented in hmg4 yet, any volunteer ???

I will do that part.

Hi,

I have attached my DBU (a very old application created in MiniGUI times) after getting successfully compiled with the latest HMG3.0.39. I have to update the printing to latest HMG. So, except printing function everything seems to be working fine.

I think it will be a better project to test for HMG4 porting, since it deals with all the functions of DBF too (filter, replace, index etc., )

Rathinagiri Sir,

Thank you

Hi All,

Looking at the current code, I've noted that some of the original project goals had changed.

HMG.4, had now exposed things that are related to the way that QT works, making it somewhat less intuitive than HMG historically had been.

Considering that, and the lack of interest (or available time) to achieve a higher degree of backwards compatibility, I think that the project name should change.

So, IMHO, a new name, that reflects the current project goals better should be used.

I'm not good for names, but, perhaps: HMG/QT or HMG/m (m=multi-platform).

This way, with new (easier to achieve) goals, like 'light' backwards-compatibility and more QT-influenced design, the project could be completed quickly, reaching its beta phase soon.

And, of course, the first version should be numbered 1.0, to make it clear, that it is a different thing.

So, HMG 3.x development could be resumed.

That's really a FANTASTIC idea Roberto.

Roberto Lopez wrote:Hi All,

Looking at the current code, I've noted that some of the original project goals had changed.

Hi Roberto,
I think you didn't look at the code carefully... at all...

and probably you didn't have the time to read the forum...

I personally spent TONS of hours to achieve hmg3 compatibility and if you read page 4 of this thread you will find the interesting calculator of Rathinagiri working in hmg4 with 2 trivial line changes !
I was able to run a program from Luigi (no source in the open) with other trivial changes, adding missing (compatibility related) bits to hmg4.

My idea (that demostrated to be faulty) was that if I could achieve better hmg.3 compatibility some hmg.3 users would test their programs...

It is not true that the original goals are changed. It is true that HMG.3 users doesn't have any incentive to move their programs to HMG.4 because of false informations or unwillingness to test changes...
read the first messages of this thread:
- why move to Qt when 100% of our software is used on Windows ? Also read as: why should we learn new things, change some source code, test all the software again when it is now working perfectly ?
- Qt/hbQt/HMG.4 is SLOW: then Carlos showed that it is not true, on the contrary HMG.4 is the quickest !!! and it is the quickest for a specific reason, it is FULLY OOP from the start to the end ! When Ricci saw it is quick he started to port his program to HMG.4 and instead of porting using HMG.3 compatible syntax he decided to use HMG.4 OOP syntax. He is now reporting some problems in the code that me and Luigi are trying to address

HMG.4, had now exposed things that are related to the way that QT works, making it somewhat less intuitive than HMG historically had been.

What makes you think this ?

Considering that, and the lack of interest (or available time) to achieve a higher degree of backwards compatibility, I think that the project name should change.

I'd change to: "considering the lack of interest from HMG.3 users to dedicate time testing HMG.4 compatibility and reporting problems and the few users (just 2) that did decided to go directly to HMG.4 syntax, I think that the project name should change.". I think it respect truth more accurately

So, IMHO, a new name, that reflects the current project goals better should be used.

I'm not good for names, but, perhaps: HMG/QT or HMG/m (m=multi-platform).

This way, with new (easier to achieve) goals, like 'light' backwards-compatibility and more QT-influenced design, the project could be completed quickly, reaching its beta phase soon.

And, of course, the first version should be numbered 1.0, to make it clear, that it is a different thing.

I'm for HMG/Qt but the / can be a problem. HMG-Qt ? If you agree, I will open a new project in sourceforge.

With Luigi we are already talking about changes in syntax allowed. It will break hmg.3 source code compatibility but with trivial changes, and it preserve "the spirit" of hmg.3. As I said, trivial changes for easier hmg.3 porting.
Other ideas are really more drastic: transform HMG.4 in a full OOP library that should programmed only in OOP (with just a thin dbase sysntax layer). It's my original idea, of a small and quick "business library" over hbQt that makes easier to write code... hbQt needs such a library, you ae going to write one yourself if you program is longer than 100 lines ! And infact I know a programmer that didn't know about HMG.4 and started to write his own, closed source, library.

Francesco