win11 and fp with activex

[noahsombrero]

I have written a program in the fp 9 ide. It relies on many activex components. It runs fine on everything up to and including win 10. On win 11 it seems that it blocks the program from executing code stored in
component functions. Like the click function for a button component. The program cannot invoke that function with window.button.click().

The main program window loads and looks ok even though it also includes many activex. But if I try to open a program window, I get error messages. Tracing through the code I see fp objects every time a call is made to a component function. But even if I disable those, the program window still fails to open.

Is there something I can do about this?

 

[Chris Miller]

I don't get what you mean with fp objects when you talk of activex. Every control on VFP forms, also an ActiveX will be an object, but ActiveX controls differ a bit.

The most common reason for ActiveX controls being a problem is they are not registered on the system. And surely the activex controls you get with VFP9 including the license to redistribute them are not preinstalled in Windows 11, I think thats a problem you face since Vista, maybe even XP. You only have some common controls like the RTF control when Office or other software is installed.

Create a setup that registers the activex controls you need.

Chriss

 

[noahsombrero]

I do use some built in fp activex. But many are third party. I do use an installer to provide necessary files and register
ocx's in the registry. No error shows in this process. This is a mature program that has been in use on many systems since 2004.

 

[Chris Miller]

I don't know, then you have to get into more details.

Besides calling events being a bad habit, the most often reason you can'tcall an event or method of an activex is when it's class isn't found in the registry and so the control is removed from the form at init.

Typical error about that is 1881: Error loading file - record number n. "object" <or one of its members>. "Issue": "error".

Where the number n, issue and error is replaced with something related to the control.

If you copy over the OCX but those activex depend on ay C++ runtime 8,9, or 10 and Win11 is only providing C++ runtime 11, then the C++ 7.1 runtime you install with your EXE is insufficient. If the activex control is VB6 based you also need a VB runtime, etc.

IF you get error 1881 you surely miss something in your setup.

Chriss

 

[Rick C. Hodgin]

Windows may block the file when it's installed. Right-click on the ocx and choose properties and see if there's an "Unblock" button in the lower-right.

--
Rick C. Hodgin

 

[noahsombrero]

The error message is 1925, Unknown member "name". This is the error I get consistently as I work through the debugger
turning off function calls, until I get to the point where there are none left. At that point, I still get error 1925 when I try to open that program window.

It might be true that it is a bad habit to call component events. It can be a very handy thing to do, however, if you want to make a certain process be manual or optionally automatic.

It does sound like I am hearing that MS has not designed win 11 to disallow activex function calls.

 

[Mike Lewis]

It does sound like I am hearing that MS has not designed win 11 to disallow activex function calls.

Can we be clear exactly what you mean by "activex function calls"? I think most of us would take that to mean calls to the methods of ActiveX controls. For example, the Navigate method of the WebBrowser control, or the Add method of the ImageList control. I'm not an expert, but I can't imagine Microsoft disallowing such calls. There must be many thousands of applications in the field that rely on calling methods of ActiveX controls.

But you also mentioned that you can "invoke the click method for a button" by calling "window.button.click()". If you are talking about native VFP buttons, that has nothing to do with ActiveX. I think the point that Chris was making was the Click method is also an event, and it is bad practice to directly call code in events. Perhaps "bad practice" is going too far, but it is definitely not ideal.

To explain further, suppose you have a Search button. There is code in its Click event to perform a search. That's fine. But suppose you also want to perform the search from somewhere else, say from a menu or a toolbar. You might think you could simply call Form1.Button1.Click() from one of those places. That would work, but it is not ideal because you might, at some point in the future, remove the button, or rename it, or move it to somewhere else in the containership hierarchy. At that point, the call would no longer work.

That point has got nothing to do with the problem that you are having with ActiveX controls, but it does emphasise the need to be clear in your terminology.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[noahsombrero]

By functions, I mean both methods and events. The program does not often call a click event, only when it is necessary to facilitate some feature. I am the only one who maintains this program or ever will, so I am not overly concerned about confusing some future person who doesn't understand why a function call no longer finds its target. There is one instance of calling an event in the form I am talking about. More often is a call to do something like set the cursor where it will be most useful to the user. That call also does not work, the same as various others that do not.

 

[Chris Miller]

The remark on Error 1925 say you should make sure the reference to controls is within scope.

Usually you would address a control in form code with THISFORM.Button.click, not with Window.Button.click. At the point the error occurs I'd check whether it's only the member - the click or other method - is not seen or whether it's the whole control. that's unknown.

If you still work with defined windows instead of forms, you should take care that forms by default have name "Form", all of them, unless you name them. So you usually work with object reference to a form, not with window or form names, you can easily get into situations your reference becomes ambiguous.



Chriss