Viktor <<<<< --- wapi_commctrl.c (now) #include <windows.h> #include <commctrl.h> #include "hbapi.h" #include "hbwapi.h" ---
Please don't explicitly #include <windows.h>, it's not necessary, as it's automatically pulled in by hbapi.h by #defining HB_OS_WIN_USED. This is the clean way (notice that commctrl.h is moved after Harbour headers, and windows.h got deleted): --- wapi_commctrl.c (corrected) #include "hbapi.h" #include "hbwapi.h" #include <commctrl.h> --- >>>>> OK. I was not sure about the sequence, so.. <<<< --- hbwapi.h (now) #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 ) ) --- This isn't ideal, we should use hb_retptr() otherwise the caller can easily mess up the values and cause various security holes, GPFs and other random behaviour. I'd suggest to change this right from the start, before introducing numeric dependent code in hbwin itself, too. With these pointers, .prg level code should only do equality check, call hb_IsPointer() and Empty() on these values. Everything else is to be avoided. --- hbwapi.h (corrected) #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 ) ) --- >>>> 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. 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. 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 ? <<< Even more ideally we should switch to hb_retptrGC() to avoid resource leaks due to .prg level programming errors, but this can be done later. >>> 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? Still thinking how can be lived with both worlds. 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. Opinions... Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/SF.net-SVN%3A-harbour-project%3A-10273--trunk-harbour-tp22017357p22017970.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
