Develop Reference

Catching cancel button click between two synchronous tasks

I have a list of tasks running and would like to show the progress in a (WinForms) form with a Cancel button.
I am aware, that there are several async options, but I have two restraints: The tasks must not run on a separate thread and the solution must be compatible with .NET 3.5 (it is an AddIn for a program, I have no access to).
It is fine, if one task finishes, before the cancellation comes into force. So I wonder, if there is some chance to check in synchronous code, if a mouse click on a button happened while having performed some task?
edit: This is the intended code:
foreach (IStep step in Steps)
{
if (Cancelled)
return;
step.Run();
ReportProgress(100.0 * completedWeight / totalWeight, step.Description);
completedWeight += step.Weight;
}
ReportProgress(100, "Completed");
So IStep contains a Run() method, and I am perfectly fine with completing a step before cancelling. I do not know how to catch mouse click on the Cancel button while executing some step to set Cancelled to true.

Obviously there is no "standard" solution here, so we have to think outside the box...
Say you have your application (AddIn or whatever, doesn't matter) and you can't control the loop from a button.
You read/write to the database.
On top of your loop, where it says:
if (Cancelled)
return;
We have to replace with:
If(CheckIsCancelled())
You have to find a way to make a button that can be clicked, either another form near the current one, but it must be able to run independently from the current form that is blocked by your loop.
Create a database parameter in some sort of Config/Util table.
E.g. CancelMyLoop - Bit
On that button click - set the parameter value to true.
And back to the method: CheckIsCancelled()
it will go in the db and read that value every time.
Downside is performance, but you want the impossible so you have to settle with a workaround like this...
You can create your own implementation, just giving you an idea.

Registering for UIAutomation structure change events

I am working on an application that is monitoring a given application for automation events. Currently, I am working specifically with structure change events on a WPF application that I developed.
public void MonitorStructureChangedEvents(AutomationElement element)
{
Automation.AddStructureChangedEventHandler(element, TreeScope.Subtree, OnStructureChanged);
}
where in this case, element is the root AutomationElement of the Application (its main window). The WPF application in question is just a Window with a grid view and various controls (text boxes, checkboxes, buttons, etc). It is a test app I have developed specifically for testing UIAutomation events.
I am using a Unit Test project to test these events, and I am launching the application in the ClassInitialize decorated method. I do not register for StructureChanged events until the application is launched and I have located it via WMI in my TestMethod. The application is spawned as a new process.
However, upon registering for structure changed events, I receive structure changed events for all the elements in the main window of my application, even though the WPF application is effectively idling. I have buttons in the main window that add and remove controls to test StructureChanged events, and it does work, however I am unsure why when I initially register, all of the elements fire a structure changed event.
Edit: After further testing, I notice that these events are fired as soon as I either click on the application window, or hover over a button. It then fires a structure changed event for every element in the app one time. After it is done, it no longer fires a structure changed event if I hover over a button, or click on the application (even after clicking on another application or the desktop)
Edit2: After further testing, I believe I figured out the cause of the issue, but no solution yet. When I try to TreeWalker.RawViewWalker.GetFirstChild(rootApplicationElement) I receive a null. It appears that the AutomationElement that I am acquiring has no children cached. Once I add the StructureChanged event handler on the element, the TreeWalker method works, and I get a valid element. It seems when I activate the window after this, that's when it realizes that it now has all these new child elements. Is there a way to cache all the descendants of the rootApplicationElement so that before I add the event handler, I can walk the entire subtree?

I was able to solve the problem by using the following method
CacheRequest request = new CacheRequest();
request.TreeScope = TreeScope.Element | TreeScope.Descendants;
using (request.Activate())
{
rootApplicationElement = AutomationElement.RootElement.FindAll(TreeScope.Children,
new PropertyCondition(AutomationElementIdentifiers.ProcessIdProperty, ApplicationInstance.ProcessId))[0];
}
I do not advise that people acquire a root element in this fashion, since if an application has more than one window you will get more than one result, but this was tailored to a specific testing need.

How to create a custom .NET ComboBox with the textbox active during edit

I'm trying to implement my own combobox like a lot of folks before me. What I want to accomplish is a combobox that filters and highlights items in the dropdown list while the user is typing in the combo textbox. The behaviour of a regular combobox after you click the arrow button is that the dropdown pops up and the focus stays in the textbox. This way you can start typing right away.
In order to customize the dropdown control you have to implement something from scratch. Most of the implementations that I've come across use either a Form or a ToolStripDropDown to host the custom control. Both are toplevel controls which means that you have to somehow close it yourself if the user clicks somewhere outside the dropdown. ToolStripDropDown does this automatically if AutoClose is true, but also somehow steals the combo textbox the focus on show if it is activated. A Form must be shown using ShowWithoutActivation() in order to prevent it from stealing the focus.
The problem is that the dropdown does never close unless I click somewhere within the dropdown and therefore activate it.
Another twist is that the combobox control is supposted to be hosted in an MFC application instead of a pure WinForms app.

The dropdown never being activated (gaining focus) is the main complication here. Otherwise you could just use the forms Deactivate event to hide it. The way to go here is to add an IMessageFilter to the WinForms application and catch mouse click messages. The message filter then determines whether the click took place outisde of the dropdown and closes it. If you are creating a WinForms application you are done.
Some extra work is necessary if you are for example in a MFC application hosting the control in a MFC window. In that case your IMessageFilter is useless. The reason is that the WinForms Application is never being run and therefore the event pump is never being invoked. Instead the MFC message pump does all the message handling. To solve this issue I've come accross a neat trick to activate the Application message pump in MFC applications.
In MFC applications there is usually an equivalent to the WinForms Application which is CWinApp (or CWinAppEx). The trick is to tap into the PreTranslateMessage method and serve the WinForms Application message pump before (or after) the MFC message pump:
BOOL CWinApp::PreTranslateMessage(MSG* pMsg)
{
if (FilterWindowsFormsMessages(pMsg))
{
return TRUE;
}
return CWinApp::PreTranslateMessage(pMsg);
}
BOOL CWinApp::FilterWindowsFormsMessages(MSG* pMsg)
{
Message message = Message::Create(IntPtr(pMsg->hwnd),
int(pMsg->message),
IntPtr((void*)pMsg->wParam),
IntPtr((void*)pMsg->wParam));
if (Application::FilterMessage(message))
{
return TRUE;
}
return FALSE;
}
This way the registered IMessageFilters are being served and everything works fine.

Winform App - Webpage Interaction

Windows Form Application – Manipulating input-elements in WinForm WebBrowser
Although I am familiar with HttpWebResponse/HttpWebRequest to login to a website, I was trying it now via using the mshtml library and found some weird behavior and I would like to see if someone else might be able to help me out here..
I have an HTML login page with a java backend with a Username field, a Password field and a Button.
The logic is very basic, I have a built a winform app with a built in webbrowser.
At the Document_Completed event I use the following code to enter my settings and to click the button.
private void webBrowser_DocumentCompleted(object sender, WebBrowserDocumentCompletedEventArgs e)
{
if (webBrowser.Url.ToString() == #"MyWebPage/signin")
{
HTMLDocument hdc = new HTMLDocumentClass();
hdc = (HTMLDocument)webBrowser.Document.DomDocument;
IHTMLElement elb = hdc.getElementById("login_button");
IHTMLInputElement elu = (IHTMLInputElement)hdc.getElementById("username");
IHTMLInputElement elp = (IHTMLInputElement)hdc.getElementById("password");
try
{
elu.value = "MyID";
elp.value = "MyPwd";
elb.click();
}
catch { }
}
}
Apart for this code being very quick and without error handling, it should do the trick and it does, partially..
There are two scenario's:
I launch the tool, it loads the webpage.
The tool populates the UserID field and the Password field correctly
The tool fails to click the button
I click the button manually, I am logged in, I click logout, I am back at login page
I immediatly logged in again, the tool enters the information
The tool immediatly clicks the button as well.
Is there anyone who might be able to explain me why this happens and how I could get around this with the current setup (hence not using HttpWebRequest). I don't see the difference between loading the page at startup or being redirected after logout, but apparently there is a difference in there or I am doing something wrong.
Any feedback on this matter is very much appreciated.
Thanks,
Kevin
EDIT:
I added a Button to my Windows Form that bas the same backend Code as below in order to click the button on the webpage, this works perfectly.
I triggered clicking this button in the webBrowser_Completed event but it doesn't work.
For some reason, everything I add to the webBrowser_DocumentCompleted event does not allow me to trigger the click event for the button in my WebBrowser control. Once that entire event has completed, if I then try to trigger it it works but I would like to automate this.. Any advice?

This might be a long shot and not the most elegant workaround but how about letting a backgroundworker run for a second in your DocumentCompleted event that then triggers the button that you clicked from it's seperate thread. This might just get this automated.
As this will run from a different thread, keep in mind that you might have to invoke certain controls so this might be another downside to this workaround..
If this doesn't work then, as Regfor previously suggested, Watin.org can help you out.

how about this :
HtmlElement button = webBrowser.HtmlDocument.GetElementById("login_button");
button.InvokeMember("click");
it works in my program.

Sharepoint Ribbon: Circumventing Context sensitivity

I'm new to sharepoint development and I'm trying to modify the behaviour of the Sharepoint ribbon. As you all know, the ribbon is such that when something else gains focus(e.g a list item), the ribbon automatically switches to an appropriate tab or tab group(e.g the List tools tab group).
I'd like to disable this constant switching of tabs and make the browse tab to always be the active tab, unless the user explicitly clicks on another tab.
I've tried doing the following in the Page_Load() of a Usercontrol, but it only works once, when the page is initially loaded. What am I doing wrong? More importantly, how could I do it right, if at all?
Basically, I'm hoping someone could point me to the event that's fired when the context changes and the ribbon switches, and how I could hook up to this event and force the ribbon to switch back to the browse tab.
protected void Page_Load()
{
string showBrowseTabScript = string.Empty;
showBrowseTabScript = #"
function ShowBrowseTab() {
var ribbon = SP.Ribbon.PageManager.get_instance().get_ribbon();
SelectRibbonTab(""Ribbon.Read"", true);
}
SP.SOD.executeOrDelayUntilScriptLoaded(function() {
var pm = SP.Ribbon.PageManager.get_instance();
pm.add_ribbonInited(function() {
ShowBrowseTab();
});
var ribbon = null;
try
{
ribbon = pm.get_ribbon();
}
catch (e) { }
if (!ribbon) {
if (typeof(_ribbonStartInit) == ""function"")
_ribbonStartInit(_ribbon.initialTabId, false, null);
}
else {
ShowBrowseTab();
}
},
""sp.ribbon.js"");
";
this.Page.ClientScript.RegisterClientScriptBlock(this.GetType(), "BrowseTabScript", showBrowseTabScript, true);
}

Here is my solution to the problem, in case anyone is interested.
Taking Ken Henderson's suggestion into consideration, I was able to achieve what I've been trying to do, although I achieved this by modifying the code of the SP.Ribbon.js and SP.Ribbon.debug.js files. I'm using the SP.Ribbon.debug.js to show my solution below, since it is not as cryptic as the SP.Ribbon.js.
Basically, I use the code below to trick the ribbon into thinking that the User is on a different tab and has clicked on the "Browse" tab. You will notice that I set the old tab information in the code. It will still work without me doing this, but I did it just in case the ribbon needs that information for something else I'm not aware of. This code, in combination with the Page_Load() function I posted in the first post, cause the ribbon to behave just like I needed it to.
SP.Ribbon.PageManager.prototype = {
executeRootCommand: function (commandId, properties, commandInfo, root) {
ULSMg8: ;
var $v_0;
if (!SP.ScriptUtility.isNullOrUndefined(commandInfo) && commandId !== 'RibbonEvent' && (commandId !== 'CommandContextChanged' || (!SP.ScriptUtility.isNullOrUndefined(properties) && properties['ChangedByUser']))) {
// My changes to SP.Ribbon
if (properties["ChangedByUser"] === false) {
properties["ChangedByUser"] = true;
var $NewContextId = properties["NewContextId"];
var $NewContextCommand = properties["NewContextCommand"];
properties["OldContextId"] = $NewContextId;
properties["OldContextCommand"] = $NewContextCommand;
properties["NewContextId"] = "Ribbon.Read";
properties["NewContextCommand"] = "ReadTab";
SelectRibbonTab("Ribbon.Read", true);
}
// End of changes to SP.Ribbon
// the rest of the code has been ommitted for clarity
return $v_0;
}
}

To the best of my knowledge SharePoint doesn't expose any events to detect when the ribbon tabs update (either tabs adding/removing or which is active). At least I was unable to find any a few weeks ago when I was trying to detect when tabs were added/removed (I didn't care which was active just the number/width of them).
(Sorry for the lack of details, the SharePoint dev environment at the office is unavailable at the moment so I can't look up the details very easily.)
There are two possiblities for solving this problem (each has risks/problems):
Override JS Functionality
Figure out what JavaScript function is being called when the user clicks on an item that updates the ribbon. You might be able to replace that function with your own that provides the behavior you want. This would be similar in concept to a custom master page that scrolls on the window and has to change the behavior of the width sizing. I'm unable to verify the details at the moment but it looks like the function is called SingleItemSelect in core.js.
This could be a problem if you have exceptions to when to override this behavior and if MS changes anything in the future you're implementation may break and/or need to be updated.
Add your own event handler
In your JavaScript code try to find an appropriate DOM event to attach an event handler to in the ribbon to detect when MS's code changes the ribbon. There is a good chance given the limitations of the DOM events that there will not be an event to attach a handler to. You may end up adding a function that is called periodically (polling loop/timer) that detects ribbon tab changes and resets the active one.
Honestly this will not work well since there will be flickering as MS's ribbon code changes the active tab and your's changes it back. Additionally you'll need to detect when the user clicks on a tab so that you don't undo their changes.
Wrap up
Honestly I would push back and get this requirement changed so that the ribbon behavior works the way MS designed and not try to fight it. If the ribbon showing up when the user clicks on an item is really an issue then I would propose to the client that instead of forcing the Browse tab as active to add an additional link in the ribbon area somewhere that allows the ribbon (or at least the part that expands over the title area) to be toggled as hidden/shown independently of what MS's JavaScript is doing to the ribbon.