VB6 - MSCAL.OCX Replacement: "Kal"

[dilettante]

Some people aren't happy with the DateTimePicker and MonthView controls that come with VB6. They'd like to use the Calendar from MSCAL.OCX, but this control is not really approved for use in VB6 programs and more importantly hasn't been redistributable for a long time - if ever.

Oddly enough some searching I did failed to turn up examples of straightforward Calendar clone efforts. Everyone seems to want to make something jazzier: exta bells and whistles, clashing color schemes, etc. So here we have Kal, a replacement or alternative to MS Calendar.

This is a quick and dirty attempt at an alternative to the Calendar control that is part of MS Office. It is written in 100% VB6 (and should compile in VB5 as far as I know) with no risky subclassing or other stunts. But this is also one of those "don't need it until you need it" kinds of things. I'm not claiming Kal is particularly special, and if you find a better clone go ahead and post a link to it below this post.

The main limitation is that Data Binding has not been implemented, but this should be a simple matter to add if you need it.

Being quick and dirty, there may be bugs in it yet. There is also a lot of room for optimization and code cleanup here. The idea was to get something put together fast, so if nothing else it may serve as a platform for you to start with... or at least give you some ideas.

I've added a few minor extensions, like more color properties and a NewValue event triggered on any date change. I don't think I missed too many things, but be sure to read the comments at the head of the Kal.ctl module!


As far as I know it is working fine. You can just add the Kal control (and its KalDayCell sub-control) files to your Projects. Or you could add them to a new OCX Control Project and expose Kal and the Enums and make your own reusable Calendar control library.

Kal should be close to a drop-in replacement for MSCAL as it stands.

Sample project attached along with full source.


Known glitch, Should be fixed now:

Compiling the sample project from the command line (or by right-click, Make) results in a "failed to load control, see Form1.log for details" abort. Compiling from within the IDE works fine though.

[Nightwalker83]

I have encountered an "Out of Memory" error on the following line:

Private Sub CloneControls()
    Dim I As Integer
    
    For I = 1 To 6
        Load shpDayName(I)
        shpDayName(I).Visible = True
        Load lblDayName(I)
        lblDayName(I).Visible = True
    Next
    For I = 1 To 41
        'Load cellDay(I) 
        cellDay(I).Visible = True
    Next
    linShadowVert.ZOrder vbBringToFront
    linShadowVertDayName.ZOrder vbBringToFront
    linShadowHoriz.ZOrder vbBringToFront
End Sub

I commented out the line in question.

Although, error only occurs when trying to compile the project.

[dilettante]

Thanks for taking a look.

I was able to cause an Out of Memory error on compile too, though it required some adjustments such as commenting out the error trapping in the Resize event handler of Kal.ctl.

That line of code is fairly critical though, so commenting it out doesn't solve the problem. All of this must be tied together somehow, perhaps the Resize gets triggered recursively? More work is needed before this will be stable enough for everyone. When it works, it works - and when it doesn't it is a nightmare.

I wonder if the problem is related to nesting UserControls?

[dilettante]

Well, I bit the bullet and gave up on loading additional instances of a UserControl within a UserControl. Clearly the control cloning was where the problems lay.

This should be more stable, and it compiles with right-click, Make just fine now. No more "Out of Memory" errors here.

Corrected version posted above!

[Nightwalker83]

One thing I did notice is that it would load once in the IDE but when you went to load it again after unloading it would cause an error. I can't remember if it was a different error or still the "Out of Memory" error listed above.

[dilettante]

The real redist story for MSCAL.OCX seems a little murky.

The Nays

There are MS KB articles for at least Office 97, Office 2000 and Office 2002/XP that clearly say this OCX requires an Office Developer Edition license.

And the VB6 Redist.txt file does not list MSCAL.OCX for either limited or extended redistribution.

The Yeas

The VS 6.0 Professional and Enterprise installation CDs (and probably standalone VB6 Pro & Ent CDs) and their install process include an Office 97 version (8.0.0.5007) of MSCAL.OCX.

Furthermore there is even a KB article providing PDW packaging assistance for VB6 programs using that version of MSCAL.OCX (a "how to fix the buggy MSCAL.DEP file which has the wrong version numbers in it and tries to register it incorrectly" article).

And even another KB article on getting the O97 version to install into Win2K when installing VS/VB 6.

But Another Nay

The Microsoft-supplied standard VB6 component merge modules for use in building Windows Installer packages do not include MSCAL.OCX of any version.

What To Do?

Well, if possible don't use any version of MSCAL.OCX at all. After all it isn't listed in Redist.txt at all and the explicit KB articles say "no way." Perhaps Kal can help you there.

Or maybe you want to take a chance. Then you should only package the 8.0.0.5007 version from the CDs (which installs into System32/SysWOW64). The best way to make this happen if you have a later version of Office on your dev machine is to copy the 8.0.0.5007 copy into:

C:\Program Files\Microsoft Visual Studio\VB98\Wizards\PDWizard\Redist

or

C:\Program Files (x86)\Microsoft Visual Studio\VB98\Wizards\PDWizard\Redist

or wherever your PDW's Redist folder has been installed to.

This will at least cause the PDW to use the version from the VS/VB6 CDs instead of a later version that may currently be registered on your machine. If using another packaging technology you'll have to take explicit steps to package this O97 version.

But will your program still work right when installed on a system with Office 2000, 2002, 2003, 2007, 2010, etc? [A proper installer will skip it if a new version is already installed and registered.]

My Conclusion

Where I come down on this personally is that there are far more strikes against using this control library than for using it. I've only listed a few of the pros and cons that I can still find easily. There is a wide general consensus that you can't redist and shouldn't use MSCAL.OCX in a VB6 program. If asked directly, Microsoft would probably say the same thing.

But I'm no longer as sure.

All I can say for certain is that nothing after the version 8.0.0.5007 is safe to deploy (if indeed that version is either).

[dilettante]

Something that needs elaboration is a quirk involved in adding this to your own Projects if they are not named Project1.

This stems from the fact that Kal.ctl uses instances of KalDayCell.ctx, but in the files provided in the attachment these are internally named "Project1.KalDayCell" due to the way VB6 works. If this whole thing had been created as an OCX then we wouldn't have this, but I wanted to provide it as includeable source modules to avoid presenting you with another OCX to deploy.

So here is what you want to do:

• Open your Project in the VB6 IDE.
• Copy the Kal*.* files to your Project's folder (or maybe a Kal subfolder of that folder).
• Use Project|Add File... in the IDE to add KalDayCell.ctl to your Project.
• Look at your project, and note the Project Name you used. You can also find this on the Name= line in the .vbp file.
• Open Kal.ctl in Notepad. Do a find and replace, changing all Project1 occurrences to your Project's name! Save and exit Notepad.
• Now go back to the IDE and add Kal.ctl to your Project.

That might help some of you by taking care of the "broken linkage" you'd otherwise run into when trying to open your Project in the IDE.