Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Pass SAFEARRAY to COM server
Message
From
14/08/2006 11:52:18
 
 
To
09/08/2006 17:19:24
Gary Foster
Pointsource Consulting LLC
Chanhassen, Minnesota, United States
General information
Forum:
Visual FoxPro
Category:
COM/DCOM and OLE Automation
Miscellaneous
Thread ID:
01144211
Message ID:
01145340
Views:
18
I based that on the documentation for the component, and information from the object browser.

I know those dates look weird, but they are supposed to be integers formatted that way, rather than dates. I'm abloe to make the alternative method call work fine, which is the one that inserts individual records. I was hoping for the block transfer version to help speed things up in my program. The program converts one type of stock price data to another format, for use in a different analysis program. I can start finding a work-around for it. DIM AS does not seem to really have an effect.

>Hi,
>
>A few years ago, a co-worker created a C++ COM data type tester that reports what it received. We were trying(unsuccessfully) to get VFP6 to use safearrays. If I do the following with that DLL:
>
>DIMENSION aDate[100] as LONG
>aDate = 20060101
>x=CreateObject('MyDataDohicky.datatester')
>COMARRAY(x,10)
>x.Test(@aDate) && Reports that it gets VT_ARRAY of VT_I4 VT_BYREF
>
>DIMENSION aDate[100] as DATE
>aDate = DATE()
>x.Test(@aDate) && Reports that it gets VT_ARRAY of VT_DATE VT_BYREF
>
>BTW, only VFP 8 and later allow this, earlier versions could only send by value, not ref. Do you know for sure that the arrays need to be LONG, DOUBLE, etc.?
>
>Gary
>
>
>
>
>
>>I'm trying to pass arrays to a COM object, without success. My reading so far does not seem promising. The below is a test I set up that does not work. Use of @ makes no difference, use of COMARRAY() makes no difference. I don't get errors but nothing happens.
>>
>>The component documentation shows it wants SAFEARRAY's as parameters. I know that Fox does not do arrays internally the way C++ or VB do, and I imagine this is the source of the problem. I saw something about converting to string and passing that, but I didn't understand it well enough to try that. If someone can explain that, I'd be happy to work around it. These arrays are supposed to be doubles and longs.
>>
>>Thanks, sample code:
>>
>>
>>&& MlReader {14AE4119-AB4D-449D-B41A-6278EDEAFC84}
>>&& MlWriter {20315AFA-7C65-41BF-98F0-A16DAB307D7E}
>>oMetalib = createobjectex("{20315AFA-7C65-41BF-98F0-A16DAB307D7E}","","")
>>cFolder = [test]
>>cDir = ADDBS("c:\metastock\"+ALLTRIM(cFolder))
>>oMetalib.CreateDirectory(cDir)
>>oMetalib.AppendSecurity([MSFT],[Microsoft],1)
>>
>>DIMENSION idate[100] as long
>>DIMENSION itime[100] as long
>>DIMENSION iopen[100] as double
>>DIMENSION ihigh[100] as double
>>DIMENSION ilow[100] as double
>>DIMENSION iclose[100] as double
>>DIMENSION ivolume[100] as double
>>DIMENSION iopint[100] as double
>>ddate = 20060101
>>FOR i = 1 TO 100
>>idate[i] = ddate
>>itime[i] = 0
>>iopen[i] = 123
>>ihigh[i] = 200
>>ilow[i] = 100
>>iclose[i] = 123
>>ivolume[i] = 3000
>>iopint[i] = 0
>>ddate = ddate + 1
>>ENDFOR
>>oMetaLib.AppendDataRecArray(@idate, @itime, @iopen, @ihigh, @ilow, @iclose, @ivolume, @iopint)
>>
>>*oMetaLib.AppendDataRecArray(20010721, 0, 123, 200, 100, 123, 3221, 0)
>>oMetaLib.CloseDirectory()
>>
Jim Newsom
IT Director, ICG Inc.
Previous
Reply
Map
View

Click here to load this message in the networking platform