OK. Is more cleaner. An another issue is I think is in hbtrace.c with the following line:
MultiByteToWideChar( CP_ACP, 0, hb_strncpy( message, buf.psz, sizeof( message ) - 1 ), -1, buf.lp, HB_SIZEOFARRAY( buf.lp ) ); The strncpy( message, buf.psz, sizeof( message ) - 1 ) can lead into a recursive HB_TRACE call, as it happened in one of my test case. Best regards, István -----Original Message----- From: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] On Behalf Of Przemyslaw Czerpak Sent: 2010. január 4. 18:09 To: Harbour Project Main Developer List. Subject: Re: RE: RE: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour On Mon, 04 Jan 2010, Bisz István wrote: > OK. Maybe I was too happy to see this message, sorry. Ups. I've just seen that it was not always shown but only when //INFO were used so it's fine for me. I only suggest to replace: hb_snprintf( buffer, sizeof( buffer ), HB_I_("Memory allocated but not released: none") ); hb_conOutErr( buffer, 0 ); with simple: hb_conOutErr( HB_I_("Memory allocated but not released: none"), 0 ); best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour