ActiveX on Windows 7 32-bit

[John_B__Walter]

I have an ia32 program which can be built on system A or system B both running Windows 7 32-bit with Visual Studio 2010 SP1 and IVF 2013.5.198

Either of these executables will work on system A but has an Access Violation on system B when it attempts to open a dialog which contains an ActiveX object.

This would seem to be a Windows 7 policy/permissions problem. No files beyond the executable are being accessed. This only happens when the dialog contains an ActiveX object. Does anyone out there know of a policy/permission which would be tied to using an ActiveX object in a Fortran program? The two machines have the same Windows 7 Enterprise 32-bit, but they were setup by different individuals so easily could have different policies/permissions. It's probably unrelated but system A has internet access while system B is isolated from the net.

[mfinnis]

I take it this issue hasn't been resolved. I have a similar if not the same problem. Currently I use VS2008 on WinXP and Windows 7 systems and develop dialog applications that contain ActiveX controls. I have no problem running the applications on WinXP or Windows 7 systems. I noticed that the latest version of the compiler doesn't support integration with VS2008 so I though I'd upgrade to VS2010 (the latest version my employer currently supports). On installing VS2010 and XE 2015 and building an application I found I had problems running it in Windows 7. Thinking it might be an XE 2015 issue I went back to XE 2013. After some experimentation building a sample application (the default dialog with ActiveX control project with the Array Visualizer AvGraphCtl control - though any control I've tried has the same effect) in VS2008 and VS2010 on WinXP and Windows 7 I have:

applications built in VS2008 run in WinXP and Windows 7, applications built in VS2010 run in WinXP but not Windows 7. (I have tried the applications in various 'flavours' of the operating systems on 'clean' virtual machines so it doesn't look like a particular machine configuration causing the issue.) The applications fail in the call to DlgModeless before the callback routine is called and from the stack frame in the debugger it looks as if the exception originates in ifdlg100.dll.

This is slightly different to John's experience in that he has his program running on a Windows 7 system. Has anyone else seen this sort of behaviour or managed to fix/workaround it?

(I've submitted this to Premier Support but can get no response let alone an answer.)

[Steven_L_Intel1]

Sorry that you're not getting timely responses on your issue after the initial responses. Unfortunately, this sort of issue is very difficult to diagnose as the error often is happening inside Microsoft code. I'll check with the support engineer working this issue to see if there's a way to make progress.

[Steven_L_Intel1]

I see your project depends on the Array Visualizer OCX. Can you reproduce the problem using the FXPLORER sample we provide?

[mfinnis]

Steve,

Thanks for the comments. I appreciate that the issue might be very difficult to resolve.

I'm not sure the FXPLORER sample is likely to exhibit the same problem as it isn't a dialog application project as such. Building it on a Windows7 machine in VS2010 it runs, sort of; the GUI isn't drawn properly and there is no functionality though it doesn't crash. Building it on the same machine in VS2008 it runs with no problem.

The reason I used the Array Visualizer control is because it's available and is the same version of the control on all the machines so takes some of the variability out of the problem. Similarly I used a clean dialog project so that there is no extraneous code to confuse the issue. Using the control used in the FXPLORER sample, the MS Web Browser control, in a clean dialog project on a WIndows7 machine I have the same behaviour as with the Array Visualizer control, namely when built with VS2010 it crashes during the call to DlgModeless, when built with VS2008 there is no problem.

I haven't got access to the WinXP machine until tomorrow when I get back to work. I'll try building the FXPLORER sample on that machine then.

[Steven_L_Intel1]

XP is not of interest to us anymore, as we no longer support it in the 2015 product. (Even though you're using an older version, we would not make any fixes in that version, assuming there was something we could fix.)

I will test FXPLORER using the various VS versions under Windows 7. My guess is that there's some issue with the MSVC library which varies by VS version.