On Fri, 24 Apr 2009, Mindaugas Kavaliauskas wrote:
Hi,
>> 2009-04-24 23:15 UTC+0300 Mindaugas Kavaliauskas (dbtopas/at/dbtopas.lt)
>> * harbour/contrib/hbole/olecore.c
>> * harbour/contrib/hbole/oleauto.prg
>> + implemented FOR EACH enumeration. The code was proposed by
>> Przemyslaw on mailing list. Some fixes applied.
> I've put some hands on OLE again - added FOR EACH enumeration support.
> Though, OLE does not support backward iteration. 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.
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.
> I've tried to run contrib/hbole/tests/testole.prg code and work a little
> for missing features. One of the first is array access operator.
> It can easy be implemented by adding:
> ...
> METHOD __Index( nIndex ) OPERATOR "[]"
> ENDCLASS
> METHOD __Index( nIndex ) CLASS HB_OLEAUTO
> RETURN ::Item( nIndex )
> The feature is available in current code also, i.e. I can write:
> oWorkbook:WorkSheets:Item(1)
> Of cause
> oWorkbook:WorkSheets[1]
> looks more friendly, but don't we invent something new in OLE world. I've
> tried to write a simple .vbs script. Visual basic does not accept
> oWorkbook:WorkSheets[1]
> It does accept:
> oWorkbook:WorkSheets(1)
> 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.
> Ok, I can add the 3 lines and make a support for array access operation.
> If you'll look to win_tole.prg, you'll see that implementation is more
> complex than 3 lines proposed by me, it tries to handle array assign. It
> tries to do it in two ways: using :_Item(), and using :SetItem(). If you
> look to ICollection documentation you'll not find any of these collection
> item assignment ways documented. ICollection supports Item(), AddAt(),
> AddItem() methods, but no SetItem(). This is why, I do not want to
> implement these array assignment syntax. But do we need array access
> syntax? How does it work on OLE automation object in other languages?
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.
If no one suggests something then IMO you should chose what you are
finding the best and the cleanest solution. I trust your decisions.
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
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.
But here I also can be wrong and it's possible that in real OLE world
it's not necessary to introduce such functionality so I'm leaving the
decision for you.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
