FB II Compiler







Disk I/O














Made with FB


Prevent PG apps from changing their own resources

It's not complex. If you are using the built in help system there is almost nothing to do. When the help file is opened, set gResRef to equal the resoure reference for the help file. Individual resources are read from your application the first time they are needed, but stored in the help file when changed. It was George Beckman's idea. He says it works great.

STAZ ~)~

I have an update on PG projects and where PG is going to store resources, PG application dates changing with each run and Network Versions of software. This is a long post...sorry.

I spent a good while on the phone with Chris Stasny and need to apologize before I start as I will probably misquote him.

It _is_ possible to have PG save its "PG Magic" information somewhere other
than the Application's Resource fork. If you already use PG Help it can be done with two lines of code as Mars predicted:

In the HFS Util.FLTR find the following...

LOCAL FN openHelpFile
' Create or open the application's help
' file.

<snip> about half way down find this

LONG IF LEN(helpName$)
  resRef = USR OPENRFPERM(helpName$,SYSTEM(_aplVol),_fsRdWrPerm)
  LONG IF resRef > 0
    gHelpResRef = resRef
    gResRef= resRef <<<========= and add this

<Snip> near the bottom find this...

LONG IF resRef > 0
  gHelpResRef = resRef
  gResRef= resRef <<<========= and add this


Compile it and that's it. It works. No need to do anything to the existing help file. Just start using your app and it will run as always.

What happens...
When the app starts the PGGP init routine runs and sets gResRef to the Application's resource file. The file is opened and stuck in the resource list, on top. Then the help file is opened. It is stuck in the resource list, on top. From then on, (regardless of the resource positions in the list) the app tries the Help File resource when it needs a button or window, etc. If it finds it it uses it. If it can't find it, it keeps searching down the resource list. It will find the needed resource in the App resources and load it. But, and here is the good part, when it writes it it will write to the Help File resource fork. The Help File resource builds dynamically. I watched this happen over local talk, booting the app from another computer. First time the app calls for a window or dialog, the little AppleTalk arrow thingies go to work. The next call for that same window, AppleTalk is silent and the window is built from the local drive.

The good and the bad of this...and this is mostly my thinking, so don't blame Chris for this...

If a user's resource gets trashed and they call, you might get away telling them to throw the help file away. A new one will be created on the next run and all will be well, _except_ they don't have help anymore. So they probably need to re-install. But if you do not actually use help, everything will be fine.

If you do a clean system install, and you stored ID numbers in resources, the user will be grumpy because they have to dig out info. (Chris mentioned that one). But if the app gets crunched, then they have to dig anyway after an install.

If you make your app a shared app, the app date will cease to change.

If you make your app a shared app, it becomes a true Networked version in that you will get your last window placement rather than the last placement on the server copy.

If you send out upgrades and have changed something in any window, you need to make sure the help file is wiped clean again.

I foolishly used the same help file name for version 3.3 and Beta 4.0 of one of my apps. When 4.0 changes the help file as above, 3.3 doesn't like that help file and very strange window overlays happened.

If you have nine zillion windows and the like they will be being duplicated in preferences. I guess you could hack around this with resEdit or Resourcer.

I hope this leads those of you with PG interests closer to some answers.

p.s. I don't know if I am all that enflamed with networked versions, but I work in a district where this is discussed and loved by some. The great part is upgrades are placed on the server once and the clients never know about it. Be warned as per the upgrade plan noted above, this could cause problems if the client help.file is not altered or returned to just a help file. The new app, will never look in the new app resource file for the new window information as the old window attributes are still in help. Fix a bug of say a editable field being made static and the user will still be moaning and groaning.


Concerning the Shared flag in Application Information...

I am finding that you _can_ set the flag and double boot an application. I can't believe I am saying this because I have tried this several times, but it is true, PG or no PG. I think my problem was that I always set the flag in resEdit and then compiled the project, tried it and it failed. That was because in the compiling, the flag was set back. When I open a compiled version and then set the flag, it will double boot. So, thanks again for giving me fuel to feed the testing fire.


I snipped out the message 'cause it was so long :) but my question/suggestion is about things like updates or other situations where the help file might need deleting/restoring/etc. Couldn't the app itself run a check against the help file? For instance, if there were a version resource that the app could check. If the version was less than the app's the app could bring up a dialog saying "Updating current version" or something and rebuild the basic resources to go in the help file from the app.

I also think that the thing about the prefs getting corrupted might not be so bad. If the user does have to dig out numbers, that isn't so different than if some other app's prefs had gotten trashed. Many software titles I have store IDs and such in the prefs.

Last thing. Why not put the help resources in the app itself. Then, if the prefs need rebuilt the app can do it. I'd include the option _not_ to move all the help stuff, though, too. Not everyone wants the help that badly (I wouldn't want 1 meg of help over localtalk).

This probably doesn't do more than voice the obvious, but if there is some problem with this idea it'd be nice to know before I tried to implement it ;)