How to control the form size expansion without events - windows

I have a windows form with 6 textboxes. On the form load, by default, only one textbox will be displayed with the form size reduced. Once i enter the text into the textbox, my form size should increase and should display second textbox without any button click or textbox events. The intention behind it is that user doesn't put any extra effort to click button as it should be user friendly. Is there any possible ways of doing it?

No, it is impossible to do it without events, but possible without button clicks (which are actually producing events which should be handled)
So the most user friendly thing you can do is using events and where is no reason to avoid them. To achieve your functionality you have to
a) Set the Autosize property of the form to true
b) Handle the TextChanged event of your only textbox with following code:
private void textBox1_TextChanged(object sender, EventArgs e)
{
if(((TextBox)sender).Text.Length > 0)
{
TextBox tb = new TextBox();
tb.TextChanged += new EventHandler(textBox1_TextChanged);
this.Controls.Add(tb);
}
}

Related

How to show the appointment page from a form region in outlook

I have a very simple outlook form region. It is configured as a separate item, and, it is set to appear whenever a we try to compose a new appointment item. (Meeting request).
Once I click the button above, it should populate the sender and go back to the main appointment page. The code to do that is:
private void button1_Click(object sender, EventArgs e)
{
item.RequiredAttendees = "John.Doe#contoso.com";
var exp = item.Application.ActiveInspector();
if (exp == null) Debug.Print("NULL");
else exp.ShowFormPage("Appointment");
}
But this doesn't do anything. What is the correct way of doing this?
Use the SetCurrentFormPage method of the Inspector class to display the specified form page or form region in the inspector.
As a workaround you may try to call the Appointment button programmatically. Use the ExecuteMso method of the CommandBars class to execute the control identified by the idMso parameter. See Office 2013 Help Files: Office Fluent User Interface Control Identifiers for the actual idMso values.

List item unresponsive on second click event

In my Windows Phone 7 application I have a number of list views. Each listViewItem has a click event (By setting 'selectionChanged' attribute to the listBox in my xaml). Now a very peculiar thing happens:
When I click on an item in the listbox the first time everything goes well, in this case the user gets taken to another screen. When I go back from that screen to the listbox, I select the very same listboxitem but this time the event doesn't register, nothing happens...
I then first have to tap on another item, let that ones even fire, then only can I tap on the first item. So in other words, I can't fire a click event for a listItem twice in a row. I'm thinking it's because the event handler on the listbox says 'onSelectionChanged', if you select the same item the selection hasn't technically changed.
So what other eventHandling attribute can I use on my listbox to register selection events on it's items?
Thanks for any help!
AFAIK, Theres is no such event. So, the work around is,
In the OnNavigatedTo event handler of the first page, set the SelectedIndex to -1
YourListBox.SelectedIndex = -1;
And while doing so, make one small modification to your Selection_Changed handler
void Selection_Changed(...)
{
if(YourListBox.SelectedIndex == -1)
return;
//rest of your code
}
In your case, SelectedItem in the ListBox is set for the first time. The second time you tap on the same item, technically its not a SelectionChanged event, hence its not firing.
Clearing the SelectedItem at the end of SelectionChanged event would do the trick.
Below is a code snippet that could be helpful,
private void ListBox_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
//
// do your stuff here
//
//reset the selection of the sender (ListBox)
(sender as ListBox).SelectedItem = null;
}

Windows Phone 7 Selection_Changed automatically

currently I'm developing an app for WP7 but came across a little problem with a Listbox event call Selection_Change. The problem is that when i return to the page that contains the listbox the selection_change event triggers without being changed at all or without any user input. The listbox code is similar to this:
private void lsbHistory_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
int index = lsbHistory.SelectedIndex;
NavigationService.Navigate(new Uri("/Views/NextPage, UriKind.Relative));
}
On the page I navigate to, the only way out of the navigated page is by pressing back button or start button meaning that it will return to the page that contains the listbox. When I Navigate back the selection change triggers leading me sometimes to a exception. Has anyone been through this before?
Consider always checking if it's -1 (the default value).
private void lsbHistory_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
int index = lsbHistory.SelectedIndex;
if (index != -1)
{
NavigationService.Navigate(new Uri("/Views/NextPage, UriKind.Relative));
lsbHistory.SelectedIndex = -1; // Set it to -1, to enable re-selection.
}
}
Also, you should consider wrapping the Navigate call in Dispatcher.BeginInvoke to have a better, more smooth, page transition.
The event will be fired when the list is populated.
The simplest solution for you will probably be to add a check that there is nothing selected before triggering your navigation:
if (lsbHistory.SelectedIndex > -1)
{
// do navigation
}
One thing to notice is that when you navigate back to the page which containt the ListBox, the ListBox still has the SelectedItem set to the value it had when the user navigated away. This means that lsbHistory.SelectedIndex will get the index of the item which was selected when the user navigated forward.
Maybe there's something in your code which presumes that the ListBox's SelectedItem is null when the user navigates to the page?

Is it possible to detect the DOM element tapped in a WP7 WebBrowser control?

Is it possible to detect the DOM elements under a spot the user taps on a website using the WP7 WebBrowser control? I would like to let the user identify certain sections of the rendered page.
Yes. This code works pretty well for me:
private void button1_Click(object sender, RoutedEventArgs e)
{
// first define a new function which serves as click handler
webBrowser1.InvokeScript("eval", "this.newfunc_eventHandler = function(e) { window.external.notify(e.srcElement.tagName); }");
// attach function to body
webBrowser1.InvokeScript("eval", "document.body.addEventListener('click', newfunc_eventHandler, false);");
}
private void webBrowser1_ScriptNotify(object sender, NotifyEventArgs e)
{
// this should be called every time you tap an element; the value should be its tag name
Debug.WriteLine(e.Value);
}
It goes along Justin's answer (who beat me while coding). It first defines a click handler which then is attached to the page's body (all via InvokeScript). Every time you tap an element ScriptNotify should be called on the WebBrowser reporting the tapped element's tag name.
Make sure you have set IsScriptEnabled true for your browser control.
I'm guessing you'd have to build something off of the ScriptNotify Event.
At that point, you would register a JavaScript Event handler as usual but that event handler would, in turn, call window.external.notify("someMessageToHandle");. You would then have to route the calls appropriately.
If you don't have the ability to add the JavaScript event handlers directly on the page, you could instead add them using WebBrowserControl.InvokeScript.

Key Preview and Accept Button

Using winforms, I have set the KeyPreview property to true and have event handles for the proper key events within the base form as well.
Within the forms that inherit from it, I set the AcceptButton property based on the requirements of the application.
There are certain cases in which I want the enter key to have functionality different than that of the AcceptButton.
I was hoping to capture the enter key press within my base form and check for the special cases where I do not want the AcceptButton event to fire.
It appears though, that the AcceptButton click is fired before any of the key events within my basef form. I could write functionality into the click events of the possible acceptbuttons, but, in my opinion, that would be a hack.
Any suggestions?
Thanks.
Another way to handle this is to override the form's ProcessDialogKey() method where you can suppress the accept and/or cancel buttons. For example, I have an application with a filter editor that filters a grid based on user input. I want the user to be able to hit the return key when the filter editor control has the focus to apply the filter. The problem is the accept button code runs and closes the form. The code below resolves the issue.
protected override bool ProcessDialogKey(Keys keyData)
{
// Suppress the accept button when the filter editor has the focus.
// This doesn't work in the KeyDown or KeyPress events.
if (((keyData & Keys.Return) == Keys.Return) && (filterEditor.ContainsFocus))
return false;
return base.ProcessDialogKey(keyData);
}
You can take this even further by dropping the following code in a base dialog form. Then you can suppress the accept button for controls in subclasses as necessary.
private readonly List<Control> _disableAcceptButtonList = new List<Control>();
protected override bool ProcessDialogKey(Keys keyData)
{
if (((keyData & Keys.Return) == Keys.Return) && (_disableAcceptButtonList.Count > 0))
{
foreach (Control control in _disableAcceptButtonList)
if (control.ContainsFocus)
return false;
}
return base.ProcessDialogKey(keyData);
}
protected virtual void DisableAcceptButtonForControl(Control control)
{
if (!_disableAcceptButtonList.Contains(control))
_disableAcceptButtonList.Add(control);
}
As our workaround, we captured the enter and leave event for the control that we wanted to have override the acceptbutton functionality. Inside the enter event, we held the current accept button in a private variable and set the acceptbutton to null. On leave, we would reassign the acceptbutton back to the private variable we were holding.
The KeyPreview events could have done something similar to the above. If anyone has a more elegant solution, I would still love to know.
Thanks.

Resources