Hi Pritpal, Thank you for your explanation. Yes, it is clear to me now.
regards, Budyanto On 13 Mar 2009 at 13:43, Pritpal Bedi wrote: > Hi Budiyanto, All > > > > > If you mean revising (or rewriting) GTWVW into Harbour, then I'll be very > > much > > interested, as well as many others. But please keep it backward compatible > > as > > much as possible. I remember you said here in the past that GTWVW is > > "impossible" to port to the new GT API because there is a conflict with > > GTWVW's use of first parameter as window designator (for most functions). Do > > you finally find a way to solve that problem? Or do you plan change the > > convention in GTWVW? (I hope it is the former.) > > > > Am I interpreting it right with what you mean by "porting GTWVW in GTWVG"? > > > > When GTWVW came into existance I had already ported my applns to GTWVG, > the then GTWVT+WVTGUI, so I never looked into GTWVW deeply. Everything > I needed was available in GTWVG ( current name ). Rather at that time > I thought pseudo emulation of controls was good enough to appeal my clients > and > I was saved of the time to learn a new protocol. With only little efforts I > was > able to roll my applns with a new look and feel. > > Over the time concepts changed. Multi-Window and Multi-Threading forced me to > look into real windows world. I was convinced that a lot can be achieved on > this > front as MT and GT modal of Harbour is much superior to any other in the > market > today. > > I looked around for effective GUI modal to base my next developments > targetting > not only my own needs but the Clipper community in general. The available > modals > in-use for Harbour around were as follow: > > 1. FWH > 2. VXH > 3. HWGUI > 4. MINIGUI > 5. XAILER > 6. GTWVW > > Every modal had its pros and cons. Some had documentation missing, > some were pure IDE based, some dynamic but heavily based on #define(s) > ( due a large number of parameters for a single activity ), and some lacked > OOP. > Every modal had its own parameters passing and calling convensions. And, for > sure, all modals lacked adaptation to MT, the biggest mainstay in the coming > future. > > What I wanted to base next efforts on development of a GUI : > > 1) It must be adaptable to MT modal. > 2) It should be able to take advantage of MW GT whereever possible. > 3) It must adhere to standardization of parameters and calling convensions. 4) > It must be having a well written documentation. 5) If possible, it must have a > user-base. 6) And above all, it must be able to base Multi-Platform GUI. > > After a lot of thinking and spadework I could not accept any of the above. > I just picked Xbase++. This compiler's subsystems were almost fitting > my ideology, is having a large user-base, ships with descent documentation, > complete with MT capabilities and nicely fits into Multi-GT environments. > > Moreover I had worked with this compiler for some time and know how > best its parameters passing and calling conventions were. Also I wanted to > have > a well define class framework to dream for a multi-platform GUI framework. > > I knew to follow an already established framework is always a difficult > task. > To create a new protocol you are the master of your own thoughts. But to > copy > feature-by-feature is very difficult. But I choose the difficult way. > > Also I wanted to have an integrated library which could absorb different > scattered GUI modals into one as all were having one aspect in common - > Harbour. > My first results are quiet encouraging and now GTWVG can host: > > * pure console, > * pseudo GUI console, > * Xbase++ consols and dialogs with xbase parts, > * pure consoles with Xbase parts, > * and a mixture of any of the above. > > In this evolution process GTWVW becomes the next natural GEM to > be inducted in this whole picture, and probably FWH too, who knows. > > If you invest a little time in GTWVG's Xbase++ implementation, you > will wonder how a Xbase++ .prg ( with only those controls which have > have taken some shape ) can be compiled in Harbour. And this is the > same intention for GTWVW too. No code change whatsoever. > > As before, today also i say that it is difficult to port GTWVW as is > in new GT system. As GTWVG and GTWVW share the same code base at the > core levels it is easier to embed GTWVW GUI controls into GTWVG. > End user will not experience any change to his/her code. This way > it is not as difficult as it seems to be. > > Also to rewrite it again will be sheer waste of time and resources. > In fact I could never take advantage of GTWVW because it become mutually > exclusive with GTWVG, and which I do not want at this time. Possibly > in the coming few days I will lay the base structure how GTWVW > functionality can be included in GTWVG. There onwards there should be > cummulative effort to achieve this goal. I alone can achieve but it may > take a bit longer. > > To conclude, GTWVW is not going to be rewritten but will be included > in GTWVG and for sure end-user will need a minimum to change his code. > > > Hope I am clear enough. > > Regards > Pritpal Bedi _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
