This "calendar" plugin implements a "to do" list and "events" list.
It uses a database so the lists are shared between all instances of MUSHclient, and all worlds.
When installed it creates a new database and tables if necessary. Then each time it automatically lists events in the next 14 days, and outstanding "to do " items. You can add new events or "to do" things easily.
eg.
event Christmas 25/12/2002
todo take dog for walk
todo buy a pizza
See the plugin help for more details.
Below is an example of using it. The plugin is available from the plugins page.
Plugin Calendar installed.
Database 'C:\Program Files\MUSHclient\worlds\calendar.mdb' created.
Table 'todo' created.
Table 'event' created.
Database is: C:\Program Files\MUSHclient\worlds\calendar.mdb
Nothing to do.
No events.
Type 'calendar:help' for help.
Now let's add some things to do ...
todo eat
todo drink
todo make merry
To-do item 'eat' added to the database
To-do item 'drink' added to the database
To-do item 'make merry' added to the database
todo
--------Things to do--------
#2: drink (since 11/15/02 4:20:10 PM)
#1: eat (since 11/15/02 4:20:05 PM)
#3: make merry (since 11/15/02 4:20:16 PM)
Now some events ...
event Christmas AT 25/12/2002
event water garden AT 20/11/2002
event go to cinema AT 25/11/2002
Event 'Christmas' AT '25/12/2002' added to the database
Event 'water garden' AT '20/11/2002' added to the database
Event 'go to cinema' AT '25/11/2002' added to the database
events
--------Events in next 14 days--------
#2: water garden AT 11/20/02
#3: go to cinema AT 11/25/02
futureevents
--------Future events--------
#2: water garden AT 11/20/02
#3: go to cinema AT 11/25/02
#1: Christmas AT 12/25/02
delevent 3
Event item 'go to cinema AT 11/25/02' deleted from the database
Now let's finish off some 'to do" items.
done 2
To-do item 'drink' marked as done
todo
--------Things to do--------
#1: eat (since 11/15/02 4:20:05 PM)
#3: make merry (since 11/15/02 4:20:16 PM)
done
-------Done items--------
#2: drink (done on 11/15/02 4:26:21 PM)
However, I seem to have a small problem with it. It appears to install fine ... but then a few seconds later MUSHclient crashes. I tried this a couple of times, with the same results each time.
Hmmm, this is what I dislike about Windows. Crashes like that which I can't reproduce. Naturally it doesn't happen to me or I wouldn't have released it.
I think we can safely speculate that it is a problem in one of your DLLs. After all, it is almost entirely a script, using only a couple of MUSHclient features, like world.note to write to the screen.
First, check which version of VBscript you have installed. I have quickly written a plugin to do that for you. Download the plugin "VBscript_Version" and install it. Then type "scriptversion" and report what you see. It should be something like this:
Script engine = VBScript
Version = 5.0
Build = 3715
If your version is older than that try downloading and installing a newer version. There is a link to do that in the Mushclient -> VBscript part of the forum.
If that doesn't help we'll have to try the version of your ADOX and ADODB DLLs. I'll have to research where you'll find that information.
To help me work out which bit it is, do any of the following lines appear after you install the calendar, and if so, which?
I have been doing some more research. The four COM objects that the plugin uses are in the table below. These are the versions and file locations I have on my NT 4 PC.
Unfortunately unless you are using NT 4 they will probably be in different locations and have different versions, but at least it is a starting point.
You could, for instance, use the "find file" function in Windows to find "msado15.dll" somewhere on your C drive.
Then, right-click on it, and select "Properties", and the select the "version" tab. You can then compare the file version.
If you don't have the database DLLs there are various ways of getting them. I have trouble making sense of Microsoft's page (too much information) but the gist seems to be that you can download them from Universal Data Access Web Site
When I last wanted to get the DAO DLLs I found that installing Office 2000 did the trick, so if you have that (and for some reason haven't installed it), then installing it may give you those DLLs as a side-effect.
Let me know how you go, we should be able to get it working one way or another, and our experiences will hopefully help others.
Well, I don't seem to be crashing now, and now I get the message 'Plugin Calendar Installed', but after that I get a box popping up with the following message:
Error number: -2146827859
Event: Execution of line 108 column 3
Description: ActiveX-komponenten kan inte skapa objekt.: 'ADOX.Catalog'
Called by: Function/Sub: OnSetup called by timer
Reason: processing timer ""
Btw, apart from having the dll properly registered in MUSHclient, should the scripting type also be set to VBscript and enabled, or is that just for scripts? I have that set at the moment, anyhow.
Btw, apart from having the dll properly registered in MUSHclient, should the scripting type also be set to VBscript and enabled, or is that just for scripts?
Plugins are independent of what scripting type you have set, that is one of the beauties of them. For instance, you can have plugins in different languages.
Whoops, I keep forgetting my error messages are in Swedish. ;)
Essentially, the Active-X component can't create the object. And no, that dll doesn't seem to exist. I'll see if I can figure out which download it is that I need.
Windows 98. However ... I have Windows XP on another machine, I wonder if the dll exists there and could be copied over? Of course, I wouldn't know for sure where it should go. Or should it be in the same place as the other two?
Try this link: Microsoft Data Access Components (MDAC) 2.5 RTM (2.50.4403.12) Download Page (download 7.5 Mb) - it appears to have the relevant files. You could copy the files from XP, which may or may not work, but you will probably find they have to be 'registered' otherwise the DLL will physically exist but won't appear in the registry, and it won't know where to find it.
Okay, installed the MDAC 2.5 thing, and now I am not crashing. However, upon reinstalling the plugin, I don't get any of the messages that should show up and if I try to type 'events' it tells me it can't find the file 'C:\MUSH\MushClient\Worlds\calendar.mdb'.
Maybe something is left over from the old install, and preventing a full new install?
Update: Hrm, okay, the calendar install worked in one world, so now the db is there for all worlds to use. The only thing that I know for sure is different between the two worlds, however, is that the one it worked in has pueblo/mxp enabled.
Btw, is it possible for me to edit the plugin to change the date format? American dating (m/d/y) confuses me entirely. ;)
This is what make me nervous about using Microsoft.Jet.OLEDB.4.0 as the provider field without first having some why to make sure that v4.0 is installed and more importantly, that the Access driver is installed. Most programs that support databases include a copy of ODBC and the needed driver 'just in case' it is not up to date or the needed driver isn't installed on your machine. Also, looking at one of the script, it seems that while we check to see if the database exists, the script doesn't bother to verify that it was actually sucessfully created. This is not a good idea, since it not only doesn't inform you if the type of file you tried to create is unavailable or that it failed.
It could be that for some reason installing the MDAC 2.5 was only enough to give you access to creation, but that the ODBC drivers are still missing (I thing ODBC is a seperate package). If you go into the systems control panel and ODBC is in fact installed, there 'should' be a ODBC control panel in there. This is supposed to be part of the standard Windows install and should even more definitely be there if the machine has word, excel, access, etc. on it, but... Who knows how some of these systems get set up.
I do have some ODBC stuff installed. I have Access 97 installed, and have recently been working on installing some kind of program that can handle transferring text or Access dbs to mySQL on another server.
However, I know not all of it is working; I was unable to install myODBC successfully to get Access to work directly with mySQL, and that failed install may have messed some stuff up (but I reinstall Access afterwards, and it appeared to replace the files with the right versions).
Anyhow, it did work when I installed it from one other world ... although isn't the db created supposed to be Access compatible? I can't seem to open it, at least.
However, upon reinstalling the plugin, I don't get any of the messages that should show up and if I try to type 'events' it tells me it can't find the file 'C:\MUSH\MushClient\Worlds\calendar.mdb'.
I don't quite understand that. It is supposed to check for the database every time. Did you wait the 5 seconds for the plugin to check the database? It waits that long because if it does it immediately any error message disappear because the window hasn't been created yet.
Anyway, sounds like it is working now. :)
Quote:
Btw, is it possible for me to edit the plugin to change the date format? American dating (m/d/y) confuses me entirely. ;)
I had hoped it would get the date format from the current system format. Do you have your local format set in the Regional Settings control panel? It is important that you do. For me that made the dates display in Australian format. On the web page some of the examples are in American format simply because the PC I used to get those examples from was still in the default (American English) mode.
Anyway, I have released version 1.1 of that plugin that does further checks of the CreateObject calls in the initialisation, and also does a "FormatDateTime" call for each displayed date, which according to the VB documentation ought to display the dates according to the regional settings.
Quote:
Also, looking at one of the script, it seems that while we check to see if the database exists, the script doesn't bother to verify that it was actually sucessfully created. This is not a good idea, since it not only doesn't inform you if the type of file you tried to create is unavailable or that it failed.
If you can tell me the call to make to verify that the database exists and is a correctly formatted database I will be happy to make it. However it sounds from Linda's post that the file was not there at all, which is what my (rather simple) check was supposed to detect. I am making the assumption that if the "create database" call succeeds then it has in fact created a database.
Quote:
It could be that for some reason installing the MDAC 2.5 was only enough to give you access to creation, but that the ODBC drivers are still missing (I thing ODBC is a seperate package).
I am not sure why you are worried about ODBC. You may remember from the earlier posts about databases that the whole idea here was to bypass ODBC. The calls open the database by name (file name) not by ODBC data source name. Thus the availability of ODBC should be irrelevant to the exercise.
Anyhow, it did work when I installed it from one other world ... although isn't the db created supposed to be Access compatible? I can't seem to open it, at least.
Yes it certainly is, however I also seem to recall from earlier discussions that there was an incompatibility between the engine type 5 and Access 97. Ah, the joys of Microsoft products!
Linda, if you open the plugin (you can do this from the Plugins menu by selecting the plugin and clicking Edit) and then change the line which has "Engine Type=5" to "Engine Type=4", and then save and reinstall, you should get an Access 97 database. See this forum post, last entry on the first page:
However you will then need to delete your database file and let it get recreated as it won't be backwards compatible, ie. the damage is done once it is created.
It is probably worth it in your case to get the earlier engine, because then you can just open the database in Access and play around with it.
This is what make me nervous about using Microsoft.Jet.OLEDB.4.0 as the provider field without first having some why to make sure that v4.0 is installed and more importantly, that the Access driver is installed.
It makes me nervous too, but the checks in the plugin to see if "CreateObject" succeeds should partly guarantee that the drivers are there.
Also, distributing the database drivers is both an overhead, and possibly not legal, however I have put pointers to the pages where they can be found on the plugins page.
1) The date format: It appears to display properly (according to my system settings), I was just confused by the fact that it has to be entered as mm/dd/yyyy
2) I deleted the old db, downloaded the updated plugin and changed the engine to 4. However, upon reinstalling it I once again get the error of it not creating the db and then saying the file doesn't exist. Maybe the plugin should include a 'createdatabase' command?
I am successfully entering events using dd/mm/yy, eg.
event boxing day AT 26/12
futureevents
Event 'boxing day' AT '26/12' added to the database
--------Future events--------
#2: water garden AT 20/11/02
#1: Christmas AT 25/12/02
#4: boxing day AT 26/12/02
As for the install problem, there was a recently-reported problem that timers in plugins are not working properly. Perhaps this is related to that? I saw the same thing myself when I opened the world from scratch.
However once the database is created the problem should go away (for you) for good.
Ah, I thought I had to stick to the date format listed in the example.
But I can't open it in Access yet because right now I am unable to get the database created. I've installed and reinstalled the plugin a few times, in different worlds, but no luck.
In all worlds except one nothing happens (although it does install, because if I type events it reports it can't find the db file), and in one world it is reported as installed, but it also reports it can't find the db file.
Update: Okay, deleting the files in the 'state' directory allowed me to reinstall the plugin and get the db created.
Well, at least it did work eventually and now the created db does work in Access.
I had to uninstall the plugins from all worlds, save the worlds and clean out the state directory, and then it seemed to work. So I guess that removed all traces of the previous install.
And okay, now I have the hang of the dating. I was confused by how it would return my system dating even if I entered in another format, but now its sorted out. It works whether I use dd/mm/yyyy or yyyy/mm/dd to enter.
Each plugin has an "id" which is near the start of the plugin file. In the case of the Calendar it is "805364a6309ecdf2b4e366cf". Removing the state files with that in the second part of the file name would have been sufficient. In my case the file was called:
The first part of the name is the world's ID, the second part the plugin's ID.
Thus, this command would have worked (in a DOS window):
del *-805364a6309ecdf2b4e366cf-state.xml
However *why* you had to do that isn't totally clear.
I am glad it is now working, hopefully it will now solve the problems you wanted solved. You can change the number of days in the future showed when you type "events" by modifying the number "14" in about the 3rd line of the plugin.
With respect to ODBC... There are only as far as I know about three ways to install database drivers: 1. with programs like excel, word, etc., 2. Individually by downloading them or 3. as a basic set that comes with the ODBC install. The fact that these prepackaged with the OS as 'part of' ODBC does not guarentee that they are there. The options... Install ODBC even if you don't plan to use it, hope you can find a download of the specific driver or install a big MS product you inho could have found a better option to replace. lol So yes, ODBC has nothing to do with how we are accessing them, but it does have an indirect influence on what types of files you can access.
With regard to the possible version conflicts.. I have seen a few cases where the driver name was employed as the access point, but only for 1-2 types. I am not sure how it works exactly, but it is version independent. The whole implimentation is imho a major mess compared to installing the correct driver with the program that will use it. lol
I am having similar problems as Linda. I see nothing printed like this:
Quote:
Plugin Calendar installed.
Database 'C:\Program Files\MUSHclient\worlds\calendar.mdb' created.
Table 'todo' created.
Table 'event' created.
Database is: C:\Program Files\MUSHclient\worlds\calendar.mdb
Nothing to do.
No events.
Type 'calendar:help' for help.
I get this message when I try to enter an event: Could not find file 'C:\Program Files\MUSHclient\worlds\calendar.mdb'.
I have updated my DLLs withe the link on your plugins page and have VBscript Version 5.6. Was wondering if you could enlighten me on what to do?
Maybe it has got confused and thinks the database is created already. Sounds like it. Try removing the plugin, then going into the plugins "state" directory (subdirectory under plugins) and removing files with "805364a6309ecdf2b4e366cf" in the name. This will be the state file for the calendar plugin.
Then reinstall the plugin, and it should start again from scratch.
Sorry to say the same thing happens. Hmm. Maybe you could put together a little .zip with the .mdb files I need? I'm at a total lost on what to do. Never had this kinda trouble before from any of your stuff.
Oh yeah, great job on an awesome MU* client. Use to be a diehard Portal fan, then I got introduced to your wonder client and been an addict since then.
Hmm - sounds like it is related to the known bug with timers in plugins, as the database is created by a timer set up by the plugin in its initialisation.
I have made an empty database, and zipped it up. You should be able to find it at: