Here you can found info regarding xbase part http://xbaseprogrammer.com/ClassHierarchy.cgihere interesting sample xbase part http://www.knowlexbase.com/en/software/downloads/yukon/index.html
2009/3/13 Pritpal Bedi <bediprit...@hotmail.com> > > 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 > > > > -- > View this message in context: > http://www.nabble.com/GTWVG-and-Buffered-Console-tp22478907p22501471.html > Sent from the Harbour - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- Massimo Belgrano Analisi e sviluppo software per Lan e Web - Consulenza informatica - Formazione Delta Informatica S.r.l. http://www.deltain.it/ +39 0321 455962
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
