I also opt for clean code. If compatibility is such concern we should find some optional compatibility layer. Maybe cleaner OLE implementation will result in more robust app/3rd party lib code, too, which is always a good thing.
Brgds, Viktor On Wed, Apr 8, 2009 at 4:29 PM, Mindaugas Kavaliauskas <dbto...@dbtopas.lt>wrote: > Hello, Pritpul, > > > The simplicity was the main goal, after I found original OLE is not >>> working (it was xHarbour times) and I was unable to understand some >>> implementation ideas. >>> >>> >> If you are looking at it, please make it syntactically compliant with >> hbwin/win_ole.c parameters, i.e., TOleAuto() class with <hObj> <oObj>. >> Then it attains staus of replacing the hbwin->ole implementation. >> > > I've chosen HB_OLEAUTO to be consistent with Harbour convention, I can > easily change it, but "TOleAuto" breaks this rule. > > I'm against :hObj, because: > 1) it does not allow to use any OLE classes having Hobj method; > 2) it is internals of object, that's why we have __hObj (two underscores). > You should not use it at all. > > > Regards, > Mindaugas > > > _______________________________________________ > 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
