Important changes in AntView 1.1

While we strive for backwards compatibility, sometimes that ideal can’t be met in order to go forward.

This is the case with the move from AntView 1.0 to AntView 1.1.
A few changes had to be made to the control. These API changes might mean you will have to make changes to your source. Hopefully the downsides are minimal. Let me list the changes first one by one and then explain what that means for you and why this change was made.

  1. The CreateWebViewOnCreate property now defaults to False instead of True
  2. The OnNavigationCompleted event was missing the NavigationId parameter, this has been added.
  3. The OnFrameNavigationCompleted event was also missing the NavigationId parameter.
  4. Changed parameters of type IUnknown to their respective interface types
  5. Registration-free COM via manifest file requires changes.
  6. You can’t run AntView 1.0 and AntView 1.1 simultaneously.

These changes are explained in more detail below.

CreateWebViewOnCreate property change

When you create the AntView control it no longer automatically creates the WebView2 control as well. As a result you now might have to send “CreateWebView” to the control after you instantiate it.

When the control was built, it seemed like a good idea to automatically create the -out of process- WebView2 control as soon as the AntView control was instantiated. This caused real problems in some Studio/IDE environments during design mode. Losing access to property panels, inability to change settings, the UserDataFolder setting being ignored because it was set too late.. etc.. All these problems were curable by changing the default value of this one property and set it to false.

If you really prefer to keep this property set, then check out the new AntViewGlobal interface.

OnNavigationCompleted parameter change

The OnNavigationCompleted event now has the NavigationId parameter that was missing for the AntView 1.0 control.
This is not a big issue AS LONG as your development environment supports UInt64 parameters from an ActiveX control.
If your development language doesn’t support UInt64 then now that event no longer works for you ….

This was anticipated upon by passing the navigationId as a hexadecimal string instead in the OnNavigationCompletedHex event.
But in that case you have to set the property “EventsUseHexadecimal” to true.
With that set to true the control will use the hexadecimal variants of events where available.

OnFrameNavigationCompleted parameter change

This change is like the OnNavigationCompleted parameter change above, but now you should use OnFrameNavigationCompletedHex.

IUnknown parameters to interface type change

I don’t really expect people are negatively impacted by this particular change, but just to make sure, here are the changes:

For the IAntViewNavigationStartingEventArgs interface, the property RequestHeaders changed type from IUnknown to IAntViewHttpRequestHeaders.

For the IAntViewWebResourceRequest interface, the property Headers changed type from IUnknown to IAntViewHttpRequestHeaders.

For the IAntViewWebResourceResponseView interface, the property Headers changed type from IUnknown to IAntViewHttpResponseHeaders.

Event OnNavigationStarting now uses IAntViewNavigationStartingEventArgs instead of IUnknown.

Event OnWebResourceResponseReceived now uses IAntViewWebResourceRequest and IAntViewWebResourceResponseView instead of IUnknown.

Event OnFrameNavigationStarting now uses IAntViewNavigationStartingEventArgs instead of IUnknown.

These “IUnknown to <interface>” type changes have been made so that you can actually use the above methods & events from within VB and VBA. Without this change you could not use any of these parameters.

We tested with DataFlex, Visual Basic, Excel (VBA) and Visual FoxPro and none of them needed required code changes for the IUnknown data type change.

Registration-free COM via manifest file requires changes

Developers using registration-free COM via manifest files will have to create a new manifest snippet. The interface has been cleaned up with parts that we’re not using with the AntView control, as a result some interfaces have been removed.

There’s also several new interfaces that need to be added to your manifest file.

This is not needed if you use COM registration via regsvr32.

You can’t run AntView 1.0 and AntView 1.1 simultaneously.

While we looked into being able to have applications with AntView 1.0 as well as AntView 1.1 the amount of overhead it would cause at this moment in time is too high.

Creating new GUIDs for all the interfaces is not the problem.

However it also meant having to update all the ProgID references to include a version suffix and that would require more changes for almost everyone.