Run-time error '2763' setting date/time picker value.

[Killer42]

Hi all.

I have a couple of dtpicker controls on a form. When one is changed by the user (that's me, in this case) the code in the _Change event sets the other one, to keep it within a logical range (can't start a task before it's requested).

I know I had this working, but don't recall for certain what has changed. Anyway, it is now causing

Run-time error '2763':
 
DTPicker returned the error: An error occurred in a call to the Windows
Date and Time Picker control..

I've been doing some searching on TSDN and elsewhere, without success so far.

Oh, just had a thought. Is it possible I'm just running into the old silliness of not being able to address the properties while the control is hidden? I'll test that and get back to you.

[Killer42]

Damn! That was it.

I still can't believe Access VBA is so stupid it can't change a property of a hidden control. :( Now I'll have to rewrite all my code to show the control, change it, then re-hide it - but only if it was hidden to start with. Grrr...

[nico5038]

You can keep the control visible, but use a rectangle on top and manage the visibility of that to reveal the dtpickers.

Nic;o)

[Killer42]

You can keep the control visible, but use a rectangle on top and manage the visibility of that to reveal the dtpickers.

Sneaky - I like it! :)

[Killer42]

Sneaky - I like it! :)

Argh!

How can I cover up the dtpicker? I've tried placing a label and an option group over it. They can both cover up the label, but the actual picker control shows through them. (Yes, I have them set to "normal", not transparent).

I can't seem to create a unbound object frame without placing an object in it, or an image control within putting an image in it. I keep trying things that are perfectly simple in VB6, and running into limitations in Access. :(

I suppose if necessary I can create a small image using the same colour as my background, but what if the colour scheme changes? And will the image control work as a cover? I'll have to test it - hopefully some time today.

Any other ideas for a "lid" control I can put over my dtpickers? I love the idea, but so far the implementation is proving to be a real pain.

[Killer42]

P.S. The various controls that I tried did cover up the dtpicker at design time, but at runtime, no-go.

[nico5038]

And hiding the form, then set the dtpickers and then show the form ?

Nic;o)

[Killer42]

And hiding the form, then set the dtpickers and then show the form ?

Interesting idea, but not likely to be an option in this case. Each click to a datepicker adjusts others to keep them in synch.

This is starting to feel just like MS Word - you know, the way it seems to be designed to prevent you finding any way to do what you want to do. No matter which way you turn, they've found some way to cut off that approach. :(

[Killer42]

In this case, I think I'm going to go back to my original technique, hiding and showing the dtpickers. But rather than setting their Value directly, I'll pass the control and the new value to a routine which performs this logic

Hold the value of .Visible property
If it's hidden Then
  Set .Visible to True
End If
Set .Value to passed value
If it was originally hidden Then
  Set .Visible = False
End If

Seems a bit of an ugly solution, but I think it should work. I'm thinking of also passing the property name, so I can use it for things other than .Value.

[Killer42]

...I'm thinking of also passing the property name, so I can use it for things other than .Value.

Well, what a surprise! It didn't work.

I expect it will work alright if I use the original routine to explicitly set the .Value property, but when I passed the string "Value" and tried to set control.Properties(PropName) I got run-time error '2455': You entered an expression that has an invalid reference to the property Value.

Sigh... :(

[Killer42]

I've changed my code to invoke a new sub which works as outlined above. It's not elegant, but appears to work.

Since hiding the dtp's behind another control didn't pan out, I was thinking, maybe I could leave them visible but shift them off-screen. Can't take the time to go into it now, though. (I'd need to play with things like Tab Stop and so on.)

[NeoPa]

Try this :

'SetVal sets the value of a control even if it's hidden.
Public Sub SetVal(ctlThis As Control, varValue As Variant)
    Dim blnVisible As Boolean
 
    With ctlThis
        blnVisible = .Visible
        .Visible = True
        .Value = varValue
        .Visible = blnVisible
    End With
End Sub

I don't know if this is a lot more elegant than your version but it certainly worked for me (except I didn't set up a DT Picker control - just tested it on a TextBox).

[nico5038]

Ever though to switch to an all Access calendar like the one from:
http://www.mvps.org/access/forms/frm0050.htm
(keep shift pressed, otherwise there's an error...)

Nic;o)

[Killer42]

...I don't know if this is a lot more elegant than your version but it certainly worked for me (except I didn't set up a DT Picker control - just tested it on a TextBox).

No offence, but I'm not going to bother trying. During testing on the DTPicker, one of the things I tried placing over it was a text box. The DTPicker just seems to bust through everything, including textboxes.

For now I'm just going to go with my current solution, which looks as though it works, even if it is ugly behind the scenes. It's not worth rewriting over and over.

Actually, now that I come to read it, your solution is the same one I'm using. The only difference is that I'm testing the visibility and only changing it when necessary. I've always been under the impression that setting control properties is slow compared to reading them or playing with variables, and so avoid it whenever possible.

[Killer42]

Ever though to switch to an all Access calendar like the one from: http://www.mvps.org/access/forms/frm0050.htm
(keep shift pressed, otherwise there's an error...)

Thanks for that Nico. I'll be curious to have a look at it, when I can find time. But for now I'll be sticking with the workaround I've got, since it has the advantage of already having been done. :)

[nico5038]

No thanks needed :-)
I stopped using the dtpicker as it won't work on all PC's. In general I try to work without ocx controls as much as possible to limit dependencies to the .dll hell :-)

With A2007 this trouble is "solved" as every date datatype will get a calendar control automatically.

Nic;o)

[Killer42]

...With A2007 this trouble is "solved" as every date datatype will get a calendar control automatically.

I don't suppose they've overcome the old 2GB limitation? Even 4GB would be some improvement.

[nico5038]

Not that I know of. Guess they won't do much effort for the Jet engine as they want to sell MS SQL <LOL>

Nic;o)

[Killer42]

Not that I know of. Guess they won't do much effort for the Jet engine as they want to sell MS SQL

Yeah, that's what I figured.

[NeoPa]

No offence, but I'm not going to bother trying. During testing on the DTPicker, one of the things I tried placing over it was a text box. The DTPicker just seems to bust through everything, including textboxes.

For now I'm just going to go with my current solution, which looks as though it works, even if it is ugly behind the scenes. It's not worth rewriting over and over.

Actually, now that I come to read it, your solution is the same one I'm using. The only difference is that I'm testing the visibility and only changing it when necessary. I've always been under the impression that setting control properties is slow compared to reading them or playing with variables, and so avoid it whenever possible.

That's fine Killer.
I didn't get to see your code so didn't know what you'd come up with.
I worked on the basis that as a form is user operated, the efficiency of the routine (with unnoticeable levels of delay) was secondary to the tidyness of the code. You obviously have something just as good already (No surprise there really :)) so that's ok.

[Killer42]

...I didn't get to see your code so didn't know what you'd come up with.

What's that? Posting without reading everything first? I'm shocked! ;)

[NeoPa]

I saw your pseudo-code, the outline thinking.
Wasn't sure what you actually came up with.

[Killer42]

I saw your pseudo-code, the outline thinking.
Wasn't sure what you actually came up with.

Ah. Well, in the end I copied the pseudo-code pretty closely. Um.. hang on...

Public Sub Set_DTP_Value(ctl As Control, ByVal NewValue As Date)
  ' Since I have so much trouble setting the value of my datetimepicker
  ' controls due to this exteremely annoying and STUPID limitation
  ' in Access that they have to be visible, I've written this litte
  ' generic routine to take a datetimepicker (actually, it will accept
  ' any type of control, but I don't recommend it) and set the value,
  ' turning the visibility on and off as required to (A) allow the change,
  ' and (B) maintain the controls original state.
  Dim HoldVis As Boolean
  With ctl
    HoldVis = .Visible
    If Not HoldVis Then
      .Visible = True
    End If
    .Value = NewValue
    If Not HoldVis Then
      .Visible = False
    End If
  End With
End Sub

As you can see, I'm pretty verbose when it comes to comments. What a surprise! :)

I considered putting some extra code in to safeguard against going outside of the MinDate and MaxDate range, but in the end I didn't bother. There's so much shuffling around of values (with attendant errors due to the aforementioned range limit) that in the end I just set the min and max 'way off in the past and future and left them there.

Of course, the nice thing about having the value-change encapsulated here is that it will be that much simpler (hopefully) if I do decide to modify the method.

[NeoPa]

Like the comments ;)
Bear in mind the type of your value parameter (NewValue) for fully generic use.

[Killer42]

Like the comments ;)
Bear in mind the type of your value parameter (NewValue) for fully generic use.

In the generic "name the property" version (see copy below), I used Variant for the value type. Normally I hate variants (probably a sign of age :)) though I guess they do have their uses. But as long as the data type is known (as it is here) I prefer to use it. Oh, I meant to ask - what would be the correct type to use for the dtpicker. In my "real" routine (the one with the long comments) I only used the generic "As Control" because I didn't know the right type.

Public Sub SetValue(ctl As Control, ByVal Prop As String, ByVal NewValue As Variant)
  Dim HoldVis As Boolean
  With ctl
    HoldVis = .Visible
    If Not HoldVis Then
      .Visible = True
    End If
    .Properties(Prop) = NewValue
    If Not HoldVis Then
      .Visible = False
    End If
  End With
End Sub

[NeoPa]

I like that code :)
I wasn't sure you could do that generically but you found a good way.
DTPicker controls - I don't know what they are. ...But if you add a watch to one (or even just to the form) then, when the code is active (in break mode) you can see the type in the Watch Window.

[Killer42]

I like that code :)
I wasn't sure you could do that generically but you found a good way.

Thank you. However, if you read an earlier post in this thread, you'll see that it didn't work. But I don't know why.

DTPicker controls - I don't know what they are. ...But if you add a watch to one (or even just to the form) then, when the code is active (in break mode) you can see the type in the Watch Window.

Good point. I'll give it a shot.