david, i know when the exec is NOT connected to the UI that Trace works fine. if it's possible to use the UI to make a .net file, and then run dx -script foo.net in batch w/o the UI and watch the trace messages, then i'd suggest that.
but from context i'm guessing you are trying to debug display problems. that might still work in script mode, but might not depending on how much interactivity you need. i apologize that i don't remember the details, but i think the reason the messages don't show up is because of the way DXDebug() calls DXqmessage(). i think the first parameter which is some sort of label. when the dxexec runs with the UI and sends messages to the UI, the label determines what the UI does - errors, warnings, etc have different labels. i see from the code that DXDebug messages have NULL as the label. for your own debugging, you might find another DXqmessage which does show up in the UI's message window (like a warning or error or something) and use the same label from it and see if that makes them visible. the other question is what the eventual "right" thing to do with them is - most of them are pretty ugly messages only intelligible (or not!) to the code writer. i'm not sure exposing them in the general case is necessarily a good thing. nancy [EMAIL PROTECTED]
