CopyMem - Can I see data?

I'm having a tough time with some code I've ported from C.

I have to use CopyMem to stuff some data into a var, and in one instance it works correctly, but following that it fails and usually causes a crash.

Is there any way to "see" the data I want to copy and it's length?

I'm concerned that the var I'm copying to is not the correct size, or that the declaration of the var is not correct.

Unfortunately, I'm copying into a farily complex Type....

I've attached the basic code for anyone bold enough to look at it.

Specifically, look at the processData sub, where the CopyMem calls are.

You will not be able to run this code directly since you won't have the app I'm working with.

However, if you want, you can download a trial version:
http://www.infograph.com/forms/down...?product=myriad

There is sample integration code (in C) in the intgclt folder after installation.


Thanks!

You could do the following just prior to the CopyMemory call. This will allow you to see the individual byte values that you are trying to move.

VB Code:

Dim i As Integer
Dim b As Byte
For i = 0 To LenB(pRecord) - 1
    CopyMemory b, ByVal pCallBackRecord.Data + i, 1
    Debug.Print b;
Next i
Debug.Print

It's kind of a kluge. I don't know if there is a better way of sequentially accessing each byte in the record.

Thanks, but that's not really what I meant when I wanted to view the memory....

I'm working with another program using a callback.
It's passing an address
When I use Copymem, part of what I get back is another address.

I then have to use Copymem again to fill my Type.

The problem I'm having is either:
1) I don't think the second address is valid AND/OR
2) I dont think the TYPE use in the 2nd Copymem call is setup correctly 'cause the values I get back are completely wrong.

For example, I'm expecting a value (double) like:
-10.029
and I get:
5.340239002e-218

So, my question is:
Can I view the contents of my memory and track down the correct values? If I can do this, can I logically work backwards to make sure my TYPE declaration is correct?

Quote:

---

The problem I'm having is either:
1) I don't think the second address is valid AND/OR

---

Does the second address look reasonable when you display it? I.E. MsgBox "copying data value: " & pCallBackRecord.Data

Quote:

---

2) I dont think the TYPE use in the 2nd Copymem call is setup correctly 'cause the values I get back are completely wrong.

---

What does the C declaration for the Doubles look like? I get a 404 when I click the link for the trial version.

Quote:

---

So, my question is:
Can I view the contents of my memory and track down the correct values

---

Not clear as to what area of memory you want to view. Please specify the structure and/or field(s).

1) I popup a msgbox and the value is: 1099511628
Of course, this varies, but the way I would think it would.
For example, if I open a different file within the other app, the address changes. If I re-open the original file, the address changes back to the first one I get. I find it strange that the address would be 'linked' to the specific file opened.

2) Download the attachment from the original post in this thread. It contains a file called "composite.c" which has all the declarations from the C++ sample code.

3) We'll skip the 'viewing memory' part for now....

4) I've attached a new version of my program, which still fails to retrieve the correct values, but does not crash. Also in the zip file is a screenshot of the values I get back and the values their sample app gets.

5) I've also placed an IE URL in the zip file so you can download the app I'm working with.....

Thanks for your interest, by the way.

Note:

In my previous reply I mis-typed.
Instead of:
"...but the way I would think it would. "

It should be:
"...but NOT the way I would think it would."

Quote:

---

1) I popup a msgbox and the value is: 1099511628
Of course, this varies, but the way I would think it would.
For example, if I open a different file within the other app, the address changes. If I re-open the original file, the address changes back to the first one I get. I find it strange that the address would be 'linked' to the specific file opened.

---

I haven't studied the code in great detail and therefore do not have a real good feel for everything that is going on. The first thing that came to mind is that the addresses may point to the buffer spaces that are allocated to the open files.

Quote:

---

2) Download the attachment from the original post in this thread. It contains a file called "composite.c" which has all the declarations from the C++ sample code.

---

I'va alread done that, yesterday at the office and today at home. I will get the new version though.

Quote:

---

5) I've also placed an IE URL in the zip file so you can download the app I'm working with.....

---

I have VB 5.0 at home (I don't use it much for personal developement) - will I be able to compile you code without much trouble?

Quote:

---

Thanks for your interest, by the way.

---

No problem. Maybe I'll learn something from it.

I have to assume that you have the correct VB definitions for IGBOOL, IBINT, etc. I don't have VC++, so I can't look them up. All of my C coding is done on HP (formerly Tandem) Non-Stop Servers. Most of my interprocess communication is between C servers on the HP and VB & Java applet clients on PCs.

You should be able to use VB5 no problem. Just make sure you compile it before running it or VB will complain.

The sample version of my code is very basic - I'm trying to solve the hard parts before I write anything else!

Try downloading Myriad (the app I'm integrating with) from the URL I attached.
It's basically a file viewing app for about 250 file formats.

I don't use VC++ either, but the sample code with Myriad (and the "composite" file I sent) shows where they are redefining the data types -
There's also and included document "intgclt.doc" which is basically the reference manual for writing an integration.

I forgot to mention something about the C function declaration long FAR PASCAL WndProc. This is telling the compiler to use Pascal's calling convention.

C and Pascal push parameters onto the stack in opposite directions from each other. It's been so long, I'm not sure if I remember which is which, but I think C pushes them last parameter first. I'm not even sure about VB.

This may or may not be a problem.

One more thing -

In the "loadIt" sub in my code, you'll need to specify some file of your own to open, or, once Myriad is running and before you click the "document" button, open some file in Myriad (any kind of drawing file will work - just in case though, I've attached a sample file from one of my clients.

D'oh!
Here's the attachment

<FAR PASCAL>

I don't think it's a problem - I'm getting the first callback ok (at least I'm getting 2 of 3 parts ok). The order seems right....