| Ambos lados, revisión anteriorRevisión previaPróxima revisión | Revisión previa |
| en:migrar.de.xharbour.a.harbour [2012/10/12 11:08] – jfgimenez | en:migrar.de.xharbour.a.harbour [2022/02/07 17:03] (actual) – editor externo 127.0.0.1 |
|---|
| |
| * You can not use any object member as indexes on loops ''FOR / NEXT''. This means, that code like this:<code> | * You can not use any object member as indexes on loops ''FOR / NEXT''. This means, that code like this:<code> |
| FOR ::nCounterr := 1 TO 100 | FOR ::nCounter := 1 TO 100 |
| ...</code>should be modified by something like this:<code> | ...</code>should be modified by something like this:<code> |
| FOR n := 1 TO 100 | FOR n := 1 TO 100 |
| ::nCounter := n | ::nCounter := n |
| ...</code>Detected by the compiler. | ...</code>Detected by the compiler. |
| | <note>UPDATE: This was fixed later in Harbour, and only applies to Xailer 2.7. Newer versions are free of this lack.</note> |
| |
| |
| * You can not use array indexed on string types. You must use the ''Substr()'' function to extract individual characters. This extension was made on xHarbour long time ago, although it brought some problems (run-time errors difficult to detect), it had greatest advantages on some cases. However, this was never implemented in Harbour. For example:<code> | * You cannot use array indexed on string types. You must use the ''Substr()'' function to extract individual characters. This extension was made on xHarbour long time ago, although it brought some problems (run-time errors difficult to detect), it had greatest advantages on some cases. However, this was never implemented in Harbour. For example:<code> |
| nTotal := 0 | nTotal := 0 |
| FOR n := 1 TO Len( cString ) | FOR n := 1 TO Len( cString ) |
| FOR n := 1 TO Len( cString ) | FOR n := 1 TO Len( cString ) |
| nTotal += Asc( Substr( cString, n, 1 ) ) | nTotal += Asc( Substr( cString, n, 1 ) ) |
| NEXT</code>Although this construction is also possible:<code> | NEXT</code>Although this other construction is also possible:<code> |
| nSuma := 0 | nTotal := 0 |
| FOR EACH cChar IN @cString | FOR EACH cChar IN @cString |
| nTotal += Asc( cChar ) | nTotal += Asc( cChar ) |
| cChar := Upper( cChar ) | cChar := Upper( cChar ) |
| NEXT</code>Not detected at compile-time, but yes at run-time. | NEXT</code>Not detected at compile-time, but at run-time. |
| |
| |
| |
| * Change ''At()'' with 3 parameters to ''hb_At()''. In xHarbour, the ''At()'' function admits a third parameter which indicates the first position to start the search. In Harbour, the ''At()'' function remains exactly the same as in //Clipper//, with two parameters and when you need the third parameter you must use the ''hb_At()'' function. Detected by the compiler. | * Change ''At()'' with 3 parameters to ''hb_At()''. In xHarbour, the ''At()'' function allows a third parameter which indicates the first position to start the search. In Harbour, the ''At()'' function remains exactly the same as in //Clipper//, with two parameters, and when you need the third parameter you must use the ''hb_At()'' function. Detected by the compiler. |
| |
| |
| * The ''Trim()'' function does not admit the third parameter to indicate extra characters to delete like ''TAB'', ''CR'' and ''LF'' from the end of the string. We have added the ''XA_Trim()'' function to overcome this lack. Detected by the compiler. | * The ''Trim()'' function does not allow the third parameter to indicate extra characters to delete like ''TAB'', ''CR'' and ''LF'' from the end of the string. We have added the ''XA_Trim()'' function to overcome this lack. Detected by the compiler. |
| |
| |
| * Change ''ADel()'' with 3 parameters for ''hb_ADel()''. On xHarbour, the ''ADel()'' function admits a third parameter to reduce the array size. Harbour ignores this third parameter and you should change to ''hb_ADel()'' or resize the array manually with the ''ASize()'' function. Not detected at compile-time nor at run-time but may clearly brake your code. | * Change ''ADel()'' with 3 parameters for ''hb_ADel()''. On xHarbour, the ''ADel()'' function allows a third parameter to reduce the array size. Harbour ignores this third parameter and you should change to ''hb_ADel()'' or resize the array manually with the ''ASize()'' function. Not detected at compile-time nor at run-time but may clearly break your code. |
| |
| |
| |
| * Change ''hb_SetCodePage()'' to ''hb_CdpSelect()''. Detected at linking time. | * Change ''hb_SetCodePage()'' to ''hb_CdpSelect()''. Detected at linking time. |
| | |
| | |
| | * Change ''Super:'' into ''::Super:''. In xHarbour and Xailer 2.7's Harbour release, ''Super:'' is used to access parent class members from a child class. Later, this //reserved word// was removed, and now it has to be used ''::Super'' to access parent class members. |
| |
| |
| |
| |
| * Change ''HB_EnumIndex()'' with ''<obj>:%%__%%enumIndex()''. Inn xHarbour the function ''HB_EnumIndex()'' returns the current active index on a ''FOR EACH / NEXT'' loop. In Harbour there is no such function, to retrieve the same index loop value you can call the method ''%%__%%enumIndex()'' over the variable that stores the current loop value. For example:<code> | * Change ''HB_EnumIndex()'' with ''<obj>:%%__%%enumIndex()''. In xHarbour the function ''HB_EnumIndex()'' returns the current active index on a ''FOR EACH / NEXT'' loop. In Harbour there is no such function. To retrieve the same index loop value you may call the method ''%%__%%enumIndex()'' over the variable that stores the current loop value. For example:<code> |
| FOR EACH oControl IN ::aControls | FOR EACH oControl IN ::aControls |
| LogDebug( oControl:__enumIndex() ) | LogDebug( oControl:__enumIndex() ) |
| |
| |
| * When creating objects with only its class function name, the parameters you may give will not be sent to its ''New()'' constructor method. In xHarbour. For example:<code> | * When creating objects with only its class function name, the parameters you may give will not be sent to its ''New()'' constructor method. In xHarbour, any parameter passed to the class function, was passed to its ''New()'' method. For example:<code> |
| ::oBtn := TButton( Self )</code>this was equivalent to:<code> | ::oBtn := TButton( Self )</code>was equivalent to:<code> |
| ::oBtn := TButton():New( Self )</code>But not in Harbour. You must call the object method ''New()''. In the case of Xailer object is specially important because or first (and normally only) parameter of the ''New()'' constructor is ''oParent'', that could become ''Nil'' provoking important errors and in some cases difficult to find. Not detected at compile-time, nor at run-time. | ::oBtn := TButton():New( Self )</code>But not in Harbour. You must call the object method ''New()''. In the case of Xailer objects, it's specially important because or first (and normally only) parameter of the ''New()'' constructor is ''oParent'', that could become ''Nil'' causing important errors and in some cases difficult to find. Not detected at compile-time, nor at run-time. |
| | |
| | * The scope validation of class members is more strict and correct than xHarbour. xHarbour took for good some scopes incorrectly, while Harbour does it well, and leads to surface errors that had not occurred. F.e. if you try to access from ''TForm'' to a ''PROTECTED'' control's property, xHarbour erroneously permitted it because ''TForm'' is also inherited from ''TControl''. But really, that property belongs to another object, the control (although it's in the same hierarchy), and not to the form, and therefore should be a mistake. This is the biggest difference to fix. It is not detected at compile-time and although some run-time errors arise, not always it depends on the conditions. For example the same ''PROTECTED'' member of a class maybe accessed from a method of a child class but only if this member belongs to the same object that makes the call. In the practice, when working with ''PROTECTED'' methods, expression like ''::Property'' or ''Self:Property'' are normally correct, but expressions like ''Object:Property'' are not. |
| |
| * The scope validation of class members is more strict and correct than xHarbour. xHarbour took for good some scopes incorrectly, while Harbour does it well, and leads to surface errors that had not occurred. Eg If from ''TForm'' you try to access a ''PROTECTED'' control property, xHarbour erroneously permitted because it was deriving from ''TForm''but also from ''TControl'' which has the permissions. But really, that property belongs to another object (although is in the same hierarchy) and not to the form (belonging to the control) and therefore should be a mistake. This is the biggest difference to fix. It is not detected at compile-time and although some run-time errors arise, not always it depends on the conditions. For example the same ''PROTECTED'' member of a class maybe accessed from a method of a child class but only if this member belongs to the same object that makes the call. In the practice, when working with ''PROTECTED'' methods, expression like ''::Property'' or ''Self:Property'' are normally correct, but expressions like ''Object:Property'' are not. | * The ''PRIVATE'' scope works in a different manner in Harbour than xHarbour. On both cases, this scope means that the member can only be accessed from a method of its own class and not from outside of it or any child class. But in Harbour, if a ''PRIVATE'' method is overloaded, a new member is created with the same name, but in the rest, completely different from its parent class. This implies that when the parent class private member change its value, the child class member does not change, and the opposite. In all aspects the two members are completely different. This was not the behavior in xHarbour. A overloaded ''PRIVATE'' method there was only a member on the object with a unique value. |
| |
| |
| * The ''PRIVATE'' scope works in a different manner in Harbour than xHarbour. On both cases, this scope meas that the member can only be accessed from a method of its own class and not from outside of it or any child class. But in Harbour the ''PRIVATE'' method is overloaded, a new member is created with the same name, but in the rest, completely different from its parent class. This implies that when the parent class private member change its value, the child class member does not change, and the opposite. In all aspects the two members are completely different. This was not the behavior in xHarbour. A overloaded ''PRIVATE'' method there was only a member on the object with a unique value. | * The ''ErrorNew()'' function that creates an ''Error'' object in xHarbour supports many parameters to indicate the type of error: ''cSubsystem'', ''nGenCode'', ''cOperation'', ''cDescription'', ''aArgs'', ''ModuleName'', ''cProcName'' and ''nProcLine''. However in Harbour as in CA-Clipper it does not receive such parameters. Therefore, in Harbour the ''Error'' object created by ''ErrorNew()'' will be created meaningless. The simplest way to fix this is to create a ''MyErrorNew()'' function to get the parameters used on xHarbour and that function will create the error object and set the value of its members. Not detected at compile-time nor at run-time but produces useless error objects. |
| |
| |
| ===== At the C level ===== | ===== At the C level ===== |
| |
| * ''hb_par???()'' and ''hb_stor???()'' do not admit the extra parameter to be used for array handling. When used with arrays you must change them with the functions ''hb_parv???()'' and ''hb_storv???()''. Detected at compile time. | * ''hb_par???()'' and ''hb_stor???()'' do not allow the extra parameter to be used for array handling. When used with arrays you must change them with the functions ''hb_parv???()'' and ''hb_storv???()''. Detected at compile time. |
| |
| |
| |
| |
| * ''hb_parl()'' returns ''FALSE'' if the parameter is not of type //logig// (p.ej. //numeric//). In xHarbour returned ''TRUE'' if the parameter was numeric and different of 0. This can arise logical errors. Not detected at compile time, since internally C treats the ''BOOL'' type as ''INT'', neither generates run-time errors, therefore is really difficult to detect. | * ''hb_parl()'' returns ''FALSE'' if the parameter is not of type //logical// (p.ej. //numeric//). In xHarbour returned ''TRUE'' if the parameter was numeric and different of 0. This can arise logical errors. Not detected at compile time, and since internally C treats the ''BOOL'' type as ''INT'', neither generates run-time errors, therefore is really difficult to detect. |
| |
| |
| |
| |
| * ''hb_retclenAdopt()'' does not exist, must be changed to ''hb_retclen_buffer()''. But notice that ''hb_retclen_buffer()'' adds an extra ''chr(0)'' to the end of the buffer, so the buffer have to be one byte larger than what it's really needed. Detected at compile time. | * ''hb_retclenAdopt()'' and ''hb_retclenAdoptRaw()'' do not exist, and must be changed to ''hb_retclen_buffer()''. But notice that ''hb_retclen_buffer()'' adds an extra ''chr(0)'' to the end of the buffer, so the buffer have to be one byte larger than what it's really needed. Detected at compile time. |
| |
| |
| * You can not directly use a ''HB_ITEM'' structure. You must always use its pointer of typeo ''PHB_ITEM'' and create the //item// using ''hb_itemNew( NULL )''. Detected at compile time. | * You can not directly use a ''HB_ITEM'' structure. You must always use its pointer of type ''PHB_ITEM'' and create the //item// using ''hb_itemNew( NULL )''. Detected at compile time. |
| |
| |
| ===== Inside Xailer ===== | ===== Inside Xailer ===== |
| |
| * You must use the Harbour distro provided by Xailer Harbour due to a necessary modification in the //classes.c// module in order to perform our OOP extensions. The modification consists in the addition of only two small features in the end of the module. | * You must use the Harbour //distro// provided by Xailer Harbour due to a necessary modification in the //classes.c// module in order to perform our OOP extensions. The modification consists in the addition of only two small functions at the end of the module. |
| | <note>UPDATE: This only applies to Xailer 2.7. Since Xailer 3.0 it's no longer needed, and any Harbour's //nightly-build// may be used for Xailer. However, Xailer will only support our //official// Harbour's //distro// which is available from the Xailer's download area.</note> |
| |
| |
| * Now, the events are stored in an internal ''DATA'' with ''PROTECTED'' scope with the same name of the event but with an //F// before, as we always did with property real values. The actual content of this the ''DATA'' can not be used or assigned in any way, as it represents memory pointers, and handling only can cause GPFs. For practical purposes, the only thing that affects is to be avoided naming any member of a class with the same name as an event with an F before. | * Now, the events are stored in an internal ''DATA'' with ''PROTECTED'' scope with the same name of the event but with an //F// before, as we always did with property real values. The actual content of this new ''DATA'' can not be used or assigned in any way, as it represents memory pointers, and handling it only can cause GPFs. For practical purposes, the only thing that affects is to be avoided naming any member of a class with the same name as an event with an F before. |
| |
| |
| PROPERTY aForms AS TForm[]</code> | PROPERTY aForms AS TForm[]</code> |
| |
| * In order to avoid problems with ''PRIVATE'' scope , all of them are changed to ''PROTECTED''. | * In order to avoid problems with ''PRIVATE'' scope, all of them have been changed to ''PROTECTED''. |
| |
| | * ''SetKey'' is a reserved word. We have changed the method name ''SetKey'' of ''THotkey'' for ''SetHotKey''. Not detected at compile time. May cause wrong application behavior. |
| |
| * ''SetKey'' is a reserved word. We have changed the method name ''SetKey'' of ''THotkey'' for ''SetHotKey''. Not detected at compile time. May provoke wrong application behavior. | * If you use the **MinGW** compiler, be aware that library and compiled modules syntax is completely different from Borland C. Libraries must have the extension "**.a**" but also they should be prefixed with the letters "**lib**". The extension for the compiled modules is "**.o**" instead of "**.obj**". |
| |
