My users are unable to add macros to some brand new 5.1.8 reports they have created. This isn’t a Supervisor rights issue. Even signed in as General Supervisor it isn’t possible to do. On my machine I can do it using Desktop Intelligence or 6.5.3, but not in 5.1.8. (Most PCs only have 5.1.8, so I don’t believe it relates to multiple versions of BO client).
What is more peculiar is that if the users open a report which already has macros they can view, edit etc the macros, but in the same session they can’t create macros or even use the vba editor at all on the new macro-less report.
My current theory is that this has something to do with the operating system, this client has recently switched to XP service pack 2. On an old W2K PC this still works okay. Thoughts?! Oh, I have tried creating macros in Word and that is fine…
No, it is a custom packaged distribution. If the “download VBA support” step had been skipped I don’t think the users would be able to go Tools/Macro/Macros…and edit macros which already exist? Thanks for the suggestion though.
In those reports which already have macros, when I try to step through the code using F8 I get ‘Object library not registered’. I’ve checked tools references and used regsvr32 and regtlib to register the various dlls and tlbs…but still no joy, I need to try reinstalling the vba stuff I guess - its just next to impossible at this client. Watch this space
Do you know if, during the SP migration, they was some modification in Microsoft Office. In fact, I think the internal BO VBA editor use the Microsoft VB Editor. Have you check on the Windows Box wher you canno’t create VB macro on BO you can do it on word or excel ?
Nice one Bernard. I think I mentioned earlier on that I had tried in Word and it was okay. I have actually tried Word, Excel, PowerPoint and Outlook - no problem getting to the macro dialogue box or putting a basic macro together and running it. MS Access gives me an ‘Out of Memory’ error when trying the same thing though. I wonder if v5, v6 and XI all share the same VBA editor or if each uses a slightly different one
Ok, I see it is more a system relevant trouble than pure Bo One.
I could suggest you to investigate using the sysinternal tool to check, when trying to launch the vba editor on both good platform and bad one which DLL are called, which values are successfull or not changed in registry.
I’ve tried swapping them via Tools/References, but because you are already ‘within’ VBA at this point you can’t start using a different version of VBA. It isn’t that vba332.dll is incorrect - on non-XP PCs it is this file and exact same version that is being used. I’m thinking more and more that the package that has been used to deploy the product is just missing some several ‘bits’.
BusObj V5 does indeed use an older version of VBA, but multiple versions of VBA can easily co-exist. I agree with your conclusion. Something from the install is off. Any chance you can do a “from scratch” installation, instead of using the package?
You wouldn’t believe how tricky it will be, but yes I can and I believe the install done this way will work. However…its the installed based of users that then becomes the problem. So, I am currently trying to get hold of the person who created the package to understand if they ever had this bit of functionality working.
That file already exists. Can you be more specific about launching as administrator. Do you mean running BO signed on as a general supervisor or logging on to windows as a local admin?
Right, I tried that but it hasn’t made a difference - thanks anyway. It turns out that the test of the package basically consisted of ‘Can I sign on, yes - right it must be okay then’
(BOB member since 2002-08-15)
(BOB member since 2002-09-19)
(BOB member since 2002-08-15)
(BOB member since 2003-05-26)
(BOB member since 2002-09-19)
(BOB member since 2006-11-09)