|
|
|
Tim Smet
Posts: 37
Joined: 2015-10-06
|
Hi,
Because you can have multiple mail windows open when trying to send an email, so composing multiple emails at once we could not control the TAdxRibbonButtons directly because if you change the property using the variables that get created when adding these ribbon buttons. It will change for example the pressed and enabled state for all open windows (instances) instead of just the one you are using.
Because of this we implemented something that was suggested here " https://www.add-in-express.com/creating-addins-blog/2013/01/30/preserve-outlook-ribbon-controls-state/ " on how to preserve control state.
We created a GetStateProperty and SaveStateproperty function and for each TadxRibbonButton we have that is shown on the mail compose window we assigned the propertychanging event to read the state using getstateproperty. This all works as it should wherever we use it except on one place.
It seems the event for propertychanging is only fired once (for each adxribbon button properties) the 1st time you open a mail compose window. but not for any other mailcompose windows we open afterwards. This creates the problem that the button states (like pressed and enabled) of the previous send email is rememberd and show when we open a new compose mail window (to send another email). I partially fixed this by using the itemsend event and reverting all properties (using savestateproperty) to its initial value so that when we open a new compose mail window this problem does not occur.
However this only works if we acctually send the composed mail not when we cancel sending (by closing the compose windows). So in that case opening a new compose window after we cancelled a previous one will take over the ribbon button states of the previous (cancelled) mail compose.
The cullprit is it seems that the propertychanging event does not fire again as said before.
So how can we fix this ?
Is there an event we can use somewhere when the compose mail window gets closed so we can revert the ribbonbuttons states there or even better an event that fires whenever a compose mail window is opened so we can set initial button states for this compose mail instance there ?
Any other idea's ?
Thanks
Edit: i just found the outlookappevents i see there are onnewinspector or oninpsectorclose events but how can we know for example with onnewinspector event that the inspector is the compose mail window ?
Edit2: I currently added following code in the onnewinspector appevent
if Inspector.Class_ = 35 then //olinspector
begin
adxribbontabSaveSendMail.Invalidate;
end;
The adxribbontabSaveSendMail is the ribbontab that is displayed only on a compose mail window. The invalidate forces a redraw / refresh of the ribbontab and makes sure the propertychanging is called again. I also noticed the invalidate does not trigger propertychanging event if there is no compose mail window open. But still when opening a received mails the code above gets still triggerd but does not trigger a propertychanging event on the ribbontabutton items. This seems to work but i'd like to be able to only execute above code on a compose mail window and not on received / send items you open but only for the compose mail window |
|
|
Posted 27 Apr, 2017 04:09:03
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 17221
Joined: 2006-05-11
|
Hello Tim,
Tim Smet writes:
Because you can have multiple mail windows open when trying to send an email, so composing multiple emails at once we could not control the TAdxRibbonButtons directly because if you change the property using the variables that get created when adding these ribbon buttons. It will change for example the pressed and enabled state for all open windows (instances) instead of just the one you are using.
On how to solve this task, please see section "Updating Ribbon Controls at Run-Time", see the PDF file in the folder {Add-in Express}\Docs on your development PC.
Does this solve the issue you described in your post?
Regards from Belarus (GMT+3),
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 27 Apr, 2017 07:11:46
|
|
Top
|
|
|
Tim Smet
Posts: 37
Joined: 2015-10-06
|
Hi Andrei,
we are already using PropertyChanging event as described there that's not the problem.
The problem is it only fires once if we press "create new mail" it will fire (for all ribbon ribbon tab buttons and its properties like visible, enabled, pressed). Then you change for example the pressed or enabled state by clicking on the button and close the new compose mail window (so don't send email) then you click again on the button for creating a new mail this time the PropertyChanging never fires making it use (cached by outlook) values from the previous opened mail window. Our Getstate function already gets the correct values (inside the PropertyChanging event) the problem is it's not fired ever again when composing a new mail after you composed at least one email before. It's not even fired when you create new mail (it fires now if it's first time you open a new mail window) then send mail then click send mail again this opens a new compose email window for the 2nd time but PropertyChanging never occurs and it's using the previous (cached by outlook) state of the buttons.
I found away around it as i explained above by using the newinspector event and explicitly calling adxribbontabSaveSendMail.Invalidate which forces a redraw of (all) adxribbontabSaveSendMail instances and (also) forces the PropertyChanging event to trigger thus correcting / fixing the issue i described above. The problem is we call adxribbontabSaveSendMail.Invalidate too much since we don't know how to know the inspector is a "compose new mail window" in the newinspector (it also fire for example when double clicking on received mail in the inbox folder as it opens that mail in a new window but it's not a compose new email window). I looked in google and could not find a way to know if its a new compose window or not.
i can probably create a small sample addin to show the problem i'm talking about.
Currently i'm thinking of leaving the code as is with the newinspector to force trigger PropertyChanging when opening a new compose mail all the time and not just when opening it for the 1st time. |
|
|
Posted 27 Apr, 2017 07:40:28
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 17221
Joined: 2006-05-11
|
Thank you for the explanation.
I believe you've run into what we call "cached inspector". I would try to call TadxRibbonTab.Invalidate before or soon after the new compose email is opened. You can find this out: intercept the Ribbon button creating a new item and call TadxRibbonTab.Invalidate in the next InspectorActivate event.
Regards from Belarus (GMT+3),
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 27 Apr, 2017 08:02:47
|
|
Top
|
|
|
Tim Smet
Posts: 37
Joined: 2015-10-06
|
Hi Andrei,
I do think it's indeed caching the compose new mail inspector as that's what i'm basically seeing.
I was preparing an example project that shows you the problem we are having before i noticed your post above. So i'll be checking out what you posted above. The thing is i was already trying to call TadxRibbonTab.Invalidate but using the newinspector event not the activate one, which seemed to fix our problem but my main problem was that's it's being call too much.
I'll check out what you said and see if i can come up with a better way.
However since i already created the sample app to show the problem here it is:
http://www.dataconsult.be/davy/DcsOutlookAddin%20addinexpress.rar
compile it and run in outlook 2016 compose a new mail and click on one of the new ribbonbuttons on the left so it's gets a visible pressed rectangle around it. then close the mail and click again on compose new mail you'll notice the button you clicked is still pressed down and the propertychanging event (that would reset the pressed state) is not being called.
if you remove the exit call in NewInspector you'll notice that fixes it but that event triggers a lot (eacht time you open a received mail or a send mail) so for the received mail items where the ribbon tab is not being displayed it's being called unnecessary. And it was that i tried to prevent by looking for a way to know if the inspector is the compose new mail inspector
Look for code with comments //ADDIN EXPRESS:
Also please let me know if you had downloaded the sample so we can remove it from our site.
I will now check what you said and try to use the activate event
edit:
Hang one have to edit the sample addin as it's still using one of our own controls (the image list you need to replace it with normal imagelist and remove dcsctrls unit
edit2:
Ok fixed it, it's now using a normal image list and removed the dcsctrls dependency |
|
|
Posted 27 Apr, 2017 08:43:53
|
|
Top
|
|
|
Tim Smet
Posts: 37
Joined: 2015-10-06
|
Hi Andrei,
I figured out a way to know if the inspector is a new mail compose inspector thanks to this thread: https://www.add-in-express.com/forum/read.php?FID=5&TID=12967
I basically check for inspector.currentitem being a mailitem then inspector.currentitem.sent and inspector.currentitem.submitted both being false if that's the case it's a new compose mail window as with reading a mail sent is true even for received items it seems |
|
|
Posted 27 Apr, 2017 09:26:24
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 17221
Joined: 2006-05-11
|
Tim,
I've downloaded the archive.
Regards from Belarus (GMT+3),
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 27 Apr, 2017 09:29:44
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 17221
Joined: 2006-05-11
|
|
Tim Smet writes:
I figured out a way to know if the inspector is a new mail compose inspector
Where do we stand now? Does calling Invalidate works for you?
Regards from Belarus (GMT+3),
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 27 Apr, 2017 09:58:51
|
|
Top
|
|
|
Tim Smet
Posts: 37
Joined: 2015-10-06
|
Hi Andrei indeed it does, it had always worked and i was doing that just too much because i could not detect a way to know if an inspector was a compose new mail window and i had found a way to do that by using sent and submitted boolean values of the inspector.currentitem if both are false it's almost definatly a inspector that is a new compose email. There's just one exception (but could be considered the same) being that if you save your mail from the compose window as a concept (so it's not sent) and reopen it later on sent and submitted are both still false, but still it's okay at least now i'm not doing it for received mails.
So i consider it solved now via the invalidate system with the newinspector event (intstead activate as that triggered more then newinspector).
Cheers & thanks. |
|
|
Posted 27 Apr, 2017 10:06:14
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 17221
Joined: 2006-05-11
|
Thank you, Tim!
An email just created has an empty string in its EntryID property. This property is set when you save the email. That is, an email opened from Drafts has EntryId non-empty.
Regards from Belarus (GMT+3),
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 28 Apr, 2017 01:51:22
|
|
Top
|
|
Forums
Topics
Search
Help
Login
Register