Using the new OCX format

[Gian Young]

I am in the process of converting one of my FF2 projects and have run into a roadblock with the OCX/Active X implementation.

The OCX I have been successfully using in FF2 uses the ATL71.DLL container, this OCX does not have a Visual Interface and appears to be unsupported by Jose's new Typelib Browser 4.0.13.

By unsupported I mean that following the FF3 instructions all appears to be implemented and the code compiles without error, however upon running the program the event code simply doesn't appear to fire.

I accept this but my question before I start attempting to convert my project further is:- Can I bring my FF2 code and Typelib Browser 1.00 code for this OCX into FF3, naturally I would place the ATL71.DLL component in the same release folder as the .exe. Can you think of any reasons this would not work.??

For reasons of commercial confidence I would prefer not to publically mention the OCX in question but would be happy to provide details privately if required.

Regards

Gian Young (Australia)

   

[José Roca]

Non visual OCXs don't need a container. Use PB's NEWCOM statement to create an instance of it and PB's EVENTS FROM and EVENTS END to sink to the event class.

[Gian Young]

Thanks Jose,

Truthfully I do not know or understand yet how to do what you suggest but I will attempt to learn and succeed.

I thought I was pretty cool managing to get these OCX'x working with the help of your Typelib now I will have to learn more

Regards

Gian Young

[José Roca]

The browser can be used to generate the interface declarations and the class for events sink.

Here is an example that uses ADO, that is a non visual ActiveX control, and demonstrates how to create an instance of the control and the use of EVENTS FROM/EVENTS END to sink to the events fired by the control: http://www.jose.it-berater.org/smfforum/index.php?topic=2606.0

[Gian Young]

Thank you Jose for trying to guide me in the right direction. Unfortunately I cannot see any relationship to using the method you describe in your refered example to my actual OCX's requirements.

I must admit I find implementing OCX's/ActiveX support in FF2 much easier and logical to understand and use than now in FF3 and PB9, I know it is claimed to be simpler but for those on the edge like me it is not.

The very fact I manged to get this OCX that I currently work with running with FF2 so easily and reliably and yet in FF3 I am getting absolutely nowhere is very frustrating. Maybe I am getting too old ?

For the moment I am abandoning FF3 and reverting to FF2 so that I can get on with some production.

I sincerely appreciate your help and support, I hope in time I can return to FF3.

Best Regards

Gian Young

[Paul Squires]

I think what Jose is implying is that for non-visual OCX's you do not use the OCX/ActiveX control in FF3. You can control the OCX directly by using code only! That means that you do not need a container (be it ATL71 or Jose's container). It becomes a situation where it is almost like just dealing with any other DLL.

Fire up Jose's TypeLib Browser or PB's Browser and generate the interface and events code. In the FF3 code editor you create an instance of the COM control using NEWCOM, etc...

If you like, you can send me a private message with the name of the OCX and I will see if I can generate some skeleton code to get you going in the right direction.

[José Roca]

 
Exactly. An OCX is a DLL with just a different extension name. ADO is also an ActiveX (Microsoft ActiveX Data Objects), but as it has a .DLL extension nobody is trying to use it with an OLE container. Using a non-visual ActiveX with a container is a waste of resources.

The way FF2 supported OCX only allowed the use of late binding, and generated low-level classes for events. Now you can also use the more efficient early binding and direct interface calls if the OCX has a dual interface, and you can use PB classes for events sink, that are more flexible and also easier once you learn how to use them.

[Pat Dooley]

I was just getting started with converting my handful of non-visual OCX's from FF2 to FF3 using the container method I was used to when I ran onto this thread. It has been a real eye-opener.
Using PolarCryptLight as an example, here is what I came up with. It seems to work fine.
But just because it works, may not mean it's right as I have found out.

In FF_AppStart I added to the end:

Code Select Expand


#INCLUDE Once "..\modules\pcrypt.inc"
Global pCrypt As CryptoLightICryptoLight  'line 72 in pcrypt.inc
Global pEvents As ICryptoLightEventsImpl  'line 145 in pcrypt.inc


Form1:

Code Select Expand


'------------------------------------------------------------------------
Function FORM1_BTNENCRYPT_BN_CLICKED ( _
                                     ControlIndex     As Long,  _ 
                                     hWndForm         As Dword, _ 
                                     hWndControl      As Dword, _ 
                                     idButtonControl  As Long   _ 
                                     ) As Long

Local sPassword As String
Local vPlainTextInput As Variant
Local sPlainTextOutput As String
Local vEncryptedText As Variant
Local vDecryptedText As Variant
Local sEncodedText As String
Local vDecodedText As Variant
Local vEncodedText As Variant

If IsFalse(IsObject(pCrypt)) Then
   ' Could not create an object refrence, exit the application
   MsgBox "Unable to create an object refrence."
   Exit Function
End If

sPassword=UCode$(FF_TextBox_GetText( HWND_FORM1_TBPASSWORD ))
pCrypt.password=sPassword

vPlainTextInput = FF_TextBox_GetText( HWND_FORM1_TBPLAINTEXTINPUT )
vEncryptedText = Pcrypt.Encrypt(vPlainTextInput)

sEncodedText = ACode$(Pcrypt.Encode( vEncryptedText,%pcfHex ))
FF_TextBox_SetText( HWND_FORM1_TBENCODEDTEXT, sEncodedText )

'work backwards to see if it works
vEncodedText = FF_TextBox_GetText( HWND_FORM1_TBENCODEDTEXT )
vDecodedText = pcrypt.decode( vEncodedText,%pcfHex )
vDecryptedText = pcrypt.decrypt( vDecodedText )
sPlainTextOutput = ACode$( pcrypt.encode(vDecryptedText,%pcfBinary ))
FF_TextBox_SetText( HWND_FORM1_TBPLAINTEXTOUTPUT,sPlainTextOutput )

End Function

'-------------------------------------------------------------------------
Function FORM1_WM_CREATE ( _
                         hWndForm As Dword, _      ' handle of Form
                         ByVal UserData As Long _  ' optional
                         ) As Long

pCrypt = newcom $PROGID_CryptoLightCryptoLight25    'line 16 in pcrypt.inc
pEvents = Class "CICryptoLightEvents"  'note quotes, line 143 in pcrypt.inc
Events From pCrypt Call pEvents

End Function

'-------------------------------------------------------------------------
Function FORM1_WM_DESTROY ( _
                          hWndForm      As Dword _  ' handle of Form
                          ) As Long
                         
Events End pEvents
pCrypt=Nothing 'is this needed or just a good idea                         

End Function

Any comments welcome.  Complete project attached
Patrick Dooley

[José Roca]

Yes, it's that easy. And it will be still easier when PB will implement native unicode suport, avoiding the use of UCODE$/ACODE$.

Besides, if you use the new COM support, transition should be easy if PB adds an OLE container to a future version of PBWIN, unless they made it only for DDT...

pCrypt=Nothing 'is this needed or just a good idea   

It is not needed. PB does automatic reference counting.