Remove Help File Caches

General
#1

I know this has been discussed before but I can’t seem to resolve the problem.

I have added a new help file for my app and am using AppWrapper 3 to link it to the app. But each time I run the wrapped app I get an older (sometimes much older) version of the help file.

I have trawled the web and tried the following to try and rid the machine of all its help cache files:

  1. Delete all instances of the xxx.app file
  2. Terminal: killall helps
  3. Terminal: rm -rf ~/Library/Caches/com.apple.help*
  4. Terminal: Sudo Purge
  5. Restart
  6. Build App in Xojo
  7. Wrap App in AppWrapper

But still the result is an older version of help.

So…help!

#2

One of the great things about this forum is sometimes it makes things work - even without a response. Suddenly the help file is correct - and I have no idea what I did that was different…

#3

To clear the help cache:

  1. Close your app
  2. Issue these commands in terminal:

killall helpd rm -rf ~/Library/Caches/com.apple.help*

#4

I am struggling with this again. I cannot get rid of the old help files from the cache.

I have tried the following, in order:

  1. Remove all copies of the .app from the development machine (except in applications). Close app.
  2. Terminal killall helpd
  3. Terminal rm -rf ~/Library/Caches/com.apple.help*
  4. Restart machine
  5. Build app in Xojo
  6. Open AppWrapper 3. Delete Help. Add new Help. Publish.
  7. Wrap app.
  8. Drag wrapped app to Applications - allow it to overwrite old version.

When I run the app it still has the old version of help files attached.
Any ideas what I am missing.

#5

Have you tried restarting? I’m not kidding btw.

App Wrapper does the two terminal commands when it wraps and includes help files in the application.

I’ve spent years on trying to make it easier to add proper Apple help to an application, while it feels like Apple work to make it harder.

For my last two projects I’ve not bothered wasting my time. In one project we simply opened a web page (heck it’s what all the competition do nowadays, only ours isn’t ad infested). On the other I simply used an HTMLViewer and floating window.

I believe in doing a job properly and at the very least trying to make my Mac applications look and feel like Mac applications should be, but the Recent Help Viewer is an absolute pig. I too have wasted far too much time in trying to use it and therefor have given up. After all, our competitors that Apple promote don’t even have help, their help takes you to an ad page to buy the pro version of their apps directly from their site, cutting Apple out of the equation. It seems that Apple’s cool with that.

#6

I think Apple’s now caching these in memory, rather then somewhere on disk (why they feel the need to cache, I have no idea). Seems to be the situation with some other APIs, where deleting files doesn’t have any effect any more.

#7

there is a helpd daemon
/System/Library/PrivateFrameworks/HelpData.framework/Versions/A/Resources/helpd

#8

Multiple restarts - at different parts of the process - no avail.
Helpd doesn’t seem to identify any problems.

I took a look at the Resources of the app. I can see the appropriate app.help bundle and its contents are correct. However when I click the app.help bundle it brings up the old help file, despite the contents being the new file.

The contents of the plist also seem correct.

Reading the Apple Help guides, it seems the app should call AHRegisterHelpBook (both for Carbon and Cocoa apps - though the words are a little ambiguous).

Not being a wiz at declares, is this something that could fix the problem, if I knew how to do it?

#9

Ah, I thought, why not use Terminal Installer ( sudo installer -store -pkg <> -target /) to install the app into Applications. Maybe that would trigger the link to the new help file.

Alas no, that didn’t work either. Nor did following that with a System Restart.

Looks like the folks at Xojo don’t use Apple Help either.

#10

Using Apple help would require us to have at least 2 different help systems - one for OS X and at least one for everything else

#11

According to the following Apple document, this isn’t needed on Cocoa if the plist keys are correct.
https://developer.apple.com/library/mac/documentation/Carbon/Reference/Apple_Help/#//apple_ref/c/func/AHRegisterHelpBook

#12

I wrapped up a bunch of declares into a drop in module.
http://www.ohanaware.com/appwrapper/HelpExample.zip

The module “AppleHelp” contains 3 main functions.

  • addHelpMenuitem( toMenu as menuitem ) - This adds a “Application Help” menuitem to a menu of your choice.
  • register as boolean - Uses the function to register any help books in the bundle.
  • show( withAnchor as string = “” ) - Displays either the main page if no anchor is specified or the specified anchor. This function will also call register if it’s not already been called.

At it’s very simplest, you should be able to display the Apple help by calling “AppleHelp.show”, make sure that your application is wrapped with App Wrapper (so that the correct plist keys are specified).

Let me know if this makes any difference or not.

While checking the console logs I found the following message, which suggests that El Capitan is preventing App Wrapper from killing the Help Daemon. Great!

6/9/16 10:16:52.015 AM App Wrapper[2069]: killall helpd: No matching processes belonging to you were found
#13

huh
helpd shows here in activity monitor as run by me
but then I did kill it as root the other day & havent rebooted so … :stuck_out_tongue:

#14

Many thanks Sam. I’ll let you know how I get on.

#15

[quote=270718:@Norman Palardy]huh
helpd shows here in activity monitor as run by me
but then I did kill it as root the other day & havent rebooted so … :P[/quote]
I think SIPs is preventing App Wrapper from killing it, because App Wrapper didn’t launch it. Hopefully the declare code will help James. If not, then we’ll have to think again, or go for an alternative solution.

I used to think I was a step above the competition because my apps used Apple’s Help Viewer and they didn’t, now I think I may have been a fool for wasting all that time fighting a process that gets more and more broken with each release.

Personally, for my next project, I’m going to go with my own Help Viewer.

Look forward to it mate.

#16

As you noted Apple does seem intent on making it harder & harder to “do the recommended things”
So people just stop doing them
Skip the App Store & you can almost forget all the other distribution rules too

#17

Good news and bad news. Good news is that something did trigger recognition of the new help file, but bad news is that it might not be the register command.

I continue to get problems on my development machine - despite using the register command - it doesn’t always pick up the new version of the help file.

At least when I copy over to a non-development machine it seems to pick up the latest version. So I guess I just have to trust that when the new version goes out to customers that they don’t get the same problems.

Thanks again Sam for all your help. I’d buy you a tinny if I was in the right country.

#18

Hopefully one day mate :slight_smile:

There’s a couple of things to note about the Register command that I’ve read on the Apple docs.

  • It’s a Carbon only function, it doesn’t exist in Cocoa so it may not work in future builds of the OS X.
  • According to one document, it’s not needed if the plist keys are present.
  • According to another document, it’s not needed if you use the AppleHelp.show( ) function.

But it’s there incase it does help and the code I’ve written will automatically call it when using AppleHelp.show (with no anchor being passed).

Thinking about there’s only a couple of advantages to using the Apple Help over your own.

  • The Help Index is used by Spotlight & the “Search Help” menuitem that gets automatically added to the Help Menu.
  • It uses the same central interface as Apple’s own applications, and a handful of 3rd Party applications.

Everything else (including your own search function) could be accomplished with a 3rd party control/window.

#19