Develop Reference

How to get notified after the event ends

In my UWP app I am using DynamicOverflowItemsChanging event of a CommandBar my usecase is not very complex, I tried to solve another problem I had by using this event, see the answer of this post.
So as shown in the answer in the link I provided above, I am trying to invoke this event and sync the visibility of MoreButton now the problem is this event is fired when the secondary overflow menu of command bar doesn't have the item removed or added yet, so they still show the items which they had before the event was fired, but when this event is completed then transfer of items is also completed.
So in short I want to raise another event somehow or get notified when the DynamicOverflowItemsChanging completes its execution, so I can have the correct data and set the visibility of more button correctly. or in other words I want to implement a behaviour of DynamicOverflowItemsChanged event, which unfortunately doesn't exist in the api, so I am looking for an alternative way.
I know I can invoke another event right at the end (just before DynamicOverflowItemsChanging event is finished), but that way I still don't get the correct values, correct values only become available when this event finishes its execution. Like we can do with Task.Then() so when a task completes another can automatically start, so I want something like that here . any suggestions would be appreciated.
protected override void OnApplyTemplate()
{
var barr = (CommandBar)GetTemplateChild("MediaControlsCommandBar");
//the event to control the dynamicoverflow automatically.
barr.DynamicOverflowItemsChanging += (s, e) =>
{
if (_secondarycontrols.Items.Count == 0 && e.Action == CommandBarDynamicOverflowAction.AddingToOverflow)
_moreButton.Visibility = Visibility.Visible;
else if (_secondarycontrols.Items.Count == 1 && e.Action == CommandBarDynamicOverflowAction.RemovingFromOverflow)
_moreButton.Visibility = Visibility.Collapsed;
};//when this event finishes here I want to get notified.
//base implementation
base.OnApplyTemplate();
}

Warm greetings, fellow Microsoft Student Partner :-) .
The quick and dirty hack would be to add a Task.Delay to the end of the handler and hope the items will have changed until the delay is over. This is of course really ugly and error prone. I would suggest a different solution.
You already have access to the _secondarycontrols which is a CommandBarOverflowPresenter. This is very useful, because Items property has a VectorChanged event which is fired whenever an item is added, removed or changed. This means, you can actually use this event and move your logic inside it instead of using the DynamicOverflowItemsChanging event. You can then directly check for the number of items which will be accurate.

Is it possible to fire ComboBox SelectedIndex Changed Event even when old and new index are same?

I have a scenario is which I need to fire the SelectedIndexChanged event of a winform's combox even when the old and new index is same.. I can not use SelectionChangeCommited because the values are being set programmatically .. and it wont get fired. Is it by any chance to force 'SelectedIndexChanged' to fire even when old and same index are same?

It seems wierd that you want the event to refire for the same item. It's probably because you just want to reexecute the event handler logic. Why dont you extract the SelectionChanged logic into a new method and call that one programmatically?

Nothing prevents you from calling event handler directly:
comboBox1_SelectedIndexChanged(comboBox1, new EventArgs()); // or (null, null)
But solution of atomaras is a better (nicer) way to do it.
I myself dislike to use standard components in more-less serious software. Instead I subclass all standard components from very beginning and adding functionality to them as soon as I need it without needs to change anything in the existing forms.
In this case I'd add a public event riser OnSelectedIndexChanged to execute event (to run code inside event handler programmatically).

combobox.selectedIndex = value;
combobox.selectedevent(null,null);

Event handler doesn't execute after subscribing new event handler

I have a MVVM application in WPF. I have an event that gets dispatched from a static instance of a class.
When a given condition occurs, I need to listen for the next occurrence of said event. I do this with the following code:
myInstance.OnData += myEventHandlerInstance;
The event handler is removed at a later time, but as soon as it is added, the event handlers in the other view models no longer execute. I have verified that the dispatcher is the same instance in all places where the event is fired and handled (using the methods described below).
Why does the existing handler not get executed?

delete this line:
myInstance.OnData -= new EventHandler(myInstance_onData);
Why were you doing this? You should get the original event handler and remove that. Also, you should do this outside the event handler itself.

You'll have to put in something like this, to ensure that your code is executing on the right thread:
if(Dispatcher.CurrentDispatcher.CheckAccess())
{
<Code here>
}
else
{
Dispatcher.CurrentDispatcher.Invoke(<Code here>)
}

Thanks for the help everyone. You helped me focus in on the problem. The problem was purely a structure/logic issue, I was able to dig deeper into the code.

Issue in CheckedChanged event

I have a check box and I have subscribed for the CheckedChanged event. The handler does some operations in there. I check and uncheck the checkbox programmatically (ex: chkbx_Name.Checked = true), and the CheckedChanged event gets fired.
I want this event to be fired only when I manually check or uncheck it. Is there any way to avoid firing of this event when i check/uncheck it programmatically?

unsubscribe the event before you set:
check1.CheckChanged -= check1_CheckChanged;
then you can programmatically set the value without the checkbox firing its CheckChanged event:
check1.Checked = true;
then re-subscribe:
check1.CheckChanged += check1_CheckChanged;
[EDIT: March 29, 2012]
The problem with Tanvi's approach is you need to catch all source of manual check or uncheck. Not that there's too many(it's only from mouse click and from user pressing spacebar), but you have to consider invoking a refactored event from MouseClick and KeyUp(detecting the spacebar)
It's more neat for a CheckBox(any control for that matter) to be agnostic of the source of user input(keyboard, mouse, etc), so for this I will just make the programmatic setting of CheckBox really programmatic. For example, you can wrap the programmatic setting of the property to an extension method:
static class Helper
{
public static void SetCheckProgrammatically(
this CheckBox c,
EventHandler subscribedEvent, bool b)
{
c.CheckedChanged -= subscribedEvent; // unsubscribe
c.Checked = b;
c.CheckedChanged += subscribedEvent; // subscribe
}
}
Using this approach, your code can respond neatly to both user's mouse input and keyboard input via one event only, i.e. via CheckChanged. No duplication of code, no need to subscribe to multiple events (e.g. keyboard, checking/unchecking the CheckBox by pressing spacebar)

No. Those property change events fire whenever the property value changes, regardless of whether this was done by your code, by the control's own code or databinding. It's all the same code path, usually.
What you can do, however, if your event handler resides in the same class as the code that changes the property value, is to introduce a private boolean field in the class which you use as an indicator of whether the current property change is triggered by your code or by the user. After your change you simply reset it. The event handler would then look at the field and decide of whether it should do anything or not:
class Foo : Form {
private bool checkedProgrammatically = false;
void someMethod() {
// ...
checkedProgrammatically = true;
checkBox1.Checked = true;
checkedProgrammatically = false;
// ...
}
private void checkBox1_CheckChanged(object sender, EventArgs e) {
if (checkedProgrammatically) return;
// ...
}
}

I'm sorry I can't just comment on Michael Buen's answer due to my being new here (no reputation), but for what it's worth I strongly prefer his solution to Johannes Rössel's for a couple of reasons.
1) the checkedProgrammatically variable is a little too close to global for me. There's nothing to stop another method accidentally setting it to true, causing all your events to stop.
2) you could end up with a lot of variables depending on the number of events you're dealing with. It would be easy to change the wrong one and the results can be difficult to debug.
3) it's more obvious what you're doing when you unsubscribe then resubscribe. All the logic is right there, and you don't need to change your event handlers to exit early depending on certain conditions.
I've used both methods extensively and I find Michael's a lot easier in the long run.

You can use the MouseClick event and in that check for the checked state of the checkbox.
This way it wont be triggered programatically, it would only be called when the user manually checks or unchecks the checkbox.

You can set boolean variable before changing value programiticaly, and check than reset that variable in checkedchanged event

How to trigger SelectIndexChanged event to VListBox?

Somebody know the VListBox?
It is fast to load item to the listbox.
But I can't get the SelectIndexChanged Event be triggered by set SelectIndex.
Somebody know how to trigger that event by winapi or something else?
VlistBox source code is in the page above.

does the event get fired when you click on the item with a mouse?
if so then it may be by design. also if you are selecting it via code then a better way is not "how to manually trigger the event". consider refactoring the event handling code into a new DoSelectionChanged() method and have the code that calls SelectIndex() call that. in this way the "meaty" stuff that normally would be in an event callback can be used by other methods, not just the callback.
hope that helps

Wy don't you call the EventHandler manually?
vListBox1_selectedIndexChanged(null,null);