1,931 questions
Automation NativeWindowHandle of DateTimerPicker differs from HWND of it
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(32, 74%, 13%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMS%3C/text%3E%3C/svg%3E)
Michaletzky, Sandor
0
Reputation points
Hello,
I'm working on UI Automation test of Windows Forms application. It contains a DateTimePicker, and I want to set its value from test independently from current user language.
I thought that ValuePattern could be used for this purpose. Getting value from it provides date in string format, corresponding to the long date format of the current language. But after formatting the date to be set in the same format and sending it with ValuePattern.SetValue, the date didn't get set.
That's why I tried to set the date with sending window message (DTM_SETSYSTEMTIME = 0x1002). I wrote a simple WinForms application to do the same inside the application, and it worked well. Then in the test code I queried native window handle with getting AutomationElement.Current.NativeWindowHandle value, and I sent the message to this window handle. But it didn't work at all. It turned out that the value read with AutomationElement.Current.NativeWindowHandle is equal to the real window handle of the DateTimePicker + 0x10000. The real window handle was read in the application containing the DateTimePicker instance.
That is very weird, because I also have code to automate ComboBox with window messages without any issue, in that case the real window handle of the ComboBox is the same as it is read out with AutomationElement.Current.NativeWindowHandle.
Could you help me how can I handle this issue, please?
Thanks in advance,
Sandor Michaletzky
Developer technologies Windows Forms
Windows for business Windows Client for IT Pros User experience Other
{count} votes
-
RLWA32 49,536 Reputation points2023-06-02T08:44:41.1566667+00:00 I could not reproduce the HWND problem. I created two Winform applications containing DTP controls. One was .Net 6 and the other was .Net Framework 8. Each one displayed the window handle of its DTP control. A .Net Framework 8 automation client was used to obtain the DTP HWND from both of the Winform applications. In each case the correct NativeWindowHandle value was retrieved.
-
Michaletzky, Sandor 0 Reputation points
2023-06-02T08:53:49.3133333+00:00 Hi RLWA32,
Thanks for your quick response.
The issue is with UIAutomation. When tester code uses System.Windows.Automation.AutomationElement of DateTimePicker. The value of AutomationElement.Current.NativeWindowHandle is greater with 0x10000 than native HWND.
The test code uses Framework 4.5.
The AutomationElement is in assembly: UIAutomationClient, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
-
RLWA32 49,536 Reputation points
2023-06-02T09:06:13.5166667+00:00 .Net Framework 4.5 has been out of support since 2016. Support ended for 4.5.2 a year ago. Perhaps your issue would be resolved by using a currently supported version.
-
Michaletzky, Sandor 0 Reputation points
2023-06-02T09:16:07.07+00:00 In my component containing DateTimePicker the OnLoad method looks like this:
protected override void OnLoad(EventArgs e) { using (VTrace trace = new VTrace(_msDomain)) { base.OnLoad(e); trace.Info($"DatePicker.Handle=0x{(int)dateTimePicker1.Handle:X}"); } }The trace line in the OnLoad method produces this line: VMS.FAST.Testing.Automation.WindowsFormsTestbench.WinFormsTestbench OnLoad ->DatePicker.Handle=0x851E4C
In the automation code of DateTimePicker there is a Date property of type DateTime. Code of its setter looks like this:
public DateTime Date { set { using (VTrace trace = new VTrace(_msDomain)) { trace.Info($"DatePicker.Handle=0x{(int)Control.Current.NativeWindowHandle:X}"); --- other code lines to do the job --- } } }The tracer line above produces this line: VMS.FAST.Testing.Automation.Local.Controls.DatePicker Date.set #90 ->DatePicker.Handle=0x861E4C<-
As it is visible handle got from automation (0x861E4C) is greater than got from native code (0x851E4C). The difference is always 0x10000.
-
RLWA32 49,536 Reputation points
2023-06-02T10:01:37.1433333+00:00 Can you reproduce the issue with independent applications that do not use that testing framework? If not and the issue only manifests when using the framework then I suggest you seek support from the testing framework authors.
-
Michaletzky, Sandor 0 Reputation points
2023-06-02T10:09:21.8633333+00:00 I will try to write an independent test application to reproduce the issue and send the code to you.
However, the phenomenon is very weird: I use to control a ComboBox from the same test DLL (with UIAutomation) by means of NativeWindowHandle of ComboBox. In that case the two window handles are equal.
-
RLWA32 49,536 Reputation points
2023-06-03T10:40:44.6333333+00:00 It seems that UI Automation treats the DTP control as a second class citizen. There is no UI Automation documentation for this particular control. For example, the DTP is not among the control types listed for the .Net Framework at UI Automation Control Types. The useless ValuePattern.SetValue method problem has existed for years. The DTP is not a ComboBox but UIA assigns it the ComboBox control type. Uggh.
Sign in to comment
Sign in to answer