Hi Pritpal,
> >>>> > > I agree your implementation is valid, but then it > holds good for new PRG code only. > > If we return pointers and in the next call we sent it back to > another function, then it has to be retried as wapi_par_POINTER()? > Or I am missing something. Yes, it should be retrieved using hb_parptr(). But, here on retrieval, we can be flexible, and also accept numeric: ( ISNUM( n ) ? ( HB_PTRDIFF ) hb_parnint( n ) : hb_parptr( n ) ) > If this is the case then I am afraid the wrappers I will be writing > will be usable in my applications or not. Most of the functions > designed in few years are adapted to numeric values only. > It also implies that I have to rewrite my souces again, which > is not at my priority list at present. Since we're developing a Harbour component here, and a new one, we should aim for best quality, not compatibility. I'd suggest to gradually clean your code and switch to hbwin then. > Yes off course for new developments it is the ideal situation. > So, if I cannot test my existing code, there is no motivation for > me to write wrappers. My existing libraries are serving my purpose > for sure. > Or if you have some other thoughts ? We already have several non-generic/duplicate/parallel implementations of winapis inside Harbour, so now we should aim for a good one, not yet another compromise. That was the goal we've discussed and agreed on last week. If we go the same route with the same mistakes as the previous implementations, I see no point to deal with this topic in such depth. Sorry to say that, but in Harbour we shouldn't use limitations because of your own local codebase. If we go this route we just unnecessarily limit ourselves, and we lose the freedom of doing it the way we've decided. To keep compatibility with your own code, we need to give up a lot of what we've discussed last week. Again, the point is to have one good quality Windows API wrapper collection which satisfies most users, and which can be used from .prg, safely and easily. If this cannot be done, we don't have to use any new naming, just carefully merge the currently spread WIN_ functions (from gtwvg, hbole, uhttpd) under hbwin library, that's all. Yes for sure, but it is not exactly the same with WINAPI. > For example: > Method One() > ::hBitmap := WAPI_LoadImage(...) > > Method Destroy() > WAPI_DeleteObject( ::hBitmap ) // How this will be handelled in GC? When creating a GC collected object, you also specify a destructor function which gets called when the object should be freed, so in this destructor function you call DeleteObject(), and you're done. In fact, you don't even need to use WAPI_DeleteObject() on the .prg level, as it's handled automatically. Please examine the code I've sent to you to the list a few weeks ago. (FFIND API, and maybe another one). I've also pointed you to hbcurl, or the new hbssl, where such method is used for several objects. Once you get the scheme, it's not at all complicated. > One thought comes to me: > > wapi_commctrl.c > > #if defined( HB_HANDLES_AS_POINTERS ) > #define wapi_ret_HANDLE( n ) ( hb_retptr( ( HB_PTRDIFF ) n ) ) > #define wapi_ret_HRESULT( hr ) ( hb_retptr( ( HB_PTRDIFF ) hr ) ) > #define wapi_ret_COLORREF( n ) ( hb_retptr( ( HB_PTRDIFF ) n ) ) > #else > #define wapi_ret_HANDLE( n ) ( hb_retnint( ( HB_PTRDIFF ) n ) ) > #define wapi_ret_HRESULT( hr ) ( hb_retnint( ( HB_PTRDIFF ) hr ) ) > #define wapi_ret_COLORREF( n ) ( hb_retnint( ( HB_PTRDIFF ) n ) ) > #endif > > Until one can switch to finer mode. Maybe if the default is hb_retptr() for Harbour. But even then the problem is that it will create confusion and incompatibility for .prg code. Should we then have hbwinptr.lib and hbwinnum.lib, too? :) It just makes things weird. It's generally not a good idea to do these kind hacks in the lib to please one specific application. Instead, if I were you, I'd create a new #define to cover type check (later easily switchable to hb_IsPointer()), plus start to switch to EMPTY() instead of '== 0'. Switching to EMPTY() is safe even if you use numerics. Also see this article, I've just read it today, and it's on topic: http://blogs.msdn.com/oldnewthing/archive/2009/02/13/9416485.aspx Brgds, Viktor
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
