Hi Reynaldo Pritpal have announced the idea of implement a layer compatibility of gtwvw in gtwvg but it have made an huge work for hbqt (Gui Multiplatform) & gtqtc (access like gtwvt to hbqt) & hbxbp (Xbase ++ compatible syntax, made possible compile xbase++ program on linux and mac-os)
I have tried port of basic WVW_nOpenWindow, WVW_lCloseWindow, wvw_setmaincoord to wvg and my sample demonstrate that is possible, is very imperfect but works with this liittle sample so i invite Pritpal made a starting implementing of this base component (not from my bad source) WVW_nOpenWindow, WVW_lCloseWindow, wvw_setmaincoord are foundation component, other people can continue implementation Most will be made by a #include .or. by a simple wrapper class" reversing wvt2wvw.ch because implement wvw_ syntax same as wvt but with a additive parameter that is windows number if Here are present any Voluntary contribution for vww2wvg, i invite reply to this messages Usefull will be also create little sample that cover all command in alfabetic order Thanks in advance // Experiment for Emulating gtwvw with gtwvt/gtwvg/XWC #IFDEF __PLATFORM__WINDOWS REQUEST HB_GT_WVT_DEFAULT #DEFINE THREAD_GT "WVT" #ELSE REQUEST HB_GT_STD_DEFAULT #DEFINE THREAD_GT "XWC" #ENDIF #COMMAND DEFAULT <v1> TO <x1> [, <vN> TO <xN> ]=> IF((<v1>)=NIL,<v1>:=<x1>,NIL) [; IF((<vN>)=NIL,<vN>:=<xN>,NIL)] STATIC S_Ocrt:={} STATIC S_setmaincoord:=.f. #XTRANSLATE setpos( => setpos2( FUNCTION main local X_Number:=9 cls wvw_setmaincoord(.t.) WINDO=WVW_nOpenWindow("", 5, 5, 7, 40) @ 5,5 ,7,40 box "" @ 6,6 SAY "Number" get number READ WVW_lCloseWindow(WINDO) RETURN FUNCTION WVW_nOpenWindow(X_title,x_top,x_left,x_bottom,x_right) local ocrt x_ocrt := hb_gtCreate( THREAD_GT ) setmode(x_bottom-x_top+1,x_right-x_left+1) // ? x_bottom-x_top,x_right-x_left x_oCrt := hb_gtSelect() aadd(s_ocrt,{x_ocrt,X_title,x_top,x_left,x_bottom,x_right}) x_ret=len(s_ocrt) RETURN x_ret FUNCTION WVW_lCloseWindow(x_pos) default x_pos to len(s_ocrt) s_ocrt[x_pos,1]=nil adel(s_ocrt,x_pos,.t.) RETURN FUNCTION wvw_setmaincoord(x_coord) s_setmaincoord:=x_coord RETURN #XUNTRANSLATE setpos( => FUNCTION SetPos2( x_row, x_col ) local x_pos:=len(s_ocrt) // altd() if s_setmaincoord setpos(x_row-s_ocrt[x_pos,3],x_col-s_ocrt[x_pos,5]) else setpos(x_row,x_col) endif RETURN ---here original prippal messages Hi Budiyanto, All 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 2009/6/15 Reynaldo Henrique <rhfsyst...@yahoo.com.br>: > > > Massimo, > > Yes, that's right. Many Brazilian users, like me, want GTWVW back again. And > we know that it is not a so easy task. I really would like to praise this > idea from Patrick! > > thanks for making me know. > > Reynaldo > > > > Massimo Belgrano wrote: >> >> Follow post is from Patrik Mast on xharbour developer list >> -------------------------------- >> Hello, >> >> We have many Brazilian users who are kinda stuck with GTWVW. >> Phil, can we port GTWVW to xHarbour? Or can we port Harbour's GT >> drivers to xHarbour? >> >> Any thoughts, ideas? >> >> Thanks! >> >> Patrick >> _______________________________________________ >> Harbour mailing list >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour >> >> > > -- > View this message in context: > http://n2.nabble.com/GTWVW-is-broken-in-xharbour-....by-Patrik-Mast-tp3076949p3077436.html > Sent from the harbour-devel mailing list archive at Nabble.com. > > _______________________________________________ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- Massimo Belgrano _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour