I am using the vanilla datepicker in Silverlight 2. I bind the selected date to a value, and when that value changes I pop a messagebox to confirm that they would like to change the value.
However strange behaviour ensues when I use a messagebox straight after the datepicker's value is changed. The datepicker's popup will not close, and if you mouse over the calendar it will choose a date without having to click the mouse.
Also, after this occurs it seems to affect bindings and it cannot set the view model's property again until the page is reloaded.
This problem is rather specific so I have attached a stripped down example. Choose a date and press OK then move your mouse over the calendar to reproduce this.
My XAML -
<Grid x:Name="LayoutRoot">
<controls:DatePicker x:Name="dpTest"
Height="25"
Width="75"
SelectedDateChanged="DatePicker_SelectedDateChanged" />
</Grid>
My code behind -
Private Sub DatePicker_SelectedDateChanged(ByVal sender As System.Object, ByVal e As System.Windows.Controls.SelectionChangedEventArgs)
MessageBox.Show("Test Popup")
End Sub
Any ideas or workarounds?
Hmm this is not all that uncommon actually. A coworker of mine recently ran into very strange issues in a Windows Forms application because he was using MessageBox in response to a third party menu control's click event (before the menu had been dismissed.)
One suggestion that didn't work for him but may very well work for you is to "push" the call onto the dispatcher. That way your SelectedDateChanged handler will return before the message box actually gets shown.
Private Sub DatePicker_SelectedDateChanged( ... )
' Unfortunately my VB is rusty '
' I believe this is the correct syntax. '
Dispatcher.BeginInvoke(AddressOf ShowDateMessage)
' At this point, the message box has *not* been shown '
' It will be shown once control returns to the dispatcher '
End Sub
Private Sub ShowDateMessage()
' By this point, the DatePicker popup should be closed '
' so hopefully the issues you are seeing would be avoided '
MessageBox.Show("Test Popup")
End Sub
A couple of things to keep in mind though:
MessageBox.Show is unique in Silverlight in that it is one of the only ways to create a modal dialog. And unlike in Windows Forms where the message loop is still running, Silverlight's UI thread is stalled until it returns.
The event already takes place after the date has changed so this is not a good way to confirm the change. A cursory glance at the docs suggests there isn't a corresponding "Changing" event.
Depending on the circumstances, you might just be better off using a ChildWindow instead of MessageBox. This wouldn't have the issues you described because while it appears to be a modal dialog, it's not.
I blogged a workaround HERE that make the message box unnecessary by changing the work flow.
Related
I'm working on a VB6 project and I cam across something that I'm unable to resolve. In my project I'm using 2.0 comboboxes. Everything works fine, in terms of loading the combobox with data, selecting it, and the whole bunch. What I'm trying to do is, once data has been selected, I'm making sure that the same data has not been selected in both comboboxes. I'm trying to write a quick comparison IF statement in LOST FOCUS for one of the cbo's but it doesn't seem to work.
Private Sub cbo1_LostFocus()
if cbo1.text<>"" and cbo2.text<>"" then
if cbo1.text = cbo2.text then
MSGBOX "Duplicate Values"
else
exit sub
End if
end if
End Sub
it doesn't at all realize there is LOST FOCUS - I don't think I've ever done that to a cbo, usually textboxes and such. Any help is appreciated.
You could try GotFocus instead. It seems the LostFoucs event can be overridden or masked in certain cases. This article shows a similar problem: http://www.vbforums.com/showthread.php?396536-RESOLVED-VB6-LostFocus
Of course, you could always upgrade to the latest VB, but I'm guessing you have your reasons.
We discovered a possible bug involving the DataGridView. The DataGridView has a property, StandardTab, that is set to False by default. This default setting means that the TAB key moves between cells within the grid. When it reaches the final cell in the grid, then the TAB key moves focus to the next control. This is the setting we are using in our project.
The DataGridView is connected to a binding source in our project, which may or may not be relevant.
When the DataGridView is on a form that is being displayed from a COM-based project (VB6, in our case), the grid control loses focus when the user tries to tab within the grid. If you hold down the tab key, focus cycles through other controls on the form until it returns to the grid. When it returns to the grid, the selected cell is the one that the user was tabbing to.
So, it is possible for the user to navigate through all the cells, via a detour through the rest of the controls on the form as they move from cell to cell. This does not make for happy users.
I did find an MSDN forum question that seems to describe this problem, but the only answer to it is not terribly helpful.
I could submit this as a bug on Microsoft Connect, but I doubt they are going to fix it. Is there a way to deal with this issue in code?
Further investigation of the following events/methods revealed a pattern:
Leave (on the control)
ProcessDialogKey (on the form and on the control)
ProcessDataGridViewKey (on the control)
The last two events turned out to be key to the problem.
When we tested in a 100% .NET project, we discovered that tabbing internally would execute the ProcessDataGridViewKey event to fire. When on the last cell, the ProcessDataGridView function was not executed, but the ProcessDialogKey function was executed.
When we tested in the Interop project, the events were exactly the same, but a Leave event on the control occurred before the ProcessDataGridViewKey function was executed. The bad scenario is unique in that the control will not have focus then ProcessDataGridViewKey function is executed.
Perhaps we can test for that and make focus come back to the control? It turns out that we can, and here is a subclassed control that handles it, yet still works fine in a 100% .NET project.
Public Class DataGridViewCustom : Inherits DataGridView
Protected Overrides Function ProcessDataGridViewKey(e As System.Windows.Forms.KeyEventArgs) As Boolean
' When the grid is hosted by a form that is being loaded through the Interop Forms Toolkit,
' the default behavior of using the TAB key to navigate between cells is broken
' (StandardTab = False). The tab key causes the grid control to lose focus before it has a
' chance to process the tab key in this event handler.
'
' This handler is not executed when the TAB key is supposed to make it lose focus (i.e. when
' StandardTab is True or when TABbing off the last cell within the grid). In those
' scenarios, the ProcessDialogKey event handler is executed, and there is no problem.
' Therefore, we can assume that if this event is being processed, and the grid does not have
' focus, we should put focus back on the control.
' The datagridview has different behavior for TAB and CTL-TAB, depending on how the StandardTab
' property is set. We don't have to worry about that becuase this method only executes when the
' focus is supposed to stay within the control. A different method is executed when the focus
' is supposed to leave the control.
If e.KeyCode = Keys.Tab AndAlso Not Me.Focused Then Me.Focus()
Return MyBase.ProcessDataGridViewKey(e)
End Function
End Class
I have a DataGridView bound to a List[of Parts]. The last item in the list is always a 'dummy part', which is there to create an extra row in the grid so the user can start typing into the first cell to add a part to the list.
As soon as the user types more than x characters into that particular cell, a new DataGridView with search results appears under the cell where he is typing (a bit look Google's suggestions), and he can select one of the matches to add the part to the list.
I do this by handling the EditControlShowing event, which assigns the 'editing control' to a TextBox variable which has a handler for TextChanged.
The bug:
I want the focus to change to the second DataGridView (search results) if the user hits the down arrow key.
The EditControlShowing handler works fine first time, moving the focus to the second DataGridView and leaves the first DataGridView in a 'seemingly' functional state, i.e. all other event handlers work. But the second time the EditControlShowing handler fires, the DataGridView throws the NullReferenceException on InitializeEditingControlValue.
Because it is the DataGridView's own call which throw the error, the debugger brings me to "Application.Run" in my code, which isn't helpful.
However, I determined that the call which causes the DataGridView to go into that state, and the point at which exception is thrown, is when I steal focus from the first DataGridView by calling Focus() on the second DataGridView (or any other control for that matter).
If however I let the user change focus to the DataGridView (e.g. by clicking with the mouse), then the DataGridView stays fine.
Does anyone know why stealing focus away from a DataGridView during a handler for EditControlShowing should result in it behaving differently afterwards?
I've tried CancelEdit, Refresh, Enable/Disable etc...
Any suggestions on helping me find out what is going on within the DataGridView? I can't spot anything obvious by inspecting it at breakpoints before and after. I don't even know how to find out what object is null as its the DataGridView's own code...
Many thanks.
OK, I resolved this using BeginInvoke in the TextChanged event handler (code is in Boo but should make sense):
//The event handler
private def CellAsTextBoxTextChanged(sender as object, e as EventArgs):
...
self.BeginInvoke(ShowPartSelectionArea, currentCell, _CellAsTextBox.Text)
//The method which amongst other things, sets the focus to another control
private def ShowPartSelectionArea(currentCell as DataGridViewCell, searchString as string):
...
AnotherDataGridView.Focus()
...
I had previously tried using BeginInvoke directly at the point of calling Focus() on the other control, like so:
private def CellAsTextBoxTextChanged(sender as object, e as EventArgs):
...
ShowPartSelectionArea(currentCell, _CellAsTextBox.Text)
private def ShowPartSelectionArea(currentCell as DataGridViewCell, searchString as string):
...
self.BeginInvoke(AnotherDataGridView.Focus())
...
But the latter didn't work, perhaps because the first way actually allows the DataGridView's cell to finish everything it does whereas the second way doesn't.
So for anyone facing the same problem, I'd advise playing about with where in the call stack you use BeginInvoke.
Found an interesting problem that I first found in WinForms, and found again in Silverlight, and more than likely WPF as well when it comes to databinding.
I have a tab control with several tabs. As users click across the tabs, each time should be valid before allowing the user to switch from the tab.
For example, user is in a text box which is updated. Binding of text boxes is not flushed until the control loses focus. Loss of focus occurs when the cursor is moved from the control, and focus is given to another control.
In this scenario, the user tabs into a control (let's use text box for this example), and updates the text box. At this point the databinding has not flushed the control, and hence the VM has not yet seen the change. The user then uses their mouse to click the next tab of the control.
At this point things get interesting. I used the PreviewSelectionChanged (Telerik RadTabControl), as I want to check things out before the jump to the next tab occurs, and it also gives me the ability to cancel the event.
However, when I look at the VM, in this event, it still does not have the updated data. I see the VM is clean, and go ahead and allow the jump to the next tab.
As soon as this event is over however, the databindings flush, and the VM gets updated. what now? The events are out of sync! When the mouse was used to click the next tab, the textbox should have lost focus, flushed it's bindings, before the Preview of the Tab click! It's to late to jump back and say oops we didn't catch that in time!
I think I found an interesting work around to this issue - but I'm not 100% sure it will work 100% of the time. I cancel the current event, but then I use the Dispatcher and create a delegate pointing to another method with the same signature as the current event. The Dispatcher will add this message to the message pump, which by this time will now (hopefully?) be behind the messages of the VM updating...
My two questions are:
1) I'm assuming that the textbox control either didn't flush when the mouse left the control, or the process that was fired was too slow and hence the preview message was on the pump before the databinding - either way I see this to be a major issue.
2) Is the workaround a good solution?
Ok, first to answer question 1:
Just because the mouse left the textbox area, doesn't mean that the textbox lost focus. It only loses focus once something else gets focus. For example, if you moved the mouse out of the textbox and click on some other control on your page (it can be anything from a scroll viewer to another textbox, etc.) then your textbox will lose focus.
Now, based on that, the events do not happen in the wrong order. What happens is; your click event on the other tab triggers both the textbox to lose focus (and the data binding to take place) and the move to the next frame, and based on that, you basically get a race condition where the moving to the next tab happens before the databinding takes place.
About question 2:
What you can do is, set the UpdateSourceTrigger to Explicit, you will however be forced to then have some kind of text_changed event and manually update the binding.
You can read more about that here. It might not be the most complete explanation but is a good place to start.
On the other hand, you can associate some events to the textbox and force the textbox to lose focus on those events (e.g. mouse out).
Just an idea: Why not do everything in the VM's PropertyChanged event?
protected override void OnThisViewModelPropertyChanged(object sender, PropertyChangedEventArgs e) {
if(e.PropertyName == "WhateverProperty") {
//Do your magic here for whatever you want to set
}
}
Have your TabItems bound to a collection that will control is being disabled or not.
<sdk:TabControl>
<sdk:TabItem IsEnabled="{Binding SomeProperty, Converter={AmIDisabledOrWhatConverter}}" />
</sdk:TabControl>
That way, everything is triggered whenever a property is chaned in the vm. No more timing issues since everything is on the vm.
Just my two cents.
There's a design defect here, and you're trying to work around the defect instead of fixing it. You shouldn't have to figure out how to cancel the Click event on the tab. The tab shouldn't be processing Click events in the first place.
Generally speaking, if it's not legal for the user to click on a control, the control shouldn't be enabled. The tab should be disabled until the state of the view model is valid.
Your view model should be exposing a command for navigating to the next tab, and the tab should be bound to the command. The command's CanExecute method should only return true when the state of the view model on the current tab is valid.
This doesn't fix your other problem, which is that Silverlight doesn't support UpdateSourceTrigger="PropertyChanged" out of the box. But that's a solved problem (here is one example).
Note that if you implement commands to handle this wizard-like navigation in your application, you can, down the road, change the view to use something other than a tab control (e.g. to use navigation buttons like an actual wizard, or something like Telerik's PanelBar) without having to screw around with event handlers.
Change your bindings to include UpdateSourceTrigger="PropertyChanged".
This will ensure that your data sources are updated on every key stroke, not just LostFocus.
MyOwnTextBox()
{
this.TextChanged += (s, e) => UpdateText();
}
private void UpdateText()
{
BindingExpression be = GetBindingExpression(TextProperty);
if (be != null && be.ParentBinding.Mode == BindingModes.TwoWay)
{
be.UpdateSource();
}
}
I am using this class it updates my binding on the fly, however there is issue with empty string and null values, if your destination property is nullable string then this will update empty string in your destination property. You can get workaround by using some sort of string converter which will use null instead of empty string in case of nullable strings.
I have an application in which there are lot of TextBoxes and some Buttons like Save, SaveAs,etc.
When the user edits a TextBox, I have to check the DataBase for some range, validate the range and update the DataBase.
If there is any error in value entered by user,then I should not allow the TextBox to lose focus.
I was using LostFocus event for this and it was working fine until lately I discovered a bug in my application.
Bug : The user edits a value in TextBox and then clicks on Save button; the LostFocus event is not called and so Database is not getting updated :(
Now my question is which event should I use in TextBox to update the DataBase. I tried TextChanged event but it validates for every character and making my application slow. I am confused in chosing the right event for this kind of application!
Note :** The Buttons are in different UserControl !
EDIT 1 : I have some Commands attached to click of Buttons, these Commands are getting executed before LostFocus !! Can I set precedence or something like attached behaviours or commands should get executed after LostFocus !!
EDIT 2 : I was just debugging the application by disabling some commands, what I found was in some cases, the DelegateCommand gets executed before LostFocus, so I want to avoid that. How can I go about it ? I felt during development its impossible to developa pure MVVM application so I am kind of using a bit of codebehind !
Trapping the keyboard focus within a control is usually a sign of bad UI design - it's pretty user-hostile to force the user to fix data in a control before he can type anywhere else in the UI.
That said, you shouldn't be using events at all here. You're trying to write a Windows Forms application in WPF. You should write a WPF application.
Create a class that is a logical model of your view - i.e., there's a string property for the text box and a Command property (or, more likely, a RelayCommand) for the Save button. Bind the text box to the string property, e.g.:
<TextBox Text="{Binding MyTextProperty, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}"/>
Because the UpdateSourceTrigger is PropertyChanged, the source object will get updated every time the user types a character.
Bind the button to the command property, e.g.:
<Button CommandBinding="{Binding SaveCommand}">Save</Button>
Implement the appropriate CanSave and Save methods that the RelayCommand (as described in Josh Smith's essential article on the MVVM pattern) requires, so that the button is enabled when the string property is valid and disabled when it's not.
I think the best approach is preventing a user to proceed until all valid information has been gathered.
Just like an installation wizard with Terms & Conditions Dialog and Next button. Until you check the I Agree checkbox, Next button is disabled.
This way, you don't have to worry about user proceeding without providing valid information. This way, you can use any event on TextBox to validate your data.