dateTimePicker ModifiedChanged Eventhandler

Closed
0
0

Hello everyone,

this is a continuation of this Problem: https://wisej.com/support/question/modifiedchanged-of-imodified

It’s the same program but with Version 3.0.9

  • leaving textBox1 after changing it’s content sets textBox1.Modified to true and hits Breakpoint2. The property stays true if I don’t manually switch it back.
  • When I type into the dateTimePicker1 it immediately hits the Breakpoint1 after the first key press. I would prefer when it only hits, when I I love focus on the picker, like it works with the textbox.
  • changing it’s content with the calender control hits Breakpoint1, but the dateTimePicker1.Text is the old value.

 

As I said in the other Question, I would prefer if the controls worked similar.

Thanks in advance.

  • You must to post comments
0
0

Please retest this issue with our latest Wisej release (3.0.10)

Best regards
Frank

  • You must to post comments
0
0

To update this thread, I think I see the source of the confusion. Property changes events fire when the property changes. In the case of TextChanged it is not directly related to tabbing out of the control. The text is considered changed the moment the user types in the textbox – as it should because the user could click on a button that doesn’t take the focus away, or there can be a timer, or a keyboard accelerator, etc.

As soon as there is an event of any kind that is fired to the server, Wisej updates the state of all controls – as it should since an event of any control expects to find the correct value on any other control.

In this case, when attaching the ModifiedChanged event, Wisej fires it the moment the user modifies the text in the TextBox (by design and as required by most apps to enable save buttons, for example). However, since this event fires all the times the user types (as if it was a KeyDown handler) it also causes the TextChanged event to fire. Which is technically correct but can be confusing. It is the identical behavior as if KeyDown was attached.

The only improvement I can see here is not to fire ModifiedChanged from the client after the first time it’s fired and until the text is reset. I will log as an enhancement request.

  • You must to post comments
0
0

Hi Luca,

I attached a video of me using the TextChanged Event which fires when tabbing but not before. You can see all the code in the video.

ModifiedChanged fires on KeyDown.

Greetings

edit: added the small project as a zip as well.

  • You must to post comments
0
0

Hi Sascha

Thanks for write us

The way how its work is the following

When ModifiedChanged is attached to an handler (lazy event) it is fired immediately when typing for both TextBox and DateTimePicker (works the same way and it’s by design).

When ModifiedChanged is not attached, it’s not fired immediately (because of the lazy event system) but OnModifiedChanged is invoked when there is an event back from the browser.

The Modified property is automatically reset when assigning the Text property even with the same value.

Both work the same way,

Hope to be helpful

  • Sascha Lorenz
    I don’t understand this answer. As I have explained and shown, I have the exact same code for the DateTimePicker and the TextBox, but the events fire at different times. Does the DateTimePicker handle Lazy Events generally earlier/more often, than the TextBox? It renders the ModifiedChanged Event kinda useless for the DateTimePicker, since I can’t use the Text-Property or the User isn’t done editing the field.
  • Luca (ITG)
    We have tested it and it works the way we described. If you see a different behavior please attach a small runnable test case and the specific version of Wisej (since, as we have explained, this was fixed in the last build). The ModifiedChanged event fires when the Modified property is changed. That’s by design. If you need to check when the user is done editing use Validating, Validated, Leave, LostFocus.
  • Sascha Lorenz
    Thank you Luca. I just retried it and you are correct. But I have other programs where events like ModifiedChanged or TextChanged only fire when leaving the TextBox. I always thought that is by design with the lazy Events to reduce ajax calls. I don’t understand why these events are so indeterministic from program to program. It was quite convenient that TextChanged only hit when leaving the TextBox. I think Validating, Validated, Leave, LostFocus all hit even when the content isn’t changed. I guess I have to make my own Events for that?
  • Luca (ITG)
    Lazy event fires when there is a handler attached. I don’t know which other programs you have that behave differently, The implementation in Wisej is the same and doesn’t change depending on your program. TextChanged doesn’t fire when leaving the TextBox, it fires when the text changes. It may change when leaving the textbox or it may change when a timer fires or a button is clicked because that’s when the browser gets back to the server, for example, if you attach KeyDown you will also get TextChanged, it’s al logical and deterministic since it’s a web system where actions occur on the browser and are sent to the server when there is an event. All [PropertyName]Changed events fire when the related property changes – there is no other rule. There is no direct connection to leaving a control. In Validating you can check this,Modified, which is reset automatically when the Text property (or Value property after the last fix) is assigned. HTH.
  • You must to post comments
Showing 4 results