Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!orca!javelin.sim.es.com!lwallace From: lwallace@javelin.sim.es.com (Raptor) Newsgroups: comp.windows.ms.programmer Subject: Passing data to a DLL; strange problem! Message-ID: <1991Apr22.173022.8930@javelin.sim.es.com> Date: 22 Apr 91 17:30:22 GMT Organization: Evans & Sutherland Computer Corp., Salt Lake City, Utah Lines: 56 (One wonders if I'll ever find a Windows technique that works the first time I try it...) I've recently broken my application up into a DLL and a main program module. One of the functions I've exported to the DLL needs to enumerate top-level windows, so I want to pass it my application's top-level window handle to feed FindWindow(). First, if you've got a better technique to do this, I'm interested in hearing it. But my problem remains. I've written a tiny function to pass the handle to a static variable in the DLL. This is what's in the DLL: HWND ParentHandle; ... void FAR PASCAL TxferParentHandle(HWND hwnd) { ParentHandle = hwnd; } This is how I call it from my main module: HWND ParentHandle; ... WinMain(...) { ... TxferParentHandle(hwnd); } The DLL's copy of ParentHandle remains 0. hwnd is set as expected. It was baffling to execute the assignment statement in CodeView and see that it doesn't work! I have discovered, through CodeView, that the address of ParentHandle in the DLL is in a different segment from that shown in DS and SS (which are equal): (for example) &ParentHandle = 0c15:2794 DS = 0bea SS = 0bea This is in my DLL, just after TxferParentHandle() is called. The assembly code uses the correct offset (2794 in this case). It's just going to a different segment, for some reason. Both modules are compiled (and linked) with the small model. Has anyone encountered this? Any suggestions? -- Lynn Wallace | I do not represent E&S. Evans and Sutherland Computer Corp.| Internet: lwallace@javelin.sim.es.com Salt Lake City, UT 84108 | Compu$erve: 70242,101 Revenge is a dish best not served at all.