Trigger Foxpro debugger to open on windows 10 with ASP webpage 1

[Dave_Kunz]

Hi Folks,
For development purposes, we have a setup to trigger the foxpro debugger to pop up when testing our web pages.
This works just fine on Windows 7, but with windows 10, I can see the new vfp 9 instance inside the task manager, but the debugger display doesn't pop up on the screen to help point me to where the error is.

oVfp = CREATEOBJECT("VisualFoxPro.Application.9")
ovfp.docmd("_screen.WindowState = 1")
ovfp.docmd("_screen.visible = .t.")
ovfp.top = 0

&& to trigger the debugger
cStr = "2"
IF cStr = 2 && << This will trigger the debugger to pop up
cStr = "3"
ENDIF

ovfp.quit()
RELEASE ovfp

If I run this directly inside VFP9, it works fine, but if I call the .FXP (let's call it test_screen.fxp) from my .ASP web page (see below), the vfp9.exe shows up in task manager, but lingers there and the the web page just spins until it times out.

This is what the .ASP looks like:
<%@ LANGUAGE="VBSCRIPT"%>

<%
Set lo = Server.CreateObject("aspfox.aspfox")
Response.Write( lo.runFXP("test_screen","C:\inetpub\

http://wwwroot\testsite\",server,application,session,request,response))

Set lo = Nothing
%>

I'm unsure how to trace the vfp9 and see what it's doing and where it's hung up on. I've tried disabling UAC, increased permissions, set vfp9 to run as administrator, and disabled windows defender, but I cannot seem to figure out what on Windows 10 is keeping the debugger from popping up on my screen.

I appreciate any insights.

Thank you,
David

 

[Olaf Doschke]

When cStTR="2" sets this variable to a string, then IF cSTr=2 triggers an error exception for a type mismatch error, but not the debugger, so what is ON('ERROR') at that moment?

Also, the VFP screen is never modal, so as far as I see it you briefly show a VFP IDE and immediately quit it, unless an error halts execution. In general, an error doesn't halt execution, though. Without specific error handling you only get a messagebox that temporarily halts execution until you click OK and then continues, nothing fires up the debugger unless you SUSPEND. And, of course, that SUSPEND never should be part of normal code, but of an error handling routine you specify to react to error exceptions by telling what should be called [tt]ON ERROR yourerrorhandling(parameters)[/tt].

Documentation of AFP should give you that.
Edit: Ah, misread your ASPFOX OLE class with AFP, a web product for using VFP, but that would not be usage in ASP.NET. Sorry. But this ASPFOX class should set error handling to cause the debugger. There must be some technical documentation about how that works, but it's surely never native automatic from VFP to start the debugger by an error exception.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Olaf Doschke]

Another simpler thought: When all this once worked on another client/server. I guess it has to do with IIS settings or ASP/ASP.NET version?
Rick Strahl has had some posts or sessions on debugging a COM Server in place (within the web application context it's used in. Sp search west-wind.com.

Bye, Olaf.



Olaf Doschke Software Engineering

https://www.doschke.name

 

[Dave_Kunz]

Thank you Olaf for your insights. I really appreciate your help and your other comments from other topics have been very informative.
I had moved the error handling on the ASPFox class and tried a few things, but no luck.
I am able to get the output of the errors returning and displayed on the webpage, but no luck yet with having the debugger pop up. I may play around with this some more, but I might just accept this as is for now, but it sure makes me want to understand why.
Cheers,
David

 

[Olaf Doschke]

Whatever you rin in ASP or ASP.NET runsd in the IIS Service and that usually has no desktop interaction. That's where everything starts. This isn't just a matter of code to make this work, you're asking IIS to provide interactivity.

See remarks Rick makes on this blogpost -

https://weblog.west-wind.com/posts/2007/Oct/15/Debugging-a-FoxPro-COM-Object-under-ASPNET:

There are a couple of requirements for this to work:

IIS must run in SYSTEM context
ASP.NET must run in Full Trust
You have to run DCOMCNFG on VisualFoxPro.Application and set Impersonation to the Interactive User

Similar advice in an older blogpost comment #2 -

https://weblog.west-wind.com/posts/2004/Jul/11/Debugging-a-Visual-FoxPro-COM-object-in-place:

...Does nothing. ie does not make VFP visible.

That's because IIS runs in System context and doesn't have a console to display anything. There are a number of things that need to get set in order for it to work that way. With ASP you need to enable OutofProc COM components and you need to set the W3SVC service to allow interaction with the desktop. Bad idea, BTW.

As I said

I guess it has to do with IIS settings

IIS Management console isn't IIS, just like MS SQL Server Managemetn Studio isn't SQL Server, they're both just clients application to the services. And your ASP runs within the context of that service, usually without desktop interaction. I know how you can set up a service with a domain account to have network access and with desktop interaction and both, but it's not recommendable and also not the default. Ricks remarks tell you that this has to be enabled and doesn't work out of the box just by this VFP or ASP side code.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Dave_Kunz]

I finally got it to work by assigning my user to the COM+ and re-registering my dll and checked my permissions of the files. Not as tricky as I originally thought with Windows 10. Thanks.

 

[Olaf Doschke]

Thanks very much for feeding this back in. I never did anything with COM+, at least not in a project, I may once have tried something from the "advanced COM" section.

But good to see the possibility. Way too many are satisfied with an error log, you can learn so much more about the nature of a bug from seeing it "live", even better once you know the reproduction criteria single step towards it to see how it evolves.

It's worth much more struggles to be able to have debugging capabilities.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name