Hello Now we have one more slot in Hb_GtInfo() so back to this point again
<<< > HB_GTI_GETWINDOWHANDLE > HB_GTI_NEWWINDOW Can we use the existing names HB_GTI_???WIN? >>> We can if group agrees. But because these constants are returning values specially HB_GTI_GETWIN, I think these are not the placeholders for what I was proposing. >hb_gtInfo( HB_GTI_SPECFEATURE, <HB_GTI_WVT_EXTRAFEATURE>[, xNewValue ] ) -> <xOldValue> Me too vote for this construct. <<< But the fundamental problem with both is that we're again introducing a way to make the GTs behave differently. So it kind of ruins the concept. If we already have such stuff in common GT, maybe it'd be better to switch them to the above method, but I feel this would just give way for lots of GT specific features, so overall I think it creates more problems. BTW, the third method, and the one used for RDDs too, is to simply use hb_gt_wvt_<extrafeature>() kind of calls. This has the downside that app code needs to use #defines to exclude such call if the GT is not linked (just like for RDDs). The conceptual problem remains here too though. >>> This fundamental problem cannot be overcome completely ever. We alao analyze the it from another perspective too. Each GT has some proprietory features which other GT may/may not have. You write the application under one GT and suddenly you realize that my another customer has changed his references. If you try to update to his wishes you suddenly find yourself short of slots to hook required functionality. As a programmer, I am always aware I am writing what. If I issue a GTI instruction I always know what its ittent is. If I write only for terminal, I know I have to avoid GUI messages. But still if I do so, chances are that GT will not do anything if the GTI command does not belong to it. But certainly it will avoid rewiting of new code o hooking to a separate library and using #ifdefs. Having said that I propose these constants: HB_GTI_MESSAGE HB_GTM_HWND HB_GTM_SHOWWND HB_GTM_CREATEWND HB_GTM_CLOSEWND HB_GTM_SELECTWND HB_GTM_CENTERWND HB_GTM_PROCESSMSG HB_GTM_INVALIDATE HB_GTM_SETTIMER HB_GTM_KILLTIMER HB_GTM_KEYBOARD HB_GTM_MAXIMIZE HB_GTM_MINIMIZE HB_GTM_SETONTOP HB_GTM_SETASNORMAL HB_GTM_MOUSEPOS HB_GTM_USER These are some specific messages a window can manipulate and these are generic ones. Every GT cn take use of it in some form or the other. Particular GT specific messages will start at HB_GTM_USER + nMessage. For example: Hb_GtInfo( HB_GTI_MESSAGE, HB_GTM_SHOWWND, SW_HIDE ) Opinions, suggestions, restrictions, etc. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/GT--Multi-platform-Messaging-Interface-tp17789933p17809551.html Sent from the Harbour - Dev mailing list archive at Nabble.com. _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
