>> Just had time to read this bit, well, I couldn't have
>> said it better. Probably many other improvements could
>> be made on that driver. F.e. for me thos HB_ADORDD*()
>> functions look a little strange in an RDD. They're
>> needed to setup connection, and connection is stored
>> in thread
On Tue, 01 Dec 2009, Szak�ts Viktor wrote:
Hi,
> > Of course this RDD should be greatly improved yet and some
> > missing functionality added. Also if someone has time then
> > function like SQLTranslate() should be rewritten from scratch
> > to be real xbase to SQL expressions translator. Not a
On Tue, 01 Dec 2009, J. Lefebvre wrote:
Hi,
> You could be right, but ...
> 1) This code is not really new, and I had in mind it was working when I
> tested it some month ago (99% sure) ...
> 2) The same call in visual Basic work fine on the same OLE object ...
> I will continue to investigate,
>> I see no point in moving it back to contrib until someone
>> takes a plunge into this and known problems get fixed.
>
> So far I haven't seen any confirmed error in ADORDD code
> so I have no idea what we can fix.
>
> Of course this RDD should be greatly improved yet and some
> missing functi
> On Tue, 01 Dec 2009, Szak�ts Viktor wrote:
>> 2008-09-12 00:53 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
>> * contrib/rddado/adordd.prg
>> * contrib/rddado/adordd.ch
>>* Merged changes from xhb.
>> Some hbusrrdd.ch values seem to be missing from Harbour,
>> related features w
On Tue, 01 Dec 2009, Szak�ts Viktor wrote:
> 2008-09-12 00:53 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * contrib/rddado/adordd.prg
> * contrib/rddado/adordd.ch
> * Merged changes from xhb.
> Some hbusrrdd.ch values seem to be missing from Harbour,
> related features will
On Tue, 01 Dec 2009, Alex Strickland wrote:
> >Alex can you try to add at the beginning of rddado/tests/access2.prg:
> >FIELD FIRST
> >and change the line 33 from:
> >locate for TEST2->First = "Lara"
> >to:
> >locate for First = "Lara"
> >and then repeat the test?
> Yes, this works and
>> Thank you. So there still seem to be some things broken
>> after whichever update, my suspect is still the xhb sync job.
>
> Looking at the ChangeLog and SVN repository I haven't found even
> single xhb sync commit.
2008-09-12 00:53 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
* contrib/r
Przemysław Czerpak wrote:
Alex can you try to add at the beginning of rddado/tests/access2.prg:
FIELD FIRST
and change the line 33 from:
locate for TEST2->First = "Lara"
to:
locate for First = "Lara"
and then repeat the test?
Yes, this works and writes .T. to the console.
Regards
A
On Tue, 01 Dec 2009, Szak�ts Viktor wrote:
Hi,
> > USE test.mdb VIA "ADORDD" TABLE "Tabla1"
> > with:
> > USE xbrtest.mdb VIA "ADORDD" TABLE "Customer"
> > it works. Perhaps test.mdb is broken?
> Could be. Or it simply doesn't find it. But your
> next example suggest that it's the former.
>
J. Lefebvre wrote:
I will continue to investigate,
Perhaps this may help:
http://www.microsoft.com/downloads/details.aspx?familyid=5233b70d-d9b2-4cb5-aeb6-45664be858b6&displaylang=en#QuickInfoContainer
it is OleView.exe which is quite useful for seeing what is behind the scenes.
Regards
Ale
igine-
De : harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] De la part de Przemyslaw Czerpak
Envoyé : mardi 1 décembre 2009 15:10
À : Harbour Project Main Developer List.
Objet : Re: RE: [Harbour] Problem in OLE implementation
On Tue, 01 Dec 2009, J. Lefebvre
>-Original Message-
>From: Alex Strickland [mailto:s...@mweb.co.za]
>Sent: Tuesday, December 01, 2009 1:22 PM
>To: Harbour Project Main Developer List.
>Subject: Re: [Harbour] Problem in OLE implementation
...
>REQUEST ADORDD
>
>function Main()
>
>
>> Error OLE/3012 Argument error: OPEN (DOS Error -2147352567)
>> Called from WIN_OLEAUTO:OPEN(0)
>> Called from ADO_OPEN(312)
>> Called from DBUSEAREA(0)
>> Called from MAIN(12)
>
> It would be nice to have some idea about how error subcode sould be used.
> 3012 does not say much about the exac
Hi,
Error OLE/3012 Argument error: OPEN (DOS Error -2147352567)
Called from WIN_OLEAUTO:OPEN(0)
Called from ADO_OPEN(312)
Called from DBUSEAREA(0)
Called from MAIN(12)
It would be nice to have some idea about how error subcode sould be
used. 3012 does not say much about the exact place of e
On Tue, 01 Dec 2009, J. Lefebvre wrote:
Hi,
> Hu, not sure it is really related to a problem with ADORDD (see dos
> error).
> I have exactly the same error trying to access Crystal report runtime XI.
>Error occurred at: 01/12/2009, 14:26:32
>Error description: (DOS Error -2147352567)
Envoyé : mardi 1 décembre 2009 14:19
À : Harbour Project Main Developer List.
Objet : Re: [Harbour] Problem in OLE implementation
Hi Alex,
> USE test.mdb VIA "ADORDD" TABLE "Tabla1"
>
> with:
>
> USE xbrtest.mdb VIA "ADORDD" TABLE "Customer
Hi Alex,
> USE test.mdb VIA "ADORDD" TABLE "Tabla1"
>
> with:
>
> USE xbrtest.mdb VIA "ADORDD" TABLE "Customer"
>
> it works. Perhaps test.mdb is broken?
Could be. Or it simply doesn't find it. But your
next example suggest that it's the former.
BTW: "broken", I've fixed this file at lea
Viktor Szakáts wrote:
Can you try with the copy in 'examples/rddado' and tests
under 'tests'.
OK, got them. access1.prg fails with :
Error OLE/3012 Argument error: OPEN (DOS Error -2147352567)
Called from WIN_OLEAUTO:OPEN(0)
If I replace this line:
USE test.mdb VIA "ADORDD" TABLE "Tabla
>> BTW I'm still waiting for verification of reported RDDADO problems
>> with current HBWIN OLE code. Can some MS-Windows users check it?
>
> It is not in current SVN, I copied adordd.prg, and adordd.ch and
> tests\access1.prg from an old backup:
>
> * $Id: adordd.prg 10183 2009-02-05 09:21:52Z
Przemysław Czerpak wrote:
BTW I'm still waiting for verification of reported RDDADO problems
with current HBWIN OLE code. Can some MS-Windows users check it?
It is not in current SVN, I copied adordd.prg, and adordd.ch and
tests\access1.prg from an old backup:
* $Id: adordd.prg 10183 2009-
Hi,
Przemysław Czerpak wrote:
I'm not very familiar with OLE code so maybe I'm wrong but I do not see
any reason why it has to be the same pointer. I can imagine implementation
which will use different pointers so I would like to keep the code clean
and if I called punkVal->QueryInterface() ext
On Mon, 30 Nov 2009, Mindaugas Kavaliauskas wrote:
Hi,
> Yes, perhaps type should be unsigned int. HRESULT is a "general"
> return value, since MS uses type casting anythere.
OK, I'll update it.
> >2009-11-28 13:27 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> > * harbour/contrib/hbwi
Hi,
Hi,
Przemysław Czerpak wrote:
BTW in MS documentation dimensions are stored in 'unsigned int' instead
of 'int'. Maybe we should follow it?
So, it's long, not unsigned int. But the most strange thing is that
SafeArrayGetDim return HRESULT. Sounds like a handler, and this
stopped me from be
On Sat, 28 Nov 2009, Szak�ts Viktor wrote:
Hi,
> >> documented RTE which can substitute result so it can be easy
> >> caught by user and if necessary he can set his own preferable
> >> value for such unknown OLE variant.
> >> What it group opinion here?
> > +1 to Nil (if I have a voice)
> I als
On Sat, 28 Nov 2009, Pritpal Bedi wrote:
Hi,
> > BTW I have question about code in axcore.c.
> > In function __AXDOVERB() we have call to QueryInterface() but without
> > call to Release(). Shouldn't we add at axcore.c[213]:
> > HB_VTBL( lpOleObject )->Release( HB_THIS( lpOleObject ) );
> >
Hi
Przemysław Czerpak wrote:
>
> BTW I have question about code in axcore.c.
> In function __AXDOVERB() we have call to QueryInterface() but without
> call to Release(). Shouldn't we add at axcore.c[213]:
>
> HB_VTBL( lpOleObject )->Release( HB_THIS( lpOleObject ) );
>
> ???
>
Yes, go
On Fri, 27 Nov 2009, Mindaugas Kavaliauskas wrote:
Hi,
> >BTW in MS documentation dimensions are stored in 'unsigned int' instead
> >of 'int'. Maybe we should follow it?
> MSDN writes:
>HRESULT SafeArrayGetDim( SAFEARRAY FAR* psa );
> BCC wtypes.h has:
> #ifndef _HRESULT_DEFINED
> #define _HR
>> Hi,
> [...]
>> documented RTE which can substitute result so it can be easy
>> caught by user and if necessary he can set his own preferable
>> value for such unknown OLE variant.
>> What it group opinion here?
>
> +1 to Nil (if I have a voice)
I also prefer NIL (or some other distinctive er
>-Original Message-
>From: Przemysław Czerpak [mailto:dru...@acn.waw.pl]
>Sent: Friday, November 27, 2009 6:54 PM
>To: Harbour Project Main Developer List.
>Subject: Re: [Harbour] Problem in OLE implementation
>
>On Fri, 27 Nov 2009, Alex Strickland wrote:
>
&g
On Fri, 27 Nov 2009, Alex Strickland wrote:
Hi,
> I have an OLE dll that I am trying to use. I think it returns a
> safearray of IUnknown.
> To understand a bit better I put the following 3 debug lines in olecore.c:
> void hb_oleVariantToItem( PHB_ITEM pItem, VARIANT* pVariant )
> {
> char debug[
On Fri, 27 Nov 2009, Alex Strickland wrote:
Hi,
> Enrico Maria Giordano wrote:
> >Works fine now, thank you all.
> I tested it as well, and it works great.
It's also possible that this modification resolved some of ADO RDD
problems. Users interested in this RDD should repeat their tests.
best r
On Fri, 27 Nov 2009, Alex Strickland wrote:
Hi,
> It may be better to replace the lines at the end of hb_oleVariantToItem
> default:
> hb_itemClear( pItem );
> with a run time error?
It should be real OLE users decision. Do you prefer RT error when unknown
OLE item is received or
Alex Strickland wrote:
Is it possible to add support for this?
It may be better to replace the lines at the end of hb_oleVariantToItem
default:
hb_itemClear( pItem );
with a run time error?
Regards
Alex
___
Harbour mailing list (at
Enrico Maria Giordano wrote:
Works fine now, thank you all.
I tested it as well, and it works great.
Regards
Alex
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/h
Hi Mindaugas, Przemyslaw
I have an OLE dll that I am trying to use. I think it returns a safearray of
IUnknown.
To understand a bit better I put the following 3 debug lines in olecore.c:
void hb_oleVariantToItem( PHB_ITEM pItem, VARIANT* pVariant )
{
char debug[ 100 ];
if( pVariant->n1.n2
-Messaggio Originale-
Da: "Przemysław Czerpak"
A: "Harbour Project Main Developer List."
Data invio: venerdì 27 novembre 2009 3.57
Oggetto: Re: [Harbour] Problem in OLE implementation
Hi,
I've just check that there is also bad typo which causes that it
Hi,
Przemysław Czerpak wrote:
Yes it's really nice though it probably can be even simpler without
recursion.
This code allocates memory for index array using hb_xgrab() and needs
recursion only for allocating dynamically lFrom and lTo on C stack.
It means that it should be enough to allocate me
On Fri, 27 Nov 2009, Mindaugas Kavaliauskas wrote:
Hi,
> I've also looked at SafeArrayToArray() function from xHarbour
> win32ole.prg, but after 10 seconds I've understood it's better not
> to look at this, because I can start to replicate it. So, that's the
> reason why hb_oleSafeArrayToItem() i
Hi,
But we have new one. Looks that
VariantInit( &vItem );
at line 517 is missing.
I know, but you are faster this time :)
Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour
Hi,
Przemysław Czerpak wrote:
yes, good job. Again thank you very much.
I've also looked at SafeArrayToArray() function from xHarbour
win32ole.prg, but after 10 seconds I've understood it's better not to
look at this, because I can start to replicate it. So, that's the reason
why hb_oleSaf
On Fri, 27 Nov 2009, Przemysław Czerpak wrote:
Hi
> > I found two:
> > if( lFrom >= lTo ) // cause hb_itemClear() fall through
> > and
> > hb_arrayGetItemPtr( pItem, ul++ ) (or ul = 0;) // GPF
> I haven't seen the second one.
> > I've not replicated it.
> yes, good job. Again thank you very
On Fri, 27 Nov 2009, Mindaugas Kavaliauskas wrote:
Hi,
> >I've just check that there is also bad typo which causes that it does
> >not convert even one dimensional VT_ARRAYS to Harbour items.
> >I'll commit fix in a while so if this code needs only one dimensional
> >arrays the it may be enough.
On Fri, 27 Nov 2009, Przemysław Czerpak wrote:
> I've just check that there is also bad typo which causes that it does
> not convert even one dimensional VT_ARRAYS to Harbour items.
> I'll commit fix in a while so if this code needs only one dimensional
> arrays the it may be enough.
> Please test.
Hi,
Przemysław Czerpak wrote:
I've just check that there is also bad typo which causes that it does
not convert even one dimensional VT_ARRAYS to Harbour items.
I'll commit fix in a while so if this code needs only one dimensional
arrays the it may be enough.
Please test.
I found two:
if( l
On Fri, 27 Nov 2009, Mindaugas Kavaliauskas wrote:
> Enrico Maria Giordano wrote:
> >In the following sample, GetRows() method returns NIL (correctly
> >returns an array using xHarbour):
> Current Harbour OLE implementation supports only one dimensional
> array. I'll try to add support for multidim
Enrico Maria Giordano wrote:
In the following sample, GetRows() method returns NIL (correctly returns
an array using xHarbour):
Hi,
Current Harbour OLE implementation supports only one dimensional array.
I'll try to add support for multidimensional array in spare time.
Regards,
Mindaugas
_
Hi,
Enrico Maria Giordano wrote:
In the following sample, GetRows() method returns NIL (correctly returns
an array using xHarbour):
Can you provide some file to be tested using the following sample? In my
case sample does not work because e:\fwharbour\samples\xbrtest.mdb does
not exist.
48 matches
Mail list logo
