Andrew Lathrop wrote in message <[EMAIL PROTECTED]>...
>
>I am using the serial manager to read in a string. I am sending the string
>from the palm, and reading it on the emulator. The string is stored in a
>BytePtr array called pPointer.
Assuming the declaration to be:
BytePtr pPointer[n];
(where 'n' is some value I have know way of knowing at this point).
And there must be some sort of allocation for each slot ...
int i;
for (i=0; i<n; i++) {
pPointer[i] = MemPtrNew(n2);
}
(where again 'n2' is some limit value I have no way of knowing)
>To convert the BytePtr to a CharPtr so it
>can be displayed using a FrmCustomAlert so i can see what data was sent. I
>use the following code to convert it to a CharPtr.
> x = *pPointer[index];
Given the declarations above, the you are setting 'x' to be the
value of the first character stored, not the address of the storage
buffer.
Try
x = pPointer[index];
instead.
(If my assumptions on your declarations are wrong, perhaps
you could post the actual code you use...)
> y = (CharPtr)*pPointer;
Ok ... shouldn't 'x' be somewhere in this ?
It looks like 'y' will be set to a pointer value, pointing to
the buffer allocated for pPointer[0]; You've completely
lost the "index" you had used in the previous line.
> FrmCustomAlert( ErrorAlert, y, "", "" );
>The problem is when i put in the FrmCustomAlert line, y changes. I don't
>know why. Using the debugger i set a breakpoint right after the frm is
>displayed, and it shows that x doesn't have the same value as y.
This is understandable since 'x' was nowhere in the statement you
had assigned to 'y'...
>It has a
>random character that is displayed as an outlined heart in the form.
Again, according to the 'x' assigment I would expect to see a char value.
This char should be the first char from the buffer stored at
pPointer[index].
>But
>when i removed the FrmCustomAlert line, and use the debugger, i see that
>both x and y have the values i expect them too.
Now that I don't understand ... except that this debugger takes liberties.
If
optimization is turned on, the compiler might place the value in a register
instead of memory. In addition to that, it can reuse that register for
another
variable as long as the use of that value does not conflict with the first
one.
Make sure all optimizations are turned off in the compiler and try again.
>The problem appears to be
>with the FrmCustomAlert line, but have no idea why that would change the
>value of y since it doesn't change it.
It doesn't. The debugger lies to you if compiler optimizations are not
disabled.
--
-Richard M. Hartman
[EMAIL PROTECTED]
186,000 mi/sec: not just a good idea, it's the LAW!
--
For information on using the ACCESS Developer Forums, or to unsubscribe, please
see http://www.access-company.com/developers/forums/
