G
Guest
This question is about Windows API call, not vc. Sorry I don't know which group to post it
I got a strange result when use DDE to transfer data to Excel. What I'm doing is to read a file, and pu
data into Excel through DDE. The program will crash at different cell on different PCs (NT, XP, 2000). E.g.
on a NT, if I plan to transfer records that has 90 columns each, then my program crashed at record 18
(Excel stopped at R184C50). If I cut the column number by half (i.e., each record now has 45 columns), the
Excel stopped at R372_C8. This looks like that a global memory with limited size is somehow messed up
(184X90 almost = 372X45 )
We are using the DDE API calls directly. We use GlobalFindAtom() to check if an item is there; if not
call ClobalAddAtom() to add it. Trace shows that when we call GlobalFindAtom() to find item "R184C51"
the function returns a value saying this item is there when it's definitely not. When we call GlobalGetAtomName(
to retrieve this atom, sure it's not there (sometimes we do get some strings back, but the string looks lik
it's from a wrong memory address, something like "B_comple" ). To work around it, we tried to delete
such an Atom (in a WHILE loop), but it can't be done and the program went into a dead loop. We the
tried to change the form of the item from "R184C51" to "R184C051", "R0184C051",..., etc, and add the
new item; but this won't work either (sometimes works, some times not). So, the system memory is totall
messed up (each time we have to reboot to do another testing). BTW, the returned atom is always in the
correct range ( > 0xC000). Also, sometimes when we call GlobalFindAtom() to find say, R250C9, it ma
give us an atom value of say, R16C33, and of cource Excel cell R16C33 is wrongly updated
If the array of records is smaller than the crash threshod (e.g, less than 184 records when we're tryin
the 184X90 data), there's no problem at all. All the values can be correctly transfered to Excel. So, the
question is, is there a limit for the number of atoms that can be added into the global atom table by
calling GlobalAddAtom() ? Note that the call didn't give us any error indication, and as I said, our proble
begins when GlobalFindAtom() says it find a atom, when such an atom is not there at all
Thanks for help.
I got a strange result when use DDE to transfer data to Excel. What I'm doing is to read a file, and pu
data into Excel through DDE. The program will crash at different cell on different PCs (NT, XP, 2000). E.g.
on a NT, if I plan to transfer records that has 90 columns each, then my program crashed at record 18
(Excel stopped at R184C50). If I cut the column number by half (i.e., each record now has 45 columns), the
Excel stopped at R372_C8. This looks like that a global memory with limited size is somehow messed up
(184X90 almost = 372X45 )
We are using the DDE API calls directly. We use GlobalFindAtom() to check if an item is there; if not
call ClobalAddAtom() to add it. Trace shows that when we call GlobalFindAtom() to find item "R184C51"
the function returns a value saying this item is there when it's definitely not. When we call GlobalGetAtomName(
to retrieve this atom, sure it's not there (sometimes we do get some strings back, but the string looks lik
it's from a wrong memory address, something like "B_comple" ). To work around it, we tried to delete
such an Atom (in a WHILE loop), but it can't be done and the program went into a dead loop. We the
tried to change the form of the item from "R184C51" to "R184C051", "R0184C051",..., etc, and add the
new item; but this won't work either (sometimes works, some times not). So, the system memory is totall
messed up (each time we have to reboot to do another testing). BTW, the returned atom is always in the
correct range ( > 0xC000). Also, sometimes when we call GlobalFindAtom() to find say, R250C9, it ma
give us an atom value of say, R16C33, and of cource Excel cell R16C33 is wrongly updated
If the array of records is smaller than the crash threshod (e.g, less than 184 records when we're tryin
the 184X90 data), there's no problem at all. All the values can be correctly transfered to Excel. So, the
question is, is there a limit for the number of atoms that can be added into the global atom table by
calling GlobalAddAtom() ? Note that the call didn't give us any error indication, and as I said, our proble
begins when GlobalFindAtom() says it find a atom, when such an atom is not there at all
Thanks for help.