UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Use Adobe Pdf Activex In Access Forms, Access 2010    
 
   
AlbertKallal
post Oct 4 2016, 09:30 PM
Post#1


UtterAccess VIP
Posts: 2,825
Joined: 12-April 07
From: Edmonton, Alberta Canada


I have an application in which PDF’s are displayed on a form (up to 4 pdfs are displayed at the same time).

I been able without issue to drop in the Adobe ActiveX PDF control into an Access form for many years now.

The application in question has worked fine up to Adobe 11.

Now, since the newer Adobe DC version has come out, when I drop that ActiveX control into a form, it fails with this message:

The OLE server isn’t registered.

However, if I use the ActiveX control from vb.net on the same computer, then the ActiveX control works just fine.

Sadly, this may force me to build a .net interop form and ActiveX control in .net that in turn uses the Adobe ActiveX control. However before I consider such a horror story (and if this can even work).

Does anyone have a suggestion on how to use the Adobe ActiveX DC version in an Access form?

Many have suggested using a browser control, but I directly use the methods and properties of the PDF control via VBA like this:

CODE
   Me.AcroPDF0.LoadFile strFileName      
   Me.AcroPDF0.setShowToolbar True
   Me.AcroPDF0.setView "FitH"
   Me.AcroPDF0.setPageMode "Thumbs"



Right now, the solution is to tell clients to NOT to update beyond Adobe 11 (been telling clients for over 1 year now – but this advice is becoming increasingly more difficult).

And the Adobe update system is REALLY aggressive – it seems to “turn on” even when disabled.

I am also open to using a different (free) PDF ActiveX control if it plays nice with Access, and will not require too much VBA code to be re-written and changed.

Any ideas welcome!

Regards,
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
kallal@msn.com
Go to the top of the page
 
jleach
post Oct 5 2016, 05:58 AM
Post#2


UtterAccess Editor
Posts: 10,021
Joined: 7-December 09
From: St Augustine, FL


Hi Albert - I don't have a resolution, but a few thoughts:

>> The OLE server isn’t registered. <<

Have you verified that the new version is indeed COM compatible and that the target version (x86/x64) is indeed registered correctly?


>> Sadly, this may force me to build a .net interop form and ActiveX control in .net <<

Just to be on the safe side, is there a way to embed .NET COMVisible UI components into an Access application? While we do it often enough with code-level objects, I've never had success with this for UI objects (there was one real headache of a solution some years ago using the Windows Interop Toolkit 2.0, but those were .NET2.0 days and even that was standing on shaky legs). Maybe you've done this in the past, but for all the attempts of myself and a few others I've known who've tried it, there's never been much luck, so before you count this as a viable option at least plan on doing a POC if you haven't done this before.

>> And the Adobe update system is REALLY aggressive – it seems to “turn on” even when disabled. <<

Indeed, Adobe components are very invasive in many respects, not just with their updates (overriding default shellExecute verbs, total PITA, not respecting toolbar configurations, etc)


>> I am also open to using a different (free) PDF ActiveX control <<

I'm not aware of any, but will keep an eye out. I know of a number of .NET components (not free) that may offer Excel integration (which should, in turn, offer Access integration)
Go to the top of the page
 
ScottGem
post Oct 5 2016, 06:49 AM
Post#3


UtterAccess VIP / UA Clown
Posts: 32,217
Joined: 21-January 04
From: LI, NY


Could you, possibly, distribute the OCX file from Acrobat 11 with the app?
Go to the top of the page
 
AlbertKallal
post Oct 5 2016, 03:01 PM
Post#4


UtterAccess VIP
Posts: 2,825
Joined: 12-April 07
From: Edmonton, Alberta Canada


QUOTE
> is there a way to embed .NET COMVisible UI components into an Access application?
> solution some years ago using the Windows Interop Toolkit 2.0


Yes, the last interop forms was 2.1, and it works up to VS2010.

I am using VS2013 == I copied a few files over from vs2010 to vs2013 - and a small edit to the config file and it seems to work just fine with vs2013.

So the answer I believe is yes one can use .net to create ActiveX.

QUOTE
While we do it often enough with code-level objects


Yes, and in vb.net you ONLY need this kind of code stub:
CODE
Imports System.Runtime.InteropServices

<ClassInterface(ClassInterfaceType.AutoDual)> _
Public Class ShipCost

    Public Function Test() As String
        Return "hello world"
    End Function

End Class


That is it!!! I am going to repeat this:

The above is ALL you need!

Simple compile above with “Register for COM interop” and make com assembly visible and you are done!

No need to build an “interface”, no need for “implements” and no need to enter or work with any GUIDS etc into the code. And the above ALSO SHOWS any public member in VBA/Access intel-sense when you early bind. I been doing the above for years now.

Contrast the above simple bit of code to other examples that are complex and “many” pages long. The above thus allows one to use to .net zip routines, .net picture resizing or any other kind of .net code in VBA – and it really is just a wee bit of code. And I even figured out how to return "currency" values that are VBA compatible.

Anyone who can read VBA, can handle the above code stub in less than 5 minutes of their time.

The trick for ActiveX in Access forms???

Exposing the class as an ActiveX that can be dropped onto a form is the tricky part. However, from what I am reading, it not that hard – it only a matter of a having a “boiled” down example. The above code stub can work – the MAGIC is WHEN you run regasm

I thus really don’t need the interop tool kit, but only a .net code stub that creates the correct “registry” entries when regasm is run. When you “regasm” the .net CLASS .dll, then some custom .net code for that object can be run – that is the “magic” part that creates correct registry enters that THEN will expose the com object as an ActiveX control (that one can drop onto a form). It is this “tiny” bit of extra code that results in the object showing up in the list of ActiveX controls. And it not a lot of code from what I looking at (only a few lines).


I shall see what I can cook up, but I am eager to try a simple ActiveX .net control regardless of the pdf issue.

Regards,
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
kallal@msn.com
Go to the top of the page
 
AlbertKallal
post Oct 5 2016, 03:11 PM
Post#5


UtterAccess VIP
Posts: 2,825
Joined: 12-April 07
From: Edmonton, Alberta Canada


QUOTE
@Scott wrote:
would you, possibly, distribute the OCX file from Acrobat 11 with the app?


Golly, a great idea. Turns out that no "ocx" control seems to exist - it is however a .dll.

If I install Adobe 11 (one that works), grab/steal the AcroPDF.dll and pdfshell.dll, place it in another folder, I can now install LATEST Adobe DC version.

Now, if I do a regsver32 on the AcroPDF.dll, then the ActiveX control now works in Access.

If I could sleep well that a update to Adobe would not break Access, then I will and am going to consider this idea. (I am reasonable sure that a auto update to Adobe will re-register the ActiveX).

So this is certainly a "off" type of solution but rather creative on your part - I can confirm your suggestion does I fact work - I just have to determine if updates will break this.

I will try and post back as to what I finally figure out. There are a "number" of people in the Access community suffering from this issue - not a huge number, but I can confirm that I not the only one suffering as a result of having embedded ActiveX PDF control in a Access form.

Anyway, thanks kindly Scott + Jack, I am comfortable that I not "missing" any mainstream easy solution(s) to this issue.

Regards,
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
kallal@msn.com
Go to the top of the page
 
ScottGem
post Oct 5 2016, 04:15 PM
Post#6


UtterAccess VIP / UA Clown
Posts: 32,217
Joined: 21-January 04
From: LI, NY


Did youu check to see if DC uses the same named DLLs? If not, there should be no concern about the updates.
Go to the top of the page
 
AlbertKallal
post Oct 6 2016, 05:37 PM
Post#7


UtterAccess VIP
Posts: 2,825
Joined: 12-April 07
From: Edmonton, Alberta Canada


>> if DC uses the same .dll's

Well, Adobe DC does have the same named dll's, but the ones from DC cannot be registered via regsvr32 (this is strange).

I don't know why I can't regsver the DC ones, but I can the Adobe 11 ones. (even with admin rights - the DC ones will not register).

So it bit "messy" in this regards. I could I suppose on startup I try creating a instance of adobe reader, and if not then execute a regsvr32 on the older .ddl's. As noted, after installing DC reader, then running regsvr32 on the older dll's does work (I copied the older .dll's to a different folder). The regular DC reader seems to run just fine, looks and quacks like the DC reader, and the ActiveX control does work in Access. If updates to DC don't break this setup - this may well be the solution I adopt until I can find a better solution. So the dll's I am using are a copy - and registering them does not seem to effect Adobe DC, but does allow use from Access.

Regards,
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
kallal@msn.com
Go to the top of the page
 


Custom Search


RSSSearch   Top   Lo-Fi    21st July 2019 - 08:49 AM