Do you know how can I detect when my Outlook AddIn TAB is visible/selected at some moment?
My problem: sometimes users press the Outlook default SEND button instead my own SEND button (required for some posterior processing) and I would like to detect it to call the user's attention.
The problem is also that, users CAN press the default SEND button for messages not related/addressed to some recipients...
Objectively: if the user is, at the moment, in my TAB, I send a MessageBox to him, otherwise I don't.
Thank you!
Related
ALL,
We have a an application written with wxWidgets (wxGTK) and Qt.It is running on RHEL6 with FVWM window manager.
One of the window we have in that application is "Lock Screen" which is shown in the full-screen mode and does not have any decorations. The only way to get out of it should be to enter the password and press the "Authenticate" button.
However what we discover is that if the user starts up Terminal and then pulls up that "Lock Screen", (s)he can press ALT+TAB, switch to the Terminal and type whatever (s)he wants. We'd like to avoid it.
Is there any way possible to catch the "ALT+TAB" keystroke and do nothing when this "Lock Screen" window is displayed. The window is written with wxWidgets, but I'm asking about c++/Linux/gtk/qt in general.
TIA for any hints/advice community can provide.
[EDIT]
All I want is for the user to not be able to switch focus from the password field until the password is given and the "Authenticate" button is pressed.
[/EDIT]
And before you ask - there are couple of related questions on SO, which says solved, but they are for Windows/C#/WinForms/JAVA. If you can find something that will work on Linux with either GTK or Qt or maybe even FVWM internal settings I will gladly accept the answer.
In visual c++, I am using a message box to warn the user about invalid entry in a dialog. When the entry is invalid and the user clocks OK in the dialog, a message box pops up which the user acknowledges by clicking OK and the original dialog is still available for the user to correct his entry.
My problem is that I see different behavior when the user hits enter on the keyboard vs clicking on the OK button in the dialog. When the user hits enter instead of clicking OK in the original dialog, the message still pops up but then everything goes away after the message is acknowledged (the dialog does not persist under it like with clicking OK).
The message box is based on WinUser.h method MessageBoxA. Any suggestions why this is or how to work around it?
Maybe the CANCEL option is the DEFAULT - Enter key will simulate the click of the DEFAULT Button, i.e the one with the dashed frame
I am working on a very big and complex application for Windows written in C++ and using MFC.
I am working on this bug, where if a user presses on a balloon tooltip, it won't close, only after a timeout.
The thing is that I got the NIN_BALLOONUSERCLICK event and managed to close the tooltip, but I can't seem to catch the event raised when the user presses on the "X" button in the upper right corner.
Can anyone help me? What event should I look for? I've spent around 3 days of searching the Internet, but no one seems to know of a way.
If you can tell me how to make the "X" close button disappear, that would be okay, too!
The reason you can't find any such event is because one does not exist. It is not possible to distinguish between the balloon being closed because the user clicked somewhere on it and the balloon being dismissed because the user clicked specifically on the close ("X") button.
More information can be found in this article on Raymond Chen's blog: Why don't notification icons get a message when the user clicks the "X" button?
Basically, the event doesn't exist to keep you from doing bad things, like annoying your users. There's absolutely no reason that you should need to do something different based on how the user dismissed the balloon notification.
Making the "X" button disappear is definitely the wrong choice. Asking for that makes it sound like you're exactly the developer that the Windows Shell team was trying to protect us from. Glad someone has our back as unsuspecting users of your application. Users like to be able to dismiss things. Usability studies have repeatedly indicate that it's extremely stressful and confusing for users when there is no "Cancel" button. You need to work within the constraints of sensible, user-friendly design.
NIN_BALLOONUSERCLICK is the right choice. The tooltip will be dismissed when the user clicks on it. The documentation explains all of the various notifications that are available in greater detail.
I want to get an event to my application when someone presses the Home button:
(The silvery button with an arrow pointing left is the Home Button on the HTC Smart.)
However, when I press the button, no event at all arrives to my app. If I connect the system logger, I see that the Brew MP OS itself detects something, but it does not arrive to my app.
[CORE] CoreDaemon_HandleEvent: 111
[CORE] CoreDaemon_HandleEvent: 112
Can I register with these events so the OS passes them on to me? (Or whatever it takes to detect the home button in my app.)
I suspect the [ISHELL_RegisterNotify][2] function may be what I am looking for, but I don't know how to use it. I tried:
ISHELL_RegisterNotify(piShell, AEECLSID_OF_MY_APP, AEECLSID_CORE, NMASK_SHELL_KEY |(NOTIFIER_VAL_ANY << 16));
That didn't work, neither this:
ISHELL_RegisterNotify(piShell, AEECLSID_OF_MY_APP, AEECLSID_CORE, ~0);
I kind of hoped that last one would get me all "core" events, but neither of those two made any difference at all.
The app will first receive an EVT_KEY with wParam=63620 and then immediately get the EVT_APP_SUSPEND event.
Hence, as far as I understand, the "Home Button" can not be used in any meaningful way by Brew applications for input.
I have rules set to move some email messages into different folders. I would like this to still show the envelope in the notification area but there is no option in the rules wizard to do this. It looks like I would either have to have the rule "run a script" or "perform a custom action" allowing either vba or c/c++ respectively.
Anyone else have a better solution?
You can also achieve it not by using a rule, but doing the rule-like action in code. For example:
Private Sub Application_NewMailEx(ByVal EntryIDCollection As String)
Dim mai As Object
Dim strEntryId
For Each strEntryId In Split(EntryIDCollection, ",")
Set mai = Application.Session.GetItemFromID(strEntryId)
If mai.Parent = "Inbox" Then
If mai.SenderEmailAddress = "the-email-address-the-rule-applies-to" Then
mai.Move Application.GetNamespace("MAPI").GetFolderFromID("the-entry-ID-of-the-folder-you-want-to-move-the-message-to")
End If
End If
Set mai = Nothing
Next
End Sub
How to get the folder ID (i.e., entryID of the folder):
This is just a manual way, you could make a recursive procedure but for simple purposes this is fine. For instance, I had a structure like:
Mailbox - My_Name_Here
Inbox
The Subfolder I'm Looking For
Sent Items
...
So in the Immediate window I typed:
? Application.GetNamespace("MAPI").Folders(1)
and increased the number until I got "Mailbox - My_Name_Here"
then, I typed:
? Application.GetNamespace("MAPI").Folders(the_number_of_my_mailbox).Folders(1)
increasing the number until I got "Inbox".
Then:
? Application.GetNamespace("MAPI").Folders(the_number_of_my_mailbox).Folders(the_number_of_my_Inbox).Folders(1)
increasing the number until I got "The Subfolder I'm Looking For"
Then:
? Application.GetNamespace("MAPI").Folders(the_number_of_my_mailbox).Folders(the_number_of_my_Inbox).Folders(the_number_of_the_subfolder_i_was_looking_for).EntryID
And that was it: the entryID of the folder I wanted to move the message to. You get the point, I'm sure :)
Check out MailAlert, an Outlook plug-in that does exactly that. It still works in Outlook 2007 (although I've had some instabilities since I installed it again recently, which may or may not be related).
The new version of Mail Alert, which was just released, will allow you to control the notification icon as well as the popup alert and sound alerts. Here are some of the new features in 2.0:
Audible alerts - plays a sound for incoming e-mails
Notification area alerts - displays a notification area (system tray) icon
Program alerts - runs a program and can pass information from the incoming e-mail to that program
Mute feature - to quickly suppress all alerts
Microsoft Outlook 2007 support
Multi-monitor support
Unicode Exchange server support
And more desktop alert features:
Aero Glass style alert windows (on Windows Vista)
Ability to easily dismiss the alert window
Ability to quickly open, reply [to all] or forward a message directly from the alert window's buttons
Ability to convert a message into a task, flag a message for follow up or move a message to another folder; all directly from the alert window's context menu
Ability to set the default position of alerts to be where ever you want them
Privacy option to require a click before showing the preview of the message body
there is an option "display a Desktop Alert" on the Step 1 of the Rules Wizard. it does the trick. this wizard can be run when editing the concrete rule.