|
Oliver Giesen
Posts: 77
Joined: 2006-08-07
|
In the olden days, a backstage view would have been an option page and thus completely and neatly isolated in its own unit and accompanying dfm file. Now, AFAICT I have to put all of this into the main addin module.
Now, with the toolbars and ribbons I basically had the same problem but those were typically still easily manageable. An option page or a backstage view however can be a pretty extensive and complex bit of UI that I would rather like to keep out of my addin module. Is there some recommended way to avoid this and have the code in a separate unit again?
I can already think of a couple of ways to accomplish this but none of them seems really ideal so I was wondering what the ADX team thought about this. Maybe I was overlooking something? Is there maybe some easy way to put ADX components on secondary data modules or something like that?
Cheers,
Oliver |
|
|
Alexander Solomenko
Posts: 140
Joined: 2009-02-27
|
Hi Oliver,
Frankly speaking, it is really inconvenient to have the most of the code in the AddinModule.
But this is the way wizard Add-in Express works.
I can suggest two ways to improve your code:
1. The first one is more complicated. Don't use the wizard. Create all components and their events manually in RunTime.
2. Leave In the AddinModule only components and events only, and move the functional to separate modules. For example, to the AddinModule. There must be as follows:
........
procedure TAddInModule.adxBackstageViewShow(Sender: TObject; const Context: IDispatch);
begin
//Calling the method from the BackstageUnit from the class TMyBackstageView
MyBackstageView.DoBackstageViewShow(Sender, Context);
//MyBackstageView is instance from the TMyBackstageView class
//which needs to be created in the AddinInitialize event
end;
and in the BackStageUnit unit:
TMyBackstageView = class
...
procedure DoBackstageViewShow(Sender: TObject; const Context: IDispatch);
end;
implementation
procedure TMyBackstageView.DoBackstageViewShow(Sender: TObject; const Context: IDispatch);
begin
//Implementation of the BackstageViewShow event
end;Regards,
Aleksandr Solomenko |
|
|
Oliver Giesen
Posts: 77
Joined: 2006-08-07
|
Hi Alexander,
thanks. Yes, those were the two ways that I had been thinking of as well.
I'm not entirely sure the first one would (easily) work, as I seem to remember that ADX (or Outlook itself?) makes some assumptions about when ribbon controls are created/defined.
It's still the option I would prefer out of the two, though. As it is, creating the backstage view in code wouldn't really make a whole lot of difference from using the designer to add nodes to a tree view in the current version of ADX. This doesn't quite have the same level of productivity benefit as the Ribbon designer.
Another, more elaborate approach would be to create something similar to the existing forms manager plus a custom module editor that can host and design TadxBackstage* components independent from the main module...
I've still got a little over a month to the deadline so I'm still hoping for a response from the ADX team before I start that endeavour. ;)
Cheers,
Oliver |
|
Forums
Topics
Search
Help
Login
Register