> Mindaugas Kavaliauskas wrote: > >> USHORT uiField = hb_parni( 1 ); >> ULONG ulBlock, ulSize, ulType; >> BOOL bDeleted; > > Viktor will kill you if he sees these :)
It won't compile, so such harsh action is not necessary ;) But yes, you are right, and I forgot to send a specific message about that: From now on, only new Harbour types should be used in any new code committed to Harbour SVN, the only exception is for OS/3rd party package API specific code, this is typically Windows or OS/2 parts. Anyhow even in this case developers should pay attention to use Harbour types when appropriate, here it's easier to miss since compiler won't report an error. There is still an undecided area about new types, namely HB_UCHAR vs. HB_BYTE issue (both can be used now, and they are equivalent), but otherwise current state can be considered stable. I recommend following the same rules for 3rd party developers, new types can be added for pre-2.1 Harbour and xhb builds also. They can test code by using -DHB_LEGACY_TYPES_OFF macro. This will be the default mode after next major release, so it's good to start the preparation. Here a little help to make the conversion: HB_ULONG -> HB_MAXUINT HB_LONG -> HB_MAXINT BOOL -> HB_BOOL TRUE -> HB_TRUE FALSE -> HB_FALSE BYTE -> HB_BYTE ULONG -> HB_ULONG LONG -> HB_LONG UINT -> HB_UINT SHORT -> HB_SHORT USHORT -> HB_USHORT LONGLONG -> HB_LONGLONG ULONGLONG -> HB_ULONGLONG INT16 -> HB_I16 UINT16 -> HB_U16 INT32 -> HB_I32 UINT32 -> HB_U32 INT64 -> HB_I64 UINT64 -> HB_U64 SCHAR -> HB_SCHAR UCHAR -> HB_UCHAR We use HB_SIZE for every variable denoting string/array length or position, so it's recommended to use it in such places, instead of ULONG, and to use temporary signed size type HB_ISIZ instead of LONG/long/int. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
