I seem to be experiencing an issue with ATE 7.0.1670.0 related to XTREE. We have a dialog with an XTREE of payments made on a ticket (which starts empty.) The user can then add different payments until the ticket is fully paid. In this case, when I add another row (there is another selection dialog that is displayed and deleted in the interim) it generates an XTREE related error and results in the ATE window closing. I have not been able to reproduce in a way that would be easy to send to you. So, it may require me giving you access to a system here. I did enable the XTREE trace in the ATE miame file and was able to capture the attached traces. (I had to change to txt extension to upload to the forum). I know this probably is not very clear. If there is more info I can provide, let me know. Also, everything works fine in ATE 6.5.1728.2. I could try to find when it changed if that would be helpful.
Your trace is actually helpful, containing what I think is the smoking gun. At some point in the not-too-distant past, I encountered a crash scenario in a particular XTREE configuration which I could trace to an error within a Windows DLL during handling of a message fired from within the DLL underlying XTREE. Both being third-party modules, I never was able to get a satisfactory resolution. (The best advice I was able to get from any of the responsible parties was to look for potential memory corruption.) Which I was unable to find, but it did lead me down a path of adding a lot of housekeeping, defensive code, safety margins, etc. which eventually did seem to make the problem go away. But one of those steps was to completely unload the DLL at the end of a program.
Your log does show the DLL being reloaded after several XTREE calls, with an error (invalid control id) on the very next call. So you were trying to access an XTREE control created earlier, but the DLL had been unloaded/reloaded/reset since then.) My guess is you're using the ASFLAG AF_SBXASRUN option and these calls are occurring across multiple instances of SBX's that are acting like RUNs?
If that seems likely to you, then we should probably start with an ATE update that backs out that precautionary step (which probably was never actually necessary).
You are correct that the XTREE calls in question are happening in separate SBXs where at least the original SBX has the AF_SBXASRUN flag set. Interestingly, I don't see where the flag is set in any of the subsequent SBXs that are being called. Otherwise, what you stated seems like a likely scenario. There may be a subsequent SBX call I am missing that has the AF_SBXASRUN flag set though.
I think the flag persists across XCALLs. But I'm not sure actually sure it's the culprit here. Can you repeat your test with the ATE flag turned on? I'm looking for lines that look like this:
I think the unload is occurring in response to TAB(-10,85),5 which is sent whenever a new RUN program is loaded (but shouldn't be for SBXs), so I'm not sure yet what's really happening.
In other words, you're somehow executing a COPY command in the middle of these XTREE operations, probably via XCALL AMOS,"COPY...".
As suggested earlier, I can probably remove that logic, but it would require an update of ATE. It might be simpler, at least in the short term, to see if you can replace that COPY operation with MX_COPYFILE
Whether or not you decide to replace the COPY, if you want to verify that the ATE patch does resolve the problem, I posted a beta update of ashw32.exe here..
Also, a couple of tips on tracking down where the COPY occurs:
Use grep, or SBCSCH or your preferred search tool on the LSX files, not the source files. (That makes it a lot easier to pin down the main module when it occurs within an include.).
Turn on the EXEC, XCALL and AMOS traces (on the server side, from the dot prompt). That should show all the XCALLs and in particular, the XCALL AMOS calls in context. (If XCALL is too verbose, you can probably do without that one.) Note that each trace line will show the main program and the SBX, if applicable.
Good. I'll post a proper update for the ATE installer after a bit more in-house testing. But I think it will be cleaner to use MX_COPYFILE, or even HOSTEX to cp rather than XCALL AMOS, which is a lot more complex internally.
