Thanks for taking the time to report this bug.
This bug report isn't very useful because it doesn't describe the bug well. If you have time and can still reproduce the bug, please read http://bugzilla.gnome.org/bug-HOWTO.html and add a more useful description to this bug.

(On the other hand, this might also be a bug in gtk-2.16 we're using and it might go away once the windows build is upgraded to gtk-2.20)

Might also be related to bug 497831...

Thanks for the response Christian.  Familiar with bug-howto - did my best; thought trace file would provide needed clues.  Problem occurred on currently updated Vista 64 and Vista 32 systems with newly downloaded GnuCash v2.40.  Problem occurred when attempting to enter a reinvestment into an investment account.  GnuCash v2.40 behaved normally when entries made end of Dec2010 and beginning of Jan2011.
Test made on 02Feb2011
1.  Reset date preference to format 'ddmmmyyyy'. 
2.  Attempt to make record entry beginning with date.
3.  Select to adjust date using calendar window showing six calendar weeks with the current month in darker characters.
4.  Click arrow to change to later or sooner month - no response.
5.  Click arrows to change year - no response
6.  Clicking on a day in the current month will put that day into the date field.  Clicking on 31Jan enters 03Feb.  Clicking on 30Jan enters 01Feb.  Clicking on 08Mar enters 08Feb.
7.  Click a field in another record and the date field in that record is modified to a Feb or Mar date on the tests that I made.  If record entry is executed then the modified date in that record reverts to the originally entered date in most cases.  The last record in the file will keep whatever date is in that record's date field.
8.  Unable to type a date in the above format since letters cannot be typed into the field.  (IE - No response to typed letters in the date field.)
9.  Same behavior noted with all account types.

Please advise what specific tests would assist in this case.

Test 2 made on 02Feb2011
Created new GnuCash test account; saved in sqlite and xml formats; with no change in symptoms.

> Thanks for the response Christian.  Familiar with bug-howto - did my best;

Ok, thanks for the additional info. The report is fine, but we did not understand some of your sentences. Can you please read bug#497831 and check whether that one describes the same issue you are seeing?

If not, can you please make a screenshot of your chosen "date preference" and then a screenshot of what the register date field looks like, when you cannot enter the date? If there is some other "date preference" where you *can* enter the date, can you please make a screenshot of those as well? The screenshots should be added here as "attachment" and please in .png or .jpg format or similar, but for sure not a word document. Thanks!

Re: bug497831 - looks like there are some similarities.  Not qualified to say the two bugs are the same.

Screenshot attached.

When clicking on the arrows at the top of the date entry field pull down calendar window there is no response.  Neither the month nor the year can be changed.  When clicking on a day outside the current month the highlighted date remains in the current month, and the month label in the top line of the calendar window is not changed.

Changing the date preference to 'ISO' removed date entry problems (reported in initial report).

Thanks for working on this.  Standing by for clarification as needed.

Created attachment 180035 [details]
GnuCash Date and Date Pref

Which language ("locale") do you use in your Windows system? I wonder which locale has "ddmmyyyy" (without any separator in between) as default.

I do not have the answer available at the moment.  I typically use that format where I can since it is completely unambiguous - no guessing required as to the date - similar to a 24 hour time complete with a zone designation.  How I was able to establish that format in GnuCash is currently beyond my ability to recall.

All systems here are set to reflect the local date and time as zone -8; ie USA - Pacific Standard Time.

Will work on (re)finding the steps to use the 'ddmmmyyyy' date format.

Below is the contents of the C:\Users\w8\.gconf\apps\gnucash\general\%gconf.xml file - perhaps there is a clue to the locale here.
-------------
<?xml version="1.0"?>
<gconf>
        <entry name="autosave_show_explanation" mtime="1250559307" type="bool" value="false">
        </entry>
        <entry name="reversed_accounts" mtime="1250459363" type="string">
                <stringvalue>credit</stringvalue>
        </entry>
        <entry name="24hour_clock" mtime="1250400395" type="bool" value="true">
        </entry>
        <entry name="date_format" mtime="1296678173" type="string">
                <stringvalue>locale</stringvalue>
        </entry>
</gconf>
--------------------

Question - If I remove the .gconf file will the program revert to defaults in the preference settings and the .gconf file rebuilt?

Comment - that format worked in my Windows Vista GnuCash install (various 2.3 versions, and the 2.40 version) without difficulty until the day it was initially reported.

Thanks again.

Windows Vista has as a part of its 'Control Panel' a capability to customize 'Regional and Language Options'.  It's possible that GnuCash picked up that customized setting and made that the Locale choice for date preferences.

As a test I reinstalled GnuCash Version 2.3.17 on a computer that I went to some pains to remove all traces of previous GnuCash installs.  The date format displayed in the newly installed GnuCash account register and the 'Locale' entry in date preference was the same as set in the Regional and Language Options in Windows Vista.  I did not make a choice for the 'Locale' format in the GnuCash program.  Apparently GnuCash recognized that the date format was not the default and selected the customized format.

I think that the above is a plausible explanation of how the 04Feb2011 date format came to be used by the GnuCash program.  Why the ddmmmyyyy format is no longer acceptable is still a mystery.

All the best.

I experienced a similar problem (GnuCash 2.4.7, Win7 64bit) with GnuCash trying to use the current locale's custom date format (yyyymmdd). The calendar was completely unresponsive and any attempts to manually set the date would be discarded and replaced with the current date. Changing the date format in preferences solved the problem for me. Thanks for the comments on this bug!

Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 497831 ***

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=641200. Please update any external references or bookmarks.