Ivan

You sound soooo different :)

>Hi Alex!
>
>Sorry for jumping in, but just to let you know...
>
>I know that the developers of StrataFrame have a medical package that still has the older VFP application running within their StrataFrame.NET MDI environment and so when the end-user is running their application, they don't know when a form is a .NET form or an older VFP form. They do this by stripping out all of the menus, status bars, etc. in the VFP executable. Then they wrote a UDP listener that runs in the VFP EXE and another in the .NET application. This is the communication pipe-line between the two disparate EXEs. In fact, StrataFrame has a VFP sample that shows the beginnings of this. So the ONLY interop that is used within the VFP environment is the UDP listener. It was my understanding that they had initially tried using a COM interop to make the VFP forms show up in .NET which turned out to cause a lot of difficult behavior on the VFP side of things as it relates to Windows handles.
>
>If you post in the SF forum I am sure that the SF team could give you more direction here, but I know that it is possible because this is how they are currently distributing their medical application until all of the VFP can be replaced.
>
>Abraços.
>
>Ivan
>
>
>>Rick,
>>
>>I know you have lots of experience with VFP / .NET interop so thank you for the response.
>>
>>I am calling the VFP component from a Strataframe WinForm and saving the object reference for reuse, but since I restart the darn thing so often several debug sessions open up. Ideally I'd like a VFP development session, a Strataframe / .NET session and at most one VFP debug session if it can't be the same one as the development session. Perhaps a search by the dll "bridge" for a VFP process running in a window with a known title may be the way ?
>>
>>Any considerations, suggestions and references are welcome.
>>
>>Alex
>>
>>>If you're debugging from within ASP or ASP.NET you should let VFP start up a new copy each time because that's what happens with a DLL server. If you truly want to debug your code you should try to simulate the same exact environment that the COM server is running through or otherwise you'll see inconsistent behavior.
>>>
>>>IAC, that process is fraught with all sort of issues such as how much data you can pass around (because you have to pass parameters as literals). It's better than nothing (well maybe it isn't <s>)...
>>>
>>>Don't throw out the old the LogToFile() (or like) routine just yet <s>...
>>>
>>>+++ Rick ---
>>>
>>>>Hi,
>>>>
>>>>I am implementing a com server to provide access to VFP code from .NET based on articles by Calvin Hsia and Rick Strahl
>>>>
>>>>http://blogs.msdn.com/calvin_hsia/archive/2007/05/21/write-fox-code-in-visual-studio-that-interacts-with-your-vb-net-code.aspx
>>>>
>>>>http://www.west-wind.com/presentations/VFPDOTNETiNTEROP/VFPDOTNETINTEROP.HTM#Debugging%20your%20COM%20server
>>>>
>>>>It has come to the point that SET STEP ON opens the VFP debugger, but each time I run my test code I create a new copy of VFP. I'd like to change the code to use an already running copy if available. In Rick's article there is a reference to another article, by Maurice de Beijer who provided the original idea, but it depends on storing the hwnd value of the design time VFP on disk.
>>>>
>>>>http://www.theproblemsolver.nl/aspdevelopmentanddebugging/index.htm
>>>>
>>>>I wonder if there is some way to cycle through all windows and pick it up automatically, perhaps knowing the title or some other trick.
>>>>
>>>>TIA,
>>>>
>>>>Alex