event handler problems c# - c#

I have a handle that fires when the ItemAdd event is triggered on the Sent Items folder in outlook. This handle prompts the user and depending on their selection then opens a custom windows form to save the sent email.
Now ... heres what happens ...
The prompt shows fine when an item is placed into the Sent Items folder, if you dismiss it it will show again fine the next time the event is triggered, and so on.
If you accept the prompt, the windows form shows and are able to save the email. But the next time an email is placed into the sent items folder the event doesnt fire, and hence the prompt doesnt even show!
if i put the same handle on Outlooks OnSend event instead of on the ItemAdd for the sent items folder all works just the same, except after the windows form is loaded the first time it will continue to be loaded (ie the event fires and is handled) perfectly the next time you want it to.
It appears showing the windows form for some reason causes either the event to stop firing or the handle to drop off the sent items folder (but only the sent items folder). The latter being more likely i think. I have an idea for a work around but im not really a fan of work arounds if i can get away with it.
Would anybody know what might be going on here?
Many thanks in advance to any thoughts people may have.
Cheers,
Stuv

I had a similar problem. It sounds like one of your variables is getting garbage collected. If you can post some code I might be able to help you.

Related

How to get save confirmation dialog result of outlook

I don't know how to get result of save confirmation dialog of outlook (in C#).
This confirmation box is opened up by following:
Open mail in outlook
Made some changes in content
Close the mail
Please refer this image
I want to get this opened save confirm box and its result.
Thanks in advance.
Track the MailItem.Close / Write / AfterWrite events - Close will fire immediately before the prompt is shown, Write fires before the message is saved, AfterWrite immediately afterward.
There is no trivial way of getting such information. But you may track the sequence of events fired for the item and realize the answer following that way.
First, to handle item-level events you may develop a wrapper for an Outlook item like described in the Implement a wrapper for inspectors and track item-level events in each inspector article.
The MailItem.Close event is fired when the inspector associated with an item (which is an instance of the parent object) is being closed.
The MailItem.Write event is fired when an instance of the parent object is saved, either explicitly (for example, using the Save or SaveAs methods) or implicitly (for example, in response to a prompt when closing the item's inspector).
So, if you have got Close fired following by the Write event - that is your case!

Outlook Add-In: event when email is moved through inspector

I need to change the category of a email when the inspector-window is closing - what I am doing with the Close event.
My problem is, if the user clicks "move to folder" in the inspector, the mail is moved, after this the close event is fired, but at this point I coannot change the mail any more, because it was changed trough the mail-move (eg: EntryID gets changed).
Any ideas?
An "before-Item-moved" event on the mail would be great - or a way to reload the changed mail.
Unfortunately there's no easy way to get folder that the email was moved to. Which means you'll have to use Redemption which has events for the RDOStore object that can detect changes to any folder. But you'd also have to monitor EVERY store, because the user can obviously move it anywhere. And because the EntryID has changed, you'd need to use PR_SEARCH_KEY as the unique identifier in order to even find the email and then apply the category to it. Not fun!
Another option may be to repurpose the Move To Ribbon button to intercept the move operation, but then you'd have to provide your own folder picker! Ugly!
There is a BeforeMove event available:
https://msdn.microsoft.com/en-us/library/microsoft.office.interop.outlook.inspectorevents_10_event.beforemove%28v=office.14%29.aspx

Refreshing interface in Windows Phone when reactivating

In my first WP7 App, I have all resolved (with MVVM pattern) except for recovering the App from inactivity. I have a main screen with a list of database ítems and a field for each one that, depending on a value and the actual day, shows one value or another (not a calendar, but the same problem).
If the user goes home and, the next day, resumes the App, the calcs must be done again, to refresh the contents. Also, in a second screen happens the same: what it shows depends on the day it is.
How can I detect the activation (I know it is on the Application_Activated function, but don't know how to use it) and refresh all that I need (a refreshInterface function in my second screen, if the user leave the App there, and the main list in the main screen).
I don't need to save nothing in deactivation, just refresh data on activation only.
In your page's OnNavigatedTo method you can subscribe to Application.Activated event (don't forget to unsubscribe in OnNavigatedFrom). In the event handler you can then update the viewmodel.

Shared addin (Outlook currently) - toolbar button works a bit, then stops, no errors given

Bit of a weird one this: I've got a shared Office addin that currently targets Outlook 2007 on XP and Win7 (Excel/Word and other versions later). It adds a toolbar button, and this fires off my code. My code just reads data from Outlook. First time round, it works a treat. Second time, the button click does nothing. No errors, nothing. The rest of Outlook responds as normal.
The entire event code is in a try/catch that writes any exceptions out to a temporary file (this mechanism works if a throw an exception in code), but nothing is picked up.
According to the "Trust Center", my addin is active (not inactive or disabled). If I restart Outlook, or stop and start the addin via the Trust Center, it again works once and then stops.
If I reduce the amount of work my code does, the button will sometimes respond for about ten clicks or so, then gives up. Whichever version of my code I try, resources don't seem to change much (memory moves up a mite, the thread count stays the same).
I've read of a similar thing with Word, but this was explained by Word recreating the toolbars or menus every time it loads a document (not sure how correct this is). For me, I select an email, click once, it works, click again (no changing views in Outlook, selecting different emails, etc), and it doesn't.
Has anybody got any clues here?
You should place the variable that contains your toolbar buttons to a global scope (You can keep then as fields of the addin object). If you don't keep a valid path to them at all times, .NET garbage collector will eventually clean up these objects and the event handlers with it. This will however not remove the visible button so it will still be visible.

Silverlight IsolatedStorageFile.IncreaseQuotaTo

Msdn doc for IsolatedStorageFile.IncreaseQuotaTo states that:
To increase the quota, you must call
this method from a user-initiated
event, such as in an event handler for
a button-click event. When you call
the IncreaseQuotaTo method, the common
language runtime in Silverlight
presents a dialog box for the user to
approve the request. If the user
declines the request, this method
returns false and the quota remains
the same size.
How does Silverlight know that the method was called from a user-initiated event like a button click and not from some other thread?
More specifically: What is a user initiated event? Is there any way to overcome this limitation?
And another question:
I do some automatic downloads of files when user first accesses my application, but I don't want the user to press "Download" and then when I detect more space is needed call IncreaseQuota and have the "Silverlight dialog" appearing asking for more space.
I want to start the download automatically (not user initiated), and if I detect more space is needed, call IncreaseQuota and hence have the "Silverlight dialog" appear. (No user pressing download).
After much digging, I did find out what a user initiated event is. Seems that msdn doc specifies what a user initiated event in the section related to "events overview", but there's no link between documentation of IsolatedStorageFile.IncreaseQuotaTo and Events Overview
So a user initiated event according to the definition is:
Silverlight enforces that certain
operations are only permitted in the
context of a handler that handles a
user-initiated event. The following is
a list of such operations:
Setting IsFullScreen.
Showing certain dialogs. This includes
SaveFileDialog, OpenFileDialog, and
the print dialog displayed by
PrintDocument.Print.
Navigating from a HyperlinkButton.
Accessing the primary Clipboard API.
Silverlight user-initiated events
include the mouse events (such as
MouseLeftButtonDown), and the keyboard
events (such as KeyDown). Events of
controls that are based on such events
(such as Click) are also considered
user-initiated.
API calls that require user initiation
should be called as soon as possible
in an event handler. This is because
the Silverlight user initiation
concept also requires that the calls
occur within a certain time window
after the event occurrence. In
Silverlight 4, this time window is
approximately one second.
User-initiated event restrictions also
apply to usages of JavaScript API for
Silverlight.
When Silverlight is in full-screen
mode, some input events are
deliberately limited for security
reasons, although this can be
mitigated for out-of-browser
applications using elevated trust. For
more information, see Full-Screen
Support.
Although I don't see "IncreaseQuotaTo" inside the list of "operations", I'm guessing they just forgot it, since the behavior/limitations are the same as the ones described in the doc.
I was curios how exactly does silverlight know what a user initiated event is but after digging through .net framework source code I've got to a dead end:
if ((browserService == null) || !browserService.InPrivateMode())
{
//..
}
return false; //means that IncreaseQuota will fail
where browser.IsInPrivateMode is:
[SecuritySafeCritical]
public bool InPrivateMode()
{
bool privateMode = false;
return (NativeMethods.SUCCEEDED(UnsafeNativeMethods.DOM_InPrivateMode(this._browserServiceHandle, out privateMode)) && privateMode);
}
where DOM_InPrivateMode is in a DllImport["agcore"] which according to microsoft is confidential :(
So it looks like I won't find out soon how they're detecting user initiated events.
Thinking it more about it, I guess microsoft didn't want a user to have many tabs open in a browser and then poof: I call automatically IncreaseQuotaTo.
The IncreaseQuotaTo is a browser modal dialog. This means you can't navigate to other browser tabs while is active.
So if the user has now moved from my page to the tab with google.com, and if I would be able to call IncreaseQuotaTo with a delay, the user might think that google.com is asking for more storage :).
This would be a security breach indeed.
Had they implemented this with a page level dialog, then that would have been probably more easily hacked (or worked around).
So all in all, thinking of it, I'm starting to see why they implemented it like this and why these limitations exist.
The documentation isn't incomplete.
If I do this... button_click(..) { new UserControl() }... Does this still count as a user initiated event?
Yes. But what has that little bit of extra code really achieved?
What i've personally never experimented with is exactly what consitutes a user event; IOW is a mouse-over considered a user event? This will be very simple for you to try, and there are a multitude of other things you can experiment with. If necessary you could have a splash screen popup that welcomes the user and they have to click on it to dismiss it, at which point you make the request. It may seem a bit corny, but you can get away with things like this if you present it well.
Note that the prompt is a one-time thing. If you prompt the user and they accept, that storage is persisted for your application between visits, which means you don't need to prompt them again the next time they use your control, your quota is still increased from last time (unless the user has deliberately deleted it, which they can do by right clicking on the Silverlight control and then going to the Application Storage tab).

Categories