"(PeteCresswell)" <x@y.Invalid> wrote in
news:i6ncu6h3j9ns5g62i871ha7bur6r6q48mt (AT) 4ax (DOT) com:

You need to get away from using the Treeview from that OCX.

The lack of a native treeview control (something that was introduced
widely in Windows 95!) is a real deficiency of Access, in my
opinion, but the lack of a native control means I'm just not going
to use a treeview in any of my applications.

It's very often the case that cascading datasheets (which are a form
of treeview) can do some of the work here, but in the past, I've
replicated the functionality with formatted listboxes (i.e.,
listboxes where indendation indicates the level). It's not pretty
like a treeview, but I'd much rather avoid the difficulties of
porting away from it that will eventually happen. I used two 16-bit
OCX's in Access 2 to allow me to use controls that weren't native
(tab strip and multi-select listbox), and it meant that the apps
using those OCX's did not get upgraded until long, long after all
their siblings, because the dependencies were so difficult to
disentangle. That taught me the lesson to simply never use
non-native controls so as to not hold future development of the app.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

"(PeteCresswell)" <x@y.Invalid> wrote in
news:kiocu61f6mb5h4j23k2hqk9bvg4mad29a5 (AT) 4ax (DOT) com:

Can it be done with late binding? If so, that would be my
recommendation. If it can't, I'd look for some other way to create
spreadsheets with code modules. Surely importing code modules can be
automated without a reference to the VBIDE.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

"(PeteCresswell)" <x@y.Invalid> wrote in
news:ns3du6h269tgjjkk9eloru6qksk2aud815 (AT) 4ax (DOT) com:

I can't imagine getting my code twisted into a state where I'm using
Application.Run with Excel.

I would code around this and use some other way to get the job done,
rather than running an Excel macro with Application.Run.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

On 5/30/2011 5:44 PM, David-W-Fenton wrote:
....
In Access 2007, the Microsoft Office Object Library (MSO.DLL) seems to
be absolutely required in order to declare the IRibbonControl object for
ribbon callbacks.

In all versions of Access, the command bars and toolbars can be
manipulated without an MSO reference, by using late binding with generic
objects, though that can be tedious if you have lots of customization.
But apparently not the ribbons.

A sample ribbon callback procedure is declared like this:

Sub GetSelectedItemIndexDropDown(control As IRibbonControl, ByRef Index)

The IRibbonControl argument above will not compile without the MSO
reference.

When you try to use a generic Object in the declaration in place of
IRibbonControl (late binding), the code compiles of course, but the
ribbon callback procedure NEVER GETS CALLED, at least in my experience.
This was a surprise to me, but I could never get it to work with Object.
(It's possible I did something wrong, but all I did was change
"IRibbonControl" to "Object", compile, and test.)

So the ribbon seems to require a reference to the Office Object Library.

In your case you probably have no customized ribbon code, so you do not
need it. These days that may not be the usual case, which is why I am
posting this.

Steve

Sky <Sky (AT) NoSpam (DOT) com> wrote in news:isb9f9$7am$1 (AT) dont-email (DOT) me:

I have no ribbon code at all, as I'm not targetting anything beyond
A2003 yet (because of the needs of my particular clients).

This is a very bad thing, in my opinion. I don't know why they
couldn't have put the functionality somewhere else, or provided a
wrapper for it in the main Access application object (as with the
FileDialog object).

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/