Calendar Control WITHOUT .dll or .oxc or reference

[Robert_L_Ross]

While I LOVE the calendar controls I've seen around, I need to make one that
doesn't require registering an ActiveX control or .dll. We (at our company)
cannot access our Start/Run dialog nor a command window. Unless there is a
way to register an .oxc or .dll via VB code, we can't use those options
unless we want to go desk-to-desk installing controls/dll's.

Does anyone have a calendar control that DOESN'T require registering
anything? OR - does anyone have code to register a dll/oxc directly from VB?

Thanks!

 

[ctaleck]

While I LOVE the calendar controls I've seen around, I need to make one that
doesn't require registering an ActiveX control or .dll. We (at our company)
cannot access our Start/Run dialog nor a command window. Unless there is a
way to register an .oxc or .dll via VB code, we can't use those options
unless we want to go desk-to-desk installing controls/dll's.

Does anyone have a calendar control that DOESN'T require registering
anything? OR - does anyone have code to register a dll/oxc directly from VB?

Thanks!

http://www.lebans.com/monthcalendar.htm

I believe this solution claims to do the trick. I'm using it with no
problem in Access 97 on Windows XP systems.

 

[Robert_L_Ross]

This doesn't work. I followed the instructions exactly...complied...every
time I double-click, MSAccess crashes.

Any other ideas?

 

[Robert_L_Ross]

Plus...if I read this right...it DOES require that the "Microsoft Month
Calendar Common Control" be available. This violates what we are looking for.

The solution has to work on the most basic install of MSAccess - no add-ins,
etc.

 

[MikeB]

Here's one using only Access Form, bas Module w/Demo and example...

http://www.byerley.net/AllAccessCal.zip

 

[Stephen Lebans]

You are incorrect. The MonthCalendar control is instantiated directly from
the MS Common Controls library which exists on every WIndow install. It is
not an ActiveX control.

The Calendar solution is in use by 1000's of systems every day. There is not
a recorded instance of it crashing during normal use. If you are running it
and set break points within the subclassing code then all bets are off.

Go back and reread the instructions to incorporate it into your own MDB..

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.

 

[Allen Browne]

Robert, there are heaps of calendars out there, and another simple little
Access form here:
http://allenbrowne.com/ser-51.html

But as Stephen pointed out, there's a good chance that some other factor is
crashing your database. Below a standard sequence for addressing those kinds
of issues.

Work through the sequence in order:

1. Uncheck the boxes under:
Tools | Options | General | Name AutoCorrect
In Access 2007, it's:
Office Button | Access Options | Current Database | Name AutoCorrect
Explanation of why:
http://allenbrowne.com/bug-03.html

2. Compact the database to get rid of this junk:
Tools | Database Utilities | Compact/Repair
or in Access 2007:
Office Button | Manage | Compact/Repair

3. Close Access. Make a backup copy of the file. Decompile the database by
entering something like this at the command prompt while Access is not
running. It is all one line, and include the quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"

4. Open Access (holding down the Shift key if you have any startup code),
and compact again.

5. Open a code window.
Choose References from the Tools menu.
Uncheck any references you do not need.
For a list of the ones you typically need in your version of Access, see:
http://allenbrowne.com/ser-38.html

6. Still in the code window, choose Compile from the Debug menu.
Fix any errors, and repeat until it compiles okay.

At this point, you should have a database where the name-autocorrect errors
are gone, the indexes are repaired, inconsistencies between the text- and
compiled-versions of the code are fixed, reference ambiguities are resolved,
and the code syntax is compilable.

If it is still a problem, the next step would be to get Access to rebuild
the database for you. Follow the steps for the first symptom in this
article:
Recovering from Corruption
at:
http://allenbrowne.com/ser-47.html

 

[Robert_L_Ross]

Sorry to disagree, but not only did I try this from two clean install
machines, I tried it from the actual database it was in from the site...all
crashed. I did not modify the code in any way on the two clean install
machines, nor did I modify the basic install of MSAccess.

 

[Robert_L_Ross]

Oh, and I DID read the instructions and followed them TO THE LETTER...like I
said on my post...if anyone wants to read it.

 

[Douglas J. Steele]

I have never had to install anything to get Stephen's calendar to work.

 

[Stephen Lebans]

Robert it sounds like you would be better of using another solution.
Good luck.

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.

 

[Dirk Goldgar]

In

Sorry to disagree, but not only did I try this from two clean install
machines, I tried it from the actual database it was in from the
site...all crashed. I did not modify the code in any way on the two
clean install machines, nor did I modify the basic install of
MSAccess.

Access version and OS version? It sure sounds like there's something
unusual about your setup. You're the only one who has ever reported
this problem. Do other OS functions that display the same calendar work
OK?

 

[Robert_L_Ross]

Looks like this solution works great.

Robert, there are heaps of calendars out there, and another simple little
Access form here:
http://allenbrowne.com/ser-51.html

But as Stephen pointed out, there's a good chance that some other factor is
crashing your database. Below a standard sequence for addressing those kinds
of issues.

Work through the sequence in order:

1. Uncheck the boxes under:
Tools | Options | General | Name AutoCorrect
In Access 2007, it's:
Office Button | Access Options | Current Database | Name AutoCorrect
Explanation of why:
http://allenbrowne.com/bug-03.html

2. Compact the database to get rid of this junk:
Tools | Database Utilities | Compact/Repair
or in Access 2007:
Office Button | Manage | Compact/Repair

3. Close Access. Make a backup copy of the file. Decompile the database by
entering something like this at the command prompt while Access is not
running. It is all one line, and include the quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"

4. Open Access (holding down the Shift key if you have any startup code),
and compact again.

5. Open a code window.
Choose References from the Tools menu.
Uncheck any references you do not need.
For a list of the ones you typically need in your version of Access, see:
http://allenbrowne.com/ser-38.html

6. Still in the code window, choose Compile from the Debug menu.
Fix any errors, and repeat until it compiles okay.

At this point, you should have a database where the name-autocorrect errors
are gone, the indexes are repaired, inconsistencies between the text- and
compiled-versions of the code are fixed, reference ambiguities are resolved,
and the code syntax is compilable.

If it is still a problem, the next step would be to get Access to rebuild
the database for you. Follow the steps for the first symptom in this
article:
Recovering from Corruption
at:
http://allenbrowne.com/ser-47.html