Shawn et al,
As suggested, I compared the state information between a good copy and one that has problems - there are no differences. A simplified version of my application has a state number of 640 #H and the normal version, which has a strip chart background picture, has a state number of 465233. These numbers don't change between "good" and "bad" versions.
Barrie
Shawn wrote:
I have one more suggestion, given that now you know it's basically a corrupt data problem. Compare state information from the good copy with that from the bad copy. This will be found in the .vee file and it looks something like this:
(device 3 ACTIVEXCONTROL
(properties
(name "Libs, Classes & Functions")
(variableName "gtv")
(objectType "MSComctlLib.TreeView")
)
(implementation
(license 37 #H <some license bytes>)
(state 128 #H <state information bytes>)
)
)
The number after state indicates how many bytes are in the data, two chars for each byte. If it has to do with corrupt string data, you'll probably find a missing 0 byte. I suppose there are several other possibilities too.
---
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/".
As suggested, I compared the state information between a good copy and one that has problems - there are no differences. A simplified version of my application has a state number of 640 #H and the normal version, which has a strip chart background picture, has a state number of 465233. These numbers don't change between "good" and "bad" versions.
Barrie
Shawn wrote:
I have one more suggestion, given that now you know it's basically a corrupt data problem. Compare state information from the good copy with that from the bad copy. This will be found in the .vee file and it looks something like this:
(device 3 ACTIVEXCONTROL
(properties
(name "Libs, Classes & Functions")
(variableName "gtv")
(objectType "MSComctlLib.TreeView")
)
(implementation
(license 37 #H <some license bytes>)
(state 128 #H <state information bytes>)
)
)
The number after state indicates how many bytes are in the data, two chars for each byte. If it has to do with corrupt string data, you'll probably find a missing 0 byte. I suppose there are several other possibilities too.
---
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/".
seems that the actual cause was this corrupt data even though it did only
come into play when drawing occurred.
I have one more suggestion, given that now you know it's basically a corrupt
data problem. Compare state information from the good copy with that from
the bad copy. This will be found in the .vee file and it looks something
like this:
(device 3 ACTIVEXCONTROL
(properties
(name "Libs, Classes & Functions")
(variableName "gtv")
(objectType "MSComctlLib.TreeView")
)
(implementation
(license 37 #H <some license bytes>)
(state 128 #H <state information bytes>)
)
)
The number after state indicates how many bytes are in the data, two chars
for each byte. If it has to do with corrupt string data, you'll probably
find a missing 0 byte. I suppose there are several other possibilities too.
I'm making a note for VV2 to look into trying to validate state information,
but I don't know how much I can do about it. The state usage is all up to
the individual control.
In any case great work! After I found that Ole View puked on instancing it I
basically gave up.
-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/".