Hello Pritpal Very compliment!!!!!!!!!!! Wich c Compiler/ Operative system are supported by your active x implementation?
Do you think that we will use also active x components like ComponentOne Studio Enterprise grid, reporting, charting, scheduling, data manipulation, user interface (easy get demo from http://www.componentsource.com/features/activex-components/index.html) Do you think write a gui framework that will be a little clone of XbaseParts but portable? Can be easy added a Command Compatibility for fivewin Imo also Visual Fox Pro will have an clear and documented implementation Xbase++,Fivewin,Foxbase have an userbase who can use harbour for porting his application to open source and modern environment. Best Regard Belgrano Massimo -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pritpal Bedi Sent: Tuesday, November 04, 2008 3:33 AM To: harbour@harbour-project.org Subject: [Harbour] Higher Level Classes to Manage Consoles Hello All I am about to introduce Active-X controls in GTWVG with EVENTS management. The first results are very encouraging. The basic code is contributed by Andy Wos which I have tuned-up a little to adopt to GTWVG/GTWVT. Our beloved console window is now able to host any Active-X control like Internet Explorer, Acrobat, Excel, Shell Explorer, etc. and has the capabilities to respond to events fired by the control and manage its methods and properties as usual Harbour objects. Here is a executable and sources. Just copy files in the zip to harbour/contrib/gtwvg/tests and run the demowvg.exe. Click <Modeless Dialogs><Active-X ...> prompts. Just do not give attention to screen refresh glitches. To close the window, press ESC. If ESC does not work, then click on taskbar to minimize and then maximize then press ESC. Sometimes focus is not moved back to console even you click on the title bar. http://www.vouch.info/downloads/demowvg_ax.zip As these type of functionality is always a pain if done via function calls only, I intend to introduce class framework to manage these components properly. To begin with I have in mind a Dialog class and an Active-X class. Dialog class will be a wrapper to existing pre called functions to configure a console window like: [SEC 1] hb_gtReload( 'WVG' ) hb_gtInfo( HB_GTI_PRESPARAMS, { , , 10, 10, 400, 400, , .F., .F. } ) SetColor( 'N/W' ) CLS SetMode( 30,60 ) SetCursor( 0 ) Wvt_ShowWindow( 1 ) hb_gtInfo( HB_GTI_CLOSABLE, .F. ) after which the actual console code becomes eligible for rendering [SEC 2] Alert( 'I am in the child window!' ) and then the cleanup ( if it is a window in same thread ) [SEC 3] pGT1 := NIL hb_gtSelect( pGT ) hb_gtInfo( HB_GTI_ENABLE, pGT ) hb_gtInfo( HB_GTI_SETFOCUS, pGT ) Now to the real point of discussion: As this effort may lead to building a GUI framework, as I think positively, I want to start it on the firm grounds from the base itself. There are a lot many object modals are in usage in Harbour, or say, Clipper world, viz., FWH, XAILER, VXH, HWGUI, MINIGUI, etc., and XBASE++. For me Xbase++ modal stands best of all and has a clear implementation details in place. Now the namespace issue. I propose to have all classes same names as Xbase++ and same number of parameter passing and same life cycle. The only difference will be "Hb" as prefix instrad of "Xbp". thus XbpActiveXControl() => HbActiveXControl(). Source file naming may also follow a standard rule. I need your opinions on the topic before I start writing something. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/Higher-Level-Classes-to-Manage-Consoles-tp20315173 p20315173.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 _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
