Bug in QuantityUpDown control binding

[xcondor]

Hi,

I would like to report a bug in the QuantityUpDown control.

When the QUD Value property is the source for binding, the target property does update but the behavior is not as expected.

myTargetTextBlock.SetBinding(TextBlock.TextProperty,
	new Binding {
		Source = [B]MyQud[/B],
		Path = new PropertyPath("Value"),
		Converter = new IntToStrConverter() as IValueConverter,
	}
);

• The target updates on mouse scrolling in the QUD.
• The target updates on clicking of the up & down buttons of the QUD.
• The target updates when the QUD value is changed programatically.
• The target DOES NOT update if the user sets focus inside the QUD and types in a quantity value in the QUD. (onkeypressed handler?)
• The target DOES NOT update if the user pastes a quantity value in the QUD. (ontextchanged handler?)

I have not spent time to figure out how the QUD value property is exposed from the inner textbox, but the implementation is not consistent as there are obviously UI ways to change the value and the QUD control is not aware of the new value.

Of course there are workarounds — digging inside the control to find its nested textbox and binding to it works as expected:

myTargetTextBlock.SetBinding(TextBlock.TextProperty,
	new Binding {
		Source = [B]myQudInnerTextBox[/B],
		Path = new PropertyPath("Text"),
[COLOR="Green"]		//no converter needed as both are type string.[/COLOR]
	}
);

I have not tested if hooking an event handler would be better as I prefer data binding.

MyQud.ValueChanged+=OnMyQudValueChanged;

Bypassing an exposed public property to hack into the control's innards defeats the purpose of custom compound controls. The QUD Value property getter should include ALL the ways the inner textbox value could be changed in the UI.

Thanks for looking into this. It is a true bug. I hope it gets fixed. The fix would not break legacy code of addons but will just make the legacy workarounds obsolete/deprecated.

[NinjaTrader_ChelseaB]

Hello xcondor,

I have an example that uses a QuantityUpDown control. Using this example I am not able to reproduce the behavior.

Below is a link to a video showing manually typing a value and copying and pasting.

https://drive.google.com/file/d/1rMwMqZS6Z99iM8DoV_fy8b47gCgSihm4/view?usp=drivesdk

Below is a link to the SetIndicatorValueFromAddonWindowExample.

https://ninjatrader.com/support/forum/showthread.php?p=492686#post492686

Using this example are you getting different behavior than what is shown in the video?

Is it only the value changed event that is not triggering for this control or are you not able to get the value itself?

[xcondor]

Addon attached to demostrate the QUD bug

Is it only the value changed event that is not triggering for this control or are you not able to get the value itself?

No. It's a binding problem. But ValueChanged also fails for the same reason: the QUD is just a wrapper around a TextBox. Not a good choice for an input of type int. I have never liked Infragistics controls.

Attached is a an add-on which amply demonstrates the issue and even colors red when the value fails to update.

The issue is the loss of focus from the inner TextBox failing to propagate to the window. So the user has to click OUTSIDE the window and then the binding catches up. Traders usually lay out their workspace not to allow even a sliver of desktop, especially because NinjaTrader has no true workspace and losing focus from a window may mean searching through a cacaphony of taskbar thumbnails of various open charts and other windows spread out on multiple monitors. So the user will almost NEVER get a chance to get the value synced unless she decides to change it by some other means, different from pasting or typing it in.

This bug affects not only add-ons but GUI users of the unadulterated platform too, as various buy sell buttons depend on the quantity value. So it is a serious bug.

[NinjaTrader_ChelseaB]

Hello xcondor,

You are using custom code that is not documented by NinjaTrader.

In the example you have provided is _Qud the QuantityUpDown object in question?

It appears that you have attempted to bind this to a textbox property which would not be officially supported by NinjaTrader.

Would you like to submit a feature request for NinjaTrader to support this and fully document this?


May I also confirm you have tested my script without modifying this and found this to not function as expected?

[xcondor]

In the example you have provided is _Qud the QuantityUpDown object in question?

YES

It appears that you have attempted to bind this to a textbox property which would not be officially supported by NinjaTrader.

My code has nothing to with it. I am not looking for support on this bug. I am just reporting it.

The bug exists in the GUI for a user with no addons who only points and clicks in the GUI. And when that user manually types a value, or manually pastes a value, the QUD does not know about it, or actually gets updated later when focus is lost thereby firing the textchanged event. Until then the two values are different.

I stumbled on the bug programmatically but that is just a coincidence. I was trying to bind to the DUQ.Value property. That is absolutely the intended and preferred way and IT IS SUPPORTED. That is exactly what the QUD control is provided for. Of course binding is the preferred WPF way. When I troubleshot why part of the time the binding failed, I remembered from many moons ago the issues with compound custom controls that wrap around a textbox because a textbox tex changed event depends on loss of focus and other bubbling issues. That is exactly the case here too and loss of focus jumps to the entire window, so it makes it worse.

Clicking on another control does effectuate loss of focus and the QUD catches up. But this may not be always the case. For example, do the following:

1. Configure a hotkey buy market
2. click up to quantity of 300 in the QUD.
   Place the cursor inside the QUD and let go of the mouse.
3. type in 2 in the QUD (still do not touch the mouse!)
4. Then use the hotkey for the entry.(still do not touch the mouse!)
5. The QUD displays 2,
6. Check your orders to be pleasantly surprised you are LONG 300 contracts.

You can do this on any window which has a QUD. Some windows like the SuperDOM do not have buy/sell hotkeys but it is very easy to do in code them with a RoutedCommand bound to the Window object. Just a couple of lines of code.

I worked around it by grabbin the value directly out of the inner textbox which is always the correct value. But this is just a workaround. An ugly hack. A better fix is not to use a textbox for numeric values at all.

You said you could not reproduce the bug. So I set up a window with two different binding targets but the source is the same QUD. The state of its inner and outer should be the same but they are not.

Would you like to submit a feature request for NinjaTrader to support this and fully document this?

Reporting a bug is not a feature request. If you are still having a problem undestanding the issue, just file it and let the developers deal with it. They surely know this issue. It's nothing new. Textboxes have been the culprit for decades. I thought these kind of problems were a thing of the past. Obviously not.

[NinjaTrader_ChelseaB]

Hello xcondor,

To confirm, you are wanting to report that you are experiencing unexpected behavior when typing a value into a quantity and then using a hot key to place an order (without the QuantityUpDown losing focus).

The cause of this being the Value property of the QuantityUpDown object is not being updated until the object has lost focus.

I am able to reproduce the behavior with this use case in the UI and I have submitted a report to our development.

Once I have a tracking ID for this I will post in this thread.

We appreciate your patience.

[NinjaTrader_Brett]

XCondor,

First, just wanted to say thanks for the nice bug report. Its appreciated.

We looked into this and I do have to report its working as designed/expected. The reason why is that we have support for users to type in 10K into the QUD. The validation / parsing logic triggers once focus is removed from the field. It is possible that we could try to redesign the QUD to work on each keypress and apply e.g. partial validation on each press but we just did not design it that way. In NinjaTrader the QUD validation triggers when focus is removed from the control and is expected.

What we will be looking into is the hotkey case. Since this for sure is something which should be looked into. However any possible solution we might deploy there likely will not change what you see at a binding level.

[xcondor]

Expose the Text property

What we will be looking into is the hotkey case. Since this for sure is something which should be looked into. However any possible solution we might deploy there likely will not change what you see at a binding level.

Why not expose the Text property of the inner textbox as a property of the QUD? And then document that that is the property to be used as source for binding. Problem solved.

[NinjaTrader_Brett]

When you need to submit an order to the core its int based not string based. Hence at this time we expose a int value which is validated on focus leaving the control.

[xcondor]

When you need to submit an order to the core its int based not string based. Hence at this time we expose a int value which is validated on focus leaving the control.

I did not mean you should change the type of the QUD.Value property from int to string. That would break legacy code.

I meant expose an additional string property named something like QUD.InnerText. That way legacy code is not affected. It's the crudest but simplest fix.

[NinjaTrader_ChelseaB]

Hello xcondor,

I wanted to provide a tracking ID for the HotKeys order entry behavior. This is being tracked with ID #NTEIGHT-12771.

As new releases of NinjaTrader become available please check the release notes for this ID. Below is a public link.

https://ninjatrader.com/support/helpGuides/nt8/en-us/release_notes.htm

In the meantime, you may try de-focusing the control in your script and focusing a different control to trigger the behavior before getting the value or triggering actions that need the value.

The RolloverIndications indicator does this.

https://ninjatrader.com/support/forum/local_links.php?linkid=905

Also, below is a link to a forum thread that has similar code.

https://ninjatrader.com/support/forum/showthread.php?p=531720#post531720

I am also happy to submit a feature request on your behalf to expose an additional text property within the QuantityUpDown to be used for binding. Once I have a tracking ID for this request I will forward this to you for future reference.

[NinjaTrader_ChelseaB]

Hello xcondor,

Your request for a text property added to the QuantityUpDown control to use for binding the value is being tracked with ID #SFT-3189.

Please note it is up to the NinjaTrader Development to decide if and when any request will be implemented.

Thank you for your suggestion.