After serious thinking Peter T wrote :
Ah yes, guess I've never had need to take advantage of that possibility.
OK, but although it's possible to include multiple 'Connect' classes for
different apps, and stylistically that's probably a good idea, it's not
necessary. In the Connection events can start with say a Select Case to cater
for differing 'Application' object passed in the original OnConnection event.
While this may be doable, I don't think the intent of the text was to
suggest doing it that way. My understanding of adding a separate
designer for each use is so the appropriate flags/headers are set up in
the DLL during compile so each MSO app can know it's there AND what its
startup behavior should be. What you propose suggests that Word would
intuitively know the Excel designer is not a Word COMAddin, and so how
does it determine where to find its COMAddin designer when it won't
load an Excel COMAddin?
Sorry I don't follow "pass the xml". How/whereis the xml stored, how and when
is it passed to Excel, then what does Excel do with it.
FWIW, in the Connect class I do something like this
Public Function IRibbonExtensibility_GetCustomUI(ByVal RibbonID As String) As
String
s = LoadResString(1001)
IRibbonExtensibility_GetCustomUI = s
where 1001 refers to the entire XML stored in th Resource
You've answered your own question! You store it in a res; I store it in
a function (as indicated below). The reason I store it this way is
because <IMO>it's easier to work with if I don't have to edit a res
file.
Another benefit to storing it in a function is that I can easily
configure it for different startup scenarios. Using a res I would have
to have a different one for each scenario. Keep in mind that we only
get one shot at this, and thus we can't revise it after startup. I can
change whatever I want on my menus/toolbars at runtime.
Indeed. That also means the if the dll is to cater for the Ribbon it means
having different versions of the dll for 2000/3 and 2007+ (otherewise could
simply set the reference to the lowest Excel version).
Not really! I use the same DLL for all versions. Since the earlier
versions don't recognize IRibbonExtensibility then it's ignored
(without raising an error).
What reference context are you referring to here?
Sorry I'm confused again, in v12 do you have an XLA(m). If the ComAddin
already handles the entire Ribbon why do you need old style menus & toolbar
in v12 (in the Addins tab).
The COMAddin handles UI setup, which includes the ribbon. I do not have
a separate xlam for v12. I use the same xla for all. In the earlier
versions, my toolbar has IsMenubar set to TRUE so that the instance is
only using my menus/toolbars. To duplicate this in v12 I need to get
rid of the entire ribbon except for the Addins tab because that's where
Excel put the menus/toolbars created by the xla. This then, mimics that
the instance is only using my menus/toolbars.
So in practice, why would I want to have separate COMAddins or XLAs for
each when I have a working solution that does it all with one of each?
Less to distribute, maintain and service!
I got the orignial version when it first came out, maybe I should look at the
2007 version!
Ron's site is a valuable resource (thanks Ron). I confess though I am still
not fully up to speed with the Ribbon )-:
I'm probably being real dumb here but if all your menus etc are in the Addins
tab (ie same code to create and handle them as in previous versions), why do
you need to be concerned with the Ribbon, Implements IRibbonExtensibility
etc.
I guess your app's are designed with very specific purposes in mind.
Absolutely! Most of what I'm doing is task-driven and tailored to
user-defined specifications. I also implement the same structure for my
proprietary apps, though I haven't yet got them all converted over from
workbook-based addins.
I'd like to reach a point where I'm not dependant on M$O apps, but it's
hard to do when clients insist on having that. The release of v12 and
the ribbon concept is what set me off about continuing developing for
M$O Excel. I plan to sever my proprietary apps over time, but may not
also. (I have Farpoint Spread ActiveX, and so have already began the
switch!)
Ah, so it's just a matter of not yet getting around to moving the old-style
toolbar creation and OnAction entirely into the ComAddin.
Basically, that's correct. As for calling the menus/toolbar creation
'old-style', <IMO> Rob's table-driven system is 'state-of-the-art'
compared to any others I've seen. So in terms of speaking 'old-style',
constructing these line by line in a sub/function better qualifies as
'old-style', ..I would think!
Back to the my first thoughts again, apart from the Threading aspect there
doesn't appear to be any need for the aX dll to be a ComAddin, right? Though
I'm still unclear why you have some Ribbon stuff in a v12 version.
You have just stated the primary reason why the DLL has to be a
COMAddin. AFAIK, this is the only vehicle by which we can customize the
ribbon via code. Otherwise, using an ordinary DLL would require also
using separate addin workbooks. This will not fly with my security
obsessed clients.
I might use regular DLLs to add extensibility to my core apps if users
want to enhance it with features/functionality specific to their use of
my product. Since this use will vary between clients, I offer this by
way of user-defined Plugins. If the app is Excel-based then it could
also be provided as a xla that updates my menus/toolbar with their
menus. In this respect, my addins also host other addins. This is
harder to do in a VB6 project because VB doesn't have any built-in
mechanism for hosting addins. The best solution to mimic this that I've
been able to come up with so far is to call a DLL that displays a Form
with menus/toolbar that looks and behaves like a floating toolbar. What
I want is to be able to add menus to my menubar same as Excel does when
we add menus to its menubar. Progress to this end is doubtful since VB
is waining fast as a supported development language.<g>
I want an approach that offers me advantages as a developer while also
catering to client needs. I just don't see any sense in doing lots of
extraneous work to do simple things. I'm productivity oriented in my
thinking and so I try to reflect this in my work. I'm in the business
of creating productivity solutions for others, and so that mindset
causes me to use that thinking for myself, too.
Think I know roughly what you have there but I've never found it a problem to
do entirely within VB6, and without cells to lay out the menu details
I guess if you're used to doing this line by line in code then there's
no change from normal for you. Line by line is how I started and
converted to table-driven methodology as soon as I saw my first
example.
I can do line by line in a manner that's easy enough to follow and
maintain, but it's going to be hard (now) for anyone to convince me
that a table-driven system isn't a measureably better way to do this.
Unless you've got a vast number of buttons simply a few har coded arrays. Or
read from a text file.
Well, I think storing the table data in a text file is the way I'll do
it. I think using ADO to read that data as a recordset and dump it into
a grid control might be best since the bBuildCommandbars routine is
already design to walk through a table.
I don't want to 're-invent the wheel'. I was thinking I'd move the code
into the form class so it's an encapsulated component that I can drop
into any VB6 COMAddin or Plugin.dll project so it serves both. Bear in
mind that this is used only when complex menu structures are needed.
Since I use it to modify built-in menus and create my own toolbars and
popups, I'd like to have that flexibility for both core apps and Plugin
DLLs.
That of course is the main thing!
Interesting
But on the limited time use don't you still need some sort of license/key
combination.
Yes, that's true. I have a VB6-based licensing methodology worked out
that can I use for both workbook-based addins and VB6 apps/dlls. I
assume that your use of 'key' means the typical delimited serial-style
text string used by many. I don't use these because for the amount of
data that I store in a license code, they would be a paragraph rather
than a limited length string of characters. Instead, I ship a
License_Activator.exe that runs from within the app folder.
FWIW I find if the reference is set to v9 and it compiles it should work for
all versions. For specific later version stuff say with the range object, Dim
objRng As Object (not range), then objRng.NewMethod will also compile. So no
real need to develop in VBA at all. That said, a lot of things need to be
rewritten in v12 irrespective of the reference issue.
Hmm! I think I prefer to develop for later version stuff in that
version and using normal references as pertains to each. I guess it's
just my nature to always be testing as I go, and so having multiple
versions installed on my dev machine provides me the convenience to
have instances of each version running simultaneously.
In order to test a COMAddin we have to close all instances of Excel,
compile it, reopen all instances of Excel to test. Again, why take the
long way around when the code is portable between the two?
Yep, a lot there and thanks.
Sure!
Bear in mind that the approach I've discussed here is my purposed
method to mimic using dictator style addins as efficiently as possible
across all versions. This does not discount that what we would do for a
normal Excel addin isn't viable. I would be doing those same things the
same way in those cases where my users want my solutions available in
their standard instance of Excel.
I guess because I was forced to take this approach to serve client
needs, I've had to travel down a not too well travelled path to get
here. I don't mind sharing that, or even hearing suggestions that might
be an improvement.
I'm still a bit confused though about what's in the xla & the dll,
especially re v12 Ribbon stuff.
Well, I certainly was confused about ribbon stuff too at first. I hope
our dialog leaves you a bit less confused now, though.
I guess what it ultimately boils down to is what you're trying to
achieve in the end. In using workbook-based addins there's no choice if
we want to customize the ribbon because we have to do that within the
workbook xml. Bob Phillip's example is the best I've seen yet for
handling that. Using automated instances just gives us more flexibility
and overall control over tailoring the UI for our purposes<IMO> because
we're not messing with the user's default instance. (<FWIW>I strongly
support the notion to NEVER hijack a running instance for any reason
whatsoever)
regards,
Garry