Hi MrDuck,
Anyway, in the next days I will do some commits. But are still interested developers around ? If it becomes a project of very few people, probably the 100% compatibility goal could be abandoned...
Like Sudip and everyone who are part of the original HMG4 Developers, I am also one of those who participated but somehow indirectly. I mean I've asked for browse but the task assigned to me is Grid. Well I was interested in browse to provide those capability of tbrowse in clipper. Later I loose interest with the development due to time constraint and conflict with work. During those time, the abandonment of browse is floating around in favor of grid in HMG4. So I said to myself, HMG4 is disaster to my deployed systems. So what shall I do, I began testing the compatibility of my apps to HMG Extended.
Later again I come to a point and realized which is better, using HMG4 with wrapper or code directly with HBQT without the rules of HMG4? Perhaps it depends on program requirements.
And MrDuck is right after all, it's difficult to provide the compatibility with HMG3. However abandoning the compatibility will be a disaster to HMG3 users.
Perhaps the best thing for now is to synch HMG4 with the latest HBQT build and talk about the technical issues involved, direction, completed work (compatibility) and corrective measures. Layout those functions which cannot be ported and provide an alternate solutions to direct the calls to the appropriate calls for HMG4. Maybe this can be placed to a separate compatibility library to provide the appropriate compilation of HMG3x codes. So if one coded a new application the compatibility library is not required.
Regards,
Danny