ComboBox not accepting a pre-recorded date 1

[SitesMasstec]

Hello colleagues!

I have a form with this code in the Init procedure:

    WITH thisform
         ...
        .dtSaida.Value=YDATASAIDA
        ...

Where YDATASAIDA stores a Date (I have confirmed that YDATASAIDA, is a D (Date) VARTYPE, so I am sure its type is Date).

This is the portion on the form to store the date:

It is a ComboBox, and I need it to show the date recorded from another session (using ctl32_DatePicker, from Carlos Alloatti). Of course the user will be able to alter the date.

When running the form an error appears (just for fields storing dates):



What is wrong?

 

[Scott24x7]

Couple of things you can do.
One, SET STEP ON before WITH, and then check the value of the variables/constants as you step through, and it will tell you what value is actually contained in ThisForm.dtSaida.Value (you can also check the value of YDATASAIDA is.
OR, if you're concerned that stepping through will change the outcome, use MESSAGEBOX(ThisForm.dtSaida.Value) or MESSAGEBIX(YDATASAIDA) (I would do both, just to see what they are).
That will tell you what the value is, and it may be clear where your data type mismatch is.
Also, what is the code on the line that is generating the mismatch error? Are you checking it for VARTYPE() or is it some other comparison, where one value on the other side of the comparison doesn't match you dtSaida type? (i.e. if you compare .T. == Thisform.dtSaida.Value) and dtSaida.Value is a date, then this will give you a data type mismatch error, as will any two different data types that are being compared).

 

[Joe Crescenzi]

I replied recently to a similar question and most likely this has a similar cause.

Datatype mismatches can only mean one thing, something you are storing in a control is trying to be placed in a field that does not match it.

You can assign any value to a variable or a control and it will never give you a data type mismatch error, so it's not a matter o the control allowing you to push a date to it. It works like a variable and FoxPro variables are not rigid. You can say X=4, then say X="HELLO", then say X={01/01/2024} and it won't throw an error.

The trouble comes when you try to push that control to a field, and that also depends on how you do it. Some people use a ControlSource, which binds it directly to the column. Some people will replace the value later by saying REPLACE MyColumn with ThisForm.MyControl.Value. It is at that moment that the column type needs to match.

One possibility here is that a ControlSource may be ambiguous, such as "MyColumn", instead of "MyTable.MyColumn", where there is also a variable with the same name but different type, or in cases where there is a DataSession (I never use them), and there is a reference in there to an entirely different table.

Lastly, another common cause is timing. If the control was bound while there was no selected record, where the value is essentially NULL at that moment.

As @Scott24x7 pointed out, the best way to know for sure what is going on is using the debugger to step through the code line by line and then look at what's going on just before the error is thrown and / or throwing some MessageBoxes out there at key moments to confirm things are as they should be.

 

[Chris Miller]

A combobox value can only be a date if the items of its recordsource are also dates.

It doesn't matter that you want to display a date and have a date and think that's correct. Only a textbox could be set to a date without any further preparations on the side of the textbox, When you set a combobox value, you don't set an item it displays, that's always set with the combobox recordsource and recordsourcetype and the value has to match that of an item.

Without preparing any items or having items that are not the DATE type, you get a datatype mismatch - of course.

 

[Chris Miller]

I need it to show the date recorded from another session (using ctl32_DatePicker, from Carlos Alloatti).

Then why are you using a combobx and not a ctl32_DatePicker? Anything you recorded should be displayed for further modification with the same control it was recorded with.
You're showing a deep non understanding of anything. You don't even realize that the error with not first setting combobox items is the same error you made in your last post. You don't even remember the last lesson you've been teached about comboboxes. It's insane to help you, if you don't learn anything.

 

[SitesMasstec]

Scott, Joe, Chris, I'm trying to understand and put into practice your advices
Chris, ctl32_DatePicker is "inside" the ComboBox, it is the Parent code for the ComboBox.

 

[Scott24x7]

Hi SitesMasstec,
I use this same control, but I create the "Illusion" of a dropdown. The Ole control appers on the form only as the "drop down" for the combo. When you click it, the Ole calendar appears.

When you select a date with it, the calendar OLE Date picker pops up:


You pick a date, and then note that the date is then that value updates the apparent "selection" (in this case the date of an expense report entry).
The code in the "Change" event of the OLE Date Picker is simple:

*** ActiveX Control Event ***
* whenever user makes change in control update form with new values

dDate = DATE(This.Year, This.Month, This.Day)
*
This.Parent.txtEXPENSEDETAILDATE.Value = dDate

Where This.Parent.txtEXPENSEDATEDETAIL is the object that holds the date (The OLE Picker does not), it's just a control on the form to make it easy to pick the date, and always in the right "format").

Using a combobox where you have both .Value and .DisplayValue can cause a LOT of confusion, and you're probably working harder than you need to. Simplify it with a regular text box, and let the date picker do what it does best, while letting the text box do what it does best. And of course with the text box, you can still enforce the DATE format you want, and allow users to enter by hand instead of using the date picker, without "entangling" the two. (And not at the quantum level...)

Just thought you might try this simple(r) solution, I took your approach initially as well, but soon found creating the illusion of the combo box was easier to do, and easier for users to use without all the issues of working with the combo box for unnecessary complexity.

For clarity, note that there are TWO objects on the form, set next to each other after "Expense Date" in the image example I provided.

 

[Chris Miller]

ctl32_DatePicker is "inside" the ComboBox.

Documentation of the ctl32_datepicker https://ctl32.blogspot.com/p/ctl32-datepicker.html says this:

This control uses a standard VFP combobox and a ctl32_monthcalendar

That doesn't change anything about what I su can't set the value of a VFP combobox before iut has items. And the ctl32_datepicker is managing is combobox, not you.
The last line in that documentation is the interesting line for you:

The date value can be set/retrieved in the ctlValue property.

Don't set .dtSaida.Value=YDATASAIDA, instead

.dtSaida.ctlValue=YDATASAIDA

That is, if dtSaida is your name for the ctl32_datepicker on your form.

It's all documented, you just have to read it.

Let me tell you a secret how you can get to the point in the documentation you're interested in faster than just reading it fully: You use CTRL+F to find somthing, then search for a relevant key word like SET and the amount of words you have to read reduces very much. If you don't get to what you're intereested in there, search other relevant terms, like date or value, in this case.

Edit, again: Just a few lines above that the documentaiton says:

The control can be bound by using the ctlControlSource property. DO NOT use the ControlSource property, since VFP comboboxes cannot be bound to a date type field/property/variable.

So that's another useful property: ctlControlSoure to be set to a date field of a table, for example. Also notice the warning and advice about VFP comboboxes not being able to be bound to date type values in fields, properties or variables, that also tells you what you tried had to error.

If you use a new (free) control, there's still one minimum prize you pay anyway: Learning how to use it. Especially when you encounter errors, why not refer to the documentation?