[Harbour] SF.net SVN: harbour-project:[10930] trunk/harbour

[Mindaugas Kavaliauskas]

Hi,


Przemyslaw Czerpak wrote:
>> Should we ignore backward 
>> (descending) iteration flag and do forward iteration, should we do not 
>> iterate at all (current behavior), or should we give runtime error (which 
>> one?)?
> 
> Thank you very much.
> Probably RTE will be better - easier to detect potential problem by
> programmer.

RTE added.

> If you ask about RTE code then it's a problem. IMHO we should start
> to define all RTEs as #define constant and use separate error codes
> for different functions/RTEs just like in Clipper.
> It means that the whole core code have to be updated.

Yes. I remember this question. Your letter about error codes:
   Date: Mon, 19 Jan 2009 18:01:14 +0100
   From: Przemyslaw Czerpak <druzus at acn.waw.pl>
   Subject: Re: [Harbour] Harbour SHA2 and SHA2-HMAC support
is on my "to answer" list, but I'm not used to Clipper error code 
numbers and do not have a strong opinion about it.

Using many different error code for the same general "argument error" 
seems a little meaningless. We are limited in error numbers also if we 
add more and more Harbour functions and each of it can have "argument 
error" error.
If error code gives more information, what is wrong: indicates parameter 
number, or information about expected parameter type, it would be 
useful, but (perhaps) it is not Clipper compatible and will need to 
enhance error detection code.

In writing of OLE code a had these problems related to error processing:
1) should I use BASE subsystem, or create OLE;
2) it would be nice to put OLE error value (in case of RTE) into error 
object. But OLE error codes is 32-bit side and does not fit into OS 
error code. So, additional ole error variable is required to set before 
any RTE call;
3) that error subcode should be used for errors.


>> but this work also in current hbole implementation. That is array access 
>> syntax in VB? Does it work for OLE collections?
> 
> Here I cannot help you. Sorry but I do not know OLE enough.
> As above. Please only remember that our old OLE code comes from xHarbour
> were overloading [] in assign operation was not working correctly in the
> past so the code may have some workarounds for it. I do not know if it's
> fixed in current xHarbour code.

The problem is that I'm not an OLE user also :) I've left the most 
simple and most clean implementation here. If we will have a strong 
argument to extend implementation, we can do it in the future. But I 
guess, current one is enough to reach all ICollection functionality.


> As I can see there are two things else which are missing and we should
> define if we want to implement them:
> 1. array support
> 2. passing parameters by reference

I've added the basic (simple, but perhaps not full) support for arrays. 
It is not clear from OLE documentation for me, if we need to add 
checking of array items type to by the same if we pass it as array of 
VARIANT. Multidimensional array is passed as array of array in current 
implementation. I'm not sure if this is valid. I'll try to fix/change 
these things if I have some real life code to test it.

Passing of params by references is not yet implemented. This remains to 
be the only one major missing feature, though, nobody yet passed any 
sample for this major feature :).


> We can also think about introducing yet another feature:
> Function which makes explicit conversion from Harbour item given by user
> to variant with type also explicitly specified by user. The result should
> be returned as GC pointer item and such pointer items should be detected
> and supported in OLE function calls. It should help when it's necessary
> to pass some strictly defined parameters, f.e.:

>    oOle:table( oleVariant( NIL, VT_EMPTY ), ;
>                oleVariant( NIL, VT_NULL ), ;
>                oleVariant( 123, VT_UI8 ) )
> Our default conversion methods does not allow to strictly control variant
> types.

Yes, it could be necessary if for example some ole object accepts VT_I2 
type, but do not accept VT_I4 and we pass our HB_IT_INTEGER data via 
VT_I4 type by default. I do not have a real life needs for such function 
yet.


Regards,
Mindaugas


P.S. To Francesco Saverio Giudice: I have your MS Outlook problem in 
mind, but I do not have computer with Outlook. I hope to be able to find 
computer and test/solve your problem soon.