Posts 1 - 10 of 20
First | Prev. | 1 2 | Next | Last
|
|
|
|
Oliver Giesen
Posts: 77
Joined: 2006-08-07
|
Apart from the fact that modal dialogs in general are quickly going out of fashion, I found that it has also become increasingly difficult to make them work correctly from within an Outlook addin, especially during the startup phase. After my experiences with Outlook 2010 on Windows 7 I decided to give up and try a different approach.
My current goal is to replace the modal message boxes with more discrete "notification bars" similar to those used by most modern browsers nowadays. My initial idea was that ADX' form regions with elDockTop or ilTopSubpane should be able to provide the required functionality. However, after my first quick&dirty proof-of-concept tests, I'm not so sure anymore that it would be as straightforward as I initially thought. Especially the "folder-centricity" of form regions seems like it might become a problem down the line, e.g. how do I get my notification to be persistently displayed regardless of folder selection? I essentially need this to be a singleton (at least for Explores - Inspectors should each have their own instance).
So, before I invest any more time in this: Has anyone else tried anything like this already?
If so, was it worth it?
Is there maybe a better approach?
Cheers,
Oliver |
|
|
Posted 24 Nov, 2010 06:40:42
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18829
Joined: 2006-05-11
|
Hi Oliver,
The "folder-centricity" can be bypassed by specifying the widest possible context for the corresponding TadxOlFormsCollectionItem. Also, pay attention to the TadxOlFormsCollectionItem.Cached property, it allows using the same instance of TadxOlFrom across any folders of a given Explorer window.
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 24 Nov, 2010 09:55:20
|
|
Top
|
|
|
Oliver Giesen
Posts: 77
Joined: 2006-08-07
|
Hi Andrei,
thanks, I indeed managed to bypass the "folder-centricity" by enabling all ExplorerItemTypes and setting the Cached-property to csOneInstanceForAllFolders (I haven't experimented with notification bars in Inspectors yet, though - in that case I would want one instance per individual inspector - would I have to set Cached to csNone then?).
However, the next potential showstopper appears to be how to control visiblity of the region. So far, I haven't managed to hide the region or control its size at runtime or even just have it initially hidden. The OI does not allow me to set DefaultRegionState to rsHidden and I don't know why. IsHiddenStateAllowed is set to True. AlwaysShowHeader, CloseButton and IsDragDropAllowed are all False Splitter is sbNone.
Is there any example code out there showing how to work with form regions in code? All the demos I found so far set up everything at designtime.
Cheers,
Oliver |
|
|
Posted 26 Nov, 2010 09:15:27
|
|
Top
|
|
|
Oliver Giesen
Posts: 77
Joined: 2006-08-07
|
OK, I pretty much got visibility and size control working now (at least for Explorers), though it feels awfully like quite a hack: I've assigned an ADXAfterShow event handler and call Hide from there when I don't want the region to be shown. There's a better way to achieve this, isn't there?
On to Inspectors next.
Cheers,
Oliver |
|
|
Posted 26 Nov, 2010 10:30:46
|
|
Top
|
|
|
Oliver Giesen
Posts: 77
Joined: 2006-08-07
|
I've gotten quite a bit further now. However some minor issues remain:
- I can't seem to get rid of the splitter for the region displayed on inspectors (i.e. the second one in the DFM snippet below) even though Splitter is set to sbNone.
- I haven't managed to display a region on an Explorer with elDockTop layout that is less than ~30 or so pixels high (I'm aiming for 22). It seems there's a minimum height for elDockTop form regions. Can you confirm this? It works on Inspectors with ilTopSubpane, though.
- I'm still wondering why it doesn't seem to be possible to set an Explorer region's DefaultRegionState to rsHidden. It does work for the Inspector region. However, with the inspector it was a little tricky getting a reference to the current inspector's form region as TadxOlFormsCollectionItem.GetCurrentForm only allows getting visible or active form instances but with DefaultRegionState=rsHidden the instance in question is neither... I ended up mimicking the code in GetCurrentForm just without the checks for Visible or Active.
So far, I have only tested with Outlook 2010 on Windows 7 in case that matters.
Here's the snippet of my DFM that declares the two form regions:
object FM: TadxOlFormsManager
Items = <
item
ExplorerItemTypes = [expMailItem, expAppointmentItem, expContactItem, expTaskItem, expJournalItem, expNoteItem, expPostItem, expDistributionListItem]
ExplorerLayout = elDockTop
InspectorItemTypes = []
ExplorerAllowedDropRegions = [erDockTop]
Cached = csOneInstanceForAllFolders
Splitter = sbNone
FormClassName = 'THintBar_Rgn'
end
item
ExplorerItemTypes = []
InspectorItemTypes = [insMeetingRequest, insMeetingCancellation, insMeetingResponseNegative, insMeetingResponsePositive, insMeetingResponseTentative, insMail, insPost, insTaskRequest, insTaskRequestUpdate, insTaskRequestAccept, insTaskRequestDecline]
InspectorLayout = ilTopSubpane
Cached = csNone
Splitter = sbNone
FormClassName = 'THintBar_Rgn'
DefaultRegionState = rsHidden
end>
end
|
|
|
Posted 29 Nov, 2010 06:17:55
|
|
Top
|
|
|
Oliver Giesen
Posts: 77
Joined: 2006-08-07
|
OK, so my previous comment regarding the "splitter" was incorrect: The thing I'm seeing there is in fact not a splitter. I have no idea what it is called, though. It's a "grippy"-style button/bar that allows the user to collapse the form region. If I'm not mistaken it even defaults to the collapsed state (I think I clicked it instinctively the first time I saw it and apparently it remembers its state).
Can this be suppressed somehow? Or is there at least some way to programmatically expand the region when the user has collapsed it? As I intend to use this region also for error messages it would be really bad if the user didn't see them because they appear in a collapsed region... :-/ |
|
|
Posted 29 Nov, 2010 07:43:38
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18829
Joined: 2006-05-11
|
Hi Oliver,
Oliver Giesen wrote:
I haven't experimented with notification bars in Inspectors yet, though - in that case I would want one instance per individual inspector - would I have to set Cached to csNone then?
Caching isn't available when showing your forms in inspectors windows.
Oliver Giesen wrote:
it feels awfully like quite a hack: I've assigned an ADXAfterShow event handler and call Hide from there
You can set Self.Visible := false in that event handler.
Oliver Giesen wrote:
I'm still wondering why it doesn't seem to be possible to set an Explorer region's DefaultRegionState to rsHidden.
Thank you for copying here the settings of the items. You cannot set DefaultRegionState := rsHidden because docked panes don't support that property. That is, docked panes can not be shown in the minimized or hidden state.
To size the form programmatically, you need to have TadxOlFormsCollectionItem.Splitter set to sbNone. To activate the form use TadxOlForm.Activate().
There's a number of samples in the Advanced Outlook Region section in http://www.add-in-express.com/support/addin-delphi.php#form-regions.
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 29 Nov, 2010 11:28:58
|
|
Top
|
|
|
Oliver Giesen
Posts: 77
Joined: 2006-08-07
|
|
You can set Self.Visible := false in that event handler.
OK, and that is different/better than calling Hide() how? ;)
You cannot set DefaultRegionState := rsHidden because docked panes don't support that property. That is, docked panes can not be shown in the minimized or hidden state.
OK, so a region state of rsHidden is different from hiding the region (i.e. calling the Hide method or setting Visible := False)? I'm just asking because the latter appears to be working nicely...
Also, I hadn't really been aware so far that the elDockTop layout is special when compared to the other layouts. Apart from the fact that according to the release notes this layout is not supported on Outlook 2003 and earlier (I'll just fall back to elTopSubpane in that case), is there anything else I should be careful about when using this layout?
All in all, I've pretty much got the whole thing working the way I want it now, except for the minimum height of the elDockTop region. It would be great if you could give me either a confirmation or a solution on this one.
I was indeed able to work around the "grippy" issues by calling Activate().
Cheers and thanks for your assistance!
Oliver |
|
|
Posted 30 Nov, 2010 05:19:32
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18829
Joined: 2006-05-11
|
Hi Oliver Giesen,
Oliver Giesen wrote:
OK, and that is different/better than calling Hide() how? ;)
:)
Oliver Giesen wrote:
OK, so a region state of rsHidden is different from hiding the region (i.e. calling the Hide method or setting Visible := False)? I'm just asking because the latter appears to be working nicely...
Yes, correct. Pay attention to the "Normal, hidden and minimized task panes" section in http://www.add-in-express.com/docs/net-task-panes.php.
Oliver Giesen wrote:
the minimum height of the elDockTop region
It is equal to 33 pixels without the border width.
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 30 Nov, 2010 07:29:10
|
|
Top
|
|
|
Oliver Giesen
Posts: 77
Joined: 2006-08-07
|
|
Pay attention to the "Normal, hidden and minimized task panes" section in Custom task panes. Ah, I had missed that information as so far I had only been browsing the docs on ADX for VCL...
It is equal to 33 pixels without the border width. Thanks for the confirmation! That's good to know.
Looks like I've got all I need now (for the moment at least ;) )
Cheers,
Oliver |
|
|
Posted 30 Nov, 2010 10:43:51
|
|
Top
|
|
|
Posts 1 - 10 of 20
First | Prev. | 1 2 | Next | Last
|
Forums
Topics
Search
Help
Login
Register