No problem, I am happy to go with the bug explanation, makes me sleep easier at night knowing it may not be my failure! It is not a big deal, as I have a work around already.
Again, many thanks for your help
Duncan
Shawn Fessenden wrote:
I have tried to add an extra couple of
int32 to the arrays
Hmmm... well, the real honest-to-goodness size is really 116 bytes for an
array size of 29. Can't say what the problem may be.
Maybe I am missing something, but how
does this explain why I can't change the
first ulong value in the SetSettings value,
You're right, that doesn't have anything to do with it. Maybe the dll
functions just don't work right? It's not unusual for libraries to contain
bugs. Especially when there's a work around in place. It's cheaper to just
put it on a "known bugs" list and forget about it rather than fix it.
I'd have to see the whole thing to make a good case.
By embedded do you mean when you embed
another struct or pointer inside a struct?
Embedded systems programming. There was a time when that one little
"mistake" could have made the difference between a product that works and
one that doesn't because the memory requirements are too heavy. Those days
are vanishing now too though as embedded controllers get more flexible.
-SHAWN-
.
--
Duncan Wild
Max-Planck-Institut für biophysikalische Chemie
Abteilung Spektroskopie und Photochemische Kinetik (10100)
Am Faßberg 11
D-37077 Göttingen
GERMANY
Â
Tel.:Â Â Â Â +49-551-201-2004 (Office)
Tel.:Â Â Â Â +49-551-201-1775 (Lab)
FAX :Â Â Â Â +49-551-201-1501
E-mail:Â Â HYPERLINK "mailto:dwild@gwdg.de"dwild@gwdg.de
-------------------------------------------------------
Â
---
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
Again, many thanks for your help
Duncan
Shawn Fessenden wrote:
I have tried to add an extra couple of
int32 to the arrays
Hmmm... well, the real honest-to-goodness size is really 116 bytes for an
array size of 29. Can't say what the problem may be.
Maybe I am missing something, but how
does this explain why I can't change the
first ulong value in the SetSettings value,
You're right, that doesn't have anything to do with it. Maybe the dll
functions just don't work right? It's not unusual for libraries to contain
bugs. Especially when there's a work around in place. It's cheaper to just
put it on a "known bugs" list and forget about it rather than fix it.
I'd have to see the whole thing to make a good case.
By embedded do you mean when you embed
another struct or pointer inside a struct?
Embedded systems programming. There was a time when that one little
"mistake" could have made the difference between a product that works and
one that doesn't because the memory requirements are too heavy. Those days
are vanishing now too though as embedded controllers get more flexible.
-SHAWN-
.
--
Duncan Wild
Max-Planck-Institut für biophysikalische Chemie
Abteilung Spektroskopie und Photochemische Kinetik (10100)
Am Faßberg 11
D-37077 Göttingen
GERMANY
Â
Tel.:Â Â Â Â +49-551-201-2004 (Office)
Tel.:Â Â Â Â +49-551-201-1775 (Lab)
FAX :Â Â Â Â +49-551-201-1501
E-mail:Â Â HYPERLINK "mailto:dwild@gwdg.de"dwild@gwdg.de
-------------------------------------------------------
Â
---
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
</pre> <blockquote type="cite"> <pre wrap="">(am I right Shawn?) </pre> </blockquote> <pre wrap=""><!---->Yes indeedy. </pre> <blockquote type="cite"> <pre wrap="">I changed the function definition suchthat it is expecting a pointer of shortdata type (int16=4bytes) </pre> </blockquote> <pre wrap=""><!---->Erp - that's long (int32 = 4 bytes), but I see that was probably a coffeeproblem
> struct data types over the CFI to a
> dll function
Super!
> massive apologies if this has been
> covered before.
Well actually it doesn't get covered *enough*
> (am I right Shawn?)
Yes indeedy.
> I changed the function definition such
> that it is expecting a pointer of short
> data type (int16=4bytes)
Erp - that's long (int32 = 4 bytes), but I see that was probably a coffee
problem
> This is all well and good, and I get a return array.
K - very good so far.
> My question is, what is the most efficient
> way now of getting the values that I need
> from the array of int32's.
I think the way you're doin it now is splendid.
> will it lead to faster degradation of the
> drive I am saving the tmp file to
No. As somebody pointed out (think it was Stan or Bill) the file probably
never hits the drive (they're teeny-tiny and the cache handles it).
> is there a more efficient way?
You can use RtlMoveMemory(double *dst, long *src, long bytes). It would
avoid the overhead of Create/Write/Read/Close. On the other hand it would
probably tend to make things a little more obscure, but that's ok as long as
you thoroughly explain what's going on in the source.
> What is the 6th value?
It's packing. If packing is 8 (bytes - the Win32 default), then the extra
four bytes are explained by the fact that there are an odd number of 4-byte
entities preceding 'eventpresent'. In this case:
Counting size by #pragma pack(8)
a[0] = range .5
a[1] = prena 1
a[2] = ssweeps 1.5
a[3] = roimin 2
a[4] = roimax 2.5
a[5] = (packing) 3
a[6]-a[7] = eventpresent 4
a[8]-a[9] = timepresent 5
a[10] = savedata 5.5
And so on. Packing is inserted to align data entities (in memory) whose
sizes are equal to or greater than the packing size. From VC++ help, #pragma
pack:
<quote>
When you use #pragma pack(n), where n is 1, 2, 4, 8, or 16, each structure
member after the first is stored on the smaller member type or n-byte
boundaries.
</quote>
Since double (aka Real64) is eight bytes, it must lie on an 8-byte boundary
(if the compiler has been told to pack on 8-byte boundaries). The *reason*
this is done is to speed up memory access. Whether or not it actually does
depends on the target machine. It saves access time to align members that
are larger than the data bus.
-SHAWN-
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".