Extra Map IDs found in .chm output

[brianlaing]

I've generated an MS HTML Help project in Flare 3.1 and while it looks fine and actually works correctly, when you look at it internally, there are extra Map IDs.

For example, here's the end of the map file:

// Saved Settings area
//
#define ID_db_save_as 90000
#define ID_db_rename 90010
//
// Status area
//
#define ID_db_status_device 91000
#define ID_db_status_supplies 91010
#define ID_db_active_jobs 91020
#define ID_db_completed_jobs 91030
//

These are verified in the Flare 3.1 API Tester as working.

However, when I use FAR V4.2.0 to check the final .chm file, I get this:

debug>> Check Context: 0x015F90 (90000) -- saved_settings/db_save_as.htm
debug>> Check Context: 0x015F9A (90010) -- saved_settings/db_rename.htm
debug>> Check Context: 0x016378 (91000) -- status/db_status_device.htm
debug>> Check Context: 0x016382 (91010) -- status/db_status_supplies.htm
debug>> Check Context: 0x01638C (91020) -- status/db_active_jobs.htm
debug>> Check Context: 0x016396 (91030) -- status/db_completed_jobs.htm
debug>> Check Context: 0x016398 (91032) -- paper_output/job_type/db_secure_print.htm
debug>> Check Context: 0x016399 (91033) -- paper_output/job_type/db_saved_job_e.htm
debug>> Check Context: 0x01639A (91034) -- paper_output/job_type/db_delay_print.htm
debug>> Check Context: 0x01639B (91035) -- paper_output/paper/db_paper_size.htm
debug>> Check Context: 0x01639C (91036) -- paper_output/paper/db_adv_paper_select_e.htm
debug>> Check Context: 0x01639D (91037) -- paper_output/paper/db_new_custom_size.htm
debug>> Check Context: 0x01639E (91038) -- paper_output/paper/db_edit_custom_size.htm
debug>> Check Context: 0x01639F (91039) -- paper_output/paper/db_covers.htm
debug>> Check Context: 0x0163A0 (91040) -- paper_output/paper/db_trans_separators.htm
debug>> Check Context: 0x0163A1 (91041) -- paper_output/db_booklet_creation.htm


Note that the last ID is 91030 in the map file, and that Flare 3.1 knows it's the last one but FAR is reporting additional IDs - one for each of the already established topic ID links. It reports IDs from 91032 to 91090, repeating each of the IDs I have in the map file but giving them a second set of IDs.

Checking in the Flare project's Output > [My User ID folder] > Temporary > UPD Help PCL > Content > map_all_help_buttons_v7a.hh (this is the name of the map ID file used in the project), this is what Flare used to build the .chm:

// Saved Settings area
//
#define ID_db_save_as 90000
#define ID_db_rename 90010
//
// Status area
//
#define ID_db_status_device 91000
#define ID_db_status_supplies 91010
#define ID_db_active_jobs 91020
#define ID_db_completed_jobs 91030
//#define MadCap_Id_91031 91031
#define MadCap_Id_91032 91032
#define MadCap_Id_91033 91033
#define MadCap_Id_91034 91034
#define MadCap_Id_91035 91035
#define MadCap_Id_91036 91036
#define MadCap_Id_91037 91037
#define MadCap_Id_91038 91038
#define MadCap_Id_91039 91039
#define MadCap_Id_91040 91040
#define MadCap_Id_91041 91041
#define MadCap_Id_91042 91042
#define MadCap_Id_91043 91043
#define MadCap_Id_91044 91044
#define MadCap_Id_91045 91045
#define MadCap_Id_91046 91046
#define MadCap_Id_91047 91047... and so on until 91090

Notice after 91030 that MadCap is assigning id's.

Am I doing something wrong? It's worked fine up until I upgraded to 3.1.

I'd be much happier if these additional IDs weren't in the .chm file to potentially screw things up (and me get it in the neck from Development).

Cheers and thanks!

Brian

[blaing]

Replying to my own question to put it back towards the top of th elist.

Has anyone found a solution/workaround? I don't want this to come back and bite me later as a problem.

Has anyone else checked an output .chm to see if Flare is adding additional ids?

Thanks,
Brian

[wclass]

I have also seen this, but I've not tried to "fix" it, and I cannot guess what it might be for. So far it hasn't broken anything, but I think an explanation as to why it has been done would be nice.

All the Madcap generated IDs are unique, and all the alias links created are to existing topics, so at first glance it looks like it would make no difference (but that begs the question, why do it in the first place).

However, what if my application had included a new screen that I had overlooked and not updated the *.h file, and it happened to have a help id that Madcap is using? That could happen since our applications all have an automatic way of generating help ids. If a user presses F1 then the help that is displayed would be one of my existing topics, instead of defaulting to the first page.

I am now curious about an explanation.