In order to facilitate distributions of MUSHclient in situations where you may not want to run the installer (eg. when using a thumb drive, or when using Ubuntu), I have repackaged version 4.43 so you can (optionally) download the install as a complete directory.
The .zip file contains the MUSHclient directory and all relevant subdirectories (eg. plugins) already in the correct places. So, all you need to do is unzip it and run MUSHclient.exe. The first time around the spellchecker database will be built - this will take a few seconds.
MUD administrators may care to take that directory, add in a world file specific to their MUD (eg. with the IP address and port filled in), make that the default world to load, and distribute that as a "custom client". You may also want to add any relevant or custom plugins to load automatically for that world file.
If you do that you may want to reset things like the "first time flag". I did that by opening the preferences database with the "SQLite Database Browser" program (http://sqlitebrowser.sourceforge.net/) and editing the values in the "control" table. An alternative would be to use the sqlite3.exe program and type this:
C:\Documents and Settings\Owner\Desktop\MUSHclient> sqlite3 mushclient_prefs.sqlite
sqlite> UPDATE control SET value = 1 WHERE name = 'First time';
sqlite> .quit
The sqlite3 program is available from: http://www.sqlite.org/sqlite-3_6_16.zip
Use the installer to make a copy of MUSHclient on the desktop
Open MUSHclient (the installer offers to do this)
Wait for the spell check dictionary to be built (about 2 seconds)
Close the various welcome and help dialogs
Move the program around on the screen, and resize the main window, to taste
Change any global prefs you might want, like "Notify (errors) to output window", and "confirm before closing MUSHclient".
If you were making a custom client for a particular MUD, this would be the time to add a world file for your MUD, with the IP address, port and MUD name preconfigured. You might also add it to the global preferences "worlds to open at startup".
Also install any plugins that you might require, and load them into your preconfigured world file.
Close MUSHclient so screen positions and toolbar locations would be written to mushclient_prefs.sqlite and MUSHclient.ini.
(Optional): I deleted a few files in the MUSHclient folder that I thought would confuse new users:
mushclient.ico
lua5.1.lib
uninstall.exe (not needed really since this is an installer-less version)
Create a "logs" directory
Use the "SQLite Database Browser" program (http://sqlitebrowser.sourceforge.net/) to edit a few entries in the "control" table to make relative pathnames (you can't do this inside the program as it saves full pathnames). Alternatively you could use the sqlite3.exe program in a "command" window to do the same thing. Get this from: http://www.sqlite.org/sqlite-3_6_16.zip
This is how you would do it with the command-line version:
sqlite3 C:\Documents and Settings\Owner\Desktop\MUSHclient\mushclient_prefs.sqlite
UPDATE prefs SET value = '.\logs\' WHERE name = 'DefaultLogFileDirectory';
UPDATE prefs SET value = '.\worlds\' WHERE name = 'DefaultWorldFileDirectory';
UPDATE prefs SET value = '.\worlds\plugins\' WHERE name = 'PluginsDirectory';
UPDATE control SET value = 1 WHERE name = 'First time'; -- put first-time flag back
.quit
In the "spell" subdirectory I deleted the 3.44 Mb file "spell.sqlite". That will be rebuilt when the player starts MUSHclient for the first time, and it adds somewhat to the .zip file size.
Use WinZip or some compression program of your choice to make an archive of the resulting folder, making sure you preserve the directory structure.
Something I just figured out while working on "another project"...
7-zip File Manager (which I use anyway for decompressing stuff like .bz2 or .tar.gz files) can open the NSIS installer archive/exe directly.
So for those portable preferring people, or if you need an older version of a file (available at http://www.gammon.com.au/files) for "another project" (anyone curious yet?), you can just grab them that way.
Nah, I should be happy with it by sunday (east coast US) for you to beta...
I got a new 'pooter! Windows 7! :D
No winhlp32... :|
I'm doing a lua script to generate chm help files for ya (okay, for us... ...me.) So far I've gotten a compiled chm with version 4.41 help in it (the most current documentation.sql available). Just working out table of contents and index issues.
The Lua script has 2 requires, lfs (luafilesystem) and luasql. I figure it may be a trivial thing to swap the db engine from sqlite3 to mysql for you.
The overides for WinHelp -> HtmlHelp in MFC look minimal. I've found numerous sites that have sample code that I'll link you to later.
To the best of my knowledge, I've preseved all the context id's. I'm pretty sure I've figured out what makehm.exe does, and how to correctly generate a .hm mapping so shift+f1 should work. We'd need the WinHelp -> HtmlHelp changes to actually test them though.
I made a change to the schema of the database. I've added a table that basically serves as a replacement for the .cnt file. The documentation is all database-driven now. The script will make the required .hm, .hhp (like a .hpj winhelp project), and other files (.hhc (cnt) and .hhk (index)) to compile. I'll give you a .sql file to create and import the table.
The .htm files themselves are being redone in xhtml 1.1/transitional and css. (Boo tables. Yaaa divs!)
I've found a couple small gotcha's in the source code.
docgen's links around the buttons/chicklets reverses the href and alt values, so they're actually all broken. But docgen/makehelp.bat/makehm.exe May all be antiquated if you like the changes.
There's a "kludge" in methods.cpp that loads the hand cursor over hyperlinks from winhlp32 which can probably just go away at this point, but needs to be rethought at the very least.
I don't know if you do your own hosting or not... If you have direct access to the .php and mysql database that gammon.com.au/scripts/doc.php runs. Err, if the php hits the database or if it's translating the path to static html files... Since with the new table we're not limited to 3 fields in the .cnt file (toc depth, display, file name), this script generates "functions/GetWorld.htm" instead of "FNC_GetWorld.htm"... so either docgen will live on, the php file could be updated. I'm not positive that it actually needs to change.
I can make a new copy of the database. Give me a few minutes - I have upgraded my Red Hat Linux server to Ubuntu, principally because the disk drive was starting to sound like a jet engine getting ready to take off. Hasn't failed yet, but must be a mtter of time ...
Yeah, the context IDs are probably the only tricky thing to make it bring up the right help for the right dialog box. But I think the database has them right, or if not, there is a constant to add to them.
Yup, I've already got the docs in a sqlite db. :) (I was the one that asked for the last update on june 30)
Sorry the last bit was me rambling outloud...
Question:
Does http://www.gammon.com.au/scripts/doc.php?general=scripting hit a mysql db that you control, or do you use docgen to make the html files which you ftp up to a server someplace? If the former, the doc.php wouldn't need to change. If the latter, my script changes your naming convention from FNC_GetInfo.htm, DLG_whatever.htm; to functions/GetInfo.htm and dialogs/whatever.htm.
Hooking up MFC links:
http://simplesamples.info/MFC/HTMLHelp.php
http://support.microsoft.com/kb/191118/EN-US/
http://msdn.microsoft.com/en-us/library/aa733986%28VS.60%29.aspx
Oh regarding the sqlite and mysql conversion statement...
The script starts with require "luasql.sqlite3", changing that to "luasql.mysql" and changing the db:connect(DBpath) to db:connect(DBpath, username, pw, server, port) should be all you need to generate a chm for future versions. I'm making a point to use sql statements that work in both engines.
I'm guessing but I think your current build process basically
Calls docgen.exe to generate the rtf
Calls makehelp.bat, which calls makehm a bunch of times and then calls hwc.exe to compile the .hlp file using static .hpj and .cnt files.
With the new stuff you'd:
Call HTMLhelp.lua which connects to a database, generates the html files, generates the help context ids, generates file lists, generates a Table of contents, generates the index, and then calls hhc.exe to compile the .chm file.
hhc.exe is part of the HTML Help Workshop, which you can download here: http://www.microsoft.com/downloads/details.aspx?FamilyID=00535334-c8a6-452f-9aa0-d597d16580cc&displaylang=en
... plus a couple of extra bits to specify the database server location, username, password etc. Basically I bang the whole SQL into the server database, which is therefore a copy of what I have locally .
I use the local copy to generate the help files, and the HTML files (when generated). The server copy is used to serve up pages like the one you mentioned.
The copy process from my local copy to the server copy is effectively the "handover" when a release goes live.
Calls docgen.exe to generate the rtf
Calls makehelp.bat, which calls makehm a bunch of times and then calls hwc.exe to compile the .hlp file using static .hpj and .cnt files.
It:
Generates the .rtf file help.rtf from the database
Calls WriteMapFile (see code snippet) to quickly write out the mapping file help.hm by doing a few selects (makehm is not used).
Calls hcw.exe to read in the help.hpj file (copy below). This generates the mushclient.hlp file.
WriteMapFile (db);
// generate help file
printf ("Generating help file ...\n");
char * args [] =
{"hcw", "/C", "/M", HPJ_FILE, NULL };
if (_execvp (args [0], args) == -1)
perror ("Invoking help compiler");
}
This is the help.hpj file:
; This file is maintained by HCW. Do not modify this file directly.
[OPTIONS]
COMPRESS=12 Hall Zeck
LCID=0xc09 0x0 0x0 ; English (Australian)
REPORT=Yes
CONTENTS=DOC_CONTENTS
TITLE=MUSHclient help
COPYRIGHT=Copyright 2003 Gammon Software Solutions
HLP=..\mushclient.hlp
[FILES]
help.rtf
[MAP]
#include help.hm
[WINDOWS]
main="",,27904,(r14876671),(r12632256),f2
You can see from the above that once you have help.rtf and help.hm files, the help generation is pretty straightforwards.
The contents file is totally a manual process. However after a major change I might do the subsections with a few selects as documented in comments in the docgen program, like this:
select concat("3 ", command_name, "=CMD_", label) FROM commands ORDER BY command_name;
Stuff like the high-level contents, is simply something I did in a text editor. (It practically never changes).
All the cross references are messed up. Some use the "see_also" field, some have doc_name's. Some of the doc_name's are inconsistent (BlendPixel and FilterPixel are grouped with utils, not miniwindows... ?) Some of the doc_names are null.
There's a few orphaned help topics that aren't in the toc, which is generally okay. There's a topic in the toc that doesn't have a help file (DockToolbarNextTo, apparently killed off - google only shows it in the 4.29 diffs file) - and that causes hhc.exe to barf.
I don't mind standardizing the data - ignoring see_also and related_dialog in favor of having consistent doc_name's. Would you object to having a .sql with the full db (in sqlite syntax) available that you can munge and import into mysql? I won't alter the table schema so the php page won't break.
I'm a little concerned about putting a lot of energy into this when you had posted way back when that you didn't have the energy for it. I'm trying to have all my work cause as little work for you as possible. :)
BlendPixel and FilterPixel do not, strictly speaking, need a miniwindow, so I put them into utils. They simply modify a number giving another number.
You can probably ignore see_also, for one thing it isn't really third normal form, the way I did it. The idea was that see_also would list related things, perhaps not necessarily in the same document (BlendPixel would be an example).
However, discarding any orphans in see_also you should be able to get reasonable results.
Quote:
Would you object to having a .sql with the full db (in sqlite syntax) available that you can munge and import into mysql?
I don't quite understand the question. You mean your modified version, or something else?
Yea, if I go through and sort out all the stragglers so that cross links via doc_name are accurate, would you hate reimporting the whole db; opposed to sql for just the CREATE/INSERTs for the toc table and now a create view...
oh, I made a view that does a union on the 5 major tables (not errors) so I could consistently get to a filename id, title, summary, type (command, func, dialog, general, lua), and doc_name category... I had trouble remembering which table had a name vs command_name vs dialog_name... etc. Those are the 5 values I need for each cross reference link.
I'm working over some kinks with the cross references. I plan on tweaking the index into something more friendly as well, and will probably hit the Table of Contents while I'm at it...
If you wanted a preliminary look, or a chm to test code, context help, and getting rid of winhelp, yadda yadda...
12030 is the help context id to pull up.
ms-its: is a literal string (protocol handler)
the path will change accordingly.
Solving the "exe looks for the .hlp" issue is earlier in the thread. All the html help in mfc links give the overide code.
It's weird that you're getting no pages. On one of the error pages, would you mind right clicking, going to properties, and give me the url that it's trying to hit?
I'm working on filtering the unhelpful help pages out of the index and full-text search (i.e. GoToUrl has only menu, hotkey, and summary... btw, I can't figure out why you'd grab the mouse, highlight a link, and then go to a menu and select a menu item to open the highlighted link... instead of clicking on it...)
Also, I'm putting the cross-references in the index instead of the page content. The flow of "Go to the index, find a topic, open the topic to find references" seems to defeat the purpose of having an index.
After you install the Microsoft security update MS05-026 (KB896358), CHM help file topics may not display correctly if the file the help file was received via e-mail, or downloaded from the Internet. Instead, an error message such as ‘Action cancelled’ or ‘DNS error’ is displayed.
Recent Microsoft security updates include changes to the InfoTech protocol, which prevent CHM help files from being displayed correctly if the CHM help file is blocked by Windows Attachment Manager. Even if the security warning is acknowledged, the help file is not displayed correctly. The problem also arises when a blocked CHM help file is opened via the HtmlHelp API.
Unblock a blocked CHM Help File
1. In Windows Explorer, right-click the blocked file, and then click Properties.
2. In the General tab, click Unblock.
Open a blocked CHM Help File
1. Double-click the help file in Windows Explorer.
2. If a security warning dialog appears, uncheck the box ‘Always ask before opening this file’.
3. Click Open to open the help file.
See if that help?
other suggestions at http://www.help-info.de/en/xml/maml_troubleshooting_hh.xml
If this is the case, the problem is because you got the file from my website, and shouldn't affect the installed chm.
Yea, Thank You MS for trying to save me from myself. Don't fix the exploitable holes, fix the user... :| Stupid Unblock button.
The indenting on code samples is part of the css... It can change.
The wonky cross references are because of the whole See_also vs doc_name vs cascading cross refs (general_doc_xref table) kind of stuff. I've made more headway on that.