My (previously working) DateTimePickers have gone nuts!
-
I have a fairly simple VB.Net application which I wrote a few years ago to chart weather observations. It uses two DateTimePicker controls to specify the date/time range of the data to be charted and had been working fine, once I got a few initial minor bugs sorted out. I don't use it that often (perhaps once every 3-6 months), so I don't know when the behavior I am about to describe started. A couple of days ago, I ran the application, and, instead of defaulting to displaying the beginning and end of the most recent 24 hours for which data was available (e.g. 04/18/2017 12:23), both controls displayed only the delimiter characters (// : ). The values of the fields were apparently correct - choosing a data set and pressing the 'plot' button produced the expected plot of 24 hours' data - but the datetimepicker controls didn't 'work'. Debugging with Visual Studio confirmed that the contents of all the variables were as expected, but the controls still looked (differently!) weird in the running program, although they looked as they should in design view. Running under Visual Studio, the controls sort of worked, but with an enormous amount of horizontal space (and no delimiters) between each subfield (month, day, year, minutes, seconds), so that only one or at most two subfields were in view at a time. Has anyone seen anything like this and/or does anyone know what may be going on.
-
I have a fairly simple VB.Net application which I wrote a few years ago to chart weather observations. It uses two DateTimePicker controls to specify the date/time range of the data to be charted and had been working fine, once I got a few initial minor bugs sorted out. I don't use it that often (perhaps once every 3-6 months), so I don't know when the behavior I am about to describe started. A couple of days ago, I ran the application, and, instead of defaulting to displaying the beginning and end of the most recent 24 hours for which data was available (e.g. 04/18/2017 12:23), both controls displayed only the delimiter characters (// : ). The values of the fields were apparently correct - choosing a data set and pressing the 'plot' button produced the expected plot of 24 hours' data - but the datetimepicker controls didn't 'work'. Debugging with Visual Studio confirmed that the contents of all the variables were as expected, but the controls still looked (differently!) weird in the running program, although they looked as they should in design view. Running under Visual Studio, the controls sort of worked, but with an enormous amount of horizontal space (and no delimiters) between each subfield (month, day, year, minutes, seconds), so that only one or at most two subfields were in view at a time. Has anyone seen anything like this and/or does anyone know what may be going on.
There was a similar question posted yesterday, but I cannot recall where it was (can't find it in the obvious places). Someone suggested checking the code to see if some control information is being garbage collected early. [edit] Found it in the C++ forum: CDateTimeCtrl in Windows 10 - C / C++ / MFC Discussion Boards[^], but not sure if that helps. [/edit]
-
There was a similar question posted yesterday, but I cannot recall where it was (can't find it in the obvious places). Someone suggested checking the code to see if some control information is being garbage collected early. [edit] Found it in the C++ forum: CDateTimeCtrl in Windows 10 - C / C++ / MFC Discussion Boards[^], but not sure if that helps. [/edit]
Thanks for the pointer. As you imply, though, other than reassuring me that 'I am not alone', the C++ thread doesn't seem to help. The OP in that thread seems to have seen the problem just after applying the Win 10 Creators Update, which is when I, too, saw it, but I can't imagine why a change in garbage collection could be relevant in my case. I will look again at the code with that potential issue in mind, but I doubt if I will find anything. [edit] I have looked at the code. It is a single Form Application and there is nothing even remotely related to the problematic DateTimePickers that should be going out of scope unless/until the Form is closed. [/edit]
-
Thanks for the pointer. As you imply, though, other than reassuring me that 'I am not alone', the C++ thread doesn't seem to help. The OP in that thread seems to have seen the problem just after applying the Win 10 Creators Update, which is when I, too, saw it, but I can't imagine why a change in garbage collection could be relevant in my case. I will look again at the code with that potential issue in mind, but I doubt if I will find anything. [edit] I have looked at the code. It is a single Form Application and there is nothing even remotely related to the problematic DateTimePickers that should be going out of scope unless/until the Form is closed. [/edit]
-
I have a fairly simple VB.Net application which I wrote a few years ago to chart weather observations. It uses two DateTimePicker controls to specify the date/time range of the data to be charted and had been working fine, once I got a few initial minor bugs sorted out. I don't use it that often (perhaps once every 3-6 months), so I don't know when the behavior I am about to describe started. A couple of days ago, I ran the application, and, instead of defaulting to displaying the beginning and end of the most recent 24 hours for which data was available (e.g. 04/18/2017 12:23), both controls displayed only the delimiter characters (// : ). The values of the fields were apparently correct - choosing a data set and pressing the 'plot' button produced the expected plot of 24 hours' data - but the datetimepicker controls didn't 'work'. Debugging with Visual Studio confirmed that the contents of all the variables were as expected, but the controls still looked (differently!) weird in the running program, although they looked as they should in design view. Running under Visual Studio, the controls sort of worked, but with an enormous amount of horizontal space (and no delimiters) between each subfield (month, day, year, minutes, seconds), so that only one or at most two subfields were in view at a time. Has anyone seen anything like this and/or does anyone know what may be going on.
A "few years ago" I was running XP ... .NET something ... and probably a VGA monitor. Now I run .NET 4.6.1; HDMI monitors; Windows 8.1 / 10; no XP "themes"; new default "font families"; etc. Most certainly I had to "tweak" my UI's moving forward.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
A "few years ago" I was running XP ... .NET something ... and probably a VGA monitor. Now I run .NET 4.6.1; HDMI monitors; Windows 8.1 / 10; no XP "themes"; new default "font families"; etc. Most certainly I had to "tweak" my UI's moving forward.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
And your point is?! If you had read the second paragraph in my original post, let alone the thread that Richard pointed to, you would have seen that almost the first thing I (and the OP in the other thread) did was to go back and rebuild the application, which (at least in my case) only uses standard, current, controls, and determine that the controls in the rebuilt application also showed the strange behavior. This is not a "the application I created in 2005 doesn't run unchanged under Windows 10" issue.
-
And your point is?! If you had read the second paragraph in my original post, let alone the thread that Richard pointed to, you would have seen that almost the first thing I (and the OP in the other thread) did was to go back and rebuild the application, which (at least in my case) only uses standard, current, controls, and determine that the controls in the rebuilt application also showed the strange behavior. This is not a "the application I created in 2005 doesn't run unchanged under Windows 10" issue.
You seem mystified by behaviour that I have found typical moving from one "configuration" to another. You seem to imply you have lived with the same hardware and software all this time and "somehow" have now suddenly gone "nuts". While pointing me to a C++ forum while your app is VB.NET.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
You seem mystified by behaviour that I have found typical moving from one "configuration" to another. You seem to imply you have lived with the same hardware and software all this time and "somehow" have now suddenly gone "nuts". While pointing me to a C++ forum while your app is VB.NET.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
Our experiences apparently differ. In general, I have found that .Net applications, and particularly their standard controls, almost always continue to work as expected through hardware and software upgrades, so long as the Framework version that they require is still present on the new system. On the very rare occasions when I have seen a problem with an old compiled application on a new system, this has always been corrected by rebuilding the application on/for the new system. The C++ thread is at least arguably relevant because the apparently very similar problems that both threads describe is in a standard control which is part of the Framework, rather than in user code, strengthening (IMHO) the concern that the problem is one recently introduced into the Framework rather than 'user error'.
-
Our experiences apparently differ. In general, I have found that .Net applications, and particularly their standard controls, almost always continue to work as expected through hardware and software upgrades, so long as the Framework version that they require is still present on the new system. On the very rare occasions when I have seen a problem with an old compiled application on a new system, this has always been corrected by rebuilding the application on/for the new system. The C++ thread is at least arguably relevant because the apparently very similar problems that both threads describe is in a standard control which is part of the Framework, rather than in user code, strengthening (IMHO) the concern that the problem is one recently introduced into the Framework rather than 'user error'.
The (Windows Forms) Date Time Picker has been around since 1.1; initially, as a Windows "common dialog" control; so, no, it was not always "standard". (You were not clear on what version of .NET you first developed on; or even what OS). And any number of properties are "obsoleted" from one version to the next; and new ones introduced. I'm not convinced there may not be "some" impact somewhere. It's those "cosmetic" changes (by the vendor) that bite you.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
I have a fairly simple VB.Net application which I wrote a few years ago to chart weather observations. It uses two DateTimePicker controls to specify the date/time range of the data to be charted and had been working fine, once I got a few initial minor bugs sorted out. I don't use it that often (perhaps once every 3-6 months), so I don't know when the behavior I am about to describe started. A couple of days ago, I ran the application, and, instead of defaulting to displaying the beginning and end of the most recent 24 hours for which data was available (e.g. 04/18/2017 12:23), both controls displayed only the delimiter characters (// : ). The values of the fields were apparently correct - choosing a data set and pressing the 'plot' button produced the expected plot of 24 hours' data - but the datetimepicker controls didn't 'work'. Debugging with Visual Studio confirmed that the contents of all the variables were as expected, but the controls still looked (differently!) weird in the running program, although they looked as they should in design view. Running under Visual Studio, the controls sort of worked, but with an enormous amount of horizontal space (and no delimiters) between each subfield (month, day, year, minutes, seconds), so that only one or at most two subfields were in view at a time. Has anyone seen anything like this and/or does anyone know what may be going on.
As per the other discussion looks like Windows has made a structural change which is perfectly normal. You should be able to go around the problem by just using Windows API. The other guy with the problem said he was losing the last word but I am pretty sure that is because he didn't have enough room in the box for the wording because the font was obviously slightly different spacing. I told him about using the negative height which forces absolute height selection of font and gives windows no latitude to play with it. I don't know what parameters the original MFC code used in selecting a suitable font but you just need to work it out. WM_SETFONT should and must work because it is an API message if it doesn't work correctly it would be given a high priority to fix from Microsoft because it could effect any and every program. This should not be a big issue to fix. Using frameworks makes things easier the penalty is sometimes things can change in the Windows API that break the frameworks. The alternatively would be Microsoft not ever be allowed to change anything which as one of your comments already says this stuff has changed multiple times over the years already.
In vino veritas